This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Binding Syntax"

From HL7Wiki
Jump to navigation Jump to search
 
(229 intermediate revisions by 4 users not shown)
Line 1: Line 1:
==Binding Syntax==
+
=Binding Syntax=
 
This project is a joint effort between [[Conformance_and_Guidance_for_Implementation/Testing|CGIT]] and [[Vocabulary]].
 
This project is a joint effort between [[Conformance_and_Guidance_for_Implementation/Testing|CGIT]] and [[Vocabulary]].
 +
 +
# Project now chaired by Rob McClure, building on work from Wendy, Ted, Frank O., Rob H. and Rob S.
 +
# Current project document ''with minutes (latest work at the bottom)'' [https://db.tt/VB3Mynum HERE]
  
 
==Scope==
 
==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.
 
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.
 +
==Working Group Meeting Time Slot==
 +
September 2017 San Diego Slot is '''Thursday Q2'''
 +
==General meeting Agenda==
 +
'''Meetings occurring on the following three dates: July 18, August 1 and Aug 15 will be run by Ted Klein and use Join.me'''<br>
 +
''Remember USA is now on DAYLIGHT SAVINGS TIME EDT is UTC -4''
 +
'''Meetings occur every other week''' ''- Tuesdays @ 2pm EDT for 60 min. - alternating with VBE call''
  
==Requirements==
+
'''Telephone uses standard HL7 Vocab number: 1 (770) 657-9270,,,598745#  - NOT THE SHARED SCREEN NUMBER FOR MIKOGO OR OTHERS'''
*model binding to a single code or one or more Value Set Assertions
 
*context binding to one or more Value Set Assertions
 
*dynamic/static stability
 
*identification of MIN/MAX/IGNORE value sets in each Value Set Assertion
 
*identification of Coding Strength for each Value Set in each Value Set Assertion
 
*constraint of a Concept Domain to a sub-Domain
 
*publication of value set expansions (appendix)
 
 
 
A Model Binding is the direct association of a coded attribute or data type property to one or more specific Value Set Assertions or specific single fixed code from a coding system.  It thus has the components:
 
*Value Set Assertion or Single Code (required)
 
*Intensity (optional)
 
*sequence (optional)
 
 
 
These requirements have been updated to match the latest version of the Core Principles and Properties of HL7 Version 3 Models
 
document.
 
 
 
A Context Binding is the association between a Concept Domain, a Binding Realm, and one or more Value Set Assertions, along with effective timestamps and a sequence (if more than one Value Set Assertion is defined).  The specific items that are included in a Context Binding are:
 
*Context Domain or sub-Domain (required)
 
*Binding Realm (required)
 
*Value Set Assertion (required)
 
*effective date (required)
 
*end date (optional)
 
*Intensity (optional)
 
*sequence (optional)
 
 
 
The last five items may be repeated as a group.
 
 
 
A Value Set Assertion is the mechanism to express the coded vocabulary constraint in a binding.  A Value Set Assertion has at least one required value set declared - the MAX; this is mandatory.  A Value Set Assertion has two optional Value Sets that may be declared, the MIN and IGNORED.  For more information about the MAX, MIN, and IGNORED value sets in a Value Set Assertion, and how mathematical set operations may be used to understand how these provide a localizable, extensible, yet controllable constraint, see the discussion in Core Principles of V3 Models, chapter 5.  The value set must be declared using a unique identifier, preferably the OID of the value set.  Each value set identified in a Value Set Assertion must have an associated Coding Strength declared.  The entire Value Set Assertion has an optional Stability level declared; if not declared, the stability is Dynamic.  If declared, the stability is Static, and the effective timestamp is that which is declared in the Value Set Assertion stability.
 
 
 
A Value Set Assertion is expressed using the following ten (10) elements:
 
*MAX Value Set OID and/or name (mandatory)
 
*MAX Value Set version date/time (optional)
 
*MAX Value Set Coding Strength (CNE or CWE – mandatory)
 
*MIN Value Set OID and/or name (optional)
 
*MIN Value Set version date/time (optional)
 
*MIN Value Set Coding Strength (CNE or CWE – conditional)
 
*IGNORED Value Set OID and/or name (optional)
 
*IGNORED Value Set version date/time (optional)
 
*IGNORED Value Set Coding Strength (CNE or CWE – conditional)
 
*STABILITY StaticDate (optional)
 
 
 
