Skip to end of metadata
Go to start of metadata

Reference Material for Discussion

FHIR JIRA tickets

Current ticket:  FHIR-29968 - Getting issue details... STATUS

Old ticket: US Core binding:   FHIR-29563 - Getting issue details... STATUS

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

  • You must use a concept from the value set if the meaning you are trying to convey is covered/subsumed by a concept in the value set expansion. 
  • You must use a concept from the value set expansion luif value set expansion contains a concept that is semantically equivalent 


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

CodeDisplayDefinitionUsage NoteIssue
requiredRequiredTo be conformant, the concept in this element SHALL be from the specified value set.

extensibleExtensibleTo 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:

  1. can apply
  2. does not cover
  3. instead

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?

  1. Sender must provide 2 
    1. Heart Attack Type A
    2. Heart Attack
  2. Sender provides
    1. Heart Attack Type A  (from a code system not referenced in the bound value set)
      1. Note: this is the same as preferred binding strength
  3. Sender provides
    1. Heart Attack

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?

  1. Sender provides
    1. Heart Attack Type A  (from a code system not referenced in the bound value set)

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

In example 2, presuming that there are no codes in the value set that generalize "Heart Attack Type A" at all (e.g. "patient complaint", "health condition", etc.), then the sender is free to send their code for Heart Attack Type A and/or free text.

The intention of an extensible binding is to ensure that receivers can count on content that falls within the scope of the value set being sent in a standardized way, while still allowing for the exchange of content that falls outside the scope of the value set (because the domain is such that the value set can't be guaranteed to be comprehensive).

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.

The challenge with extensible is that you want to ensure that the value set that's extensibly bound doesn't include codes that are 'useless' for the receiver - which is what often happens when you define an intentional value set in code systems like SNOMED which have a lot of high-level abstract codes.

preferredPreferredInstances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.

exampleExampleInstances 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

Vocab Working Definition

CodeDisplayDefinitionUsage Note
requiredRequiredTo be conformant, the concept in this element SHALL be from the specified value set.
extensibleExtensible

For reference (rejected, simple definition):  

Concepts may be drawn from a value set other than the one bound to the element.

  • Very general, could apply to preferred and example. 

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 cover the concept (based on human review), the concept in this element MAY be drawn from a different value set (or, data type allowing, text) may be included instead.

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 (or, data type allowing, text) may be included instead.

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 (or, data type allowing, text) may be included instead.

A concept that would be considered is conformant when it exists in the expansion of the bound value set that is more general and as an acceptable representation of the information to be exchanged. What constitutes "acceptable" must be defined as part of the implementation guidance. If the value set expansion does not include a concept that matches or acceptably generalizes of sufficient specificity (based on human review), one or more alternate codings (or, data type allowing, text) may be the only coding sent. 



preferredPreferredInstances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
exampleExampleInstances 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):

  • No labels

