FHIR Chat · use of urn:hl7ii · implementers

Stream: implementers

Topic: use of urn:hl7ii

John Moehrke (Dec 10 2018 at 17:00):

There is a defined way of encoding an HL7 II with root or root+extension. The value is
urn:hl7ii:{ROOT}[:{EXTENSION}]
Presumably in FHIR the .system value would still be the URI identifier of "urn:ietf:rfc:3986", but I guess it is possible there could be a specific system to indicate a HL7 II identifier as different from simply URI...
the most dominant place where root+extension is used is within CDA, but it is found elsewhere.
I am interested, on behalf of IHE and specifically the MHD profile, of assuring full round-trip of these kinds of identifiers.
So I am interested in community opinion on the use of urn:hl7ii, vs not using this.
If urn:hl7ii is not used, then a II value with just root, will be encoded as rfc3986; where as root+extension must be encoded with root in system, and extension in value.

THIS text from IHE Appendix Z (that I am now updating to FHIR R4)

Z.9.1.1 Identifier and HL7 version 3 "root plus extension"
In HL7 version 3, uniqueId can be expressed as a root, or as a root plus extension.
When converting an HL7 version 3 uniqueId to FHIR, if no extension is provided, the root shall be placed into the Identifier.value, and the Identifier.system shall be set to “urn:ietf:rfc:3986”. For example, the HL7 version 3 value
<identifier root="1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504" />
would be expressed in FHIR as
{
"system": "urn:ietf:rfc:3986",
"value": "urn:oid:1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504"
}
When an extension is provided, the extension shall be placed into the Identifier.value, and the Identifier.system shall be set to the root. For example, the HL7 version 3 value
<identifier root="1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504" extension="84566" />
would be expressed in FHIR as
{
"system": "urn:oid:1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504"
“value”:”84566”
}

with use of urn:hl7ii, this simplifies to one pattern...

John Moehrke (Dec 10 2018 at 17:00):

Reference: See Grahame's blog from June 2014 http://www.healthintersections.com.au/?p=2148

Elliot Silver (Dec 10 2018 at 19:39):

(sigh) tables aren't as easy to use in zulip as I'd like...

@John Moehrke , just to clarify your examples:

• HL7 V3 encoding:

  • No extension: <identifier root="1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504" />
  • With extension: <identifier root="1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504" extension="84566" />

• Current FHIR practice:

  • No extension: { "system": "urn:ietf:rfc:3986", "value": "urn:oid:1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504" }

  • With extension: { "system": "urn:oid:1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504", "value": "84566" }

• Proposed hl7ii encoding:

  • No extension: { "system": "urn:ietf:rfc:3986", "value": "urn:hl7ii:1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504" }
  • With extension: { "system": "urn:ietf:rfc:3986", "value": "urn:hl7ii:1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629.41504:84566" }

An advantage to this would be the clear ability to round-trip the identifier from V3 to FHIR and back, correct?

John Moehrke (Dec 10 2018 at 20:17):

yes. When encoding an II datatype, this would be the recommended way to encode it in FHIR... Drawback is that everyone must know about hl7ii origin, and encoding.

Elliot Silver (Dec 10 2018 at 20:37):

Hmm, also raises issues about identifiers that pass through an II but don't originate there.

John Moehrke (Dec 10 2018 at 20:57):

yes, that is a problem... even where it is unknown that it did come from an II. root+extension is a big problem for interoperability. Really wish HL7 had not invented that. root alone can easily be simply treated as a unique identifier. Given HL7 invented root+extension, then HL7 should determine the solution when FHIR is involved.

Paul Knapp (Dec 12 2018 at 10:11):

System in FHIR is equivalent to root, value in FHIR is equivalent to extension. If you will the 'odd ' use is when an oid is used without an extension - in your first example: 1.2.826.0.1.3680043.2.1611.1.2.32884.10619.27943.27629 is the namespace (system) for the instance (value) 41504.

