Stream: implementers
Topic: II datatype mapping in FHIR
Tushar Nair (Apr 08 2021 at 21:52):
In the FHIR spec -datatypes-mapping section it's mentioned that :
If the II has only a root and no extension, the FHIR Identifier will have a system of 'urn:ietf:rfc:3986' and the II.root will appear in Identifier.value
If the II has both a root and an extension, the II.root will be mapped to a URI - either a human-friendly URL or URN or (less preferred) an OID expressed as a urn, and the II.extension will be sent in Identifier.value
When extension is absent and root is a UUID, its shown as follows:
<system value="urn:ietf:rfc:3986" />
<value value="urn:uuid:a76d9bbf-f293-4fb7-ad4c-2851cac77162" />
When extension is absent and root is an OID, then it is supposed to be presented as follows:
<system value="urn:ietf:rfc:3986" />
<value value="urn:oid:0.1.2.3.4.5" />
This is fine but as the root can be anything -an OID or UUID or maybe a string(not a regular thing). At runtime, how does a system recognize this and map accordingly. Maybe there is a simple answer to it and I am not aware, if so please bear with me. Thank you in advance.
Vassil Peytchev (Apr 08 2021 at 22:47):
This is the definition of UID - the datatype of II.root:
The allowable formats and values and procedures of this data type are strictly controlled by HL7. At this time, user-assigned identifiers may be certain character representations of ISO Object Identifiers (OID) and DCE Universally Unique Identifiers (UUID). HL7 also reserves the right to assign other forms of UIDs (RUID), such as mnemonic identifiers for code systems.
I think it is clear that only an OID or a UUID can be in the root.
Tushar Nair (Apr 08 2021 at 22:51):
Vassil Peytchev thank you. However, it's still tricky to distinguish between OID or UUID at runtime for the system. Is there any guidance around that? Thanks.
Michele Mottini (Apr 08 2021 at 23:05):
How is that tricky? digits separated by dots versus hex with possible dash separators ?
Vassil Peytchev (Apr 09 2021 at 16:13):
The V3 datatypes core schema has this for OID:
<xs:restriction base="xs:string">
<xs:pattern value="[0-2](\.(0|[1-9][0-9]*))*"/>
</xs:restriction>
and for UUID
<xs:restriction base="xs:string">
<xs:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"/>
</xs:restriction>
Lloyd McKenzie (Apr 09 2021 at 16:31):
In short - search for "contains('.')" vs "contains('-')"
Jay Lyle (Jul 15 2021 at 20:25):
This is tantalizing: "HL7 also reserves the right to assign other forms of UIDs " Has there been any suggestion of adding http to that list? Rather than requiring everyone to figure out how to, in a coordinated fashion, assign OIDs to every URI in every FHIR spec?
Lloyd McKenzie (Jul 16 2021 at 15:03):
We don't want to use OIDs in FHIR at all in any place we can avoid them. OIDs suck for developers, testers, and anyone else who actually has to look at real instances.
Jean Duteau (Jul 16 2021 at 15:28):
i think Jay was asking if we could change the V3 UID to allow URIs.
Lloyd McKenzie (Jul 16 2021 at 16:31):
Ah. I don't think there's any appetite for revising v3 data types at all (either from a new version of the standard perspective or from an implementation perspective).
Last updated: Apr 12 2022 at 19:14 UTC
