Stream: implementers
Topic: How to communicate the name of an identifier?
Tim Berezny (Dec 02 2018 at 19:04):
What is the best way to communicate programatically the "name" of an identifier (e.g., BC Driver's licence, SystemX Patient ID, Ontario HCN, etc...)? IF I understand the identifier dataType correctly, you have to go lookup the name of the identifier at the "system" uri, which may or may not be programatically retrievable in the absence of the receiving system having a pre-defined awareness of the system.
What is the best way to communicate the name of an identifier (in a human and machine readable way?
Richard Townley-O'Neill (Dec 03 2018 at 01:38):
Looks to me as if the only option is an extension.
Identifier.type seems to be more for "Driver license" than for "BC Driver license".
The extension reference is rather indirect and assumes that the valueset is known and is useful.
Peter Jordan (Dec 03 2018 at 02:53):
Try using the NamingSystem resource.
Brian Postlethwaite (Dec 03 2018 at 09:49):
I encourage the use of identifier.Type.Text for the human label
Brian Postlethwaite (Dec 03 2018 at 09:50):
The drivericense will be in the coded value, not the free text in type.
Richard Townley-O'Neill (Dec 04 2018 at 00:25):
@Brian Postlethwaite do you think that Identifier.type is meant to be specific enough to say "BC Driver License" rather than just "Driver License"? See http://build.fhir.org/datatypes-definitions.html#Identifier.type
Grahame Grieve (Dec 04 2018 at 01:25):
no I don't think so. type = there can be more than on thing with these properties
Brian Postlethwaite (Dec 04 2018 at 01:36):
I was suggesting in the text value, not the coding values (which can have many different values)
Richard Townley-O'Neill (Dec 04 2018 at 05:24):
I think of the text as another way of saying what the codings do, not a way of saying something different. So the text can be "license for driving vehicles" but not "BC driver license".
Grahame Grieve (Dec 04 2018 at 05:35):
BC drivers license would go in assigningAuthority. display
Richard Townley-O'Neill (Dec 04 2018 at 05:41):
Wouldn't Identifier.assigner.display hold "Issuer of BC licenses"?
Grahame Grieve (Dec 04 2018 at 05:42):
if we were being truly pedantic, yes. but in practice, people aren't
Yunwei Wang (Dec 05 2018 at 15:58):
Identifier does not have assigningAuthority property
Eric Haas (Dec 05 2018 at 18:26):
(deleted)
Grahame Grieve (Dec 05 2018 at 20:04):
.assigner is waht I meant
Tim Berezny (Dec 10 2018 at 17:18):
I like the simplicity of @Brian Postlethwaite approach ;)
What i'm think of is if the sending sending system is sending over a bunch of identifiers that are not necessarily defined or registered. There are cases too where the "issuing authority" is not necessarily name of the identifier. For example, "band #" (for native populations) isn't issued by "band".
Other types of identifier titles might be like, from a SPECIFIC IT system (or a specific implementation of a specific IT system, i.e. EMR_X at Organization_Y). an individual could have identifiers across a number of these various systems and identifier types.
Lloyd McKenzie (Dec 11 2018 at 02:32):
I think @Brian Postlethwaite is correct. "BC Physician License number" definitely belongs in Identifier.type.text, not Identifier.assigner.display. Assigner is about the organization, not about the kind of identifier. The same assigner could well assign multiple identifier types, but the display would be the same for all of them. On the other hand the type.text allows you to convey a more nuanced type for the identifier than the code provides. "BC Physician License number" is a perfectly appropriate "original text" for a code of "practitioner license number"
Lloyd McKenzie (Dec 11 2018 at 02:33):
@Tim Berezny If you submit a change request, we can add an explicit example to the spec showing that.
Shamil Nizamov (Feb 26 2019 at 17:09):
@Tim Berezny If this is specific to Canada only, then there is a work stream lead by Igor to translate provincial OIDs to URIs with assumption that URIs are human readable and should be understood without looking for OIDs in the registry. If, for some reason, this is not enough, then yes, you may use Identifier.type.text, Identifier.assigner or "originalText" extension. Specifically in BC most of the identifiers are driven by our local OID master list or corresponding URIs. Health Authorities may invent their own up to the point when they decide to communicate their data with other HAs, in which case URIs need to be made public (i.e. registered with BC MOH).
Lloyd McKenzie (Feb 26 2019 at 17:14):
Identifier.assigner is only for the organization, not for the original type. It's not appropriate to use an extension when a core element (Identifier.type.text) exists.
Shamil Nizamov (Feb 26 2019 at 17:45):
quote It's not appropriate to use an extension when a core element (Identifier.type.text) exists.
originalText extension is to link structured data to human readable part in the narrative. (2.4.0.5)
Lloyd McKenzie (Feb 26 2019 at 17:49):
That wouldn't eliminate the need to provide the display value in the instance if you expect anyone to render it. The link into narrative is provenance/attribution purposes, not with any expectation that systems will use it to render a field. The links won't be that precise. (And few, if any, systems would have that degree of sophistication.)
Shamil Nizamov (Feb 26 2019 at 17:57):
I've just listed all possible options without preferences.
Lloyd McKenzie (Feb 26 2019 at 18:47):
Understood. And I'm asserting that there's a single clear answer that will ensure consistency with how the same problem is addressed elsewhere
Allan Bro Hansen (Apr 01 2019 at 22:11):
I would say that Identifier.type.text is a text value for the type, not for the system (several systems could have the same type )
So I think an extension is only way to go here.
Lloyd McKenzie (Apr 02 2019 at 02:50):
Identifier.type.text is what the user sees for the identifier type and can convey more nuance than just the type. It is the expected place to say "Michigan State Drivers License Number" or "New South Wales Podiatry Registration Number". The responsible work group has already approved a change request to add clarifying language and an example to the specification supporting this usage. An extension is unnecessary.
Allan Bro Hansen (Apr 02 2019 at 06:27):
@Lloyd McKenzie
Okay - I was confused because it goes against the current description of type, https://www.hl7.org/fhir/datatypes-definitions.html#identifier. E.g. "It SHOULD not be used for codes that correspond 1..1 with the Identifier.system". But as I understand you this description of type is also about to change.
So to make sure I understand this correctly:
Lets say we have to different Radiology System: RIS-A og RIS-B each with their identifier.system. They could use the same identifier.type coding-wise to state they are RIS-systems but they should have different type.text. RIS-A will basically say "RIS-A" and likewise for RIS-B. Correct?
Brian Postlethwaite (Apr 02 2019 at 09:35):
I believe so.
Lloyd McKenzie (Apr 02 2019 at 15:18):
Correct. CodeableConcept.text can be hightly variable even when the same code is communicated.
Tushar Nair (Jul 13 2021 at 06:49):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
