Transforming from a fhir:identifier to V3:II

So this blog entry has been sitting here waiting for me to post something about how to transform FHIR Identifiers into CDA II elements in a way that works 100%.  The DocumentReference resource has an example that shows this content:

<masterIdentifier>
  <system value='urn:ietf:rfc:3986'/>
  <value value='urn:oid:129.6.58.92.88336'/>
</masterIdentifier>

What this content means is that the master identifier for the document being referenced is a URI as defined by RFC 3986.  For CDA geeks it should be obvious that the above implies that the content of the CDA document would have this in it:

<ClinicalDocument>
   ...
   <id root='129.6.58.92.88336'/>

But what about other URIs?  Well, if the URL format is urn:uuid:some-uuid-string, that's also pretty straight forward.  The output for id is simply:

  <id root='some-uuid-string'/>

OK, good.  What if the value is some other form of url?  What do we do now?  Grahame fixed this one for us by registering a new OID.

  <id root='2.16.840.1.113883.4.873' extension='some other form of url'/>

So, great, now we know how to handle all the cases where identifier.system = 'urn:ietf:rfc:3986'

What about the rest of the possibilities?
There are only three URLs you need to map to an OID described in the FHIR Identifier registry.  You can set up those lookups in an XML file somewhere.

How then, would you map an identifier containing a url in root whose corresponding OID you don't know?

There are three ways to handle this case:
1. Come up with something that produces a valid II datatype in CDA, recognizing that it might not be total cool.
2. Set the II as being not fully specified (and so requiring use of nullFlavor), perhaps committing the URL to another attribute so that the receiver might have some chance of fixing it on their end.
3. Giving up completely

Option 3 is not an option I like, so I discarded it.  You can do what you want, I almost never give up.
Option 2 is what I decided to use for my purposes.  It works, is technically valid, and might cause some complaints, but I can say, well, that URL is NOT KNOWN to my system, so we produce something technically correct with all the info the receiver might use to fix it.  So for:
  <identifier>
    <system value='http://example.com'/>
    <value value='my example id'/>
  <identifier>

I would use something like:
  <id nullFlavor='UNK' extension='my example id'
      assigningAuthorityName='http://example.com'/>
This says, I don't know the full II, I've told you what I know, you deal with it.

But, you could cheat, and say something like: "We know that url#fragment-id means the thing inside url with fragment identifier fragment-id.  So we'll treat it like that.  This is what you would get then:

  <id root='2.16.840.1.113883.4.873' 
      extension='http://example.com#my example id'/>

I'm not fond of this, because it isn't a totally legitimate answer, although most geeks might understand your reasoning, and what you generated.  It also means that your can no longer trust the content of any id that uses the value of 2.16.840.1.113883.4.873, and they really should be able to.

Fortunately for my uses, the nullFlavor case will only show up in exceptional circumstances.  All the naming systems I use in FHIR have an associated OID mapping.

For what it's worth, the same challenges exist with code system mapping, and I do the same thing: Make sure all my FHIR code systems map to an OID as well.