Stream: terminology
Topic: UTG / FHIR Core - inconsistencies
Alexander Henket (Mar 17 2021 at 06:37):
Looking through UTG I noticed at least this two missing compared to FHIR Core - canonicals http://hl7.org/fhir/ValueSet/adverse-event-outcome and http://hl7.org/fhir/ValueSet/yesnodontknow (not the same as v2-0532)
The first value set looks like unfinished work (FMM 0), and the second is example without FMM assigned . Is there a threshold before a value set should be called out in UTG, or should process be that any FHIR Core value set is represented in UTG? I did not do a full comparison.
Alexander Henket (Mar 17 2021 at 09:46):
"Slightly" more worrying: http://hl7.org/fhir/administrative-gender is also missing from UTG. That can't be right?
Lloyd McKenzie (Mar 17 2021 at 14:14):
If the value set is only used in a 'code' element, then it's not maintained in UTG - because changes drive schema changes and thus can only occur as part of an official release of FHIR. Changes must be requested through the FHIR change tracking process, not through UTG requests. That explains gender. We also said that low maturity (FMM2 or less) value sets and code systems shouldn't migrate (though I had thought they'd unfortunately been migrated anyway?) The argument there was we didn't want to jump through the hoops of regular terminology rules in terms of breaking changes when dealing with low maturity content. No clue why yesnodontknow didn't migrate.
We're exploring the option of replicating those terminologies that 'live' in the FHIR spec as read-only in terminology,hl7.org, updated whenever there's an official release. However, we don't have that process in place yet.
Alexander Henket (Mar 19 2021 at 07:38):
If the value set is only used in a 'code' element, then it's not maintained in UTG
That's awkward. I understand they need to be stable per FHIR version and I want them to be, but that is just a question of governance rules at UTG. By keeping those away from UTG you're effectively creating your own UTG domain within FHIR. I mean: even the structural terminology from V3 is in UTG and that cannot change either unless you update the RIM version (or at least that is how it used to work).
Okay so here's my problem: I'm looking for the source materials underpinning FHIR terminology. The FHIR Core STU3 and R4 materials are broken for at least the OIDs inside (CodeSystem.identifier and ValueSet.identifier) so those are unreliable and dangerous for me to use because I care about OIDs at least as much as the URIs. UTG fixes those OIDs, but FHIR as you indicated withholds certain CodeSystems and ValueSets from UTG so UTG is also unreliable because it is inherently incomplete.
What would be your advice if you needed the reliable and complete set of CodeSystems and ValueSets for STU3, R4 and beyond?
Lloyd McKenzie (Mar 19 2021 at 13:28):
V3 codes were allowed to evolve via harmonization - though they only manifested in the next release. That was confusing to many. UTG replaces harmonization. We made it very clear when FHIR terminology was moved into UTG that code-bound vocabularies would only be managed through the ballot process.
OIDs aren't super relevant for code-based terminologies. However, the intention is that eventually FHIR code-based terminologies will be surfaced (as read-only) in UTG. So that will, eventually, be your 'mostly' one-stop-shop for code systems. (There's no expectation that most value sets will live in UTG, and IG content that's low maturity will also not typically be exposed in UTG given that it's not content that should be used by anyone and isn't stable/reliable.)
Alexander Henket (Mar 19 2021 at 22:25):
Given that I have to marry V3 and FHIR and given that URIs are irrelevant in the V3 space, I have no choice but to care about OIDs.
I'm rewriting the scripting to read any OID/URI pair from UTG, and any OID/URI pair in the FHIR Core specifications not represented in UTG. That makes UTG leading for OID/URI connections, and FHIR filling in the blanks.
Content wise, I'm assuming that the FHIR holds the only source of truth for FHIR CodeSystems/ValueSets regardless of any deviations that UTG might have. Does that sound like a fair working theory or should I rewrite to read any UTG as leading, and fill in the blanks with what FHIR Core has that UTG does not?
Lloyd McKenzie (Mar 19 2021 at 22:37):
I'm saying if you're talking about a 'code' (rather than Coding or CodeableConcept), your instances won't have OIDs or URIs.
Lloyd McKenzie (Mar 19 2021 at 22:38):
For content that shows up in UTG as read-only, the FHIR specs will be source-of-truth. For other content (which shouldn't be showing up in FHIR specs at all except as references), UTG is source of truth.
Alexander Henket (Mar 19 2021 at 22:43):
By readonly you mean ValueSet.immutable=true? I'm not seeing a marker like that on CodeSystem
Lloyd McKenzie (Mar 19 2021 at 22:48):
No. They won't be marked as immutable. There won't be anything different about them in the resource instances. But they'll be referenced by a List that says they can't be updated via the UTG process.
Lloyd McKenzie (Mar 19 2021 at 22:48):
The only way to get them to change will be submitting a specification feedback issue and getting the work group to vote on it.
Lloyd McKenzie (Mar 19 2021 at 22:49):
(And then, the change won't manifest until the next official publication of the specification that uses them.)
Alexander Henket (Mar 19 2021 at 22:59):
I see List-fhir-Normative.json and List-fhir-Rendering.json in the package. Both are not descriptive in what they aim to be.
On https://terminology.hl7.org/documentation.html there is a little sentence "Value Sets and Code Systems defined as an integral part of the FHIR specification are still managed by the FHIR governance processes;"
But all in all I'm not clear yet on how to determine if a CodeSystem/ValueSet has source of truth in UTG or in FHIR if it lives in both.
Which List do I read, what in?
Lloyd McKenzie (Mar 19 2021 at 23:02):
The list isn't there yet - because the code systems you're interested in (e.g. gender) aren't there yet.
Lloyd McKenzie (Mar 19 2021 at 23:03):
And no ETA on when they will be. Right now, energy is focused on R5.
Alexander Henket (Mar 21 2021 at 10:51):
Okay. I've created https://jira.hl7.org/browse/UP-179 in the mean time which deals with the STU3 system URIs being R4 in UTG.
So I think this is the current thing:
- DSTU2 should be based on solely on FHIR Core DSTU2 spec
- STU3/R4: for uri in fhir-core-uris lookup OID in UTG R4 (because UTG STU3 is broken), fallback on fhir-core-oids in some cases
Last updated: Apr 12 2022 at 19:14 UTC