Note that Model Binding is generally specified in Implementation Guides, whereas Context Binding is generally published separately by a Realm (since a Context Binding is valid across all models in the Realm that make use of the bound Context Domain).  However, context binding to the Example Realm is common in Implementation Guides.  Note also that Model Binding cannot be used for advisory bindings; Context Binding to Example Realm should be used for those, or information should be placed into the 'Terminology Guidance' section of the Vocabulary Declaration of a coded model element for such advisory information.
 
 
 
==Keywords==
 
The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, and SHALL NOT in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. The keyword "SHALL" implies a lower cardinality of 1 but does not disallow NULL values. If NULL values are to be excluded, it will be via an additional explicit conformance statement.
 
 
 
==EBNF grammar==
 
<code><big>
 
 
 
<b>ModelBindingSyntax</b> =
 
ModelBindingSyntaxValueSetAssertion | ModelBindingSyntaxFixedCodeAssertion
 
 
 
<b>ModelBindingSyntaxValueSetAssertion</b> =
 
: "<span style="color:blue">When not null, the content of this element " </span> @bindingIntensity " <span style="color:blue">comply with one of the following Value Set Assertions, " </span> @effectiveDateInfo <span style="color:blue">" listed in order of preference:</span>" @valueSetAssertion+ <span style="color:blue"> " sequenced " </span>@bindingPriority"." EOL
 
 
 
<b>ModelBindingSyntaxFixedCodeAssertion</b> =
 
: "<span style="color:blue">When not null, the content of this element " </span> @bindingIntensity @fixedCodeAssertion @effectiveDateInfo "." EOL
 
 
 
<b>ContextBindingSyntax</b> =
 
:"<span style="color:blue">When not null, content for all coded model elements and datatype properties with a Vocabulary Declaration of Concept Domain </span>" @conceptDomain "<span style="color:blue">with a binding realm context of</span>" @bindingRealmName @bindingIntensity " <span style="color:blue">comply with one of the following Value Set Assertions, " </span> @effectiveDateInfo <span style="color:blue">" listed in order of preference:</span>" @ContextBinding+ <span style="color:blue"> " sequenced " </span>@bindingPriority"." EOL
 
:<i>(* Sorted by @bindingPriority *)</i>
 
 
 
<b>conceptDomain</b> =
 
 
 
<b>bindingRealmName</b> =
 
 
 
<b>effectiveDateInfo</b> =
 
:( (<span style="color:blue">" effective "</span> @effectiveDate ) | (<span style="color:blue"> " effective " </span> @effectiveDate <span style="color:blue"> " through " </span> @endDate) )
 
 
 
<b>bindingPriority</b> =
 
:@bindingPriority [1-9][0-9]*
 
 
 
<b>FixedCodeAssertion</b> =
 
:"<span style="color:blue">be fixed to the code</span>" Code CodeSystem "<span style="color:blue">.</span>"
 
 
 
<b>Code</b> =
 
:@code [ "<span style="color:blue">(</span>" @codePrintName "<span style="color:blue">)</span>" ]
 
 
 
<b>CodeSystem</b> =
 
:"<span style="color:blue">from the code system having the OID</span>" @codeSystem [ "<span style="color:blue">(</span>" @codeSystemName "<span style="color:blue">)</span>" ]
 
 
 
<b>CodePrintName</b> =
 
:@codePrintName["string"]
 
 
 
<b>ContextBinding</b> =
 
:EOL "<span style="color:blue">On or following</span>" @effectiveDate
 
:[ "<span style="color:blue">but prior to</span>" @expiryDate ] <i>(* If @expiryDate is present *)</i>
 
:"<span style="color:blue">,</span>" ValueSetAssertion
 
 
 
<b>BindingIntensity</b> =
 
:"<span style="color:blue"> MAY "</span> | <span style="color:blue">" SHOULD "</span> | <span style="color:blue">" SHALL </span>"
 
:<i>(* Use of 'SHALL' means that failure to observe the constraints expressed in the Value Set Assertion(s) will be judged non-conformant *)</i>
 
:<i>(* Use of 'SHOULD' means that applications are expected to obey the constraints expressed in the Value Set Assertion(s), but failure to do so will not be judged non-conformant *)</i>
 
:<i>(* Use of 'MAY' means that the constraints expressed in the Value Set Assertion(s) should be considered a helpful suggestion but no conformance expectations are being asserted. *)</i>
 
 
 
