Stream: implementers
Topic: Constraining "Required" ValueSets
Richard Kavanagh (Sep 07 2016 at 13:32):
If an element within a Resource is bound to a "Required" ValueSet, is it legal to restrict (constrain) that ValueSet or does it have to be used in its entirety?
Paul Knapp (Sep 07 2016 at 13:34):
You may constrain (logical subset) in profiles or in use but not exchange with a valueset containing other values or extend.
Aditya Joshi (Sep 07 2016 at 13:35):
Hi Richard. You can use any codes from that ValueSet as per your requirement and can constraint or create subset from the values given in ValueSet. Required means, you cannot extend (with your own codes) the ValueSet codes. It is like HL7 Defined tables (data type ID) in V2.
Richard Kavanagh (Sep 07 2016 at 13:49):
Thanks
John Moehrke (Sep 07 2016 at 13:52):
RIchard, If you see a need, now is a good time to express that need. You might have a use-case that has not yet been considered.
Richard Kavanagh (Sep 07 2016 at 15:59):
In this case our use case is a very local one. Within the NHS in England we have national standards for such things as gender, marital status, language, country codes etc. Unfortunately in places FHIR chooses to provide "required" valueSets for these which causes us a world of pain. Where our national valueset can be mapped to a subset of the FHIR valueset then we can get by.
We have other issues where this is not possible and we are raising changes which may or may not be picked up in STU3. For now we are having to do some relatively clunky modifier extensions to get around these.
Lloyd McKenzie (Sep 07 2016 at 19:45):
In HL7 Core Principles, we have the concept of both "minimum" and "maximum" bindings - maximum bindings identify the complete set of what's permitted to be used and minimum bindings identify what must be supported (and can't be later constrained out). At the moment FHIR only deals with maximum bindings - it's generally hard enough to get agreement there. I suspect at some point we'll add extensions to let implementers define "minimum" bindings when they want to say "and by the way, systems must be able to handle at least all of this subset and can't constrain them out.
Michel Rutten (Sep 07 2016 at 20:07):
Those extensions have already been defined:
https://simplifier.net/core-extensions/elementdefinition-minValueSet
https://simplifier.net/core-extensions/elementdefinition-maxValueSet
Lloyd McKenzie (Sep 07 2016 at 20:26):
Why do you have an extension for maxValueSet?
Grahame Grieve (Sep 07 2016 at 21:57):
I defined it. From the description: The maximum allowable value set, for use when the binding strength is 'extensible'. This value set is the value set from which extensions can be taken from
Lloyd McKenzie (Sep 07 2016 at 23:36):
But how is that different from "required"?
Lloyd McKenzie (Sep 07 2016 at 23:36):
You're saying "only codes from this value set are permitted" - which is what required does . . .
Grahame Grieve (Sep 08 2016 at 00:02):
if the binding strength is extensible,
Lloyd McKenzie (Sep 08 2016 at 03:23):
If the binding strength is extensible, that means you can use any code from any system if your concept is outside the specified value set. If you want to say "you must use only this set of codes" - which is what you're doing with your "max", then that's a required binding
Grahame Grieve (Sep 08 2016 at 04:06):
what you are saying is that the value set is extensible, *but* if your concept is outside the speciifed value set, it still must be drawn from a bigger value set
Lloyd McKenzie (Sep 08 2016 at 06:01):
Then it's not extensible. Instead, the value set is the larger value set. Because there's no requirement to support any of the codes in the small value set, there's no point mentioning it at all - you just have a required binding to the larger value set. Extensible means you can use any code you like - or no codes at all - for concepts outside the value set.
Grahame Grieve (Sep 08 2016 at 07:50):
not so. Extensible means that if one of these codes is correct, you must use it. Simply going with the max value set loses that.
Lloyd McKenzie (Sep 08 2016 at 20:22):
But if you have a required value set, you haven't lost anything unless your "big" value set includes duplicate concepts - which would be poor design. With the big value set, you'd be saying "you must use whichever one of these big value set codes applies". With small extensible value set plus big value set, you'd still be saying "you must use whichever one of these big value set codes applies" - adding "and by the way if one of this subset of the big value set applies, you must use that" is redundant.
Grahame Grieve (Sep 08 2016 at 21:13):
the use case I was given - one that's come up in more than one context is 'this SCT value set', but if you can't, it still must be a SCT concept.
Lloyd McKenzie (Sep 08 2016 at 21:34):
So, from a validation perspective, how is the behaviour different than simply saying "the value set is any SNOMED CT code"? Do you agree that your max binding is essentially doing a required binding to all of SNOMED? If not, how would it be different?
Grahame Grieve (Sep 08 2016 at 21:36):
yes, the max binding is doing a required binding to all of snomed. but providing a extensible binding to a snomed ct subset, and a required binding to snomed, that's different than just providing a required binding to snomed
Lloyd McKenzie (Sep 08 2016 at 21:42):
What's the difference from a validation/conformance testing perspective? Is it the fact that SNOMED allows you to say the same thing multiple ways (and thus, a value set of "all of SNOMED" is, automatically, a poorly designed value set)?
Grahame Grieve (Sep 08 2016 at 21:43):
I don't know that any computable testing can test the difference. But manual inspection could.
Grahame Grieve (Sep 08 2016 at 21:43):
and I don't think 'all of snomed' is a poorly designed value set. It might be eay to use it poorly
Lloyd McKenzie (Sep 09 2016 at 18:26):
From a good vocabulary practice perspective, it's a "questionable" value set because there are multiple ways to convey the same concept, but I guess it wouldn't qualify as "poorly designed" because it's still a single code system. If the intention is to say "you must send this concept as pre-coordinated, but other concepts can be whatever you like", then I guess that works. To me, this is actually an example of multiple bindings - you have both a required binding and an extensible binding that tightens down how you're allowed to send certain concepts.
Last updated: Apr 12 2022 at 19:14 UTC
