Stream: terminology
Topic: Designations from code system supplements in Coding.display?
Rob Hausam (Jan 09 2020 at 17:47):
Unless I've overlooked it, it seems that we've only barely touched on the question of whether you can use a designation from a code system supplement in a resource instance in Coding.display. I can't find anything documented in the spec that specifically addresses it, and searching back in Zulip this is all that I found (from 2018-03-20):
Michael Lawley: 1. Can a supplement specify and alternative display value for a concept?
- Can it specify an alternative use code for a designation?
Grahame Grieve: #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
And this from 2018-11-16:
Xiaocheng Luan: Hi everyone, I work in Paul's team, new to FHIR. Guess my main confusion is what exactly a supplement is. I could imagine two extreme views:
(1) A supplement is a "patch" to the code system it references, it's not a code system by itself (and thus can't be used in a Coding). A supplement-aware terminology server considers it to be part of the code system it "supplements".
(2) A supplement is a code system of its own right, it "inherits" the definitions from the code system it references and adds extra, much like a subclass in the context of object oriented modeling. It thus has its own code system URL (e.g., loinc.org-ext1) and can be used in "Coding".For the "patch" view in (1), there could be issues of local vs. global/standard, and consistency issues across terminology servers on specific code systems (with/without different supplements defined).
For the "subclass" view, it may obligate terminology servers hosting such "supplement/subclass" code systems to be fully aware of/support the filters, properties, etc., defined in the original (parent) code system?
This "subclass" view was what I thought it should roughly be but it does not appear to be the case based on the conversations in this thread?Lloyd McKenzie: A code system supplement is absolutely constrained to be #1. It cannot define new codes, nor can it define new meanings for codes. However, it can define new properties, new display values and/or new relationships for codes defined in another code system.
Lloyd's take on it isn't particularly detailed but it sounds at least somewhat more permissive. So is the consensus still that an additional designation that is specified in a code system supplement cannot be used to populate an instance of Coding.display, or is this something that we do (or want to) allow?
Lloyd McKenzie (Jan 09 2020 at 17:58):
It's certainly something we need to allow. However, it may be that the value set will need to acknowledge the supplements that are in scope for the use of that value set. (We can't expect a validator to check for displays defined in supplements it doesn't know anything about...)
Rob Hausam (Jan 09 2020 at 18:26):
Yes, we will need to consider that. If the supplement is included in an IG (package), would it also need to be declared in the value set definition(s)? Probably so, but we should look at all of the possible options.
Lloyd McKenzie (Jan 09 2020 at 18:32):
Sounds like a good thing for Vocab to discuss :)
Lloyd McKenzie (Jan 09 2020 at 18:34):
If it's just any supplement that happens to be available in the hierarchy of dependencies or in the local guide, that makes things easier for the specifier, but somewhat harder for the tool. It also creates some challenges with using terminology services - as you'd need the terminology service to be aware of the supplements. Would also need to consider whether it's allowed to point to a supplement that isn't part of the hierarchy of dependencies or local guide, or whether you must always have a dependency.
Ken Sinn (Jan 09 2020 at 20:49):
I'm getting the following error if I use -sct ca to run against the canadian set
Error @ ImmunizationRecommendation.recommendation[0].targetDisease.coding[0] (line 12, col2) : Unable to provide support for code system http://snomed.info/sct version 20611000087101 for 'http://snomed.info/sct#36989005' --
Without -sct ca, I get the following, similar to yours.
Error @ ImmunizationRecommendation.recommendation[0].targetDisease.coding[0] (line 12, col2) : Unable to provide support for code system http://snomed.info/sct version 900000000000207008 for 'http://snomed.info/sct#36989005'
In both instances, the code should have been found.
Grahame Grieve (Jan 10 2020 at 03:21):
we certainly do not want value sets to have to explicitly declare language packs. But we've pretty much agreed here before that they need to declare supplements if they use them in filters
Rob Hausam (Jan 10 2020 at 03:39):
I think we did agree on that. But I'm not sure at that point how thoroughly we had considered all of the possible use cases. I'm not saying for sure that I think we could or should do something different - just that we may not have explored all of the possible scenarios fully. I'm thinking particularly in the IPS context with the use of and desire to communicate multiple languages. I think it does work with the current Coding.display rules - but the Immunization example that we had in the IPS spec wasn't following that, and that's what I'm cleaning up now.
Patrick Werner (Jul 27 2020 at 16:02):
We are currently evaluating how to use: http://hl7.org/fhir/ValueSet/iso3166-1-2 with german displays.
As this will be a language pack with no filters i assume, that i have to create a CS with a new URI.
supplements has to be pointing to: urn:iso:std:iso:3166
Patrick Werner (Jul 27 2020 at 16:03):
can i then just add the concepts, just insert a german display value and setting the CS language to DE ?
Rob Hausam (Jul 27 2020 at 16:07):
I don't think you should create a new code system (I'm pretty certain that HTA would not agree with that). It sounds like this is appropriate to do with a code system supplement.
Igor Sirkovich (Jul 28 2020 at 03:20):
Coincidentally, we've just tried to use http://hl7.org/fhir/ValueSet/iso3166-1-2 too, however, it doesn't seem to work yet as the IG Publisher generates an error and replaces this with a blank binding in the profile.
Patrick Werner said:
We are currently evaluating how to use: http://hl7.org/fhir/ValueSet/iso3166-1-2 with german displays.
As this will be a language pack with no filters i assume, that i have to create a CS with a new URI.
supplements has to be pointing to: urn:iso:std:iso:3166
Grahame Grieve (Jul 28 2020 at 04:23):
uh? what's an example?
Patrick Werner (Jul 28 2020 at 10:23):
Rob Hausam said:
I don't think you should create a new code system (I'm pretty certain that HTA would not agree with that). It sounds like this is appropriate to do with a code system supplement.
I also thought i will create a CS with the same canonical URI, but with a different language, then i read: https://www.hl7.org/fhir/codesystem.html#supplements which states:
- The CodeSystem.url for a supplement SHALL never appear in a Coding.system
- The CodeSystem.url for a supplement must be under the control of the authority creating or publishing the supplement (e.g. not in the same space as the code system being supplemented, unless the supplement is being issued by the same authority as the original code system+
Patrick Werner (Jul 28 2020 at 10:23):
So i'm confused on how to provide a supplement just for german display values.
Grahame Grieve (Jul 28 2020 at 10:34):
so that means that you can't publish a supplement with a URL like http://hl7.org/fhir/CodeSystem/3166-supplement, because you aren't hl7.org (though you could ask us to do that). But you can publish it as http://hl7.de/fhir/CodeSystem/3166-supplement because you have the authority to do so (assuming you act on behalf of HL7 germany in this case)
Patrick Werner (Jul 30 2020 at 09:13):
Understood, thanks.
What about this use-case: an uv profile defines a VS Binding. This VS contains english displays. For the German Implementation we want to have german displays, but not violating the VS Binding.
Patrick Werner (Jul 30 2020 at 09:15):
So i would create a CS with a different URI, containing the same concepts, but with german display values. Mark it as supplement?
Patrick Werner (Jul 30 2020 at 09:16):
And it would be up to the server/validator, to pick up the supplement(s) when expanding the VS?
Patrick Werner (Jul 30 2020 at 09:17):
Or do i have to take the original CS, extend the concepts with designations, give it another uri than the original CS?
Patrick Werner (Jul 30 2020 at 09:23):
P.S.: i missunderstood: "The CodeSystem.url for a supplement SHALL never appear in a Coding.system" which means i still code with the original CS URI, and never insert the supplement CS URI, which has to be a different URI.
Grahame Grieve (Jul 30 2020 at 11:03):
I think you need to change the binding to a binding that invokes the supplement
Patrick Werner (Jul 30 2020 at 13:55):
which breaks conformance in a derived profile
Patrick Werner (Jul 30 2020 at 13:58):
@Michael Lawley i heard you might be interested in language specific expansions as well.
Lloyd McKenzie (Jul 30 2020 at 14:49):
@Patrick Werner Why would it break conformance?
Lloyd McKenzie (Jul 30 2020 at 14:49):
You're allowed to change even required bindings - you just can't increase the set of codes available.
Patrick Werner (Jul 30 2020 at 14:51):
oh! right.
Patrick Werner (Jul 30 2020 at 14:52):
Thanks for the clarification
Michael Lawley (Jul 30 2020 at 20:56):
Yes, if you change the binding to an equivalent ValueSet (eg by including the original) that also references the supplement, then $validate should take into account the german displays.
Last updated: Apr 12 2022 at 19:14 UTC
