I think I solved this problem for myself last year or so, or else the answer wouldn't be so readily available in my brain.
The challenge is this: You have an identifier in a CDA document. You need to convert it to FHIR. And then you need to get it back into CDA appropriately.
There are four separate cases to consider if we ignore degenerate identifiers where nullFlavor is non-null.
For case 3, it gets a tiny bit messy. You need a lookup table to map a small set of OIDs to FHIR URLs for FHIR defined identifier systems. If the OID you have matches one of the FHIR OIDs in that registry, use the specified URL. Otherwise, convert the OID to its urn:oid form. If it is a UUID, you simply convert it to its urn:uuid form.
Going backwards:
If system is urn:ietf:rfc:3986, then it must have been in root-only format, and the value is the OID or UUID in urn: format. Simply convert back to the unprefixed OID or UUID value, and stuff that into the root attribute.
Otherwise, if it is a URL that is not in urn:oid or urn:uuid format, then look up the identifier space in the FHIR identifier system registry, and reverse it to an OID, and put that into root. Otherwise, you just convert back to the unprefixed OID or UUID value, and stuff that into root. In that case, the extension attribute should contain whatever is in value.
So now then, you might ask, how do I represent a FHIR identifier that is NOT one of these puppies in HL7 CDA format. In other words, I have a native FHIR identifier, and CDA had nothing to do with generating it. So, there's a system and a value, but no real way to tell CDA how to deal with it. To do that, we need a common convention or a defined standard.
So, pick an OID to define the convention, and a syntax to use in value to represent system and value when system cannot be mapped to an OID or UUID based on the above convention. In this manner you can represent a FHIR identifier in CDA without loss of fidelity because CDA does not provide any limits on value. Oh, and modify the algorithm above to handle that special OID in case four.
I'll let HL7 define the standard, select the OID, and specify the syntax. I have better things to do with $100 than register an OID for this purpose. But clearly, it could be done.
Keith
The challenge is this: You have an identifier in a CDA document. You need to convert it to FHIR. And then you need to get it back into CDA appropriately.
There are four separate cases to consider if we ignore degenerate identifiers where nullFlavor is non-null.
- <id root='OID'/>
- <id root='UUID'/>
- <id root='OIDorUUID' extension='value'/>
For case 3, it gets a tiny bit messy. You need a lookup table to map a small set of OIDs to FHIR URLs for FHIR defined identifier systems. If the OID you have matches one of the FHIR OIDs in that registry, use the specified URL. Otherwise, convert the OID to its urn:oid form. If it is a UUID, you simply convert it to its urn:uuid form.
Going backwards:
If system is urn:ietf:rfc:3986, then it must have been in root-only format, and the value is the OID or UUID in urn: format. Simply convert back to the unprefixed OID or UUID value, and stuff that into the root attribute.
Otherwise, if it is a URL that is not in urn:oid or urn:uuid format, then look up the identifier space in the FHIR identifier system registry, and reverse it to an OID, and put that into root. Otherwise, you just convert back to the unprefixed OID or UUID value, and stuff that into root. In that case, the extension attribute should contain whatever is in value.
So now then, you might ask, how do I represent a FHIR identifier that is NOT one of these puppies in HL7 CDA format. In other words, I have a native FHIR identifier, and CDA had nothing to do with generating it. So, there's a system and a value, but no real way to tell CDA how to deal with it. To do that, we need a common convention or a defined standard.
So, pick an OID to define the convention, and a syntax to use in value to represent system and value when system cannot be mapped to an OID or UUID based on the above convention. In this manner you can represent a FHIR identifier in CDA without loss of fidelity because CDA does not provide any limits on value. Oh, and modify the algorithm above to handle that special OID in case four.
I'll let HL7 define the standard, select the OID, and specify the syntax. I have better things to do with $100 than register an OID for this purpose. But clearly, it could be done.
Keith
0 comments:
Post a Comment