FHIR JIRA tickets
Current ticket:
Old ticket: US Core binding:
McClure Proposed wording:
Definition: The expansion set of concepts that have been determined for use, but additional concepts that fall within the scope of the value set definition may be considered conformant for exchange. It is strongly recommended that if a concept, not in the expansion needs to be exchanged, and that concept is subsumed by an existing expansion member, that existing member also be sent.
The R4 wording is here:
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
Proposed rewording for the definition of the binding strength for Extensible:
The set of concepts in the expansion that has been generated from the bound Value Set Definition, plus additional concepts that fall within the scope of the value set definition, are considered conformant for exchange. If a scoped concept that is not enumerated in the expansion needs to be exchanged, and that concept is subsumed by an existing expansion member, implementers SHOULD also send that existing scoping member.
Usage Note: The only concepts that can pass automated conformance testing are those that are enumerated in the expansion of the bound value set.
To be continued...(1/7/2021)
Usage Note: An extensible binding is inherently non-specific with regards to the concepts that can be considered proper conformant members of a value set that meets the binding requirements. This is because there can be great variance in agreement among implementers and conformance testers regarding if a concept not in the bound expansion is “subsumed” by a concept that is in the expansion. Of note, including very general concepts in the value set expansion must be avoided because such concepts will have a broad scope of potential new concepts that could be considered "subsumed" by some implementers. Implementers that desire tight conformance will expect that if a new concept can be determined to be subsumed, via human or code system relationship testing, then the most specific subsuming concept in the bound expansion MUST be sent in addition to any other new concepts. Implementers that allow for looser conformance testing would allow that if a new concept has a meaning that is different than any concept in the bound expansion, independent of subsumption coverage of meaning, then the new concept may be exchanged without also including any other concepts in the the current expansion. Both approaches are considered conformant with an Extensible binding. Given that independent implementers can interpret the binding differently (tight versus loose) even when working from the same implementation guide, use of this binding should be severely restricted.
Lloyd's comments: This proposed definition change can't be made for FHIR use as it would be a breaking change of normative content. The proposed wording is essentially not practically differentiatable from 'preferred', making it useless to have 'extensible' in addition to 'preferred'.
Binding strength: https://build.fhir.org/codesystem-binding-strength.html
December 14, 2020 - Vocab co-chair call
The R4 wording is here:
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
We know there are at least 2 interpretations of the R4 text.
This is what has been taught in Vocab training and represents the intent of the original authors. Here are a couple of options we tossed around
Unfortunately the word subsumption is not in the R4 definition which might have provided clarity.
It has always been assumed that a human would select a concept if the exact, desired concept is not in the value set expansion. Unfortunately we did not do semantic equivalence using humans.
Rob M: Extensible (in FHIR) means that in the context of an implemented IG you can create a new value set that contains the concepts you need to use. Either a new version of the bound value set or a completely new value set can be used? Going against the implementation guide?
(Rob M: Sending a code that is not in the value set expansion but is within the scope, the code is from another value set) However, a code might be sent that is within the scope (e.g. a new code for COVID-19) that is not in another value set - possibly a value set in someone's mind - not one that actually exists. Ted: because there is always a value set that is all codes in a code system, then technically in FHIR, all codes are in a Value Set.
Rob H: all data instances are only based on code systems (not value sets)
Rob H: if implementers take the path that a code may be sent if the semantic meaning is not in the value set expansion, you have made extensible equivalent to preferred
Extensible may be interpreted more like required, or more like preferred
Rob H: the value of extensible lies between required and preferred
Ted: in terms of conformance testing, if there is an exact match to a code in the value set expansion, then it is conformance, if not an exact match, a warning is issued to indicate a human being should take a look at the value
(we know if something is good, or we can't know if something is valid)
Rob M: suggests we acknowledge extensible straddles the fence, and is not reliably implementable. Implementers may choose to interpret extensible as aligned with required or with preferred. Conformance testing guidance may be crafted using Ted's wording above.
Recommend that people not use extensible binding strength in implementable IGs.
How does Value Set versioning impact this? This is an issue across all binding strengths. However, with a required binding, version could seriously impact what can be sent.
Robert Hausam volunteers to create concise, clear wording to define extensible binding strength along with usage notes. We should do this for R4B. Carmela A. Couderc will add a JIRA for this task. Rob H appreciates any help on this very important topic. Rob McClure will craft something (suggests we acknowledge what is happening in the community - people have focused on the individual concept and not subsumption)
Ted Klein suggests the usage notes highlight that the use of extensible binding strength should be avoided
****************************
End of 12/14/2020 minutes
Previous notes for history
| Code | Display | Definition | Usage Note | Issue |
| required | Required | To be conformant, the concept in this element SHALL be from the specified value set. | ||
| extensible | Extensible | To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead. | Added Parts of the definition that contribute to possible confusion:
Do we know the original intent of this binding strength? Does it matter? Do the education materials consistently/accurately reflect the original intent? Does it matter? Example 1: Clinician selects: Heart Attack Type A Bound value set expansion does not include Heart Attack Type A, however it does include Heart Attack. Core issue: Which is the expectation of the sender?
Example 2: Clinician selects: Heart Attack Type A Bound value set expansion does not include Heart Attack Type A, nor Heart Attack. Core issue: Which is the expectation of the sender?
DataType has an impact on the usage of this binding strength. NOTE: due to the ambiguous wording, implementations have interpreted the existing definition different ways. Responses from Lloyd: In example 1, the sender MUST send the code from the value set that says "Heart Attack". Presuming the data type is CodeableConcept, they're free to also send the code for "heart Attack Type A" and/or text that conveys the additional detail. If they were to only send the code "Heart Attack Type A", they would be non-conformant The degree of detail the sender wants to convey isn't a primary consideration. What matters is the level of granularity that receiving systems are counting on receiving. The expectation is that senders will have to map and there may be information loss - which is why they're free to convey their original concept as well. | |
| preferred | Preferred | Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant. | ||
| example | Example | Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included. |
Terminology Binding Examples: http://build.fhir.org/terminologies-binding-examples.html
Health Intersections examples: http://www.healthintersections.com.au/?p=2810
| Code | Display | Definition | Usage Note |
| required | Required | To be conformant, the concept in this element SHALL be from the specified value set. | |
| extensible | Extensible | For reference (rejected, simple definition): Concepts may be drawn from a value set other than the one bound to the element.
Note: CC removed the "to be conformant" part of the sentence for the definition. The concept in this element SHALL be from the specified value set if any of the codes within the value set match or acceptably generalize the concept being communicated. If the value set expansion does not include a concept that matches or acceptably generalizes 11/16/2020 discussion/adjustments: The concept in this element SHALL be from the specified value set if any of the codes within the value set exactly represent or are a more general representation of the concept being communicated. If the value set expansion does not include a concept that exactly represents or is a more general representation of the concept (based on human review), the concept in this element MAY be drawn from a different value set Next steps consider changing the wording to include: (draft below) Semantically aligned vs: exactly represent Meaning of the concept The concept in this element SHALL be from the specified value set if any of the codes within the value set is semantically aligned or is a more general representation of the concept being communicated. If the value set expansion does not include a concept that semantically aligns or is a more general representation of the concept (based on human review), the concept in this element MAY be drawn from a different value set | A concept |
| preferred | Preferred | Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant. | |
| example | Example | Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included. |
Usage Note(s):