<b>ValueSetAssertion</b> =
 
:MaxValueSet [ MinValueSet ] [ IgnoreValueSet ] [ StaticDate ]
 
:<i>(* MinValueSet and IgnoreValueSet appear if the minimumValueSet or ignoreValueSet, respectively, are defined in the value set assertion *)</i>
 
 
 
<b>MaxValueSet</b> =
 
:"<span style="color:blue">be drawn from </span>" ValueSet
 
:( "<span style="color:blue">if an appropriate code exists within that expansion, otherwise a local code or original text SHALL be used.</span>" | "<span style="color:blue">.</span>" )
 
:<i>(* ValueSet is taken from element maximumValueSet.  First option is used if @codingStrength is CNE, second iS CWE *)</i>
 
 
 
<b>MinValueSet</b> =
 
:"<span style="color:blue">In addition, all applications SHALL at a minimum support</span>" ValueSet "<span style="color:blue">.</span>"
 
:[ "<span style="color:blue">  As well, SHALL must support all local codes and originalText.</span>" ]
 
:<i>(* ValueSet is taken from element minimumValueSet.  Last clause used if @codingStrength is CWE *)</i>
 
 
 
<b>IgnoreValueSet</b> =
 
:"<span style="color:blue">When receiving, all applications SHALL ignore - not process or raise an error when receiving - </span>" ValueSet
 
:( "<span style="color:blue">as well as all local codes and original text.</span>" | "<span style="color:blue">.</span>" )
 
:<i>(* ValueSet is taken from element ignoredValueSet.  First option is used if @codingStrength is CWE, second if CNE *)</i>
 
 
 
<b>StaticDate</b> =
 
:"<span style="color:blue">All of the above expansions SHALL be resolved based on the </span>",
 
:( "<span style="color:blue">date </span>" @staticBindingDate "<span style="color:blue">.</span>" | "<span style="color:blue">date of processing.</span>" )
 
:<i>(* First option is used if @staticBindingDate is present, otherwise use second option *)</i>
 
 
 
<b>ValueSet</b> =
 
:"<span style="color:blue">the set of codes in the expansion of Value Set</span>"
 
:[ ValueSetName ] [ ValueSetId ] [ ValueSetDef ] [ <ValueSetVersion> ]
 
:<i>(* At least one of ValueSetName, ValueSetId and ValueSetDef must be present *)</i>
 
 
 
<b>ValueSetName</b> =
 
:"<span style="color:blue"> </span>" @name
 
 
 
<b>ValueSetId</b> =
 
:"<span style="color:blue">with the identifier</span>" @id
 
 
 
<b>ValueSetDef</b> =
 
:"<span style="color:blue">containing all codes descended from root code</span>" @rootCode
 
:( "<span style="color:blue"> including</span>" | "<span style="color:blue"> excluding</span>" ) "<span style="color:blue">that root code</span>"
 
:<i>(* Use the first option when @includeRoot is true, second option otherwise *)</i>
 
:<i>(* NOTE: This style is restricted to use only when dealing with the ActClass, EntityClass, RoleClass, ActMood, EntityDeterminer, ActRelationshipType, ParticipationType and RoleLink classCodes.  For these the code system is fixed and can be inferred.  There is no ability to constrain the code system version. *)</i>
 
</big></code>
 
 
 
<code><big>
 
<b>ValueSetVersion</b> =
 
: @ValueSetVersionStatic | @ValueSetVersionDynamic
 
 
 
<b>ValueSetVersionStatic</b> =
 
:"<span style="color:blue"> using the version defined on </span>" @staticDate [ "<span style="color:blue">at </span>" @staticTime ]
 
 
 
<b>ValueSetVersionDynamic</b> =
 
: "the most recent version of the value set available at the time of processing"
 
</big></code>
 
 
 
