Original HL7 wiki page HERE and this material is taken from there.

Binding Semantics Project calls and meetings

Value Set Expansion (VSE) Project - INACTIVE

Project is on hold through summer 2018.

Next meeting is November 1 at 3:30PM ET.

VBS Document Repository 

Current Working Material

Terminology Binding intends to specify a set of rules to control the use of coded concepts within a specification. These rules are typically used in a particular implementation to support a specific use case (which can be quite broad.) This document describes these rules segmented into three categories:

  • Information required to identify specific codes that are to be used for each of the coded data elements in the specification
  • Information required to specify expected behaviors in the exchange of coded information by conformant applications
  • Requirements for allowed constraints in derived specifications 

These rules are accomplished by specifying a value set binding for each of the coded data elements in a specification to be implemented.

A Value Set Binding describes an implementable terminology binding that has two flavors:

  1. A Direct Value Set Binding is a declaration that binds a value set directly to a model element and when this is done, all jurisdictions must remain conformant to the binding which can still allow change as noted in our binding semantics. [V3 Model Binding]
  2. An Indirect Value Set Binding is a declaration that binds a value set to a Concept Domain that exists to describe the intended model element scope. This Concept Domain will be (usually) tied to one or more model elements via a previously specified Domain Binding. In this case the Indirect Value Set Binding is essentially transferred through the Concept Domain to the associated model elements. [V3 Context Binding]

A Domain Binding is an unimplementable terminology binding that is a declaration that binds a Concept Domain to (usually) one or more model elements. As such a Domain Binding simply describes ''a scope'' that characterizes a value set binding (specified elsewhere or in future) for the associated model elements.

Incomplete Glossary

Concept Domain: A uniquely identified named description of the ideas intended to be used to express the semantics of a coded model element. This uniquely named description may be represented by a concept drawn from a code system, but in all cases it is not intended to specify the allowed instance values that may be exchanged or recorded in the noted model element.
Coded Data Element: A model element (also referred to as a data element) that is intended to convey a specific type of information using concepts drawn from a controlled vocabulary.
Currently Available: Most recently released version of a Code System available for application to a patient record, existing on the terminology server in use.


Terminology Binding Diagram

A Value Set Binding To A Data Element

  1. SHALL describe a Content Value Set Binding and,
    1. we need to review and discuss the Core Principles notion of a priority sequence of different bindings on the same data element
  2. MAY describe a NULL Value Set Binding.

The allowed content to be exchanged for the model element will be determined by the union of value set expansions specified by the Content Value Set Binding plus the NULL Value Set Binding.

  1. A Content Value Set Binding describes coded values that represent expected content for the data element.
  2. A NULL Value Set Binding describes allowed NULL values for the data element
    1. This NULL value set applies only to coded "nulls" and not numeric null situations (infinity, real vs. integer.)
    2. The set of allowed values for the value set SHALL be drawn from the Null Code System (OID: 2.16.840.1.113883.1.11.10609, FHIR)
    3. It is expected that if the model element supports NULLs then either each model element will define a specific NULL Value Set Binding or there will be overall NULL Value Set Binding that applies to all of the data elements that do not have an individual NULL Value Set Binding in the entire model specification
    4. This Binding Semantic Specification does not specify how to implement a NULL Value Set Binding. For example it may be implemented so that both the expected values and the allowed nulls are all sent in the value slot, or the nulls might be sent in a separate property or component of the coded data type.
    5. Note that the NULL Value Set Binding can have a strength of either NEA or CEA (below) because it is acceptable to specify a null set with strength CEA that would allow a user to choose a null from the null code system that better matches their specific Use Case and send that as an exception value that happens to be a null.
    6. A NULL Value Set Binding may NOT specify a binding guidance verb of OPEN, but can specify any of FIXED, CLOSED, EXTEND, or RESTRICT.
  3. Taken together, the UNION of all value set bindings represent the full binding for the data element
  4. If you do not specify a NULL Value Set Binding for the data element (or overall in the model specification) then the default is a binding which permits (an implied value set) any value from the NullFlavor code system for the data element without restriction as required by the Use Case.

