Vocabulary
Space shortcuts
Page tree

Versions Compared

Old Version 11

changes.mady.by.user Carmela A. Couderc

Saved on

compared with

New Version 12

changes.mady.by.user Lloyd McKenzie

Saved on

Key

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

...

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.

...