Stream: terminology
Topic: CodeSystem supplements
Michael Lawley (Mar 20 2018 at 23:37):
1. Can a supplement specify and alternative display
value for a concept?
2. Can it specify an alternative use
code for a designation?
Grahame Grieve (Mar 21 2018 at 00:07):
#1 it can add designations. We haven't described any way in which it could replace the display defined by the code system, but we also haven't said that a code system supplement can't define a designation that is the most appropriate to use in a given context.
#2. no. but it can define a new designation with the same value and a new use code
Peter Jordan (Mar 21 2018 at 01:28):
Are supplements permissible for SNOMED CT?
Grahame Grieve (Mar 21 2018 at 01:35):
summary of discussion on call this morning:
- SCT editions are fragments of SCT.
- it's theoretically possible that someone could publish an entire copy of SCT, but no one is empowered to resolve all the conflicts that arise trying to do so
- SCT language packs might be supplements
- there's a useful thing to do with code system supplements: adding external property references to SC concepts (e.g. this SCT concept for lab test has x loinc codes as result tests)
- you could do the same using reference sets in SCT. FHIR is probably easier to author and consume in the FHIR world, SCT reference sets are easier to use across the SCT eco-system
- FHIR has no reason to prohibit SCT supplements
- SCT could probably do so, but why? Inclination seemed to be not to prohibit, but good documentation is required somewhere
Peter Jordan (Mar 21 2018 at 07:44):
Thanks Grahame. It will be interesting to see if supplements are an easier way to implement some of the SCT Reference Set types. An example of a Value Set containing SCT concepts and supplementary information about those concepts might be helpful.
Michael Lawley (Mar 21 2018 at 09:55):
1. Wrt "SCT editions are fragments of SCT.", this was an assertion of Grahame's and I'm not quite sure what it really means (ie. what the implications are). On the surface it seems plausible, but I'd like to understand better how this interacts with, for example, the versioning dimension. It's also not entirely clear what are the practical impacts of fragments; the spec (rightly at this stage) warns about having multiple fragments present in a terminology server.
2. From an IP perspective, I believe anyone with a SNOMED licence is empowered to resolve a merged version of SCT, but the challenge is getting others to accept it for use. I could conceive an national release centre (NRC) attempting such a thing, probably in collaboration/consultation with other NRCs.
3. SCT language reference sets manifesting as supplememts is very appealing, if only to establish "a use of preferred term". Currently there's no way within SCT to mark a designation as unacceptable, but I believe that may be a desirable additional role here. However, I don't fully understand how supplements are referenced as part of a ValueSet definition or in an operation like $expand because I've only just stumbled across http://hl7.org/fhir/StructureDefinition/valueset-supplement which raises some questions for me:
a - why is this not directly referenced?
b - why an extension and not an element in ValueSet
?
c - Why is it typed as Reference(CodeSystem)
and not uri
or canonical
?
4. I don't believe there's any desire (nor authority) for SCT to prohibit supplements since they don't affect the hierarchy or the modeling of concepts
Michael Lawley (Mar 21 2018 at 09:57):
@Peter Jordan do you support supplements with $expand
or $lookup
?
Grahame Grieve (Mar 21 2018 at 11:45):
#1 - agree about the practical issues; in fact, that's a good description of the issue. Agree that the fact that the editions are heavily linked to versioning means that the natural way to think about them is as versions, but underneath that is the fact that the versions are on subsets of the whole. Were one to extract out a frozen version, but still split up into national distributions, then you'd have fragments for real. But I'm not claiming that would be a useful thing to do, and since no one is going to (or, at least, should not try) representing SCT as an actual CodeSystem resource instance, it's all pretty academic
Grahame Grieve (Mar 21 2018 at 11:46):
#3 - we didn't make it a core element yet because we're being conserative. If it gets used enough, we'll probably elevate it. It should definitely be a canonical(CodeSystem) - I realise that I haven't systematically reviewed the extensions. can you create a task for that?
Michael Lawley (Mar 21 2018 at 12:00):
Is there ever a reason for Reference(CodeSystem), Reference(ValueSet), or Reference(ConceptMap) rather than canonical(CodeSystem) etc?
Grahame Grieve (Mar 21 2018 at 12:04):
possibly in a corner case - literal reference. but we've pretty much said not enough justification. just do canonical
Michael Lawley (Mar 21 2018 at 12:06):
Added GF#15808
Peter Jordan (Mar 21 2018 at 19:07):
@Michael Lawley, I don't support supplements in any operation at the moment as, like you, I'm not sure how they can be referenced by ValueSets and for $lookup the 'parent' Code System (let alone an individual code) doesn't contain any reference to a supplement. I'm also still uncertain in general about the use of FHIR to resolve limitations in external (to HL7) code systems.
Carol Macumber (Apr 11 2018 at 13:37):
@Peter Jordan Ditto, we have yet to implement supplements. We currently support the creation of local "namespaces" that can contain their own concepts AND designations, terms, attributes and relationships to and from other "namespaces". Further, a local "namespace" can contain only associations between other namespaces, which aligns with a FHIR ConceptMapand not a FHIR CoddeSystem..sigh. The local "namespaces" composed of concepts and additional attributes, I think, can be represented as supplements, but time will tell :)
Grahame Grieve (Apr 13 2018 at 10:47):
2 example resources:
Grahame Grieve (Apr 13 2018 at 10:48):
codesystem-example-supplement.xml
Grahame Grieve (Apr 13 2018 at 10:49):
valueset-example-supplement.xml
Grahame Grieve (Apr 13 2018 at 10:49):
These are for testing code system supplement functionality
Grahame Grieve (Apr 13 2018 at 10:49):
Bryn Rhodes (May 24 2018 at 22:39):
@Grahame Grieve , here's the example that I brought up at the CIMI lunch that I don't see how to represent with a Code System supplement: https://github.com/cqframework/opioid-cds/blob/master/pages/cql/OMTKLogic-0.1.0.cql#L140
Bryn Rhodes (May 24 2018 at 22:40):
I don't think we could represent it with a ConceptMap either, because it's not just a straight conversion factor, it depends on the dose and the dose form.
Grahame Grieve (May 24 2018 at 22:40):
we discussed that use case in vocab, and it was one of the key reasons that we dropped ConceptMap back to trial-use - you aren't the only one with that use case
Grahame Grieve (May 24 2018 at 22:41):
or one like it
Michael Lawley (Sep 01 2019 at 22:51):
Looking for examples of CodeSystems supplements to test the new functionality in Ontoserver V6.
Both language translation supplements and property supplements are supported.
@Peter Jordan did you have any of these?
Peter Jordan (Sep 01 2019 at 23:06):
Only a simple example of a language translation supplement that Grahame created - https://terminz.azurewebsites.net/fhir/CodeSystem/bundle-type-german which supplements https://terminz.azurewebsites.net/fhir/CodeSystem/bundle-type
Last updated: Apr 12 2022 at 19:14 UTC