A Value Set Binding must specify, and only need specify the following three (four?) items

1) SHALL specify the information necessary to determine a specific Expansion Instance

It may be that more than one specific expansion to accommodate the identification of all the coded content needed, but no matter what, when a value set is specified it will be fully specified so that a single expansion is clearly identified. The intention is that the specification of the value set expansion will follow the approach noted in the Value Set Definition project. This means that every binding will always be pointing to an actual value set and guidance indicating if all implementers are to use that value set or can do something different.

  1. The exact syntax to be used for the binding statement is to be described here (TBD) and will be fully aligned with the Value Set Definition project and Core Principles.
  2. A binding statement is specified with the following three pieces of information. A single instance of a statement has the following requirements noting that if an attribute is not included, the noted default will apply:
    1. SHALL include a value set identifier that will resolve to a full value set definition.
      1. One VSD may have one-to-many instances of VSD versions
    2. MAY include a value set version identifier or a date that will constrain to a single value set version. The default when not specified in the binding or a further constraint is the most currently available.
      1. A particular version instance of a VSD might specify explicit versions of included content or might not
    3. MAY specify the version of each needed code system, or a date that will constrain to a single code system version. The default when not specified in the binding or a further constraint through use of a Profile is the most currently available.
      1. Versions of content to be included in an Expansion used in a particular implementation can be determined by downstream profiling using an Expansion Profile. In the absence of such an Expansion Profile, the 'currently available' versions are used.
  3. In specifying a specific value set in a binding the IG is communicating that an implementation can be created using the specified value set and be conformant. In addition, the binding semantics described in item #2 below convey in what way (if any) subsequent IGs can change the value set specified or send additional codes (if allowed) and remain conformant.
  4. Alternatively, binding of the coded data element can be fully deferred to a downstream specification. To do this the coded data element is associated with a semantic category, such as a HL7 V3 concept domain. This association is not a value set binding, it is a Domain Binding as noted above. This approach is intended to provide strict guidance on the scope of the value set that will eventually be bound via an Indirect Value Set Binding to the explict set of codes needed to support the identified use case. This association states that value set scope eventually bound MUST be consistent with the scope of the semantic category used to describe the association.

A value set binding SHALL result in a specific value set expansion code set as determined by an expansion operation that follows the process noted below:

  1. Must specify a value set identifier
    1. This identifier will always be the same for any value set definition version
    2. The identifier SHALL be resolved to a document or location that describes a value set definition that is conformant with the VSD specification
  2. Will result in a specific value set definition version (that can be resolved to an input parameter to be used by the expansion process.)
    1. To be determined by the following precedence order:
      1. A specific version identifier. If not provided then...
      2. A date that will be used to determine the latest value set definition version available to the expanding service on the specified date. If not provided then...
      3. An external artifact that specifies the following (Note: the external artifact can not add new concepts to the expansion created):
        1. A specific version identifier. If not provided then...
        2. A date that will be used to determine the latest value set definition version available to the expanding service on the specified date.
    2. If none of the above are provided, the expansion SHALL use the latest value set definition version available to the expanding service on the date the expansion is created.
  3. Must specify a code system version for each code system needed (that can be resolved to an input parameter to be used by the expansion process.) Each code system version used by the expansion operation SHALL be determined in the following manner:
    1. Any CLD clause that includes a reference to a specific version of a code system, the expanding operation for that clause SHALL use the code system version specified (as defined in VSD). The code system version SHALL be determined by one of the following in precedence order:
      1. A specific version identifier. If not provided then...
      2. A date is provided that will be used to determine the code system version, that is the most recent as of that date provided (I.E.: is available for use) to the expansion service. Note, the date used can not be presumed to align with any specific publishing date for a code system version because expansion services may not implement code system updates in a similar fashion.
      3. If no specific version of a code system is provided within a clause, then...
    2. If the entire CLD is LOCKED to a specific version of a code system, The expand operation SHALL use the code system version specified by the LOCK (as defined in VSD) for all operations where the code system version is not already specified. The code system version described by the LOCK SHALL be determined by one of the following in precedence order:
      1. A specific version identifier. If not provided then...
      2. A date is provided that will be used to determine the code system version, that is the most recent as of that date provided (I.E.: is available for use) to the expansion service. Note, the date used can not be presumed to align with any specific publishing date for a code system version because expansion services may not implement code system updates in a similar fashion.
      3. If no specific version of a code system is provided by a LOCK, then...
    3. An external artifact that specifies the following (Note: the external artifact can not add new concepts to the expansion created):
      1. A specific version identifier. If not provided then...
      2. A date is provided that will be used to determine the code system version, that is the most recent as of that date provided (I.E.: is available for use) to the expansion service. Note, the date used can not be presumed to align with any specific publishing date for a code system version because expansion services may not implement code system updates in a similar fashion.
      3. If no specific version of a code system is provided in an external artifact, then...
    4. The code system version to be used will be the most recent version that is available for use by the expansion service. Note, each expansion service may have a different "latest" code system version available at any particular time.
  4. The above SHALL be completed for each code system needed for the expansion.