'''Note''': ''EOL'' Represents an end of line as appropriate to the rendering technology (so &#60;br>, CR, CR/LF, etc.)
 
 
 
'''Note''': all dates should be formatted as "yyyy-mm-dd".
 
'''Note''': value set ID should be formatted in Object Identifier (OID).
 
 
 
===Issue===
 
The MIF representation of value set binding has (and has had for a while) the idea of "revision frequency" as a characteristic of the binding assertion. It appears at the same level as the static binding date.  The definition is as follows:
 
 
 
<b>revisionFrequency</b> "Indicates how often applications are expected to update their codes to reflect changes to the value-set associated with the attribute"
 
 
 
Allowed values are:
 
 
 
<i>Edition</i>: The value set associated with the domain is 'frozen' at the set of codes available at the time the Edition referenced by the interaction was published.  I.e. The codes which were published by HL7 as part of the edition for 'internal' code systems and the codes which were available in external code systems at the time the edition was published
 
 
 
<i>CodeSystem</i>: The value set bound to concept domain changes with the underlying code system.  Applications are expected to support codes from the current version of the code system, regardless of declared edition.
 
 
 
====Background====
 
This element has been available for model bindings since MIF 2.0.0 in May, 2006.  It was added with the intention of being used by implementation guides and conformance profiles.  It has never been used in HL7 International models because the tools don't support capturing it.  To the best of my knowledge, it has not been used in implementation guides or profiles to date yet either.  The objective is, for value set assertions that are not staticly bound (i.e. that do not have a static binding date), to indicate how often implementers are supposed to keep up with changes to the value set expansion.  One possibility is they only compute a new expansion for each "release" of the underlying specification and they use the expansion for the release communicated in the version attribute of the instance.  For example, if they receive an instance declaring that a version of "NE2007", then they use the value set expansion for that release date.  They don't have to track intervening changes in the code systems.  The other possibility is they need to keep current as the code systems change.  Whenever anything the value set depends on gets updated, implementers are expected to compute a new expansion and validate based on that "current" expansion.
 
 
 
====Decision Alternatives====
 
The Vocabulary Work Group needs to do one of three things:
 
- Request that this concept be deprecated or removed from the MIF
 
- Add the concept into Core Principles and into this binding syntax specification
 
- Request modifications to this concept as represented in the MIF and then incorporate the revised content into Core Principles and into this binding syntax specification
 
 
 
====Discussion====
 
The challenge with expectations for "keeping up to date" with a vocabulary are not just dependent on the bound vocabulary, but also on what the application is doing.  For example, the vocabulary for drug codes might change bi-weekly.  For a prescribing or dispensing application, a revision frequency of bi-weekly might also be an expectation.  However, for a research application doing retrospective analysis, a frequency of yearly might be perfectly fine.
 
 
 
====Recommendation====
 
Capture guidance around revision frequency in the "Vocabulary Guidance" annotation, but not as part of the binding syntax.  This attribute should be deprecated from the MIF.
 
 
 
==Examples==
 
 
 
<b>NOTE: these examples have not yet been updated to reflect the newly proposed EBNF syntax</b>
 
 
 
Model Binding:
 
 
 
Single Code Binding:
 
 
 
Value Set Assertion Binding:
 
 
 
 
 
--[[User:Tklein|Tklein]] 02:22, 14 September 2010 (UTC)I'm thinking a model binding to a set of codes will look more like this:
 
 
 
A code element SHALL be present where the value of @code is asserted by MAX Value Set 2.16.840.1.113883.19.3 LoincDocumentTypeCode 20100422 CWE, MIN Value Set 2.16.840.1.113883.19.6 MinimumDocumentTypeCode CNE with stability 20101015
 
 
 
The following are older examples that use the former syntax which fails to support the current binding characteristics:
 
 
 
CONF-ex1: A code element SHALL be present where the value of @code is selected from Value Set 2.16.840.1.113883.19.3 LoincDocumentTypeCode DYNAMIC.
 
 
 
CONF-ex2: A code element SHALL be present where the value of @code is 34133-9 Summarization of episode note 2.16.840.1.113883.6.1 LOINC STATIC.
 
 
 
A restatement of these under the proposed syntax might look like:
 
 
 
1.  When not NULL, the content of this element be drawn from the set of codes in the expansion of Value Set "LoincDocumentTypeCode" with the identifier 2.16.840.1.113883.19.3 if an appropriate code exists within that expansion, otherwise a local code or original text MAY be used.
 
 
 
2.  {A coded element} SHALL be present where the value of @code be fixed to the code 34133-9 "Summarization of episode note" from the code system having the OID 2.16.840.1.113883.6.1 "LOINC" using the version of the code system as published on 20110415.
 
 
 
--[[User:TedKlein|TedKlein]] 14:53, 28 July 2011 (UTC)We need some further examples showing the full Value Set Assertion with all three components.  Something like:
 
 
 
When not NULL, the content of this element shall be drawn from the set of codes in the expansion of Value Set "AcknowledgementDetailType" with the identifier 2.16.840.1.113883.1.11.19358 if an appropriate code exists within that expansion, otherwise a local code or original text MAY be used.  All of the above expansions SHALL be resolved based on the date 20110311 effective 20110601
 
 
 
 
 
--[[User:Tklein|Tklein]] 02:22, 14 September 2010 (UTC)And a context binding something like this:
 
 
 
Context Binding:
 
 
 
When not null, content for all coded model elements and datatype properties with a Vocabulary Declaration of Concept Domain "ActDetectedIssueType" with a binding realm context of "R1" SHALL comply with one of the following Value Set Assertions, respecting the identified date ranges and listed in order of preference:
 
On or following 20100701 but prior to 20110615 be drawn from the set of codes in the expansion of Value Set "ActDetectedIssueCode" with the identifier 2.16.840.1.113883.1.11.19572 if an appropriate code exists within that expansion, otherwise a local code or original text MAY be used.  On or following 20110616 be drawn from the set of codes in the expansion of Value Set "ActIssueCode" with the identifier 2.16.840.1.113883.1.11.20357 if an appropriate code exists within that expansion, otherwise a local code or original text MAY be used.  All of the above expansions SHALL be resolved based on the date of processing.
 
 
 
Context Domain Constraining to a Context sub-Domain:  to be defined
 
 
 
Context binding to a single code:  to be defined
 
  
Context binding to a list of value set assertions with overlapping dates: to be defined
+
=== Meeting will be one of the following web share environments - see agenda for which one will be used===
 +
''Free Conference Call Session''
 +
# Go to https://www.freeconferencecall.com/join/vocab
 +
# Enter your name and email, then click on "Join"
 +
# Select 'cancel' when it asks you if you want to buy something
 +
# It will open a window with the screen share which will start when the presenter starts the meeting
 +
# Click on the little telephone icon to start audio
  
  
--[[User:TedKlein|TedKlein]] 14:53, 28 July 2011 (UTC)Is the sequence in the bindings implied by the sequence of prose sentences in the syntax?
 
  
==Translations==
+
''Mikogo session''
The grammar listed above is using the English language for convenience. However, it can be assumed that localized implementation guides will be created not written English. Therefore, a translation is necessary. This could be done best by defining a country specific the grammar. The grammars defined so far are listed below.
+
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
  
===German===
+
The above link works with any browser.  Once there:
HL7 Germany provides a detailed description in German as well, which can be found at [http://wiki.hl7.de/index.php/Vokabular-Einbindung].
+
# Click on "Knock To Enter"
  
<code><big>
+
The September 15, 2016 meeting will use the join.me session above
<b>DesignTimeDynamicBindingSyntax</b> =
 
:„Der Wert für“ CodedElement („MUSS“ | „SOLL“) „DYNAMISCH aus dem ValueSet“ (ValueSetOID | ValueSetName) „ausgewählt werden.
 
:„Der Wert für“ CodedElement („MUSS“ | „SOLL“) „DYNAMISCH aus dem ValueSet“ (ValueSetOID | ValueSetName) [„ODER“ (ValueSetOID | ValueSetName)] „ausgewählt werden.“ EOL
 
  
<b>DesignTimeStaticBindingSyntax</b> =
+
The March 29, 2016 meeting will use the join.me session above
:„Der Wert für“ CodedElement („MUSS“ | „SOLL“) „STATISCH aus dem ValueSet“ (valueSetOID | valueSetName) ValueSetEffectiveDate „ausgewählt werden.
 
:„Der Wert für“ CodedElement („MUSS“ | „SOLL“) „STATISCH aus dem ValueSet“ (ValueSetOID | ValueSetName) ValueSetEffectiveDate [„ODER“ (valueSetOID | ValueSetName)] ValueSetEffectiveDate „ausgewählt werden.“ EOL
 
  
 +
----
  
Reduction to a single code:
+
=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. <br><br>
 +
A '''''Value Set Binding''''' describes '''[[an implementable terminology binding]]'''  that has two flavors:
 +
#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]
 +
#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 '''[http://wiki.hl7.org/index.php?title=An_implementable_terminology_binding#Non-Implementable_Terminology_Bindingan 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. <br>
 +
<br>
 +
'''Incomplete Glossary'''<br>
 +
'''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.<br>
 +
'''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.<br>
 +
'''Currently Available''': Most recently released version of a Code System available for application to a patient record, existing on the terminology server in use.
 +
<br>
 +
[https://creately.com/diagram/iqtsedg4/cKu2FYjYBD08QfSYZ8ySKS8uaU%3D Terminology Binding Diagram]
 +
==A Value Set Binding To A Data Element ==
 +
#'''SHALL''' describe a '''''Content''''' '''Value Set Binding''' and,
 +
## ''we need to review and discuss the Core Principles notion of a priority sequence of different bindings on the same data element''
 +
#'''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'''.
 +
#A ''Content Value Set Binding'' describes coded values that represent expected content for the data element.
 +
#A ''NULL Value Set Binding'' describes allowed NULL values for the data element
 +
##This NULL value set applies only to coded "nulls" and not numeric null situations (infinity, real vs. integer.)
 +
##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, [http://hl7.org/fhir/ValueSet/v3-NullFlavor FHIR])
 +
##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
 +
##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.
 +
##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.
 +
##A ''NULL Value Set Binding'' may '''NOT''' specify a binding guidance verb of OPEN, but can specify any of FIXED, CLOSED, EXTEND, or RESTRICT.
 +
#Taken together, the UNION of all value set bindings represent the full binding for the data element
 +
#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.
  
<b>DesignTimeStaticBindingSingleCodeSyntax</b> =  
+
==A Value Set Binding must specify, and only need specify the following three (four?) items==
:„Der Wert für“ codedElement („MUSS“ | „SOLL“) „STATISCH auf“ Code [DisplayName] CodeSystemOID [CodeSystemName] (EffectiveDate] „festgelegt werden.“ EOL
+
===SHALL specify the information necessary to [[determine a specific implementable 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 [http://wiki.hl7.org/index.php?title=Value_Set_Definition_Standard_Project 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.
 +
# 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.
 +
#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:
 +
##'''SHALL''' include a value set identifier that will resolve to a full value set definition.
 +
###One VSD may have one-to-many instances of VSD versions
 +
##'''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.
 +
###A particular version instance of a VSD might specify explicit versions of included content or might not
 +
##'''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.
 +
###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.
 +
#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.'''
 +
# 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.
  
<b>RuntimeDynamicBindingSyntax</b> =
+
===SHALL specify 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”===
:„Die VocabularyDomain für“ CodedElement „MUSS“ DomainName „sein. Das ValueSet für“ DomainName „in“ RealmName („MUSS“ | „SOLL“) „DYNAMISCH auf“ (ValueSetOID | ValueSetName) „festgelegt werden.
+
2017-09-26: Changed to Tolerance and perhaps this is a flag that simply allows for codes not in the bound value set.  
:„Die VocabularyDomain für“ CodedElement „MUSS“ DomainName „sein. Das ValueSet für“ DomainName „in“ RealmName („MUSS“ | „SOLL“) „DYNAMISCH auf“ (ValueSetOID | ValueSetName) [„ODER“ (ValueSetOID | ValueSetName)] „festgelegt werden.
+
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.
  
<b>RuntimeStaticBindingSyntax</b> =
+
Extensibility defines constraints that can be used to clarify how to support conformance testing. Expectation woud be that
:„Die VocabularyDomain für“ CodedElement „MUSS“ DomainName „sein. Das ValueSet für“ DomainName „in" RealmName („MUSS“ | „SOLL“) „STATISCH auf“ (ValueSetOID | ValueSetName) ValueSetEffectiveDate „festgelegt werden.
+
Binding Strength is separate and defines whether an implementer can change to a different value set
:Die VocabularyDomain für“ CodedElement „MUSS“ DomainName „sein. Das ValueSet für“ DomainName „in“ RealmName („MUSS“ | „SOLL“) „DYNAMISCH auf“ (ValueSetOID | ValueSetName) ValueSetEffectiveDate [„ODER“ (ValueSetOID | ValueSetName)] ValueSetEffectiveDate „festgelegt werden.
+
# Extensibility '''NEA''': Coding No Exception codes Allowed (This is similar to V3 CNE)
</big></code>
+
##Sending/Creating perspective
 +
###SHALL only employ values that exist in the expansion
 +
##Receiving/Consuming perspective
 +
###SHALL accept without asserting an error any value that exists in the expansion
 +
###SHALL assert an error for any other value in the data element that does not exist in the expansion.
 +
# Extensibility '''CEA''': Coding with Exception codes Allowed
 +
##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.
 +
##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.
 +
## Sending perspective:
 +
### SHALL send from expansion if idea is in the expansion
 +
### MAY send a valid  extended "exception code" if idea is not in the expansion
 +
#### Send a code and an identification of code system (can be local)
 +
#### Send text and no code
 +
##### FHIR [https://chat.fhir.org/#narrow/stream/argonaut/subject/Required.20CodeableConcepts discussion]: Consider making three flavors of CEA - Allow Exception that can be:
 +
######Either code or text
 +
######Only allow codes. No text.
 +
######Only allow Text. No codes.
 +
## Receiving Perspective
 +
### SHALL be able to identify when received code is in the expansion and not report an error
 +
### 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.
  
===French===
+
===SHALL specify [[Guidance]] on===
Not provided yet.
+
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.
 +
# 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.
 +
##'''''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.
 +
### 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.
 +
### A "downstream" conformant IG based on this binding '''SHALL''' be FIXED.
 +
##'''''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.
 +
###Again, a CLOSED binding can allow dynamic expansions.
 +
### A "downstream" conformant IG based on this binding '''MUST''' be CLOSED or FIXED.
 +
##'''''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
 +
###This binding is essentially a combination of FIXED + the current idea of Coded With Extensions (V3 CWE)
 +
###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.''
 +
### A "downstream" conformant IG based on this binding '''MUST''' be either EXTEND, CLOSED or FIXED.
 +
###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
 +
####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.
 +
#### 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.
 +
##'''''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
 +
###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.
 +
###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.''
 +
### A "downstream" conformant IG based on this binding '''MUST''' be either RESTRICT, CLOSED or FIXED.
 +
###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
 +
####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.
 +
#### 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.
 +
##'''''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.
 +
###This binding is essentially a combination of CLOSED + the current idea of Coded With Extensions (V3 CWE)
 +
###This is the most permissive Binding
 +
###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.''
 +
### A "downstream" conformant IG based on this binding can be of any type.
 +
###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
 +
####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.
 +
####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.
 +
#In addition to the value set binding guidance verbs above, a '''''MAX''''' '''Content Value Set Guidance''' '''MAY''' be specified.
 +
##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'''.
 +
##A ''MAX Content Value Set Guidance'' '''SHALL''' be specified in one of the following two ways:
 +
###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.
 +
###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.
 +
===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?
  
===Spanish===
+
'''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:
Not provided yet.
+
#'''''REQUIRED''''' Where the bound value set '''must''' be used and no other can be substituted. In this case NO value set Change is allowed
 +
##Sending perspective
 +
##Receiving perspective
 +
#'''''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.
 +
##Sending perspective
 +
##Receiving perspective
 +
#'''''EXAMPLE''''' Where the bound value set is not promoted as complete or definitive. In this case value set Change Is Expected.
 +
##Sending perspective
 +
##Receiving perspective
  
===Portuguese===
+
==The following were moved from a prior version of this and are kept here for historical reference:==
Not provided yet.
+
Moved after 2017-01-19 after Jan WG
 +
<br>
 +
# '''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.
 +
## Sending perspective:
 +
### SHALL send from expansion if idea is in the expansion
 +
### MAY send something not in expansion if idea is not in the expansion
 +
#### SHALL Flag the instance in some way to clearly identify that the concept sent is not in the expansion set
 +
##### Send a code and an identification of code system (can be local)
 +
##### Send text and no code
 +
##### FHIR [https://chat.fhir.org/#narrow/stream/argonaut/subject/Required.20CodeableConcepts discussion]: Consider making three flavors of CEA - Allow Exception that can be:
 +
######Either code or text
 +
######Only allow codes. No text.
 +
######Only allow Text. No codes.
 +
## Receiving Perspective
 +
### SHALL be able to identify when received code is in the expansion and not report an error
 +
### Identify when a data instance contains content not in the expansion but is sent appropriately
 +
<br><br>Moved 2016-11-22:
 +
<br>
 +
An additional item for discussion that could be added:<br>
 +
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. <br>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? <br> 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.
 +
<br>
 +
# If "downstream" changes in the value set to be used '''are allowed''', then such a specification must clarify if
 +
## 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.
 +
## 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'''.
 +
# Restriction to only values that are within the expansion - '''CLOSED'''
 +
## 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.
 +
## It is noted that there are circumstances where a CLOSED binding may not be further constrained, and thus can be thought of as "FIXED". 
 +
## 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"
 +
## Sender perspective
 +
### Must only send values in the expansion
 +
## Receiver perspective
 +
### Must receive without error values in the expansion
 +
### Error for any other value
 +
# Binding allows use of values that are not in the expansion - '''OPEN'''
 +
## Sender perspective:
 +
### Must send from expansion if idea is in the expansion
 +
### May send something not in expansion if idea is not in the expansion
 +
#### Must Flag the instance – “OTHR” (Flavour Of Null yet is really not a null)
 +
##### Send a code and an identification of code system (can be local)
 +
##### Send text and no code
 +
##### Send a “reason that expansion code can not be sent” – This is a true flavour of null
 +
## Receiver Perspective
 +
### Must be able to identify when received code is in the expansion and not report an error
 +
### Identify when a data instance contains content not in the expansion but is sent appropriately
 +
# 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.
 +
### MIN binding describe the concepts that an implementation ''MUST'' fully support
 +
### MAX binding MUST include all the MIN concepts with all additional concepts noted as those that ''SHOULD'' be supported.
 +
### 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.
 +
### Any constraint on the binding ''MUST'' result in a new MAX value set that is a proper subset of the ''upstream''binding MAX value set.
 +
### Any constraint on the binding ''MUST'' result in a set of concepts that are within the semantic range of any defined concept domain.
 +
##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.
 +
## Some of this should be defined as default behavior.
 +
## V2 Binding strength is in this bucket
 +
## 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.
  
===Japanese===
+
=Working Example to be rendered using the semantics described=
Not provided yet.
+
'''Example'''
 +
<br>
 +
Data element used to report drug resistance in a culture. <br>
 +
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.
 +
<br> From the '''Current Working Material''' section. <br>
 +
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'''). <br>
 +
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?<br>
 +
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.
 +
#The question we must address
 +
## is if this is a ''conformant'' expansion of the value set as defined?
 +
## 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.
  
==Open Issues==
+
=Minutes=
*conditions (true/false)
+
[http://wiki.hl7.org/index.php?title=Vocab_VBS_Minutes Minutes] now on separate page<br>
*combined constraints: to be concatenated via "and" (must be reflected in BNF grammar)
+
=Use Cases=
*current grammar is not the current state of binding in HL7 v3 models; current state uses Value Set Assertion for binding
+
This section is where we will list use cases that are to be described using the approach noted
*Value Set Assertions are defined in the Implementation Guides
+
# Emerging disease tracking registry
*Value Sets may be identified by OID or name
+
# Data transmission where successive implementation guides can add additional codes to those specified in the specification being constrained
*Must be a way to assert ad hoc constraints to implement OCL-like restrictions on the bindings
+
## National value set -> state value set -> local value set
*finalize translations
+
# Start from typical base standard value set with no needed change to implement
 +
## Same as above but initial VS was an example and must be made implementable
 +
# V2 Lab (LRI) examples with the use of national to state to implemented specifications all using binding identifiers.
 +
<br>
 +
=[http://wiki.hl7.org/index.php?title=Prior_Binding_Syntax_Work Prior Binding Syntax Material Page]=

Latest revision as of 19:06, 14 November 2017

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.

Working Group Meeting Time Slot

September 2017 San Diego Slot is Thursday Q2

General meeting Agenda

Meetings occurring on the following three dates: July 18, August 1 and Aug 15 will be run by Ted Klein and use Join.me
Remember USA is now on DAYLIGHT SAVINGS TIME EDT is UTC -4

Meetings occur every other week - Tuesdays @ 2pm EDT for 60 min. - alternating with VBE call

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 - see agenda for which one will be used

Free Conference Call Session

  1. Go to https://www.freeconferencecall.com/join/vocab
  2. Enter your name and email, then click on "Join"
  3. Select 'cancel' when it asks you if you want to buy something
  4. It will open a window with the screen share which will start when the presenter starts the meeting
  5. Click on the little telephone icon to start audio


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 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 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

SHALL specify the information necessary to determine a specific implementable 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.

SHALL specify 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.

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.

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

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

Moved after 2017-01-19 after Jan WG

  1. 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. 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.
    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



Moved 2016-11-22:
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.

  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