Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

  • 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 if luif value set expansion contains a concept that is semantically equivalent 

...