FHIR Chat · id + extension · cda to fhir

Stream: cda to fhir

Topic: id + extension

John Moehrke (Jun 15 2016 at 12:46):

How is an id + extension, commonly seen in CDA documents, handled in FHIR Identifier?

Lloyd McKenzie (Jun 15 2016 at 13:56):

Do you mean root + extension?

John Moehrke (Jun 15 2016 at 14:36):

yes

Lloyd McKenzie (Jun 15 2016 at 14:38):

root goes into system, extension goes into value. Root must be transformed into a uri. This can be done using "urn:oid:[old root]", though we encourage implementers to consider mapping from OIDs to human-readable URIs for the benefit of long-term maintainability/ease of use

John Moehrke (Jun 15 2016 at 14:40):

sounds reasonable. Did I miss this explanation in the spec?

Lloyd McKenzie (Jun 15 2016 at 17:03):

It's in the RIM mappings for the data type. As a rule, we don't talk about v2 or v3 mapping too much in the text of the spec because they're no more relevant/important than mapping X12 or ebXML or any of the other numerous data exchange standards out there.

John Moehrke (Jun 15 2016 at 17:19):

okay. I will add it to the IHE profiles.

John Moehrke (Jul 19 2016 at 20:52):

So the question we have is related to how does a reader of an Identifier know that one is using this RIM mapping rule, vs a normal use of Identifier? The only way one can determine this is to know by context where the Identifier sits within that it is likely to be a RIM mapping and not a normal Identifier?

John Moehrke (Jul 19 2016 at 20:53):

which conflicts with the recommendation found in the Identifier section that says if the identifier value is globally unique that it should be put into the value with the system defined as the RFC3986

Grahame Grieve (Jul 19 2016 at 21:00):

that's a really confusing question for me.

Grahame Grieve (Jul 19 2016 at 21:00):

you don't 'use the mapping rule' - it just exists

John Moehrke (Jul 19 2016 at 22:04):

The problem is that the FHIR spec has two conflicting instructions for how to handle globally unique identifiers. One says to use rfc3986, one for RIM identifiers. This might be clear for how to take a value and put it into FHIR Identifier. My question is if I am looking at a FHIR Identifier, how to I know that the Identifier I am looking at is one that was put in there using the RIM mapping, or is really an assigning authority assigned value.

John Moehrke (Jul 19 2016 at 22:04):

mostly because as a receiver of this information I need to know so that I can query my possible non-FHIR information sources.

Grahame Grieve (Jul 19 2016 at 22:05):

I don't understand what the conflicting instructions are

John Moehrke (Jul 19 2016 at 22:07):

In the datatypes page for Identifier is this sentence "If the identifier itself is naturally globally unique (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986", and the URI is in the value."

Grahame Grieve (Jul 19 2016 at 22:07):

yes

John Moehrke (Jul 19 2016 at 22:07):

YET, in the same page, the 'mapping' for Identifier https://www.hl7.org/fhir/datatypes-mappings.html#Identifier

John Moehrke (Jul 19 2016 at 22:07):

says that with RIM mapping

John Moehrke (Jul 19 2016 at 22:07):

it is different

John Moehrke (Jul 19 2016 at 22:08):

system II.root or Role.id.root
value II.extension or II.root if system indicates OID or GUID (Or Role.id.extension or root)

Grahame Grieve (Jul 19 2016 at 22:09):

that is not in conflict, but it is worded badly now. 'indicates OID or GUID actually means, urn:ietf:rfc:3986"

John Moehrke (Jul 19 2016 at 22:18):

but that clause is useless... as the problem is that I can't tell the meaning of system is... is it a RIM like system, or is it a real identifier assiging authority

Grahame Grieve (Jul 19 2016 at 22:22):

that difference I don't understand either

Elliot Silver (Jul 19 2016 at 22:39):

Consider if i have a CDA document id which is 1.2.3.4.5. I code it as system=rfc3986, code=1.2.3.4.5. But if I have a CDA document id which is 1.2.3.4.5^678, I have to code it as system=1.2.3.4.5, code=678. That seems weird, in one case 1.2.3.4.5 is the system, but in another place it is the value?

Robert Horn (Jul 19 2016 at 22:40):

My understanding, and it is not fully clear in FHIR, is that the result is that when I take a CDA document ID, I first check for extension. If no extension, I use system = "rfc3986". But if there is an extension I use system="OID-root-of-CDA-DocumentID". This means when I receive an ID, I have to make a context based decision. If system is an OID, I need to guess based on context whether that OID is the OID for some coding system that I don't know or it's the OID from a CDA Document ID. I think I can guess based on larger context, but if the ID ever gets separated from context I won't know what to do.

Robert Horn (Jul 19 2016 at 22:41):

This makes the parsing and matching logic very complex.

Grahame Grieve (Jul 19 2016 at 22:42):

well, yes, the mapping is complex. I think we got it wrong in v3 - everyone gets root/extension wrong, and we just don't have that problem in FHIR - except when we talk about II....

Grahame Grieve (Jul 19 2016 at 22:43):

