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

Regular fortnightly meeting occurs Every Other Tuesday 2p ET for 60 minutes
Remember USA is now on STANDARD TIME EST is UTC -5

Meetings post-Orlando is every other week starting Jan. 19 - Tuesdays @ 2pm EST 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"

---

Current Working Material

Binding must specify, and only need specify the following

1. The information necessary to determine an Expansion Set. This means every binding MUST fully specify how to determine the value set version and code system version to be used – IE: Which expansion is to be used? 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. Binding needs to specify how to allow a change in the defined expansion. This may need to be blended into the items noted in section #3. 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. Given that the specific value set must be identified via the parameters included which must characterize a specific expansion content:
         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 a SHOULD binding. 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. This is a MUST binding.
   3. 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 value set 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.
   4. 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. Sender perspective
         1. Must only send values in the expansion
      3. Receiver perspective
         1. Must receive without error values in the expansion
         2. Error for any other value
   5. 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
2. 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.
   2. 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.
   3. 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.
   4. Some of this should be defined as default behavior.
   5. V2 Binding strength is in this bucket
   6. 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.

Recent Minutes

Agenda topics held over:

1. Discussion with Templates?
   1. bring Templates in once we are a bit farther along
2. Continue discussion from Orlando to determine if we can push into the V2 Specification the following:
   1. Binding to the combination of a profile + data element
   2. Capture the details of "the column in the V2 spreadsheet" within a value set that is the one referenced by the 'a profile + data element bound value set
3. Future details for discussion later:
   1. How to support definitively specifying a value set but also allow a sender to send a code not in the expansion set. OPEN allows more flexibility then this use case wants.
   2. Focus on how to clarify what subsequent types of changes that are Conformant with the specified binding
      1. Expansion changes based on code system version change
      2. Changes in VS definition (a new version) that may or may not lead to a different expansion set
   3. Identify the items in the material below that should be pulled out as not "conformance-focused" and therefore not a part of the formal Binding specification, and instead are Guidance (but should still be stated.)

---

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.

---

2016-03-01 Rob M. Chairing, Ted K., Susan B., Frank O., Serafina V

1. Discussion confirming that the content of binding information can be spread over multiple documents as occurs in:
   1. V2 (a data element from a model in a guide/standard + a profile) or
   2. US eCQM (a data element with an vs OID + vs version/code system version in release info)
   3. TK: loosely coupled binding attributes means that the linkage between binding attributes can permit multiple cardinality so that more than one value can be associated with the binding attribute that are loosely coupled.
2. Began discussion on Example above.

Next meeting continue with example.

2016-02-16 Rob M. Chairing, Rob Snelick, Ted K., Susan B., Frank O.

1. Discussing V2 use of Profile tables where a coded element in the original IG with binding specified is "fully bound" in a separate profile
   1. We have agreement that the full set of binding information can be in two places, the original IG and a separate document where the remaining binding information is provided. This can also describe what subsequent constraints are allowed.
      1. This is similar to the eCQM Binding Parameter Specification document, and V2 Profiles.
2. The ability to extend the deterministic set of concepts in a value set is slightly different in V2 from V3
   1. V2 the new concept must be included in a newly created profile where the new code is available to all - so what changes is content of the value set
   2. in V3 the user can send the new code as a user-specifed addition of the value set but the deterministic concept of the value set does not change.
   3. These need to align but may support either updating the VS definition (new version) or support for an "OTHR" code that is not in the expansion.
3. Need to create real examples to run through these elements. This needs to be our focus for the next meeting.

2016-01-19 T. Klein (chairing), Rob Snelick, Rob Hausam, Jim Case

1. Discussion on Templates
   1. No one from Templates joined the call. Ted will send an invite for the next call.
2. Further exploration of V2 (NIST) view of the binding definition
   1. We looked at the NIST slides in detail again and Ted went on at length with Rob Snelick on the places of overlap between the tabular view NIST has developed and what we are documenting here in this project
   2. Must put together more detailed set of Use Cases that illustrate the different flavors of 'OPEN'
3. Should we remove all items that are not conformance focussed, or just mark those that are required (or not) for conformance?
4. We did not get time to explore and document further the Use Case of an instance of a data element containing a coded value not in the bound value set and the conformance rules and implications wrt what must be allowed and/or prohibited (and thus what must be captured in the syntax)
5. Call adjourned at 3PM ET; next call will be in 2 weeks on February 2

2016-01-05 T. Klein, R. McClure, R. Hausam, R. Snelick, F. Oemig, S. xxxx

1. Discussion on Orlando Agenda
2. Focused on item 3. Need to work through how to allow use case described in Orlando Agenda. Ted to bring another use case.

2015-12-22 discussion: T. Klein, R. McClure, H. Grain, R. Hausam.

1. Moved "further allowed constraint" section to #3 from being #2. Cleaned up text in this section and moved content from #1 to this section. Section is not complete.
2. How is DYNAMIC to work?
   1. Allowing changes to expansion set determined by the same value set version based on a different code system version.
   2. A restriction of the concepts in the default expansion based on the definition originally specified, using a new value set
   3. DYNAMIC in core principles value set binding is restricted to code system version used and need to determine how this should apply to changes in VS version.

2015-12-08 discussion

1. Concept Domain:
   1. MAX value set actually is a computable statement describing concepts that represent the semantic space/concept domain allowed conceptual domain.
   2. In FHIR a Data Element Definition is exactly the same thing as a V3 "Concept Domain", both of which define the semantic space for the model element.
   3. Prose statement that describe "behavior" of subsequent users wherein changes are allowed when that subsequent user wants to implement something different than the deterministic binding.
   4. What needs to be done is to pull out items from above that describe this "behavior" stuff and make that not a part of the binding semantic.
   5. It is aligned and needs to be included, but would not be BINDING SPECIFICATION

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.

Old Minutes

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