Stream: terminology
Topic: FHIR-specific SIDs
Lloyd McKenzie (Oct 23 2018 at 01:13):
We've defined SIDs for a number of external code systems ICD10, ICD9, NDC codes, etc. All of these are rooted in the FHIR namespace - e.g. http://hl7.org/fhir/sid/ndc. However, none of these URLs are really FHIR-specific. If you wanted to, you could easily send these URLs to identify the code system in v2. We just went through a major exercise to shift all of our v2 and v3 code systems to a "neutral" URL reflecting our migration to a unified terminology maintenance process. That's a nasty and painful process - and we're quite certain we're done with it. However, do we want to make the same change for external code systems? Doing so would be painful, but if we're going to make the change, doing it in R4 in parallel with the changes to the other code systems seems like the time to do it. It would presumably mean a shift to something like http://terminologies.hl7.org/sid/ndc.
@Grahame Grieve @Rob Hausam @Ted Klein ?
Grahame Grieve (Oct 23 2018 at 02:01):
I'm moderately opposed to changing these - seems like change for change's sake, but agree that if we're going to do, it has to be now.
Grahame Grieve (Oct 23 2018 at 02:03):
we moved what we moved to terminology.hl7.org because that was necessary to reflect their ongoing management arrangements. But that won't be true for the sids. So changing them only increases maintenance on our side with no upside so far as I can see
Grahame Grieve (Oct 23 2018 at 02:04):
and no upside for implementers
Lloyd McKenzie (Oct 23 2018 at 02:28):
Agree it's not critical. And agree that it involves work - work to do the conversion and work to do the hosting. The main reason for doing it is to avoid confusion. Putting content that's not actually "FHIR" in the FHIR namespace is inevitably going to confuse implementers. And there will absolutely be those who say that they can't send "http://hl7.org/fhir/sid/ndc" in a v2 message because they're not doing FHIR. Plus, it makes it easier for terminologies.hl7.org to be seen as the "primary" source for terminologies in HL7. In practice, a lot of the guidance in our terminology pages should actually be maintained outside the FHIR spec because it's as applicable in CDA and v2 as it is in FHIR (though we do have some FHIR-specific guidance too). We might want to move some of that at some point - and that'll be easier if the primary location is already FHIR independent.
I won't go to the wall for this change, but I think that long term, it would be a better thing. This is certainly the last opportunity the change could be made. If we don't do it now, it's never going to happen.
Rob Hausam (Oct 23 2018 at 03:02):
I agree that it's better for these to be consistent with the rest. I wouldn't go to the wall for it, either, but I think it will be easier to make sense of it in the long run if we are able to make the change now. Having these urls stay in the FHIR namespace when they're not FHIR-specific and there isn't a reason for them to be there other than deciding not to change them is workable, but, as Lloyd said, probably not the best long term.
Grahame Grieve (Oct 23 2018 at 06:29):
if anything, this is an argument not to change them. Almost all of them already have OIDs and entries in table 0396 so the URLs should not be used outside FHIR
Grahame Grieve (Oct 23 2018 at 06:30):
and even if they should be used in v2, it would only because we said so in table 0396
Lloyd McKenzie (Oct 23 2018 at 14:49):
Are we saying that OIDs are preferable to URLs in v2? I guess that's a good marketing ploy for FHIR, but "ick".
Robert McClure (Oct 23 2018 at 17:27):
It seems to me that by promoting the use of urls as the canonical identifier we also need to accept the responsibility of creating a registry to help implementers find the item referenced since the canonical identifier can't change and therefore the "url" can eventually become a uri and we'd loose a major benefit of the url capability. I see that as a huge issue for terminology artifacts because the FHIR approach really does liberate terminology by making it "always available, always resolvable."
Given that, I'd not push to make the changes if we commit to providing a registry to resolve canonical urls for any item included in a published HL7 specification. I'm hoping UTG could eventually do that. If so, then we tell implementers that they should treat the canonical url as a "meaningless resolvable identifier" so don't read too much into the words included. Just like we do with OIDs. Of course humans will still want to jump to conclusions.
Rob Hausam (Oct 23 2018 at 17:50):
I think that's likely to be the best solution ultimately.
Grahame Grieve (Oct 23 2018 at 20:58):
Are we saying that OIDs are preferable to URLs in v2
no I meant OIDs in CDA, since that is mandated. We could add OIDS to table 0396 but that would seem... ick... yes
Lloyd McKenzie (Oct 23 2018 at 21:26):
When tables aren't listed in 0396 - which is most of them - you can use either an OID or a URL to identify them in v2. Which means the FHIR URLs might manifest in v2 instances. I accept that's a low-probability and low-frequency outcome though.
Ted Klein (Nov 03 2018 at 11:32):
Just saw this...all tables are in 0396, but there is an 'implicit' entry there that needs to be enumerated, and it is on my to-do list...sigh...the V2 coded datatypes in 2.6 and later explicitly have components for OIDs in them; they were added to support V2-CDA interoperability quite a few years ago. I don't really see a point in adding yet another bunch of components to hold the URI, nor do I see an advantage to adding yet another synonym for the V2 code systems (besides the table number, the mnemonic, and an OID) to table 0396.
Lloyd McKenzie (Nov 03 2018 at 14:35):
In theory, the URL is going to be more relevant to the implementer community than the OID is in a few years. The purpose of the multiple representations is to aid conversion - and perhaps to nudge implementers toward using the same identifier as the other standards they're most likely to convert to and from.
Grahame Grieve (Nov 03 2018 at 19:34):
We certainly don’t want new components in v2
Last updated: Apr 12 2022 at 19:14 UTC
