Stream: implementers
Topic: identifier.system must be an absolute reference
Brian Reinhold (Apr 23 2019 at 21:43):
I am getting an error from Grahame's 4.0.0 server that states that the Patient.identifier.system must be an absolute reference. In this case the system identifies a business partner's system under which a certain group of patients are catologed. This system identifier was defined by the business partner and only they can understand it. It doesn't make sense to me that this is not a valid use case. I also don't see anywhere that the system must be an absolute reference. It may be convenient for a standardized understanding of the cataloging system but that it not the intent here ... only the particular business partner can understand it.
Grahame Grieve (Apr 23 2019 at 21:54):
it's still important that it be an absolute reference. Is that hard?
Brian Reinhold (Apr 23 2019 at 21:57):
it's still important that it be an absolute reference. Is that hard?
In this case the system was specified by a business partner and they rule. I could always make a fake absolute URL but they would not understand it.
Grahame Grieve (Apr 23 2019 at 21:59):
if you make a relative URI, there's no reason that someone else can't make the same, and your content couldn't be differentiated. if you make an absolute one, off a root you own, or using an oid or uuid, then that won't happen. It's super not hard to use a uuid
Brian Reinhold (Apr 23 2019 at 22:48):
if you make a relative URI, there's no reason that someone else can't make the same, and your content couldn't be differentiated. if you make an absolute one, off a root you own, or using an oid or uuid, then that won't happen. It's super not hard to use a uuid
Of course, it just happened to be a customer demand. So we are stuck with it. But I can always use something else; I just happened to be uploading patient information configured for that use case. In the PHD IG, patient information is always out-of-band as it is not something provided by the PHD via a STANDARD protocol.
Grahame Grieve (Apr 23 2019 at 22:49):
what's the customer demand? to be non-conformant?
Brian Reinhold (Apr 23 2019 at 22:54):
what's the customer demand? to be non-conformant?
That's their system. In this case the data is not going to a FHIR server but to their server; they just want the data in FHIR format as there are lots of convenient tools to parse such a data model. They don't care about the transactions or any of that other stuff. Its not like anyone can read the data from where ever they put it anyways. I am also pretty sure they transform it into a proprietary form. We aim to satisfy our customers. -- But the Patient is the only thing they can specify. Everything else is controlled by the PHD.
Richard Townley-O'Neill (Apr 23 2019 at 23:53):
Why is an error and not a warning that Patient.identifier.system is not an absolute reference? There is nothing in uri, Identifier.system, or Patient to say that it must be an absolute reference.
Grahame Grieve (Apr 23 2019 at 23:57):
no but it does say it must be unique, and how else can it be?
Richard Townley-O'Neill (Apr 24 2019 at 00:02):
Of course! "The value SHALL be unique within the defined system" and, as you said above, if several places may use the same system they may use the same value as well and the identifier may not be unique.
Richard Townley-O'Neill (Apr 24 2019 at 00:05):
Thought that means that if Identifier is used for capturing historical data where value is known but the system is unknown, the use is invalid.
Lloyd McKenzie (Apr 24 2019 at 00:22):
The system must be globally unique
Lloyd McKenzie (Apr 24 2019 at 00:24):
So that if both system and value are present, the identifier as a whole is globally unique
Richard Townley-O'Neill (Apr 24 2019 at 00:25):
Can you capture historical data where value is known but the system is unknown?
If so, how?
Grahame Grieve (Apr 24 2019 at 01:06):
just leave system out. That usage is documented in the spec
Richard Townley-O'Neill (Apr 24 2019 at 01:22):
Not my clearest day: "The value SHALL be unique within the defined system" If there is no system, the value will meet that condition.
Thanks. :embarrassed:
Brian Reinhold (Apr 24 2019 at 09:39):
The system must be globally unique
The only remark I have on that is to have something that is globally unique really requires global cooperation and typically registration of something with a global organization (such as a BT address or an IEEE system id EUI). Not all business use cases are going to go for that are are willing to pay for that. All they need to assure is that the identifier is unique within their infrastructure (whatever that may be).
Grahame Grieve (Apr 24 2019 at 10:34):
UUIDs are good and supeor easy
Brian Reinhold (Apr 24 2019 at 11:26):
UUIDs are good and supeor easy
True but hard to remember.
Lloyd McKenzie (Apr 24 2019 at 14:31):
URLs have a global registration requirement and management expectations. You need to register for (and pay for) a domain name and the organization that owns the domain name is responsible for managing the URLs with that domain name as a base. That provides us with the basis for a globally unique id. Relative references bypass that and therefore aren't globally unique - which isn't allowed.
David Riddle (Jan 16 2020 at 22:51):
@Grahame Grieve ,
You indicated...
just leave system out. That usage is documented in the spec
By 'documented in the spec', are you referring to the fact that you can infer that usage from the "The value SHALL be unique within the defined system" verbiage that @Richard Townley-O'Neill points out above, or is this usage documented more explicitly somewhere?
I realize that the cardinality for system is 0..1 according to the Identifier datatype definition (https://www.hl7.org/fhir/datatypes.html#Identifier); however, I have encountered a lot of contention over whether or not Identifiers with no system specified (value only Identifiers) should be permitted/propagated.
Grahame Grieve (Jan 17 2020 at 00:27):
well, if you don't know the system, you don't know the system, so don't say it. OTOH, I strongly agree that you should know the system, and it's very bad practice (rude to your readers) not to include it if it exists
Grahame Grieve (Jan 17 2020 at 00:27):
there are lots of business contexts where you can get away with saying that there must be a system, and if you can get away with it you should
Grahame Grieve (Jan 17 2020 at 00:28):
however note that there's a classic situation where there's no situation: hardware POC testing devices that read the patient barcode, and only have value, with no system. Some gateway has to inject the right system URL somewhere based on local configuration
David Riddle (Jan 17 2020 at 13:52):
@Grahame Grieve ,
The specific use case I am interested in is the conversion of data from C-CDA documents into FHIR Resources. C-CDA documents include id elements with a II datatype (An identifier that uniquely identifies a thing or object). This II datatype supports a root attribute and an extension attribute. The root attribute is defined as 'A unique identifier that guarantees the global uniqueness of the instance identifier. The root alone may be the entire instance identifier' and the extension attribute is defined as 'a unique identifier within the scope of the identifier root'. So C-CDA id/@root = FHIR Identifier.system and C-CDA id/@extension = Identifier.value when id/@extension is present, but id/@root = Identifier.value when id/@extension is not present.
In my mind a C-CDA id element with only the root attribute populated falls into the 'you don't know the system' bucket, but that doesn't mean the id/Identifier should be thrown out (not saying you are suggesting that, but it has been suggested). i.e., I think based on your comments on this thread that a C-CDA id element that looks like this '<id root="4adc9999-7b14-12db-9fe1-0800200c9a66"/>' should be converted to a FHIR Identifier with value = 'urn:uuid:4adc9999-7b14-12db-9fe1-0800200c9a66' & no system vs. throwing that identifier out/not carrying it forward since the system is not known. Do you agree?
Vassil Peytchev (Jan 17 2020 at 18:51):
In the case of a root containing a UUID value, the system is UUID, isn't it?
Grahame Grieve (Jan 17 2020 at 19:55):
right. there's a system for 'globally unique identifiers' = urn:ietf:rfc:3986 - that's what you should use (though it implies that the UUID above gets prefixed with urni:uuid: in Identifier.value
Grahame Grieve (Jan 17 2020 at 19:55):
thats's how the CDA -> FHIR converters I have written work
David Riddle (Jan 17 2020 at 21:40):
@Vassil Peytchev and @Grahame Grieve ,
Thank you. I missed the 'urn:ietf:rfc:3986 for when the value of the identifier is itself a globally unique URI' line here http://build.fhir.org/datatypes.html#identifier. @Michelle (Moseman) Miller pointed that out to me today.
thats's how the CDA -> FHIR converters I have written work
@Grahame Grieve ,
So for root only CDA id elements, it sounds like you are checking for the 8-4-4-4-12 UUID pattern and if found setting Identifier.system = 'urn:ietf:rfc:3986' and Identifer.value = 'urn:uuid:' + id/@root. Is that correct?
What have your CDA -> FHIR converters done with root only id elements when the id/@root value does not appear to be a UUID? Do you write those as FHIR Identifiers w/o a system, or do you throw them out?
Vassil Peytchev (Jan 17 2020 at 21:48):
id/@root can only be UUID or an OID. It is of the UID datatype, where the definition states:
At this time, user-assigned identifiers SHALL only be certain character representations of ISO Object Identifiers (OID) and DCE Universally Unique Identifiers (UUID).
David Riddle (Jan 17 2020 at 22:23):
@Vassil Peytchev ,
It seems unlikely, but it sounds like a root only id element with an OID vs. a UUID in the id/@root (e.g., <id root="1.9.999.114350.9.99.999.2.7.2.99">) is possible/permitted. Is that correct?
Vassil Peytchev (Jan 17 2020 at 22:33):
Yes, id/@root can only be a UUID (system urn:ietf:rfc:3986, value urn:uuid: + id/@root) or an OID (system urn:ietf:rfc:3986 value urn:oid: + id/@root)
Last updated: Apr 12 2022 at 19:14 UTC
