Stream: shorthand
Topic: Defining a Max binding?
Jean Duteau (Apr 13 2020 at 19:15):
Is there an easy way to define a max binding on a coded value? If not, what would be the non-easy way to do this?
Keith Boone (Apr 13 2020 at 19:19):
I used to know what that means, but have forgotten. What does it mean?
Jean Duteau (Apr 13 2020 at 19:22):
the max binding defines the full set of codes that you'd accept with your actual binding being the preferred (or extensible) set of codes that you want
the common example is language where the binding is CommonLanguages with a MaxBinding of AllLanguages.
in my case, I have a Condition representing Anaphylaxis so I have a set of SNOMED and ICD-10-CM codes that represent Anaphylaxis. I have Condition.code with a preferred binding to this value set, because we might miss some but I want to ensure that if you do send me a code, that you are restricted to the US Core Condition Code value set.
Nick Freiter (Apr 13 2020 at 19:29):
In this example from US Core, https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-documentreference.html, the DocumentReference.type element has a Min binding on it, here is how you would accomplish that with FSH:
Profile: MyDocReference Parent: DocumentReference * type ^binding.extension[1].url = "http://hl7.org/fhir/StructureDefinition/elementdefinition-minValueSet" * type ^binding.extension[1].valueCanonical = "http://hl7.org/fhir/us/core/ValueSet/us-core-clinical-note-type"
You have to use the ^ syntax to directly operate on the type element. The extension is not being placed on an element in the Structure Definition, but rather on a field within the type element itself. I think you'd want to do something very similar to set a max binding.
Jean Duteau (Apr 13 2020 at 19:30):
@Nick Freiter thanks, that looks perfect.
Chris Moesel (Apr 13 2020 at 19:37):
BTW -- in the example above, @Nick Freiter used type ^binding.extension[1] because type already had another extension on it in the US Core example. Assuming max value is the only extension on your use case (Condition.code), you'd want to use: code ^binding.extension[0]...
David Hay (Apr 13 2020 at 22:20):
Shouldn't the parent be the US-Core DocumentReference rather than the base DocumentReference then?
Jean Duteau (Apr 13 2020 at 22:22):
no, he's showing us how you would replicate the US-Core DocReference in FSH
David Hay (Apr 13 2020 at 22:27):
Ah - he left out the existing extension (from USCore) in the example above...
Jean Duteau (Apr 13 2020 at 22:27):
yes
David Hay (Apr 13 2020 at 22:30):
Just out of interest (and as I'm too lazy to check for myself) if the example HAD set the parent to USCore, would you still need to use the [1] indexer? (as the parent already had the extension on it) or could you leave it out (or use [0])...
Chris Moesel (Apr 13 2020 at 22:39):
Actually, I just looked at the US Core DocumentReference and it looks like the minValueSet extension is the only extension on type in US Core -- so I don't know why @Nick Freiter used the [1] indexer. I suspect it was a copy/paste error. Nick's example should have used extension[0].
To answer @David Hay's question, if you declare US Core DocumentReference as your parent, you automatically inherit its constraints, so you get the minValueSet extension for free (whether you want it or not). If you wanted to add a maxValueSet extension, you would need to use extension[1] because if you tried to use extension[0], it would attempt to overwrite the existing extension (which is not allowed).
David Hay (Apr 13 2020 at 22:45):
Thanks @Chris Moesel !
Keith Boone (Apr 14 2020 at 05:45):
So if we put Max binding and min binding into FHIR Terms, the min = the preferred set, and the max = required set. I would a) bind to a required value set (that's the max), and define that value set in terms of two other value sets: a) The preferred value set (the min), and b) everything else. Creating an extension for Max doesn't establish an enforced constraint with existing tooling, which is perhaps why there's already a min extension rather than a max. The min extension sort of does what I suggested using already existing value set mechanisms, but makes it clear that one of them is the MIN.
Grahame Grieve (Apr 14 2020 at 06:13):
min != preferred
Grahame Grieve (Apr 14 2020 at 06:13):
Creating an extension for Max doesn't establish an enforced constraint with existing tooling
yes it does
Nick Freiter (Apr 14 2020 at 11:59):
I used the [1] indexer intentionally because the original base DocumentReference resource does have an existing extension on type.binding. The FSH I gave leaves this existing extension, while it appears this extension is overwritten in US Core. I didn't want to give FSH that overwrites the existing extension, so that is why there is a difference.
Reece Adamson (Apr 14 2020 at 19:04):
TIL, interesting thread. I saw this previous discussion that discusses minValueSet and maxValueSet for those who want some more background:
Mark Kramer (Apr 18 2020 at 11:52):
What if FSH offered something like this?
- foo from MyPreferredValueSet (preferred)
- foo from MyMaxValueSet (max)
Jean Duteau (Apr 18 2020 at 14:59):
and
- foo from MyMinValueSet (min)
Mark Kramer (Apr 19 2020 at 13:22):
Submitted issue: https://github.com/FHIR/sushi/issues/371
Chris Moesel (Apr 20 2020 at 13:37):
I think the question here is whether or not min/max VS are used enough to warrant adding them as a 1st-class feature of FSH. For some reason, FHIR has chosen not to support them as 1st-class properties -- so why should FSH? That's an honest question, with no negative connotation intended.
If they are not commonly used, including them in FSH may just make things more complicated/confusing for the 95% (???) of authors who don't use them -- as now you need to understand not only the differences between the normative bindings, but also the min/max bindings and understand which binding flavors can be applied concurrently and which ones cancel out previous values... Again, not arguing against it, but trying to think of the implications of adding these to FSH grammar (as every feature you add to the grammar, by definition, increases the grammar's complexity).
Mark Kramer (Apr 20 2020 at 16:41):
The issue is there to be racked and stacked against priority of other issues.
Grahame Grieve (Apr 20 2020 at 21:14):
For some reason, FHIR has chosen not to support them as 1st-class properties
It's on the plan for R5
Grahame Grieve (Apr 20 2020 at 21:15):
you need some strategy to avoid people having to say "I just can't use FSH because I need a min or max value set"
Chris Moesel (Apr 21 2020 at 00:17):
@Grahame Grieve said:
you need some strategy to avoid people having to say "I just can't use FSH because I need a min or max value set"
FSH supports it now via the same way FHIR does: by allowing the author to specify an extension. So it's no harder in FSH than it currently is in FHIR.
This discussion was about whether we should make it even easier to do in FSH than in FHIR (by abstracting away the fact that it is an extension). Knowing that FHIR R5 will support min / max VS more directly, I think it's easy to justify FSH adding special support in the grammar for it. Thanks for that tidbit of info!
Grahame Grieve (Apr 21 2020 at 00:54):
I don't think it should be easier than that.
Chris Moesel (Apr 21 2020 at 02:32):
@Grahame Grieve -- I think I may be confused. You said above that "It's on the plan for R5" regarding making min/max VS "1st-class properties". So that sounds to me like FHIR is planning to make min/max VS easier to use. But you also said "I don't think it should be easier than that" regarding the need to currently use extensions for min/max VS. Did I misunderstand something?
Grahame Grieve (Apr 21 2020 at 03:06):
for now, you shouldn't make it easier. When we add multiple bindings in R5, then FSH should follow along.
Grahame Grieve (Apr 21 2020 at 03:06):
cause then we'll know what it looks like
Last updated: Apr 12 2022 at 19:14 UTC
