Stream: terminology
Topic: CS/VS URIs for FHIR/V3/V2
Alexander Henket (Jan 23 2019 at 17:59):
As of R4 the system uri for all HL7 managed valuesets and codesystems was updated to something "http://terminology.hl7.org/..."
What's the expectation for DSTU2/STU3 systems? Should they be capable of supporting what was valid at the time only, or should every system be NamingSystem aware and be expected to deal with any identifier for the same object? The latter would be impossible without a leading NamingSystem repository I guess, so I'm assuming it's the former.
Grahame Grieve (Jan 23 2019 at 18:21):
you have to support the correct identifier for the version as specified...
Grahame Grieve (Jan 23 2019 at 18:21):
we haven't talked seriously about a naming system registry, but I think we should
Alexander Henket (Jan 23 2019 at 18:31):
I build mine from http://hl7.org/fhir/STU3/namingsystem-terminologies.xml and http://hl7.org/fhir/STU3/namingsystem-registry.xml and combine those with the current version with the OID as my key to merge.
Alexander Henket (Jan 23 2019 at 18:32):
I basically run an OID registry with URIs as properties.
Grahame Grieve (Jan 23 2019 at 18:33):
yes. it's not rocket science, but we should run one centrally
Alexander Henket (Jan 23 2019 at 18:34):
I don't know how to properly handle 2 URIs in a NamingSystem where one is contextually preferred over the other. Something is preferred in a NamingSystem or it is not. There's no syntax for "preferred for STU3 and below"
Grahame Grieve (Jan 23 2019 at 18:34):
which version of FHIR are the naming systems in?
Alexander Henket (Jan 23 2019 at 18:35):
Their basis is my OID Registry that contains this context. So I guess I could export my NamingSystem contextually
Alexander Henket (Jan 23 2019 at 18:36):
If called from STU3 API I could make the appropriate URI preferred
Alexander Henket (Jan 23 2019 at 18:36):
This NamingSystem would only be true for STU3 then. For R4 it would be other
Alexander Henket (Jan 23 2019 at 18:41):
The version StructureDefintion thing in the meta becomes ever more important
Alexander Henket (Jan 23 2019 at 20:37):
I think I need to do this anyway, as there's been quite some juggling with the OIDs from fhirVersion to fhirVersion. Example: pasted image
Alexander Henket (Jan 23 2019 at 20:38):
The last line without the fhirVersion attribute is whatever comes from the hl7.org/fhir link without specific version.
Grahame Grieve (Jan 23 2019 at 21:58):
that is not supposed to have happened. I'll have to investigate
Alexander Henket (Jan 23 2019 at 22:03):
For DSTU2 you will also encounter the typo for all V2 CodeSystems 133883 instead of 113883. For STU3 you'll find 926 NamingSystems where the oid looks like <value value=".1.113883.4.642.1.197"/> i.e. missing the first bit.
I remember that in the early days Ted was unhappy with the OIDs and some juggling was the consequence. I hope R4 is stable in that sense.
Grahame Grieve (Jan 23 2019 at 22:16):
it better be
Alexander Henket (Jan 27 2019 at 14:35):
I'm missing http://nucc.org/provider-taxonomy (OID 2.16.840.1.113883.6.101) from the STU3 / R4 NamingSystems. It is listed on the http://hl7.org/fhir/terminologies-systems.html page though.
Same for OID 2.16.840.1.113883.5.1105 which apparently is covered by 2 URIs
Alexander Henket (Jan 27 2019 at 14:35):
Are the NamingSystems not the source for the page? @Grahame Grieve
Grahame Grieve (Jan 27 2019 at 20:28):
no the page is edited by hand.
Grahame Grieve (Jan 27 2019 at 20:28):
make a task...
Alexander Henket (Jan 30 2019 at 20:32):
Alexander Henket (Feb 03 2019 at 11:03):
I keep spinning in circles around this and I cannot seem to find closure. Another angle after talking to Frank Oemig. He pointed out that valueset oids existed for the longest time for V2. These are however not used by the NamingSystems in FHIR, and the terminology-systems page column for it is completely empty.
Example: Table 4 Patient Class has ValueSet OID 2.16.840.1.113883.21.5 and CodeSystem OID 2.16.840.1.113883.18.5 which presumably should have mapped onto http://terminology.hl7.org/ValueSet/v2-0004 and http://terminology.hl7.org/CodeSystem/v2-0004.
There are however no NamingSystems for that. Added this to ticket GF#20329
Alexander Henket (Feb 03 2019 at 11:07):
Also the text above the terminology-systems.html table for V2 seems inaccurate because of the final forward slash
URI (all prefixed with http://terminology.hl7.org/CodeSystem/v2-/)
For V3 this looks more accurate: Name (URI = http://terminology.hl7.org/CodeSystem/v3-...)
Grahame Grieve (Feb 03 2019 at 20:01):
I see that FHIR specifies the OID correctly for the code system
Grahame Grieve (Feb 03 2019 at 20:01):
you could make a task to populate the OIDs in the valuesets and create naming systems
Grahame Grieve (Feb 03 2019 at 20:02):
and another to fix the typo on the slash
Alexander Henket (Feb 04 2019 at 09:13):
I could make all those separate tasks, but seems to me that what we need is full alignment between the OID Registry, the NamingSystems, the terminology-systems pages, the HL7 V2+ publications and other derivative works. I get the feeling that we are either lacking proper source-of-truth, or lacking proper derivative works processes.
Would you agree what that and would you think that attacking that is best served by multiple tickets?
Before your reply I had already added that slash thing to GF#20329. Suppose this ticket is the hook for alignment, I could update the description to reflect that purpose. But if you really feel that multiple tickets serve the purpose better I'll go ahead and create them
Grahame Grieve (Feb 04 2019 at 12:47):
indeed we should have full alignment on OIDs, yes. But actually getting there is the problem, with UTG forming, and the source of truth in motion. At least you haven't (yet?) reported anything wrong in FHIR this time
Alexander Henket (Feb 06 2019 at 08:02):
Well the information in the NamingSystems is incomplete, the information in the terminology index pages is incomplete. The terminology pages are at least partly inconsistent with the NamingSystems. Both do not seem to be source-of-truth for HL7, but are source-of-truth for FHIR implementers. Sure the problem is not just FHIR, but I'd disagree that is not FHIR.
What can I do to be useful here? File more tickets? And/or something else?
Grahame Grieve (Feb 06 2019 at 10:17):
It's not clear from what you've said if the information is inconsistent because it's missing, or because it's actually wrong. I think gForge tickets are the place to start
Grahame Grieve (Feb 06 2019 at 10:18):
though some of it till be self-resolving because of UTG - but it doesn't hurt to be sure ;-)
Alexander Henket (Feb 07 2019 at 09:01):
GF#20329 is rather clear in how the inconsistency is meant. I've added GF#20363 for the rest.
Last updated: Apr 12 2022 at 19:14 UTC