13 Comments

  1. RM Original proposal:

    Definition of extensible: A concept from the bound value set SHALL be used when the concept to be exchanged either matches, or is scoped by a concept in the expansion. If no acceptable concept exists in the bound value set expansion, no concept from the bound expansion is required and a concept from a value set other than the one bound to the element SHALL be sent.
    Usage note: • A concept that would be considered conformant hen it exists in the expansion of the bound value set that is more general and an acceptable representation of the information to be exchanged. If the value set expansion does not include a concept of sufficient specificity (based on human review), one or more alternate codings (or, data type allowing, text) may be included. 

  2. Responding to Rob M's last suggestion on the Vocab co-chairs Skype chat discussion:

    "Extensible: If unavailable in the bound value set, concepts may be drawn from a different value set."

    Unless elaborated further, I think that supports what Reuben proposed yesterday - basically, if you don't find what you want in the value set you are free to use what you want (and deciding that could come down as far as being based on a string match, since that may be the only way that you can REALLY be sure that you have what you want). And there isn't any clear practical line that ultimately and reliably distinguishes that from 'preferred'. This is never going to be absolutely precise, unless we require it to be based on computable concept definitions and logic - which we haven't (and of course that would have its own issues, though different ones).

  3. RH - My attempt to align with that sentiment is hidden inside the phrase "acceptably generalize" because I understand how practical that desire is. And I think it not only aligns with what we currently do but also allows for variance that can be "tested" wrt what "acceptably" means.

  4. Perhaps we add in the usage note that an implementation SHOULD define what constitutes an "acceptable generalization"? Lloyd would say "any subsumed concept within an included code system," in contradistinction to what AUS is doing. But I will note, doing so completely defeats the idea behind a specified CLD wherein if the concept is not explicitly included, you need to use subsumption to identify an acceptable existing conformant concept to use. I'm interested to better understand how Reuben Danielsjustifies this.

  5. The definitions don't directly address Lloyds "nonsensical" assertion that if we have a value set with high level codes in it "Extensible" make no sense? But, I like where the "Usage Note" is headed

    1. Actually it does. A value set describing procedures with Procedure as a code using Lloyds definition means the value set bound extensible = required. We're working on nuancing how to clarify that.

  6. What is the down side (or upside) of a required binding? You would still have the same practice "Procedure" SNOMED code sent, "Dr Bills open appendectomy" is local code (or text) sent

    1. That is up to US Core. We're trying to clarify how to NOT make an extensible that = required.

  7. I think the revised definition and usage note for extensible are an improvement over what is currently provided. I have the following feedback for consideration and further discussion.

    In relation to this revision of the definition:

    To be conformant, 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 does not cover the concept (based on human review), the concept provided MAY be drawn from a different value set (or, data type allowing, text) may be included instead.”

    I have the following points:

    1. The definition is missing references to the expansion of the value set.
    2. I think “match or acceptably generalize” may be a bit specific as this ultimately comes down to “acceptable” or not “acceptable”.
    3. The need for “drawn from a different value set” may be problematic as the concept in question may not exist in a known value set.
    4. It is unclear what is meant by “human review” and which “human” is being referred to – is it the user of the application (implementing the specification), the specification developer, the designer of the application, or someone else? Additionally, given that the bound value set may be intentionally defined (or indeed an implicit value set), it may be impossible to perform human review and the expansion may change through mutuality of the underpinning code systems of the value set definition. Further, this excludes automated or semi-automated means for determining that the concepts in the bound value set do not cover the concept. Accordingly, I am not sure that basing this solely on human review is desirable in the definition.

    Accordingly, I suggest the following revision:

    To be conformant, the concept in this element SHALL be from a valid expansion of the specified value set if any of the codes within the value set expansion match or acceptably generalize is an acceptable representation of the concept being communicated. If the value set expansion does not include an acceptable concept cover the concept (based on human review), a concept not drawn from the expansion of the bound value set may be provided (or, data type allowing, text) may be included instead.”


    In relation to this revision of the usage note:

    ”A concept that would be considered isconformant when it exists in the expansion of the bound value set that is more general and as an acceptable representation of the information to be exchanged. What constitutes "acceptable" must be defined as part of the implementation guidance. If the value set expansion does not include a concept of sufficient specificity (based on human review), one or more alternate codings (or, data type allowing, text) may be the only coding sent. ”

    I have the following points:

    1. The first statement strongly implies that concepts which do not exist in the expansion of the bound value set are not conformant, despite what is in the third statement.
    2. The second statement seems to mix “definition” with “guidance” which may not be desirable. 
    3. The second statement should take into account expansions which can change  e.g. due to updated versions of the underpinning coding systems in the value set definition.
    4. The first statement refers to “acceptable” while the third refers to “sufficient specificity” – it might be easier to read and understand if we only referred to “acceptable”.
    5. Following on from my feedback on the definition I do not think the determination of sufficient specificity should be restricted to human review.
    6. It is unclear why “one or more” alternate codings needs to be explicitly mentioned in this usage note as it is not really relevant to the use of the extensible binding and, again, is specific to the particular data type being extensibly bound to a value set (I.e. CodeableConcept can include multiple codings but Coding cannot).

    Accordingly, I suggest the following revision:

    A concept that would be considered is considered to be conformant when it:

    • exists in the expansion of the bound value set that is more general and as an acceptable representation of the information to be exchanged. or
    • iscoding not included in the expansion of the bound value set (or, data type allowing, text) if the expansion of the bound value set expansion does not include an acceptable concept. of sufficient specificity (based on human review), one or more an alternate codings may be the only coding sent. 

    Specifications must define what constitutes an "acceptable" concept (from the expansion of the bound value set) for each extensible binding. This acceptability must also take into account cases where expansions of extensibly bound value sets which can change e.g. expansion of intensionally defined value sets or expansions of value set based on updated versions of the underpinning coding systems in value set definition. Rules in relation to the use of generalised concepts from the bound value set may also be included in the acceptability criteria.

  8. I don't know how this is going to address the issue.  If the code 'Procedure' is in the value set, I don't see how it's possible for that to not "acceptably generalize" any procedure concept.  Subsumption testing is hard enough, especially with human intervention.  If you add another  layer of rules that can vary from IG to IG, you're just going to produce more chaos.  

    As a side note, the normative wording in the FHIR spec is:
    "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."

    So if a code from the valueset can apply to the concept, it must be used.  That's not a rule that can be changed at this point.

  9. Note that validity of an exception to an extensible value set isn't always something that requires human review.  It could be computably determined if subsumption testing and/or concept maps allow inferring whether the sent code is generalized by one of the codes in the value set.  Human review is only necessary when there is no way to evaluate subsumption between the concepts - typically because the codes are from different code systems and no concept maps exist.  The absence of a computable determination of subsumption doesn't mean the exception is ok, but a computable determination of subsumption should generally mean the exception isn't ok.  (I say 'generally' because sometimes codes are used in a manner that violates their intended definition, so human review might theoretically still be needed even if software determines a subsumption relationship.)

  10. Extensible is perfectly implementable.  It's just not automatable .  It requires humans.  If you say "all NDC codes, extensible", that's a totally reasonable and necessary thing to do.  It's not  equivalent to preferred and it's not  equivalent to required.  What it's saying is if the drug you're trying to represent can be expressed with an NDC code, you must use the NDC code.  If the drug you want to represent doesn't yet have an NDC code, you're free to send just text or an alternate code.

    It is  appropriate to discourage the use of extensible if the base value set includes broad abstract concepts that cover the space.  If you have a value set that says "all SNOMED Procedure codes", there's no point in it being extensible because there's no possible concept that can't be covered by the value set - i.e. no possibility of ever not having a code within the value set.  But when the value set is fine-grained (e.g. all NDC codes), then extensible is reasonable and appropriate.

    Discouraging use of 'extensible' would be very problematic, because it means that if you can't define a value set where everything is guaranteed to be covered, you can't force the use of any codes at all.  That significantly reduces our ability to cover interoperability.  Essentially what you'd end up with is required bindings to a value set that adds in a code for 'other' - which does the same thing as extensible, and leaves you with the same problem, but you end up having problematic 'other' codes with continuously shifting meaning.

  11. As an implementer, I tend to find Lloyd McKenzie's comments provide the most practical guidance on the use of extensible binding. However, when commenting on intensional value sets based on SNOMED CT one has to be aware of the constraint relating to editions and versions; therefore it IS perfectly possible for a procedure concept from one version and edition not to be present in another and that, when particularly when looking at cross-border HIE, is actually a good use case for extensible binding.

    I certainly agree that extensible binding is implementable and that the (normative) descriptions in the specification are adequate for most. Terminologists may require more detailed explanations, but should understand the risk that these may introduce terms that will confuse non-experts.

    It might also be helpful if some of the misuses of extensible binding are fixed (wherever that is possible) -  a good example is the binding from Immunisation.performer.function to http://hl7.org/fhir/ValueSet/immunization-function a Value Set " provided as a suggestive example". (smile)