Binding Syntax

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

Meeting occurs Every Other Tuesday 2p ET for 60 minutes

---

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: 
1. Go to http://go.mikogo.com
2. Enter the Session ID: 368-206-475
3. Enter your name
4. Click "Join Session"

---

Current Working Material

Binding must specify, and only need specify the following

1. Identify the value set and Identify the versions as prescribed by the value set to be used – IE: Which expansion is to be used? This likely means we have a “HL7 default” for any parameter not specified, and likely we support noting in guidance, not a binding parameter how a particular implementing entity can define a different default.
   1. Binding needs to specify how to allow a change in the defined expansion, IE: 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. We will call this SUGGESTED binding.
      1. Given that a specific value set with specific expansion content must be identified via the parameters:
         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) OR
            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.
   2. Alternatively, binding of the coded data element can be 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 binding. This approach is intended to provide strict guidance on the scope of the value set that will eventually be bound. 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. Identify behaviours of the data in the instance with respect to the values in the expansion. Through this we describe if a binding may or may not send/receive something not in the expansion determined via the process described above
   1. Restriction to only values that are within the expansion - CLOSED
      1. Sender perspective
         1. Must only send values in the expansion
      2. Receiver perspective
         1. Must receive without error values in the expansion
         2. Error for any other value
   2. 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

Old Minutes

2015-07-07_Binding_Minutes
2015-07-21_Binding_Minutes