2) SHALL specify rules to describe expected behaviors for Sending/originating data or those Receiving/consuming data regarding codes that are not members of the identified value set expansion

This can be accomplished by specifying rules using verbs and operands that describe conditions and consequent behaviors.

To Dos:

  • Define the rules
  • Define the verbs

  • Define the operands
  • Define the behaviors

We have the codes that are "expected", i.e. those that are contained in the identified expansion instance; then we have codes that are unexpected - those are are not contained in the expansion instance, and we have data that is uncoded free text.  In addition we have missing data.

Can we proceed with just TWO states:

  1. Codes that are expected, i.e. they are members of the identified value set expansion
  2. Codes that are exceptions, i.e. they are not members of the identified value set expansion

There are two additional outliers:

  1. Missing data (no known or local code to represent the desired meaning)
    1. This gets into the whole null flavor discussions
    2. Is this part of the underlying datatypes and their model structure constraints?
    3. Once approach being taken in V2 and FHIR is to incorporate the desired null flavors into the identified value set expansion instance
  2. Free text rather than a code, whether or not that code exists somewhere
    1. Is this a nuance of missing data, i.e. if not code is available then send some string value instead, which is again a kind of null flavor


The approach of adding null values into the value set does not speak to the issue of Tolerance (see below) where we need to specify whether a code that is not known a priori should are permitted to be accepted.  This is missing from #1 above (use case:  disease outbreak, new observations are documented and are flagged by a on-site created code in the field which needs to be put in the record to be found and dealt with later).

The sense of the group on the 1/9/18 call is that these outliers SHOULD NOT be part of binding, and the binding adherence rules.



From the discussions on the 12/12/17 call:

one of the following Tolerance verbs (previously called Extensibilities) to describe expected behaviors for Sending/originating data Receiving/consuming data regarding allowance of “unexpected, or exception codes”

2017-09-26: Changed to Tolerance and perhaps this is a flag that simply allows for codes not in the bound value set. 
Value set codes can still be tested when compared to the bound value set if the implementer wants to do so, but needs to display anything they are sent. 
Further discussion needed on if text and no code/code system can be sent

Exception codes are:

  • Code's that are not in the bound value set expansion,
  • Are considered appropriate for use and therefore may be sent and must be accepted by a receiver even if the code is not recognized.
  • SHALL not represent a concept that is already represented in the expansion set of the bound value set.
    • Lloyd M states that when an exception code is used, it SHALL NOT be spanned by a concept in the expansion set. ie: Royal Blue is not a valid exception code if Blue is in the expansion set.
