Stream: terminology
Topic: Using Coding as a handy NamingSystem shortcut
Jay Lyle (Aug 24 2021 at 15:26):
We're getting direction to use OIDs in FHIR to facilitate translation to/from CDA. Not crazy about it. Considering duplicating the coding in CodeableConcept, once with a system OID and once with a URL. Thoughts?
Lloyd McKenzie (Aug 24 2021 at 15:34):
Using OIDs in FHIR is strongly discouraged. First, CDA is going to have to translate from OIDs to URLs in all cases where an official URL has been defined (e.g. LOINC, SNOMED, UCUM, ICD, etc.). As a result, the infrastructure to perform translation is going to have to exist regardless. Second, the NamingSystem resource makes it easy to computably share and maintain the expected mappings. Most importantly, FHIR moved from OIDs to URIs for a reason - OIDs suck for implementers. They're hard to read, meaningless, impossible to look up and easy to get wrong. Saving money on migration only to have ongoing costs to developers, testers, debuggers and everyone else who needs to look at the raw instances is rarely going to make sense in the long term. Better to incur a bit of extra cost in the short term and save money in the long term.
Jay Lyle (Aug 24 2021 at 16:51):
Agree, agree, and agree. And I'll tell anyone who will listen. Meanwhile, would an opinion on the multiple codings be considered a concession?
Jay Lyle (Aug 24 2021 at 16:52):
Another tack: V3 data types stipulate that RUIDs must be OIDs or UUIDs, but also states "HL7 also reserves the right to assign other forms of UIDs (RUID), such as mnemonic identifiers for code systems."
What are the odds of HL7 exercising this right and admitting HTTP URLs?
Lloyd McKenzie (Aug 24 2021 at 17:53):
Sorry, missed the bit with multiple codings. There should only be one URI allowed for use for a given system. Expressing the same coding with multiple URIs is non-conformant for anything that has an official URI and would certainly be strongly discouraged elsewhere.
Lloyd McKenzie (Aug 24 2021 at 17:54):
The odds of it happening for any common public code system used internationally or in the U.S. is quite good. For something like "Hospital XYZ lab codes", the odds are zero.
Jay Lyle (Aug 24 2021 at 18:02):
Well, maybe there should be one, but many have two. E.g., http://snomed.info/sct & 2.16.840.1.113883.6.96.
Grahame Grieve (Aug 24 2021 at 18:11):
if you have to put OIDs in the resources, then the extension http://hl7.org/fhir/StructureDefinition/iso21090-CD-codeSystem is there to use
Lloyd McKenzie (Aug 24 2021 at 18:20):
urn:oid:2.16.840.1.113883.6.96 would be non-conformant if it appeared in a FHIR instance. The SNOMED code system MUST be identified with the "http://snomed.info/sct" URI if the instance is to be considered conformant. There's no allowance for sending multiple codings with different systems.
Jean Duteau (Aug 24 2021 at 18:34):
Grahame Grieve said:
if you have to put OIDs in the resources, then the extension http://hl7.org/fhir/StructureDefinition/iso21090-CD-codeSystem is there to use
Hmm, I couldn't find that extension (the link you gave also doesn't work).
Grahame Grieve (Aug 24 2021 at 18:41):
no it hasn't been instantiated, but it's the correct extension to use
Jay Lyle (Aug 24 2021 at 20:40):
- Interesting. Is that generalizable to any 21090 property? How is type resolved?
- By what criterion do we choose that rather than using two codings?
- "The SNOMED code system MUST be identified with the "http://snomed.info/sct" URI if the instance is to be considered conformant." Because that's what's in SI's 'canonical' url property?
Lloyd McKenzie (Aug 24 2021 at 20:46):
1 - leaving that to @Grahame Grieve...
2 - two codings isn't conformant, using an extension is? :)
3 - correct. It's also the URL that appears here: http://build.fhir.org/terminologies-systems.html
Grahame Grieve (Aug 24 2021 at 20:48):
yes it's generalisable, though many 21090 properties have direct FHIR maps, and aren't appropriate to use
Lloyd McKenzie (Aug 24 2021 at 20:56):
@Grahame Grieve can you expand on what you mean? I don't think there's any 'magic' that allows referencing 21090 extensions that haven't yet been defined. So what I think you're saying is "we've created extensions like this in the past, and it would be appropriate for us to define this one for that purpose". Is that accurate?
My personal leaning is we might be better off defining a slightly less esoterically named extension that would work for both code systems and naming systems if we need to go through the work of defining one for use in R5 (and pre-adopting it in prior versions). Would that make mores sense?
Grahame Grieve (Aug 24 2021 at 20:59):
https://hl7.org/fhir/iso-21090.html - is ambiguous about this. I intended that people could just use any of the implied extensions, and we'd describe things as they were useful, but the page doesn't actually say that. it implies it:
At the present time, this profile is incomplete. It only contains extensions reflecting capabilities that have been explicitly identified as "useful" in the context of FHIR
Grahame Grieve (Aug 24 2021 at 21:00):
it really feels like a dilbert thing: the standard implies that the unidentified extensions are implied to exist
Grahame Grieve (Aug 24 2021 at 21:01):
https://community.automox.com/t/favorite-dilbert-comic-strip/688
Jay Lyle (Aug 24 2021 at 21:46):
Lloyd McKenzie said:
2 - two codings isn't conformant, using an extension is? :)
Could be right, but it seems a little circular to me. What makes it nonconformant?
Lloyd McKenzie (Aug 24 2021 at 22:04):
You'd be using a system URI other than the permitted one for that code system
Lloyd McKenzie (Aug 24 2021 at 22:13):
My reading of the 21090 section is "we'll add more extensions as they're needed", not that "you're free to pretend that the extensions you want exist". So, if there's a desire to send the OID in addition to the approved URI, I think the next step is to submit a Jira issue and we'll figure out if we want to create a 21090 extension or a different extension.
Jay Lyle (Aug 24 2021 at 23:03):
I totally and implicitly trust you. But I will need to argue, so I'm looking for some writing that says that this is not permitted, or not conformant, etc. Does this writing exist?
Jean Duteau (Aug 24 2021 at 23:31):
http://hl7.org/fhir/terminologies-systems.html : If a URI is defined here, it SHALL be used in preference to any other identifying mechanisms.(2nd sentence)
And SNOMED is listed on that page.
Jay Lyle (Aug 25 2021 at 02:46):
That helps. But it still doesn't say you can't have two.
Grahame Grieve (Aug 25 2021 at 02:50):
The concept may be coded multiple times in different code systems (or even multiple times in the same code systems, where multiple forms are possible, such as with SNOMED CT).
Lloyd McKenzie (Aug 25 2021 at 03:16):
Sure. It can be coded multiple times. And it can be coded multiple times with SNOMED CT. However each time it is coded, the URI defined for SNOMED CT must be used. The line Jean quoted doesn't say "one of the codings needs to use this URI". It says the URI SHALL be used. The statement is evaluated on Coding.system, not at any higher level.
Lloyd McKenzie (Aug 25 2021 at 03:17):
If you want to send the SNOMED OID along for the ride, you can certainly stick it in an extension, but you can't stick it in Coding.system and be conformant.
Grahame Grieve (Aug 25 2021 at 03:31):
@Lloyd McKenzie I honestly think you're overstating the case here. Let's consider this:
{
"resourceType": "Condition",
"code" : {
"coding" : [{
"system" : "http://snomed.info/sct",
"code" : "39065001"
}, {
"system" : "urn:oid:2.16.840.1.113883.6.96",
"code" : "39065001"
}]
}
}
Grahame Grieve (Aug 25 2021 at 03:31):
technically, this is a coding represented once in snomed, and once in some other unknown coding system that just happens to look a lot like snomed ct.
Grahame Grieve (Aug 25 2021 at 03:32):
if you look up the OID, you'll find SCT, along with the rule that if it's SCT then it's represented with http://snomed.info/sct - which it's not. So it's not SCT, and you don't recognise it. Unless you look it up. That feels like a schrodinger's paradox ;-)
Grahame Grieve (Aug 25 2021 at 03:33):
so it's not that I disagree with Lloyd, I think it's just not right to state it so strongly.
Grahame Grieve (Aug 25 2021 at 03:33):
really, this is much clearer:
Grahame Grieve (Aug 25 2021 at 03:36):
{
"resourceType": "Condition",
"code" : {
"coding" : [{
"system" : "http://snomed.info/sct",
"code" : "39065001"
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/iso21090-CD-codeSystem",
"valueCode" : "2.16.840.1.113883.6.96"
}]
}
}
Grahame Grieve (Aug 25 2021 at 03:37):
it has the serious advantage that if you don't know about the OID, and don't care, you won't notice, where as having a second coding will immediately cause confusion for anyone processing the data.
Lloyd McKenzie (Aug 25 2021 at 03:38):
It has nothing to do with "if you recognize it". If you have no clue what the code system is and blindly spit out the CDA OID with a urn:oid: in front of it, you're non-conformant. The language doesn't say "if you recognize what code system you're dealing with". It says "If a URI is defined here". That's the only qualifier. In reality, there'll be some systems that won't try to look up the OID or won't have the capacity. Their FHIR instances will be non-conformant. I don't think the spec gives any wiggle-room - and I don't think it should. The extension example above meets the use-case and is fully conformant - aside from the fact that the extension isn't defined yet and thus is technically invalid, which is something we can fix.
Jay Lyle (Aug 25 2021 at 12:03):
"SHALL be used": I think the two-coding pattern does that. The level at which the SHALL is applied is not specified. This is a bit like an open world specification problem, where you can satisfy a requirement with one instance without securing that constraint to other instances. Lloyd's "each time" language makes sense, but if that's what's intended, I'd recommend the guidance use that language.
Robert McClure (Aug 25 2021 at 12:29):
Funny how we've danced around this issue for years and then in this thread we seem to come to an approach that would allow a system to create and accept multiple identifiers for a code system if we clarify what extension can support this. I'm loving this and think it should also apply to the code system resource. @Carol Macumber @Ted Klein @Carmela Couderc
@Jay Lyle Can you submit a tracker?
Lloyd McKenzie (Aug 25 2021 at 14:12):
@Jay Lyle If you genuinely feel it's unclear, you could submit a change request for it to be clarified, but given that the existing language doesn't talk about CodeableConcept, doesn't talk about "at least one Coding" or provide any other suggestion that exceptions are allowed, I don't see how it could be interpreted any other way. And it's certainly not something we'd want to enable. Multiple codings are intended to represent multiple representations with different codes from the same system or different encodings from distinct code systems - not to allow the same code system to be identified multiple ways. FHIR relies heavily on "one system is always identified by one URL". That's not something we would want to relax. The considerations around expediency of mapping between v3 and FHIR (and v2 and FHIR) were well considered when we designed the code and identifier data types as we did.
As a rule, you shouldn't count on the OID being present in instances period. If you start mandating that the OID-representation be included alongside the URL in instances to be willing to consume them, you're imposing a significant cost on all of your communication partners. If you want to convert from FHIR back to CDA, the cost should be on your system alone. It's not hard to look up the OID for a URI where those have been defined. If you're dealing with local systems that might not have OIDs at all, the proper solution might be a foreign namespace extension in v3 rather than forcing the v3 overhead into FHIR systems.
Jay Lyle (Aug 25 2021 at 14:44):
@Lloyd McKenzie Thanks, point taken.
And thanks for the exposition, which I will advocate.
I was writing a tracker, and I think the existing language is pretty good, but based on my misreading I think a note might help.
https://jira.hl7.org/browse/FHIR-33245
@Robert McClure : I'm not sure I follow. Are you suggesting some language regarding using the extension on CodeSystem.url?
Jay Lyle (Aug 25 2021 at 14:45):
@Robert McClure : And a question about the requirements underlying the design direction: If a CodeableConcept contains more than one coding, what is expected of the recipient? Must the recipient understand all of the codings? Use case 1: one ICD and one SCT; we expect them to be synonymous & either is fine. Use case 2: one precise and one more general; do we have expectations?
Lloyd McKenzie (Aug 25 2021 at 15:47):
There's typically no expectation that a recipient understand any of the codings. The codings don't have to be equivalent. They have to be valid codings of the concept being represented. They can have significantly different granularity. E.g. You could have one code that says "abdominal issue" and another that says "minor tear on left dorsal edge of appendix" (if that's even a thing - a doctor I am not :>)
Rob Hausam (Aug 25 2021 at 16:11):
Yeah - I think that's not a thing - but otherwise I agree. :)
Saul Kravitz (Aug 25 2021 at 17:16):
@Lloyd McKenzie I'm interested in your take on the CDC standard practice of taking snapshots of HL7 codesystems/valuesets and including them in PHINVADs with new OIDs as their identifier. See https://jira.hl7.org/browse/FHIR-33149 . In the VRDR current STU2 ballot IG, some codesystems are referred to by their HL7 URL and their PHINVADs OID ....sigh.
Lloyd McKenzie (Aug 25 2021 at 19:28):
Nothing stops people from creating whatever OIDs they like for HL7 code systems - but they can't use those as 'system' URIs in value sets. They could say that they've created a different code system, in which case they can make up whatever URI they like. In that case, they're conformant, but they're theoretically violating HL7 IP. I'm not totally sure what license HL7 terminologies are licensed under, but I don't think it's the "CC0" license we use for the core spec, in which case cloning and re-identifying would be legally just fine.
However, legally fine or not, from an interoperability perspective it's a horrible and profoundly counterproductive thing to do. Given that VSAC is supposed to be helping to foster interoperability, it's certainly something that shouldn't happen. @Robert McClure (when you're back from your travels)
Michael Lawley (Sep 02 2021 at 22:08):
:100:
However, legally fine or not, from an interoperability perspective it's a horrible and profoundly counterproductive thing to do.
Last updated: Apr 12 2022 at 19:14 UTC
