Binding Syntax

Binding Syntax

This project is a joint effort between Implementation and Conformance and vocabulary.

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.

Requirements

• model binding to a single code or Value Set Assertion
• context binding to a Value Set Assertion
• dynamic/static stability
• identification of MIN/MAX/IGNORE value sets in Value Set Assertion
• identification of Coding Strength in the Value Set Assertion
• constraining 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 a specific Value Set Assertion or specific single fixed code from a coding system.

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)
• sequence (optional)

The last four 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 Aet 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

ModelBindingSyntax =

"When not null, the content of this element SHALL ", ( ValueSetAssertion | FixedCodeAssertion ), EOL ;

(* Depending on whether the Vocabulary Declaration is a value set assertion or a fixed code. Concept domain vocabulary declarations are not covered here. *)

ContextBindingSyntax =

"When not null, content for all coded model elements and datatype properties with a Vocabulary Declaration of Concept Domain ", @conceptDomain,

" with a binding realm context of ", @bindingRealmName,

" SHALL comply with one of the following Value Set Assertions, respecting the identified date ranges and listed in order of preference: ",

ContextBinding+, EOL ; (* Sorted by @bindingPriority *)

--Tklein 20:50, 24 September 2010 (UTC)I think it is unnecessary to explicitly state "respecting the identified date ranges": what would be the syntax and meaning of NOT respecting the effectiveDate and endDate in the VSA? What is the meaning of "SHALL comply with"? In the first binding syntax I think you are saying it the right way but are only halfway there: "the content of the element SHALL ". The old syntax was clear: "The content of the element SHALL be drawn from ". I know this is not technically correct; both the old binding directly to a single value set and the new binding to a list of Value Set Assertions, are the definition of a vocabulary constraint, not a picklist (which the other phraseology implies). I think we need to improve this.

--Lmckenzi 20:32, 27 September 2010 (UTC)The effective date and end date are actually characteristics of the bindings. What I was trying to get at is they have to comply with one of the VSAs in the list where the current date is between start and end. We can't us "shall be drawn from" because that only deals with maximum. Happy to see better wording though.

FixedCodeAssertion =

"be fixed to the code ", Code, CodeSystem, "." ;

Code =

@code, [ "(", @codePrintName, ")" ] ;

CodeSystem =

" from the code system having the OID ", @codeSystem, [ "(", @codeSystemName, ")" ] ;

CodeSystemVersion =

" using the version of the code system as published on ", @codeSystemVersion ;

ContextBinding =

EOL " - On or following ", @effectiveDate,

[ " but prior to ", @expiryDate ], (* If @expiryDate is present *)

", ", ValueSetAssertion ;

ValueSetAssertion =

MaxValueSet, [ MinValueSet ], [ IgnoreValueSet ], StaticDynamic ;

(* MinValueSet and IgnoreValueSet appear if the minimumValueSet or maximumValueSet, respectively, are defined in the value set assertion *)

MaxValueSet =

"be drawn from ", ValueSet,

( " if an appropriate code exists within that expansion, otherwise a local code or original text MAY be used." | "." ) ;

(* ValueSet is taken from element maximumValueSet. First option is used if @codingStrength is CWE, second if CNE *)

MinValueSet =

" In addition, all applications SHALL at a minimum support ", ValueSet, ".",

[ " As well, SHALL must support all local codes and originalText." ] ;

(* ValueSet is taken from element minimumValueSet. Last clause used if @codingStrength is CWE *)

IgnoreValueSet =

" When receiving, all applications SHALL ignore - not process or raise an error when receiving - ", ValueSet,

( " as well as all local codes and original text." | "." ) ;

(* ValueSet is taken from element ignoredValueSet. First option is used if @codingStrength is CWE, second if CNE *)

StaticDynamic =

" All of the above expansions SHALL be resolved based on the ",

[ "date ", @staticBindingDate "." | "date of processing." ] ;

(* First option is used if @staticBindingDate is present, otherwise use second option *)

ValueSet =

" the set of codes in the expansion of Value Set",

[ ValueSetName ], [ ValueSetId ], [ ValueSetDef ], [ <ValueSetVersion> ] ;

(* At least one of ValueSetName, ValueSetId and ValueSetDef must be present *)

ValueSetName =

" ", @name ;

ValueSetId =

" with the identifier ", @id ;

ValueSetDef =

" containing all codes descended from root code ", @rootCode,

( " including" | " excluding" ), " that root code" ;

(* Use the first option when @includeRoot is true, second option otherwise *)

(* NOTE: This style is restricted to use only when dealing with the ActClass, EntityClass, RoleClass, ActMood, EntityDeterminer, ActRelationshipType, ParticipationType and RoleLink classCodes *)

--Tklein 22:45, 24 September 2010 (UTC)I think this is bad. Folks should NOT just create value sets 'on the fly'. I know this is how the tooling works, but that is a usability shorthand. Enshrining this handy user-interface gizmo used in the tool for human readable BNF grammar for Implementation Guides is, I strongly believe, a Very Bad Idea.

--Lmckenzi 20:32, 27 September 2010 (UTC)I've added the caveat restricting where it's used. I'd like the syntax to support what the MIF allows. If we allow it in models, no reason not to allow it in IGs.

ValueSetVersion = " using the version defined on ", @versionDate, [ " at ", @versionTime ] ; --Tklein 22:45, 24 September 2010 (UTC)Another Bad Idea. What is the purpose of STABILITY in the VSA if you define the value set version (which is a timestamp) in the assertion as well? Or is this your syntax for STABILITY in the VSA? Since this is part of the ValueSet definition, used in MIN, MAX, and IGNORE value set references in the VSA, then you set up a potential conflict between the STATIC STABILITY timestamp and this timestamp.

--Lmckenzi 20:32, 27 September 2010 (UTC) When referencing a value set, you've always had the ability to refer to a specific version. STABILITY applies to everything that's not already declared. As mentioned in Core Principles, you can actually nail everything down without declaring stability, in which case the staticBindingDate doesn't accomplish anything.

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:

revisionFrequency "Indicates how often applications are expected to update their codes to reflect changes to the value-set associated with the attribute"

Allowed values are:

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

CodeSystem: The value-set associated with the domain changes with the underlying cod-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

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

Examples

NOTE: these examples have not yet been updated to reflect the newly proposed EBNF syntax

Model Binding:

Single Code Binding:

Value Set Assertion Binding:

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

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.

Context Binding:

Value Set Assertion Binding:

--Tklein 02:22, 14 September 2010 (UTC)And a context binding something like this:

Context Domain ActIssuePriority SHALL be bound to MAX Value Set 2.16.840.1.113883.1.11.19358 AcknowledgementDetailType in Realm R1

Context Domain Constraining to a Context sub-Domain:

Expression of a Value Set Assertion:

Open Issues

• conditions (true/false)
• combined constraints: to be concatenated via "and" (must be reflected in BNF grammar)
• current grammar is not the current state of binding in HL7 v3 models; current state uses Value Set Assertion for binding
• Value Set Assertions are defined in the Implementation Guides
• Value Sets may be identified by OID or name
• Must be a way to assert ad hoc constraints to implement OCL-like restrictions on the bindings