Stream: terminology
Topic: required binding meaning for source system
Eric Haas (Aug 11 2019 at 23:52):
Required binding mean a source system can support 80% of them and still be conforman, I kind of derived it from looking at the min binding extension. http://hl7.org/fhir/StructureDefinition/elementdefinition-minValueSet but @Lloyd McKenzie this particular nugget is not explicitly stated in the spec ( I can't find it)? should it be?
Lloyd McKenzie (Aug 12 2019 at 03:05):
A system can be conformant if it only supports one code. There's an extension to indicate the minimum that must be supported
Robert McClure (Aug 12 2019 at 16:13):
This is a surprise to me if I'm understanding @Lloyd McKenzie . Are you saying that vocabulary has agreed that to be conformant to a required binding, all a system has to do is understand one of the defined members of the required expansion? I do not remember hearing or voting on that and would like to see the specification in FHIR that purports to clarify that.
Grahame Grieve (Aug 12 2019 at 19:26):
there's a subtle but important change there, between 'support' and 'understand'.
Grahame Grieve (Aug 12 2019 at 19:27):
I think we can say that a system cannot mis-understand any of the codes in a required binding. But we do not say anywhere which particular values in an allowed value domain that a system must support
Grahame Grieve (Aug 12 2019 at 19:27):
this is typically a subject that is taken up in particular implementation guides
Peter Jordan (Aug 12 2019 at 20:16):
this is typically a subject that is taken up in particular implementation guides
As one currently tasked to review all the SCT concepts in a CDA Implementation Guide, that makes sense to me! Given that, in practice, there is no guarantee that any given concept will be active in the edition and version of the underlying Code System in use, it would be impractical for an international standard to mandate support for particular concepts in many Value Sets, even where there is a required binding to a VS.
Eric Haas (Aug 12 2019 at 21:03):
So what I am hearing is two things:
1. It may not be obvious to the average reader of the spec that required does not mean that they have to support all the codes.
2. That IGs may define what codes must be supported
Eric Haas (Aug 12 2019 at 21:04):
if not specified in an IG then the only two ways I can think of for the implementation to expose this information is if they create their own profiles or return OperationOutcomes for unsupported codes on queries etc...
Lloyd McKenzie (Aug 12 2019 at 22:24):
Required binding is about what codes are permitted. The set of codes that
are supported MUST be allowed to be a subset and the base binding is (and
must be) silent as to the size and nature of the subset. A profile can use
a standard extension to indicate a "must support" value set if desired.
The core spec never asserts mustSupport about anything. Even mandatory
elements can be hard- coded as fixed values by senders or ignored by
receivers.
It's important that we separate declarations of "what's allowed in the
instance" from "what must implementers actually support/do something useful
with". The latter can only ever be asserted by profiles.
Eric Haas (Aug 13 2019 at 16:37):
I think we need to state that explicitly about required bindings. (for the casual fan)
Grahame Grieve (Aug 14 2019 at 08:42):
make a task...
Robert McClure (Aug 14 2019 at 19:31):
Ok - well this to me sounds like something we need to make very clear to implementers and profile creators as it seems to me to be a BIG hole in how folks will assume the process works. What is the default behavior expected to be? I'm going to guess @Lloyd McKenzie will say an implementer does not have to support any required codes at all. So @Grahame Grieve , tell me what it means in plain english to implement a required binding with none of this specified? What would I be required to do? How do I explain you need to "not mis-understand" all the codes and you don't need to support any of them? What does this mean practically?
Grahame Grieve (Aug 14 2019 at 20:45):
I'm not understanding this. A required binding means that the element, if present, SHALL contain one of the specified codes. Surely that's crystal clear.
Grahame Grieve (Aug 14 2019 at 20:46):
I'm not sure what you think "support any codes" means.
Robert McClure (Aug 14 2019 at 21:14):
@Grahame Grieve I'm asking how this requirement is implemented, I already understand what is expected in the object created. That's easy, you need to be clear about what you are telling implementers to create in their systems.
Grahame Grieve (Aug 14 2019 at 21:18):
I don't know what you mean. It's implemented by doing whatever it takes to make sure that the instance is valid, or that you don't mis-represent it.
Grahame Grieve (Aug 14 2019 at 21:20):
As soon as we start trying to write anything extra about what it means to implement, we run into the problem that there's a limitless number of ways to use FHIR, because who knows what you are trying to do. That's why must-support is never set to true in the base specification; instead, we delegate that to implementation guides, where they may have enough context to make rules about what your system must do
Lloyd McKenzie (Aug 15 2019 at 01:32):
If an element with a required binding is present, it must have a code from the value set. However, it's possible the sender will not "support" some or even most of the codes in the valueset. For example, a system could hardcode Patient.gender as "unknown" if it was trying to comply with US Core. Similarly, a receiver might ignore any codes other than "male" or "female". If you want your profile to dictate more, you have the extension to do that.
Grahame Grieve (Aug 15 2019 at 02:09):
it seems to me that we could be clear in the section about must-support that in the absence of any implementation guidance otherwise, systems are not required to 'support' the entire value domain of any element (or not support the element at all) as long as instances are conformant, and to reference this from the section about required bindings
Robert McClure (Aug 15 2019 at 04:10):
In addition to what @Grahame Grieve has said, I think we need to make clear that even if the element is a "must support" it requires an extension to also define any codes in a value set, even a required one, which codes an implementer must accept and be able to send. The fact that this is an extension in the base is a big mistake IMO - 100% of systems must decide what codes they can send and receive to use - ever heard of semantic interoperability? I'll bet a purchased beer that less than 50% pf FHIR implementers understand the implications of this thread. Asking folks about this at the connectahon would be worthwhile.
Grahame Grieve (Aug 15 2019 at 04:13):
well, you can certainly propose that we change something. It might be time to consider elevating min-valueSet and max-valueSet to base properties of ElementDefinition.binding rather than being extensions. But I don't think that'll help much with the understanding problem.
but while we're talking about we can talk about additional additional other bindings, since we have ongoing discussion about the limitations of a single main binding (@Alexander Henket )
Robert McClure (Aug 15 2019 at 04:14):
I agree with that
Grahame Grieve (Aug 15 2019 at 04:15):
I could certainly extend the IG publisher such that it could represent an expansion with codes that are also in the min-ValueSet binding in bold, for instance, if there was such a binding defined
Rob Hausam (Aug 15 2019 at 04:15):
Yes, we need to talk about allowing for additional bindings
Rob Hausam (Aug 15 2019 at 04:18):
and making min and max-valueSet core in ElementDefinition I think is also a good step, especially since we use it (at least max) in the core spec
Eric Haas (Aug 15 2019 at 20:30):
I think a better place to state the clarification would be here: http://build.fhir.org/terminologies.html#strength by adding to each binding where it is stated "the concept in this element SHALL be from the specified value set" Lloyd's dulcet phrasing : "However, it's possible a system will not "support" some or even most of the codes in the valueset."
Eric Haas (Aug 15 2019 at 20:38):
GF#23707 as a straw man proposal for vocab to gnaw on
Richard Townley-O'Neill (Aug 15 2019 at 23:46):
"However, it's possible a system will not "support" some or even most of the codes in the valueset."
After "support" add a link to some docco on must support, maybe https://hl7.org/fhir/R4/conformance-rules.html#mustSupport
Eric Haas (Aug 17 2019 at 01:44):
OTOH I worry trying to parse out the meaning here it may lead to more confusion than clarity.
Alexander Henket (Aug 20 2019 at 15:12):
I've read this thread cover to cover. As of yet I don't see a use case for min/max value set. Also I was unfamiliar with them before today.
When the element binding is required, senders SHALL draw from that binding, and receivers SHALL support anything the binding allows. That has always been the most clear statement we were able to get. Now where things go sour is when you try to define support. As Lloyd already mentioned: when you only care about pregnant women, then your receiver support for men/unknown is probably that you discard the info. So I guess the profile were to say: required AdministrativeGender, minValueSet "female" for that system.
maxValueSet is a whole different ball game. I'm still trying to grasp that one. Seems like I could say: extensible SNOMED CT ObservableEntities, maxValueSet SNOMED CT ObservableEntities + LOINC
But if both SNOMED CT and LOINC are allowable for an element: why not create a combined ValueSet, or (our usual), slice the thing where one slice points to SNOMED CT and the other points to LOINC?
Lloyd McKenzie (Aug 20 2019 at 15:21):
minValueSet allows you to identify what codes must be supported. The reason for maxValueSet is so that you can have a 'useful' value set as your extensible binding that's reasonable for use in a drop-down, while still placing an outer bound on what codes are allowed. We do this for things like language and units of measure where the set of possible codes from the underlying code systems (which we want to enforce) is infinite/near-infinite, but the set of commonly used codes is relatively small. The extensible binding lets systems use a dropdown for the easy stuff and the max binding ensures that we still end up with a legal UCUM or IETF language code if the user decides to enter an 'other'.
Last updated: Apr 12 2022 at 19:14 UTC