John Moehrke (Dec 12 2018 at 14:46):

yes, that works when one has root and extension... but it does not work when one has only root... Thus the problem, one must encode the two patterns totally differently... where as urn:hl7ii gives us one way to encode both.

Lloyd McKenzie (Dec 12 2018 at 15:38):

Why is it a problem to encode them differently if it's deterministic?

Lloyd McKenzie (Dec 12 2018 at 15:39):

More importantly, when converting an II to Identifier, you're often going to have to translate the OID to a URL - at least you will for any place where a standard URL has been defined. There's no safe way to algorithmicly do the conversion

John Moehrke (Dec 12 2018 at 15:52):

It is the rountrip problem... that is looking at the FHIR Identifier and understanding that the value there is an II that is just root, or an II that is root + extension, or someother kind of identifier

Lloyd McKenzie (Dec 12 2018 at 15:56):

If you look at an Identifier instance and see a value that's an OID with the standard URL for a bare OID, then you've got an II with just a root. If you've got anything else, you've got a root + extension

John Moehrke (Dec 12 2018 at 15:56):

not really.. OIDs are used far wider than HL7...

Lloyd McKenzie (Dec 12 2018 at 15:58):

If you're converting to an II, that's still the algorithm you'd need to use

John Moehrke (Dec 12 2018 at 16:00):

I am converting it to a interface that understands bare OIDs, and also can take II... They are different in the real world

Lloyd McKenzie (Dec 12 2018 at 16:01):

Then add an extension that says "this came from an II"

Lloyd McKenzie (Dec 12 2018 at 16:02):

You won't be able to use your urn:hl7ii with all data that comes from an II, so I don't see the point of introducing it.

John Moehrke (Dec 12 2018 at 16:02):

I am simply asking the question to HL7 as a body... a body that has invented the root+extension concept... for the best way to handle that in FHIR.. when I think I have uncovered issues.. and for which I see the urn:hl7ii as a solution someone has invented... so I am simply asking for HL7 as a body to rule on the use of urn:hl7ii in the context of FHIR Identifier... I don't care if it is YES or NO or MAYBE...

John Moehrke (Dec 12 2018 at 16:05):

I have a model, in IHE, for dealing with this without use of urn:hl7ii... I am just faced with comments asking for us to consider urn:hl7ii... so look at me considering it, and asking for community discussion. I can have IHE forbid it, but I can't have IHE ignore it and thus end up with an interoperabilty problem where some use it and others don't. I am looking to avoid and interop problem.

Paul Knapp (Dec 12 2018 at 17:08):

Well I invented hl7ii and you could use it as you suggest, but as Lloyd has said above you could simple check if the value is an OID or if the system is an OID and deal with those two situations.

Grahame Grieve (Dec 12 2018 at 19:54):

I'm not seeing the need. The CDA/FHIR project mappings say:

Grahame Grieve (Dec 12 2018 at 19:55):

  source.root as r where source.extension.exists() -> target.system = translate(r, "http://hl7.org/fhir/ConceptMap/special-oid2uri", "uri");
  source.root as r where source.extension.empty() -> target.system = "urn:ietf:rfc:3986", target.value = append("urn:oid:", r);
  source.extension as e -> target.value = e;

Grahame Grieve (Dec 12 2018 at 19:55):

that's for II -> Identifier

Grahame Grieve (Dec 12 2018 at 19:55):

and for other way:

Grahame Grieve (Dec 12 2018 at 20:01):

    value.value as v where system.value = 'urn:ietf:rfc:3986' -> target.root = v;
    system.value as v where system.value != 'urn:ietf:rfc:3986' -> target.root = v then {
      value.value as v -> target.extension = v;

Grahame Grieve (Dec 12 2018 at 20:02):

that seems pretty simple to me, and is what Lloyd said

Last updated: Apr 12 2022 at 19:14 UTC