Extensibility defines constraints that can be used to clarify how to support conformance testing. Expectation woud be that 
Binding Strength is separate and defines whether an implementer can change to a different value set
  1. Extensibility NEA: Coding No Exception codes Allowed (This is similar to V3 CNE)
    1. Sending/Creating perspective
      1. SHALL only employ values that exist in the expansion
    2. Receiving/Consuming perspective
      1. SHALL accept without asserting an error any value that exists in the expansion
      2. SHALL assert an error for any other value in the data element that does not exist in the expansion.
  2. Extensibility CEA: Coding with Exception codes Allowed
    1. This means any coded value that is consistent with the value set scope can be sent. Not all codes sent, or received, will be in the deterministic value set expansion. This is like V3 CWE. The expansion set for the bound value set will function as a MIN value set – all implementers are intended to support the set.
    2. Conformance testing of this Extensibility is up to the implementer - some characteristics of the concepts in the value set may be computably conformance testable (perhaps through the use of code system inferencing, but not all.
    3. Sending perspective:
      1. SHALL send from expansion if idea is in the expansion
      2. MAY send a valid extended "exception code" if idea is not in the expansion
        1. Send a code and an identification of code system (can be local)
        2. Send text and no code
          1. FHIR discussion: Consider making three flavors of CEA - Allow Exception that can be:
            1. Either code or text
            2. Only allow codes. No text.
            3. Only allow Text. No codes.
    4. Receiving Perspective
      1. SHALL be able to identify when received code is in the expansion and not report an error
      2. MAY Identify when a data instance contains content not in the expansion but is a valid exception code
Under consideration is to allow constraint of CEA by specifying a CEA-MAX.
This would be expressed by a value set CLD that defines a maximum set of
potential "exception" codes.

3 SHALL specify Guidance on

The further constraints may be applied in a downstream use of the specified binding and yet still be considered conformant with the original binding: Binding needs to specify how to allow a change in the defined expansion. The binding syntax will describe the value set expansion specification and also state if subsequent implementation guides can use a different value set or must only use the specified value set.

  1. For the specified value set binding, the following five Binding guidance verbs provide guidance on how a subsequent IG can change the specified expansion and remain conformant. Based on 2016-03-29 and 2016-09-13 discussions.
    1. FIXED The value set defined SHALL be fully implemented with "no more" additional concepts, and "no less" concepts than those included in the defined value set expansion.
      1. Note that a FIXED binding MAY specify only a value set identifier and so be quite dynamic in the specified expansion set to which the implementers are tied at a given time.
      2. A "downstream" conformant IG based on this binding SHALL be FIXED.
    2. CLOSED A conformant implementation SHALL use 1..N concepts from the expansion as defined by the bound value set but MAY create a new value set that defines an expansion that is a formal subset.
      1. Again, a CLOSED binding can allow dynamic expansions.
      2. A "downstream" conformant IG based on this binding MUST be CLOSED or FIXED.
    3. EXTEND A conformant implementation must use all concepts from the expansion as defined by the bound value set but may add additional concepts for exchange
      1. This binding is essentially a combination of FIXED + the current idea of Coded With Extensions (V3 CWE)
      2. The intention is that the new concepts introduced do not represent the same ideas as those already available as long as the implementer has access to the code system used.
      3. A "downstream" conformant IG based on this binding MUST be either EXTEND, CLOSED or FIXED.
      4. Additional concepts can be exchanged in one of two ways. The allowed approach needs a syntax TDB so it's clear which way is allowed
        1. If the binding is CEA then the additional concept can be sent as an "Exception value" to the existing defined value set. This means a new value set identifier is not needed but the except code is clearly identified as not in the value set.
        2. Define a new value set is defined in the IG that includes all the concepts in the original EXTEND binding (perhaps by referencing that value set in the new definition) plus adds additional concepts.
    4. RESTRICT A conformant implementation SHALL use 0..N concepts from the expansion as defined by the bound value set but may add additional concepts for exchange
      1. This binding is essentially a combination of CLOSED + EXTEND. This is computably similar to an OPEN binding but is intended to be more restrictive to communicate - essentially to a human that is interpreting the binding - that this binding does not give the freedom of OPEN, but instead requires use of the concepts already defined in the expansion set if possible, and very tight alignment to the particular concepts noted in the original binding.
      2. The intention is that the new concepts introduced can not represent the same ideas as those already available as long as the implementer has access to the code system used.
      3. A "downstream" conformant IG based on this binding MUST be either RESTRICT, CLOSED or FIXED.
      4. Additional concepts can be exchanged in one of two ways. The allowed approach needs a syntax TDB so it's clear which way is allowed
        1. If the binding is CEA then the additional concept can be sent as an "Exception value" to the existing defined value set. This means a new value set identifier is not needed but the except code is clearly identified as not in the value set.
        2. Define a new value set is defined in the IG that includes all the concepts in the original RESTRICT binding (perhaps by referencing that value set in the new definition) plus adds additional concepts.
    5. OPEN A conformant implementation may use 0..N concepts from the expansion as defined by the bound value set (i.e.; the implementation does not have to use all the concepts in the defined expansion) and may also add additional concepts for exchange.
      1. This binding is essentially a combination of CLOSED + the current idea of Coded With Extensions (V3 CWE)
      2. This is the most permissive Binding
      3. The intention is that the new concepts introduced do not represent the same ideas as those already available as long as the implementer has access to the code system used.
      4. A "downstream" conformant IG based on this binding can be of any type.
      5. Additional concepts can be exchanged in one of two ways. The allowed approach needs a syntax TDB so it's clear which way is allowed
        1. If the binding is CEA then the additional concept can be sent as an "Exception value" to the existing defined value set. This means a new value set identifier is not needed but the except code is clearly identified as not in the value set.
        2. A new value set is defined in the IG that includes the concepts desired from the original CLOSED binding (perhaps by referencing that value set in the new definition with additional functions to remove the concepts not wanted) plus adds additional concepts.
  2. In addition to the value set binding guidance verbs above, a MAX Content Value Set Guidance MAY be specified.
    1. A MAX Content Value Set Guidance describes a value set of concepts from which the Content Value Set MUST be a subset. This value set will be technically "implementable" in that is describes a defined expansion set of concepts, but it is not intended to be the functional expansion set of implemented exchangeable concepts, i.e. it IS NOT the Content Value Set Binding. The MAX Value Set Guidance is only guidance to a subsequent Content Value Set Binding.
    2. A MAX Content Value Set Guidance SHALL be specified in one of the following two ways:
      1. Specify one or more code system(s). This SHALL mean that the current, and any subsequent conformant Content Value Set Binding will be drawn from the specified code systems.
      2. Specify an implementable value set as noted above. Note: when a MAX Content Value Set Guidance specifies an actual "implementable value set," that value set is not the Content Value set Binding, which must be specified separately.

4) UNDER CONSIDERATION: 4th characteristic -> Binding Strength that declares if the value set identified must be used or can be changed

This characteristic is commonly found in bindings but is distinct from Extensibility and
may overlap some with the Guidance section above. 
For example, Can REQUIRED be something other than FIXED, like CLOSED or EXTEND?

Binding Strength is typically described as No change allowed or Change is allowed but also carries some evidence of confidence that the bound value set is useful. The Binding strength verbs are:

  1. REQUIRED Where the bound value set must be used and no other can be substituted. In this case NO value set Change is allowed
    1. Sending perspective
    2. Receiving perspective
  2. PREFERRED Where the bound value set SHOULD be used unless a different value set with the same scope must be used to meet additional requirements. In this case value set Change Is Allowed.
    1. Sending perspective
    2. Receiving perspective
  3. EXAMPLE Where the bound value set is not promoted as complete or definitive. In this case value set Change Is Expected.
    1. Sending perspective
    2. Receiving perspective



  • No labels