This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Binding Syntax

From HL7Wiki
Jump to navigation Jump to search

Binding Syntax

This project is a joint effort between CGIT and Vocabulary.

  1. Project now chaired by Rob McClure, building on work from Wendy, Ted, Frank O., Rob H. and Rob S.
  2. Current project document with minutes (latest work at the bottom) HERE

Scope

Define the human readable expression of the vocabulary constraints in implementation guides (Model Bindings) and by Realms as published sets of Context Bindings. Define the expression of the Value Set Assertion, a Model Binding, a Context Binding, and a Context Domain constraint. Information expressed in the syntax should be isomorphic to the normative definition of the data items comprising vocabulary constraints in Core Principles and the MIF ballots.

General meeting Agenda

Next meeting will be June 21 - June 7 meeting is cancelled
Remember USA is now on STANDARD TIME EST is UTC -5

Meetings post-Orlando is every other week starting May 24 - Tuesdays @ 2pm EDT for 60 min.

Telephone uses standard HL7 Vocab number: 1 (770) 657-9270,,,598745# - NOT THE SHARED SCREEN NUMBER FOR MIKOGO OR OTHERS

Meeting will be one of the following web share environments

Mikogo session

https://go.mikogo.com/?sp=&sid=368206475

If the above link does not work, you can follow these steps instead to join a session:
# Go to http://go.mikogo.com
# Enter the Session ID: 368-206-475
# Enter your name
# Click "Join Session"

Join.Me session

https://join.me/tedsnewsessions

The above link works with any browser. Once there:

# Click on "Knock To Enter"

The September 15, 2016 meeting will use the join.me session above

The March 29, 2016 meeting will use the join.me session above


Current Working Material

Terminology Binding intends to identify a specific set of coded concepts to be used in a particular implementation to support a specific use case (which can be quite broad.)

Value Set Bindings describe implementable terminology bindings and they come in 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. A 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 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 some future value set binding for the associated model elements.

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.

Terminology Binding Diagram


A data element SHALL have a Content Value Set Binding and MAY have 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 v 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 an overarching NULL Value Set Binding that applies to the entire model specification
    4. Implementation of the NULL Value Set Binding can be unique to the implementation. 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 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 the information and send that as an exception value that happens to be a null.
  3. Taken together, these two value set bindings represent the full binding for the data element
  4. Both types of value set bindings follow the following requirements (except a NULL Value Set Binding is always a MIN=MAX binding.)


A Value Set Binding must specify, and only need specify the following

  1. The information necessary to determine a specific Expansion Set. It may be that more than one specific expansion will be specified through multiple bindings where a MIN and MAX are used, 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. At present we expect a binding to include the following:
      1. A value set identifier that will resolve to a full value set definition,
      2. The value set version identifier or a date that will constrain to a single value set version
      3. The version of each needed code system, or a date that will constrain to a single code system version
      4. If one or more of these is not provided, then the default used is "currently available"
    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.
  2. Use one of the following to describe Expected behaviors for Sending/originating data Receiving/consuming data
    1. NEA: Coding No Exceptions Allowed (This is similar to V3 CNE)
      1. Sending perspective
        1. SHALL only send values in the expansion
        2. Note, this means that if a HL7 NULL Flavor is to be allowed, the NULL Flavors would need to be in the Expansion Set.
      2. Receiving perspective
        1. SHALL receive without error values in the expansion
        2. Error for any other value expectations
    2. CEA: Coding with Exceptions Allowed - "Exception value" to the existing defined value set is alowed. This means a new value set identifier is not needed but the exceptional code is clearly identified as not in the value set. This is like V3 CWE.
      1. Sending perspective:
        1. SHALL send from expansion if idea is in the expansion
        2. MAY send something not in expansion if idea is not in the expansion
          1. SHALL Flag the instance in some way to clearly identify that the concept sent is not in the expansion set
            1. Send a code and an identification of code system (can be local)
            2. Send text and no code
            3. Send a “reason that expansion code can not be sent” – This is a true flavour of null
      2. Receiving Perspective
        1. SHALL be able to identify when received code is in the expansion and not report an error
        2. Identify when a data instance contains content not in the expansion but is sent appropriately
  3. Describe what further constraints may be applied in a downstream use of the specified binding and yet still be considered conformant with the original binding:
    1. What further constraints on the specified binding can be done, i.e.: what further changes can be made. Syntax TBD.
      1. 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.
    2. The following five Binding types 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.

An additional item for discussion that could be added:
Many times people want to identify a known set of codes, say from SCT, and then allow more codes (EXTEND or OPEN) but they want the additional codes in a subsequent implementation to be drawn from SCT - either with no exceptions, or simply preferentially. Right now we would say that would just be a MAX binding to a value set with all of SCT in it.
Perhaps this can be made simpler: can we avoid requiring two bindings to the same element (MIN and MAX) since no one ever does that and I suspect few modeling systems can easily support it? Can we devise something that we add to one of our binding types that would allow stating the required or preferred code system for any additional concepts?
Perhaps we could use the word “TIGHT” or “LOOSE” to indicate that any additional concepts are to be obtained from the identified code system. TIGHT means MUST come from the code system, LOOSE means, in essence if possible.


