Stream: implementers
Topic: CodeSystem heirarchy
Nick George (Feb 12 2019 at 02:34):
Hello, When a CodeSystem resource defines a heirarchy tree (with relationship extensions), are only the leaf nodes considered valid "codes"?
Peter Jordan (Feb 12 2019 at 03:50):
It's not a question of validity - more a case of whether users should be able to select 'abstract' codes used for navigational purposes. The ValueSet.expansion.contains.abstract
element allows such codes to be marked accordingly.
Michael Lawley (Feb 12 2019 at 04:22):
They are all valid codes. Some (even leaf codes) may be marked as abstract, but that doesn't still doesn't mean they aren't selectable (eg if you're doing analytics you probably do want to select them to craft a query).
Nick George (Feb 12 2019 at 18:14):
even abstract codes can be specified in the json? e.g., here: https://www.hl7.org/fhir/v3/RouteOfAdministration/cs.html, both "_Chew" and "CHEW" are codes that that need to be considered distinct and valid?
Nick George (Feb 12 2019 at 18:18):
to be clear here, by "valid" I mean "can be expected to show up in a code field in a resource"
Lloyd McKenzie (Feb 12 2019 at 19:55):
What you can expect to show up in a resource depends on what the value set is bound to. Based on the intention of the code system, profiles shouldn't allow "_Chew" as a code inside a prescription or dispense record. However, it might be totally valid to appear inside a resource representing a decision support rule.
Nick George (Feb 12 2019 at 21:05):
the valueset expansion seems to include both: https://www.hl7.org/fhir/v3/RouteOfAdministration/vs.html
Lloyd McKenzie (Feb 12 2019 at 21:41):
Right. v3 value sets weren't designed to exclude "abstract" codes because in v3 that happened automatically. What's needed in FHIR is different value sets for the clinical vs. definitional use-cases. @Grahame Grieve, have we given any thought to generating additional value sets for the v3 value sets that filter out the abstract codes?
Nick George (Feb 12 2019 at 21:56):
mostly unrelated question but at least in the same arena: I'm super confused about the relationship between the valuesets, valuesets-v2 and valuesets-v3. For instance, how is it that a v2 valueset can contain references to a v3 codesystem? https://www.hl7.org/fhir/v2/0005/index.html
Lloyd McKenzie (Feb 12 2019 at 22:08):
HL7 is moving to a shared terminology world. We've increasingly been having v2, CDA and FHIR point to each other's terminologies. In FHIR R4, the URLs actually change so that they all come from the same canonical URL (http://terminologies.hl7.org)
Nick George (Feb 12 2019 at 22:09):
sorry if this is a dumb question, and feel free to point me to literature if there is such, but does that mean in "v3" is not a replacement of "v2", but just supplemental? and if so, how does it work retroactively so that v2 can have elements from v3?
Lloyd McKenzie (Feb 12 2019 at 22:18):
v2, v3, CDA and FHIR are all completely distinct standards families (though CDA and v3 share a lot).
Lloyd McKenzie (Feb 12 2019 at 22:19):
v2 is the oldest (over 30 years). v3 is now approaching 20 years old and CDA is about 16 or 17 years old. FHIR is the newest. All families are still 'active' (though v3 isn't very) and have new versions. We're trying to move to a place where the same terminologies can be used regardless of which standard you're using.
Nick George (Feb 12 2019 at 22:41):
gotcha. Thanks for responses. Sorry if I'm being repetitive and missing the point here, but I want to hone in a bit more on the "v3 codesystem in v2" thing. https://www.hl7.org/fhir/v2/0005/index.html is a "v2" valueset, but the codes are from a "v3" Codesystem. If they're completely distinct families, why is there this crossover? is that an anomaly? is "v2" -> "hl7v2" ? is "FHIR" the "Bundle-valuesets.json" without a "v" in the downloaded spec?
Nick George (Feb 12 2019 at 22:42):
again, if there's something written down somewhere that I should read instead of pestering you, feel free to 302 me there
Lloyd McKenzie (Feb 13 2019 at 05:09):
When the world began, v2 and v3 were completely separate from each other. They created and maintained their own code systems for everything. However, in the last 5 or so years, there's been increasing pressure to increase the consistency between them so that when taking v2 data and putting it into a CDA document (CDA is v3-based) or vice versa, you don't have to convert codes. As well, when FHIR came on the scene, we indicated an intention to leverage existing v2 and v3 code systems whenever possible rather than inventing our own. (Of course all 3 standards use external code systems like LOINC, SNOMED, etc.) In the last couple of years, the organization has decided to move to a single integrated terminology maintenance process, so that the codes and valuesets from v2, v3 and FHIR will (largely) be maintained in a single repository and maintained by a single process. We're not quite there yet, but hope to be by the end of the year.
There will still be certain differences for historical reasons, but where feasible, you'll see increased alignment across the three standards - which will hopefully make life easier for implementers that often end up sharing information using more than one of them.
Grahame Grieve (Feb 13 2019 at 11:01):
I don't think we've devoted any attention to having abstract=true and abstract=false versions of the v3 value sets. I think that would be a discussion on the terminology stream
Last updated: Apr 12 2022 at 19:14 UTC