I don't understand the context bit though - the decisions are solely made on the II itself.

Grahame Grieve (Jul 19 2016 at 22:43):

the formal mapping I did migth clarify:

Grahame Grieve (Jul 19 2016 at 22:45):

(deleted)

Grahame Grieve (Jul 19 2016 at 22:45):

group II2Identifier extends ANY2Element
  input src : II as source;
  input tgt : Identifier as target;

  root1: for src.root as r where extension.exists() make tgt.system = translate(r, "http://hl7.org/fhir/ConceptMap/special-oid2uri", "uri")  
  ext1: for src.extension as e make tgt.value = e

  root2: for src.root as r where extension.empty() make tgt.system = "urn:ietf:rfc:3986", tgt.value = translate(r, "http://hl7.org/fhir/ConceptMap/special-oid2uri", "uri")

endgroup

Robert Horn (Jul 19 2016 at 22:45):

I was kind of hoping we could phase out the extension. FHIR isn't the only place affected.

The context issue is that II is that the data structure for coded terms and II are very similar. If the context saying whether it's an II or coded term gets lost, you are in trouble. There are lots of applications that like to strip out identifiers.

Grahame Grieve (Jul 19 2016 at 22:45):

if there's an extension, then treat the root as the system (but translate it to a URI), and map the extension to the value

if there's no extension, then make the system = urn:ietf:rfc:3986, and make the value the root converted to a URI

John Moehrke (Jul 19 2016 at 22:47):

The problem is in the other direction

Grahame Grieve (Jul 19 2016 at 22:47):

if you lose the difference between code and identifier, then you're screwed. yes. But fior us, that's type not context

John Moehrke (Jul 19 2016 at 22:47):

if I have a FHIR Identifier, how do I know how to read it

Grahame Grieve (Jul 19 2016 at 22:47):

why is it a problem?

John Moehrke (Jul 19 2016 at 22:48):

because FHIR is not a bitbucket

Elliot Silver (Jul 19 2016 at 22:48):

I may need to take that identifier out of a closed FHIR system.

John Moehrke (Jul 19 2016 at 22:48):

or is it?

Grahame Grieve (Jul 19 2016 at 22:48):

if the root is urn:ietf:rfc:3986, then if you can translate the value to an OID or UUID, put it in the root. else error

if the root is not urn:ietf:rfc:3986, then see if you can translate the system to an OID or UUID, else error, then put the value in extension

Grahame Grieve (Jul 19 2016 at 22:49):

the princple problem is that the FHIR identiifer can represent things that the II can't

John Moehrke (Jul 19 2016 at 22:49):

right... so the problem comes in when the root is NOT rfc3986

Grahame Grieve (Jul 19 2016 at 22:50):

I don't think it's a problem, it just might fail. It's not unclear, anyway

Robert Horn (Jul 19 2016 at 22:50):

For example, how would I create a CDA from a FHIR resource, when that FHIR resource was created from a CDA with an extension. I want to be sure I get the same result.

Grahame Grieve (Jul 19 2016 at 22:50):

following the method above, you will. It might fail if the source was outside CDA in the first place, but it round trips for II

Elliot Silver (Jul 19 2016 at 22:51):

Or, how would I know that it is a OID+extension identifier and not some other identifier with an OID identifying the system?

Grahame Grieve (Jul 19 2016 at 22:53):

what's the difference?

Grahame Grieve (Jul 19 2016 at 22:56):

if you can convert the source system to an OID, then you represent it as a root+extension, otherwise it's an error

Grahame Grieve (Jul 19 2016 at 22:56):

I don't understand the problem you're seeing there

Grahame Grieve (Jul 19 2016 at 22:57):

the key is that you need to be able to convert from URI to OID Or UUID. I believe there's 3 states for that:
- the URI starts with urn:oid: or urn:uuid:
- I can look up the URI in some table of URIs, and find the associated OID or UUID (might be a naming system table)
- I don't know an equivalent OID

Grahame Grieve (Jul 19 2016 at 22:58):

so, yes, you probably need a look up table. But other than that. there's no issue here I can see

Keith Boone (Jul 29 2016 at 09:37):

See http://motorcycleguy.blogspot.com/2016/07/round-tripping-identifiers-from-cda-to.html for what I figured out on this a while back

John Moehrke (Jul 29 2016 at 13:45):

There must be a better way. This is an hl7 created problem. How real are the problem cases?

Grahame Grieve (Jul 29 2016 at 14:27):

I don't know what problem you still see here?

John Moehrke (Aug 02 2016 at 12:43):

There are cases where I have a FHIR Identifier, properly filled out; but I can't tell how to put that into a CDA or HL7 v2 or HL7 v3 form deterministically. The proposal that I have a registry of roots is not scaleable. -- I am not saying that all cases are problematic; but there are some that are.

Grahame Grieve (Aug 02 2016 at 21:03):

so my view is that an identifier oriinally populated from an II can be determistically converted back to an II. One that is outside the space of II, not so easily. That fact was written into the Identifier data type when we changed the semantic scope of it on day 1

Last updated: Apr 12 2022 at 19:14 UTC