The following were moved from a prior version of this and are kept here for historical reference:

  1. If "downstream" changes in the value set to be used are allowed, then such a specification must clarify if
    1. A different value set may be used (therefore control and responsibility is ceded to the downstream steward.) This is similar to Preferred/example that provide an expansion that may be changed. In V3 this is similar to representative, in CDA it is similar to SHOULD, wherein the binding may be further fully constrained and then used in an implementable guide, but a completely different value set my be bound as an alternative as long as the value set meets the required scope.
    2. Only the value set identified (by the parameters noted) can be used therefore any change in the value set to be used MUST be managed by the original value set steward because they would be creating a new value set definition version. In current CDA IGs, this is a MUST binding.
  2. Restriction to only values that are within the expansion - CLOSED
    1. This approach is expected to be the vast majority. This approach supports the notion described in #1 wherein a subsequent implementation guide can create a new value set that replaces the one noted in the current specification. The guidance provided can also state the behavior subsequent value set authors must follow when creating the value set to be implemented. For example, noting that any subsequent value set created MUST include all codes in the value set in the base specification.
    2. It is noted that there are circumstances where a CLOSED binding may not be further constrained, and thus can be thought of as "FIXED".
    3. We can think of "FIXED" as "no more, no less"; "CLOSED" is "no more, but may constrain to be less"; "OPEN" is "more, or less - do what you like"
    4. Sender perspective
      1. Must only send values in the expansion
    5. Receiver perspective
      1. Must receive without error values in the expansion
      2. Error for any other value
  3. Binding allows use of values that are not in the expansion - OPEN
    1. Sender perspective:
      1. Must send from expansion if idea is in the expansion
      2. May send something not in expansion if idea is not in the expansion
        1. Must Flag the instance – “OTHR” (Flavour Of Null yet is really not a null)
          1. Send a code and an identification of code system (can be local)
          2. Send text and no code
          3. Send a “reason that expansion code can not be sent” – This is a true flavour of null
    2. Receiver Perspective
      1. Must be able to identify when received code is in the expansion and not report an error
      2. Identify when a data instance contains content not in the expansion but is sent appropriately
  4. Presently an Element Binding may optionally include that the stated binding is a MIN or a MAX binding. When used, both a MIN and MAX binding MUST both be defined. If MIN/MAX is not stated then the binding is to function as a MIN binding.
      1. MIN binding describe the concepts that an implementation MUST fully support
      2. MAX binding MUST include all the MIN concepts with all additional concepts noted as those that SHOULD be supported.
      3. Concepts not included in the MAX binding but from the same code system are EXCLUDED from use. This is consistent with the expectation that even with an OPEN value set as defined below, no concept that falls outside a MAX binding should be sent.
      4. Any constraint on the binding MUST result in a new MAX value set that is a proper subset of the upstreambinding MAX value set.
      5. Any constraint on the binding MUST result in a set of concepts that are within the semantic range of any defined concept domain.
    1. How to implement based on the specified binding without any further constraint, i.e.; How to generate the value set expansion based on the currently specified binding.
    2. Some of this should be defined as default behavior.
    3. V2 Binding strength is in this bucket
    4. Can we clarify that a code may be sent as if the binding was OPEN even when CLOSED (e.g. New lab code for new test when set of allowed known tests are in the existing deterministic expansion and want strict adherence to the existing expansion set.

Working Example to be rendered using the semantics described

Example
Data element used to report drug resistance in a culture.
The value set would be drugs to which the organism (known or unknown) is resistant. The degree of resistance is communicated via a different element. The value set initially could be used to describe any drug that could be assessed for resistance but then would be constrained for specific uses in subsequent guides. Need to address situation where a drug that was constrained out "upstream" is now needed again, and when a new drug appears to which resistance needs to be assessed.
From the Current Working Material section.
1.2.1.1: If "downstream" changes in the value set to be used are allowed, then such a specification must clarify 1) if a different value set can be used instead (SHOULD), 2) or you must use the same value set (MUST).
In which of those choices does Allowance for a subsequent use of this element binding where in the use is a subset of the original value set. Does this require a new value set?
We currently allow FHIR in the $Expand function to obtain only a subset of the expansion set and use that as the functional value set expansion set for the value set.

  1. The question we must address
    1. is if this is a conformant expansion of the value set as defined?
    2. if we do allow this, must we identify that the "sub-expansion" is being used? We did say that was required in FHIR. Not sure how they did this.

Minutes

Minutes now on separate page

Use Cases

This section is where we will list use cases that are to be described using the approach noted

  1. Emerging disease tracking registry
  2. Data transmission where successive implementation guides can add additional codes to those specified in the specification being constrained
    1. National value set -> state value set -> local value set
  3. Start from typical base standard value set with no needed change to implement
    1. Same as above but initial VS was an example and must be made implementable
  4. V2 Lab (LRI) examples with the use of national to state to implemented specifications all using binding identifiers.


Prior Binding Syntax Material Page