Policy on the use of extensible value set bindings

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.

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.