Domain and Value Set Definitions and Binding

Domain and Value Set Definitions and Binding

Version 0.8.1

APRIL 13, 2007

Domain and Value Set Definitions and Bindings in Static Models

Purpose and Intent

(reword) This document contains proposed definitions for vocabulary items...

Introduction

• Attributes
• Properties on the datatypes
• Attributes and properties can be coded (coded elements)
• Coded elements have associated domains
• Domains are bound to value sets within realms
• Some coded elements can only express a single coded value, others coded elements can convey compositional expressions of multiple codes as their value

Code System

Within HL7, a code system is defined as a collection of codes with associated designations and meanings. Examples of code systems include ICD-9 CM, SNOMED CT, LOINC, and CPT. To meet the requirements of a code system as defined by HL7, a given code must resolve to one and only one meaning within the code system. Given this definition, each table in the HL7 Version 2 standard represents a different code system since codes are sometimes used in different tables to have different meanings. For example, “M” in the gender table means Male, while “M” in the marital status table means Married.

Concept Domain

An HL7 Concept Domain is a named category of like concepts (semantic type) that will be bound to one or more coded elements.*

Concept Domains exist because we want to constrain the intent of the coded element while deferring the association of the element to a specific coded terminology until later in the message development process. Thus, Concept Domains are independent of any specific vocabulary or code system.

Concept Domains are universal in nature (independent of any realm). The name for a Concept Domain should never contain any reference to a specific realm. Concept Domains are proposed as part of the HL7 standards development process and are approved by the RIM harmonization process. Any conflicts in proposed domains are resolved by the RIM harmonization process.

A Concept Domain is documented by specifying a name, a narrative definition, and three or more examples of concepts that are members of the domain category. This can be accomplished by at least one of the following:

1. Including three example concepts as part of the narrative definition;

1. Binding the domain in the Example Realm to a value set containing at least three example concepts;

1. Binding the domain in either the Universal or Representative Realm to a value set deemed to contain a complete set of concepts.

The binding process and descriptions of the Universal, Representative, Unclassified and Example Realms are described later in this document.

Examples of Concept Domains

The HL7 defined Concept Domain HumanLanguage, defines a category of like concepts specifying the “Codes for the representation of the names of human languages.” The HumanLanguage Concept Domain only defines the category for the concepts that represent the different human languages. The actual coded elements for the concepts comprising the content for the HumanLanguage Concept Domain will be defined by different code systems used by different entities.

For example, agencies in the United States may choose to use a code system containing codes that represent the Native American languages, while agencies in New Zealand may find such a Code System inappropriate.

Figure 1: RIM Attributes and Vocabulary Domains

• A coded element is any attribute from a v3 static model (RIM, DIM (D-MIM), CIM (R-MIM, HMD, Message Type), LIM (Template, Profile etc.)) or property from a V3 data type model where the type of that attribute or property can be specialized or generalized from the CD (concept descriptor) data type, and collections thereof. Thus, coded attributes are attributes that have a type of concept descriptor (CD), coded simple value (CS), coded value (CV), concept role (CR), coded with equivalents (CE), coded ordinal (CO), character string with code (SC), or physical quantity representation (PQR). Elements with a data type of any (ANY) are also categorized as coded elements because the ANY datatype can be constrained to CD or any of its specializations.

Sub-Domains

HL7 Concept Domains are defined as a named category of like concepts. The categorization of Concept Domains is hierarchical allowing for further constraint on the breadth of the semantic category covered by the Concept Domain. Such constrained domains are known as “sub-domains”.

Sub-domains allow for further specialization (constraint) on the intended values for a domain.

Realms

The term Realm (previously also referred to as Context of Use) is used in different ways. In the context of HL7 Vocabulary, it is used to indicate a binding realm: this manages the bindings/substitutions of value sets to reflect local rules, and is a parameterization permitting internationalization of vocabulary – binding different value sets to the same message design being used in a different country.

Each HL7 International Affiliate has control of a Binding Realm bounded by the geographic scope of that International Affiliate.

Four Generic Realms have been defined that are not specific to an International Affiliate. These generic realms should never appear in instances, they are only used in the standards creation process. All instances must declare a particular realm (or sub-realm) based on the jurisdiction from which they originate or for which they are destined or some third jurisdiction by site-specific agreement.

Universal Realm

The Universal Realm constitutes the core HL7 realm which by definition is invariable and fully inherited by all HL7 compliant implementations. I.e. If a Universal Realm binding exists for any domain, all implementations are expected to use the set of codes associated with that binding. No other bindings may exist. Structural elements and most datatypes are examples of contents in this realm. Contents from domain technical committees are not likely to be included in the Universal Realm and when introduced must go through special processes to ensure full international consensus on the constraint to a single binding.

Example Realm

The example realm is used for bindings to sets of codes that are known to provide incomplete or non-implementable coverage to the associated domain. They are used to fulfill the example requirement of Concept Domain definition. They may also be used in the construction of realm-independent example instances. Example realms are not needed when Representative Realms exist.

Representative Realm

Representative realm bindings are intended to be complete and implementable. However, unlike universal bindings, there is no expectation that all affiliates will choose to adopt the representative realm bound codes. Representative realm bindings provide both a starting point and as a focus for consensus, while recognizing that cultural and political variations between International Affiliates will result in alternative bindings. To qualify for Representative Realm designation, candidate content must be sufficiently comprehensive and internally consistent to be adoptable and implementable by specialized binding realms. A representative realm binding has no official force in an affiliate. The affiliate must explicitly choose to adopt the same set of codes with an Affiliate-specific binding for the representative set of codes to come into effect when determining conformance

Unclassified Realm

Since much proposed HL7 machinery will require the explicit specification of a realm, the creation of a realm that can accommodate content that is new and being created or legacy content that has not yet been promoted to one of the three main realms. The Unclassified Realm may also serve as a transition point for content contributed from Specialized Realms. Unclassified realms exist for HL7 administrative purposes and have no effect on implementations

Sub-binding Realms

In some circumstances, an International Affiliate might choose to create additional binding realms narrower in scope than the affiliate-wide binding realm. The sub-binding realms might be constructed geographically (regions, states, provinces, etc.) or by type of implementation (e.g. human vs. veterinarian). Sub-binding realms can only be created by International Affiliates.

Note: Because the purpose of binding sub-realms is to allow the use of different code sets for the same message within an affiliate, they can cause interoperability issues within the Affiliate. They should therefore only be introduced after careful consideration of the interoperability consequences.

Value Sets

Introduction

A Value Set represents a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

Value set complexity may range from a simple flat list of concept codes drawn from a single code system, to an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems.

Value sets exist to constrain the content for a coded element in an HL7 static model or data type property. Value sets cannot have null content, and must contain at least one concept representation where any given concept is generally (but not required to be) represented by only a single code within the Value Set.

Sub-value Sets

A sub-value set is a sub-set of a ”parent” value set.

Value Set Specification

Value sets can be specified in two ways, either by enumeration (extension), or definition (intention).

Extensional Value Set Representation (Enumeration)

From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an extensional definition is a description of a concept by enumerating all of its subordinate concepts under one criterion of subdivision.

Value sets defined by extension are comprised of an explicitly enumerated set of codes. The simplest case is when the value set consists of only one code.

Code Value	Description
M	Male
F	Female
U	Unspecified

More complex variations might relate to hierarchical coding systems such as the following fictitious example:

Code Value	Level	Description
1123123	1	Education
1343434	2	Diabetic Education
1445455	2	Stroke Education
2135534	1	Counseling
2344566	2	Emotional
3456663	2	Daily Living

Intensional Value Set Definition (Definition)

From ISO (http://www.tc215wg3.nhs.uk/pages/pdf/vote0204.pdf), an intensional definition describes the intension of a concept by stating the superordinate concept and the delimiting characteristics.

Value sets defined by intension are value sets that are defined by a computable expression that can be resolved to an exact list of codes.

For example, an intensional value set definition might be defined as, “All SNOMED CT concepts that are children of the SNOMED CT concept ‘Diabetes Mellitus.’”

Some common strategies used to define intensional values sets include:

1. 1. 1. Reference a head concept and its subordinate concepts in a hierarchy.
      2. Reference only the concepts subordinate to a head code (and not the head code itself).
      3. Create arbitrarily complex unions, intersections, and exclusions of the two previously described types of value sets.
      4. Other mechanisms, including statements created using a rich expression language.

Nested Value Sets

When a Value Set Entry references another Value Set, the child value set is referred to as a Nested Value Set. There is no preset limit to the level of nesting allowed within value sets. Value sets cannot contain themselves, or any of their ancestors (i.e. they cannot be defined recursively).

Intensional Value Sets can be defined by either fixing the Value Set definition to a specific version of the Code System (when the Code System supports versioning), or by decoupling the Value Set definition from the version of the code system. This seemingly subtle variation can have very significant impact on the final list of concepts which the Value Set ultimately resolves to.

When the Value Set definition is tied to the version of the Code System, the value set content will remain fixed when instantiated. When the Value Set definition is independent of Code System version, the content of the Value Set can vary as the Value Set is resolved against different versions of the Code System.

Value Set / Code System Relationship

Whether specified extensionally, intensionally or both, a Value Set can contain concepts from one or more code systems. While drawing concepts from multiple code systems in many cases is desirable, care must be taken to ensure that a given meaning is only represented by a code or codes from a single code system. For example, it would be inappropriate to create value set where a given orderable item like a hematocrit could be represented by a CPT code and also by a LOINC code. If a single concept (meaning) ends up being represented by more than one code in a Value Set in this manner, it allows for the possibility that the same information can be recorded in two different ways. This can lead to confusion and error in analyzing the recored data.

On the other hand, a value set is allowed to contain more than one code for a given concept as long as both codes are drawn from the same code system. For example, in the UCUM coding system “l” and “L” are both codes for liter. While this is undesirable, it is permitted for a value set to have both codes as members of the set. When this occurs, the codes are referred to as synonyms.

Value Set Versions

Value sets are versioned. The version of a value set changes when:

1. For enumerated value sets
   1. Any allowed values are added or deleted
2. For intensionaly defined value sets
   1. If the logic of the defining expression changes

Changes that correct the spelling of terms, or additions of terms that do not add new codes to the value set, do not cause the version to change.

There are multiple strategies for tracking value set versions. Two of the most common are:

1. Increment the version number each time a change is made to the value set.
2. Track add/modification dates for each change to the value set.

By a vote of the Vocabulary TC on September 15, 2006 at the Boca Raton meetings, it was decided that HL7 will reference all value set versions based on effective date and not by available date or by a version number. This policy has the following implications:

1. For enumerated value sets maintained by HL7, the activation date and inactivation date for individual codes in the value set must be maintained as part of the value set database.
2. For intensionally defined value sets in the HL7 value set database, the activation date and superceded date must be recorded (tracked) each time the logic of the definition is changed.
3. For externally maintained terminologies that have named/numbered releases, a table must be maintained that shows the modification dates for the named/numbered release.
4. For externally maintained terminologies that maintain modification dates for each individual code change, no additional information is needed.

Bindings

In order to be implemented and meet conformance, static models containing components intended to contain a coded element must be associated with a value set that can be resolved to all legal values that may be carried in that model component. Such an association is referred to as a vocabulary binding.

Value Set / Concept Domain Relationship

There are two mechanisms of binding an attribute or data type property to a value set that HL7 has agreed to support:

Design-time binding: this is binding a coded attribute or data type property in a static model directly to a value set. In this case, the concept domain of the ancestor model governs the semantics of the binding. That is, the contents of the value set bound in the child model must be consistent with the concept domain definition in the parent model. Where the corresponding attribute or property in the parent model is a value-set or is a domain which has been bound to a value-set, the value-set bound to the child model attribute or property must be the same or a proper constraint of the parent model value-set.

Runtime binding: this is binding a coded attribute or data type property to a collection of data including concept domain and realm that is resolved at runtime to a specific value set by a terminology server. In this case the concept domain and realm are used as keys by a terminology server to resolve the concept domain reference to a single version of a value set. This type of binding is used primarily when the precise desired value set to be bound is not knowable at message design time. Because the realm associated with the instance is identified within the instance, it is possible for a receiver who knows the message specification (and thus the concept domain) to determine the appropriate value-set to validate against.

Static and Dynamic Binding

Value set binding can be static or dynamic. Static binding means that the allowed values of the value set do not change automatically as new values are added to a value set. That is, the binding is to a single version of a value set. Dynamic binding means that the intent is to have the allowed values for a coded item automatically change (expand or contract) as the value set is maintained over time. This means that for dynamic binding, the binding is to the most current version of the value set in the terminology server at a given point in time.

A static binding is fully specified when the binding references a specific version (date) as well as the value-set OID/unique name

Dynamic binding is fully specified when the binding only references the value-set OID/unique name and does not specify a version date.

Un-bound domains

In some situations, a Concept Domain referenced in an implementable HL7 static model might not have an applicable binding for the affiliate making use of the model (no universal binding and no Affiliate binding for that affiliate). In that case, the domain is considered to be un-bound. The determination of the set of codes to use remains subject to site-specific negotiation until such time as an applicable binding is created for that affiliate or universally.

Additional notes on domains and value-sets

Concept Domain and Value Set Naming Conventions

HL7 concept domains, and value sets will be named according to the following rules:

• All concept domains and value sets will use “camel back” style names.

• The name will be restricted to the basic 26-character alphabet and the digits 0-9 using ASCII characters. White space (tabs, spaces), punctuation (periods, commas, colons, semicolons, parentheses, quotes, etc.), underscore, hyphens or other separators are not allowed in the name.

• The leading character must be upper-case alpha

• Concept domain and concept sub-domain names should be accurate labels for the virtual concepts that they contain. Concept domain and concept sub-domain names should never include realm or code-system specific information. The concept domain name should also be independent of the RIM attribute where possible, so that the concept domain can be re-used with different attributes. For example, a concept domain should be called “HumanGender” rather than “PatientGender” so that the same domain could be bound to the “GuarantorGender” attribute.

• Value sets should be named by combining the name of the concept domain and/or other use context that will uniquely identify the value set.

--66.18.217.179 23:13, 13 April 2007 (PDT)Question - can't a value-set be bound to multiple concept domains? If so, wouldn't it be appropriate to name the value-set independent of the concept domain?

• For example, the following would be appropriate names:

Concept Domain: HumanGender
Value Set: HumanGenderUSRealm

Concept Domain: Country
Value Set: CountryFIPS

HL7’s Implementation of value sets

Value Set can be referenced as either Abstract or Specializable. If a value set is referenced as abstract, the “navigational concept" - the root concept of which all other concepts in the value set are specializations - is not selectable. If specializable, the root concept (head code) is selectable, meaning that highest level concept can be selected without further refinement.

NOTE: Being Abstract or Specializable is not a property of Value Set itself, but is an indication that for any specified context, the Value Set should be referenced as either Abstract or Specializable. --66.18.217.179 23:13, 13 April 2007 (PDT)Question: If Abstract or Specializable isn't a characteristic of the value-set, and it's not declarable as part of the binding, how is it established? Fundamentally, I think this IS a construct of the value-set definition. Two value-sets defined by referencing the same concept and all specializations, one defined as abstract and the other as specializable would be two distinct value-set definitions

Figure 2 Value Sets

X-Domain (X-Value Set) [Deprecated]

“X-Domain” is a misnomer. A more proper name would be “X-Value Sets”, since they are really HL7 defined value sets or sub Value Sets. X-Domains came into existence to address a muddling between the Code System hierarchy and Value Sets. Earlier versions of the vocabulary maintenance tools didn’t distinguish between a Value Set that referenced concepts X, Y and Z and a concept code with subtypes X, Y and Z. The prefix “X-” was added to Value Sets that were intended to represent simple collections, not conceptual hierarchies. A rule was established that new concept codes couldn’t be introduced within an “X-” domain. They first had to be entered elsewhere in the coding scheme hierarchy and then added separately to the “X-” domain. As time permits, all X-Domains will be replaced by Value Sets. --66.18.217.179 23:13, 13 April 2007 (PDT)Comment: Guidance is required on names. At the moment, we continue to use the lower-case x prefix when creating value-sets for structural code systems

Value Set Binding in Implementation Guides

Assumptions

1. All value sets shall be defined in the HL7 value set database and/or a realm specific value set database that conforms to the HL7 value set design and structure. Value set definitions created by realm affiliates will be kept in the HL7 value set database. Value sets are not defined directly in an implementation guide, they are identified in the implementation guide by reference to the definition of the value set that exists in a value set database.
2. The person or organization that creates and adds the value set to the HL7 value set database shall be responsible for insuring that the content of the value set is maintained.
3. An OID shall be assigned to every value set. OIDs for value sets in the HL7 owned Realms (Universal, Example, and Representative) should be registered in the HL7 OID registry. A value set can optionally be assigned a name. If a value set is maintained in the HL7 value set database and has a name, the name shall be globally unique within the value set namespace, and the name shall be chosen in such a manner as to be descriptive in a globally unique namespace. The value set name shall be different from the name of the Vocabulary Domain. (E.g. “Human Language” would not be an appropriate value-set name, while “USRecognizedIsoHumanLanguages1993” would be an appropriately descriptive name. Value set OIDs and names are unchanging (static) over time.
4. An implementation guide shall identify a value set by reference to its OID. The globally unique name can be included for readability.
5. The creators of an implementation guide may make local names for value sets. If the implementation guide uses local names for value sets, then the implementation guide shall include a table that shows the cross reference from the local name to the OID. Where possible, the globally unique name of the value set from the HL7 value set database will be used as the local name. Local names for the value sets must be unique only within the implementation guide.
6. The implementation guide may contain a copy of the value set definition to facilitate easy review and balloting. The value set definition could be the expression for an intensionally defined value set, or all or part of an enumerated value set. The definition included in the implementation guide is a copy for documentation purposes only, and is not the source of truth for the definition of the value set.
7. For purposes of this discussion, if any part of a value set is intensionally defined, the whole value set is considered to be intensional.
8. A new value set shall be created when the construction policy or versioning policy needs to be different. If, for a similar set of codes, one group needs an enumerated value set and another group needs an intensionally defined value set, two value sets shall be created. The two needs cannot be met by a single value set. This situation might occur if one group wants to control orderable drugs by creating their own formulary list, and a different group wants drugs to be orderable as soon as they become part of a nationally maintained database. These divergent needs can only be met by defining two separate value sets, even though both value sets would contain codes for orderable drugs.
9. Traceability of value set contents over time means that one can determine for a given coded attribute or data type property in a message the exact set of codes that constituted the value set at the time the data was created. Traceability can only be accomplished if, for each coded attribute in the data, the effective date of the value set that was used in data creation is known. (Note: There is currently no field in current message or coded data type specifications to allow communication of the identity and version of the value set in messages. The requirement for traceability needs to be discussed further and the use case for traceability confirmed with the membership of HL7. We may want to add the value set and value set effective date as optional elements of coded data types.)
10. In situations where old and new data are sent using the same message definition and the value set bindings are different in the different eras, the terminology server will use the creation date of the data as one of the parameters for selecting the correct value set for a given message. (Note: There is currently no field in current messages that requires the communication of data creation date in messages. In most cases, Act.author.time would work as a valid surrogate for data creation date.)
11. A degenerate case of design time static binding exists where there is a need for binding a particular coded attribute to a specific single code. Rather than creating a value set consisting of a single code value, and developing all the supporting administrative machinery, this binding may be accomplished as Single-code binding, which is design-time static binding to a specific code drawn from a specific code system, with optional inclusion of the version date.

1. There are many kinds of static models that can or will exist in the future, including R-MIMs, CMETs, templates and profiles. All of these models may include binding to concept domains and/or value sets. A given attribute value must conform to all of the value set bindings expressed in all static models or to run time bindings that are applicable for that instance of data. Note that it is possible that different translations present within the attribute may be used to satisfy the binding expectations of different static models.

Binding Strategies

Strategy for Design-Time Dynamic Binding of Value sets

This method is used when dynamically binding a value set to a coded attribute or data type property in a static model at design time. Design-time dynamic binding for both extensionally and intensionally defined value sets (native or imported) is accomplished by referencing the OID or the name (or both) of the value set in the binding statement.

Strategy for Design-Time Static Binding of Value Sets

This method is used when statically binding a value set to a coded attribute or data type property in a static model at design time. Design-time static binding for both extensionally and intensionally defined value sets (native or imported) is accomplished by referencing the value set OID or name (or both) and the effective date of the value set in the binding statement.

Strategy for Design-Time Static Binding to a Single Code

This method is used when statically binding a single code to a coded attribute or data type property in a static model at design time. The binding is accomplished by stating the code, the code system OID or name (or both) and optionally the effective date of the code system version. --66.18.217.179 23:13, 13 April 2007 (PDT)Question:What's the point of referencing the code system version. When you reference a code, you reference the code independent of version. In an instance, there's no guarantee you'll ever know the version. The semantics of a code are not allowed to change from version to version

Strategy for Runtime Static Binding to a Single Code

This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a single code in a code set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific coded value:

• The identity of the static model
• The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+)
• The concept domain that is bound to the coded attribute or data type property

--66.18.217.179 23:13, 13 April 2007 (PDT)Question:What's the point of repeating the concept domain? It's not needed to achieve the binding, and could be FAR broader than the code you're constraining to.

• The binding-realm within which the data exchange is to occur
• The code, the code system OID or name (or both) and optionally the effective date of the code system version

--66.18.217.179 23:13, 13 April 2007 (PDT)Question: As above

Strategy for Runtime Dynamic Binding of Value Sets

This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a dynamic value set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific value set:

The identity of the static model The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+) The concept domain that is bound to the coded attribute or data type property --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above The binding-realm within which the data exchange is to occur The OID or name (or both) of the value set

The first three properties are part of the model binding statement for the model. The last two properties are part of the runtime binding statement contained in the terminology server. The Binding-Realm is passed in a message instance wrapper (RealmCode); the concept domain, the realm, and the value set must be available to the terminology server, and may be included in an implementation guide. --66.18.217.179 23:13, 13 April 2007 (PDT)RealmCode may be asserted at more than just the root wrapper. There are use-cases where a single message instance will contain content drawn from multiple binding-realms. At the moment, it can be asserted for any class, though MnM has discussed restricting its assertion to model boundaries only (e.g. start of a payload wrapper or CMET).

Strategy for Runtime Static Binding of Value Sets

This method is used when a concept domain is bound to a coded attribute or data type property in a static model and the reference is to be resolved to a static value set by a terminology server at runtime. The following elements must be known in order for the terminology server to resolve the domain name to a specific value set:

The identity of the static model The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+) The concept domain that is bound to the coded attribute or data type property --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above The binding-realm within which the data exchange is to occur The OID or name (or both) of the value set The effective date of the value set

The first three properties are part of the model binding statement for the model. The last three properties are part of the runtime binding statement. The Binding-Realm is passed in a message instance wrapper (RealmCode); the concept domain, the realm, the value set, and the effective date must be available to the terminology server, and may be included in an implementation guide

Syntax for Design-time Binding of Value Sets to Attributes in Static Models

General description of the syntax and reserved words

The key words "SHALL", "SHOULD", and “MAY” in this syntax are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. Furthermore,

SHALL equates to CNE as defined in other HL7 documents SHOULD equates to CWE as defined in other HL7 documents

The keywords "DYNAMIC" and "STATIC" shall be interpreted as defined above. For CDA, pathName is a standard XPath statement. The name of the immediate containing structure is assumed to be known and is not explicitly stated in the pathName.

For V3 messaging, pathname should be a fully qualified reference to an attribute in the static model. [Note: We need a standard syntax for making a fully qualified pathName.] --66.18.217.179 23:13, 13 April 2007 (PDT) Suggest (ClassName.attributeName[.datatypePropertyName]+) :>

Narrative Syntax for design-time dynamic binding:

The value for (“pathName of coded element”) (SHALL | SHOULD) be selected from ValueSet ([valueSetOID] | [valueSetName] [OR ([valueSetOID] | [valueSetName]]) DYNAMIC

ValueSetOID or valueSetName must be present. No value set name can be named “DYNAMIC” or “OR”.

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

Examples of design-time dynamic binding:

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode DYNAMIC.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode OR ValueSet 1.2.34.1.26 SnomedCtDocumentTypeCode DYNAMIC.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode DYNAMIC.

Or

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 DYNAMIC.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet LoincDocumentTypeCode DYNAMIC.

Table form for design-time dynamic binding

ELEMENT IDENTIFICATION	STRENGTH	VALUE SET OID	VALUESETNAME	FLEXIBILITY
CLINICALDOCUMENT/CODE	SHALL	2.16.840.1.113883.11.217892	LOINCDOCUMENTTYPECODE	DYNAMIC
CLINICALDOCUMENT/CODE	SHALL	2.16.840.1.113883.11.XXXXX	SNOMEDCTDOCUMENTTYPE CODE	DYNAMIC
CLINICALDOCUMENT/CODE	SHOULD	2.16.840.1.113883.11.217892	LOINCDOCUMENTTYPECODE	DYNAMIC
CLINICALDOCUMENT/CODE	SHALL	2.16.840.1.113883.11.217892		DYNAMIC
CLINICALDOCUMENT/CODE	SHOULD		LOINCDOCUMENTTYPECODE	DYNAMIC

Narrative Syntax for design-time static binding:

The value for (“pathName of coded element”) (SHALL | SHOULD) be selected from ValueSet ([valueSetOID] | [valueSetName] [OR ([valueSetOID] | [valueSetName]]) STATIC (valueSetEffectiveDate)

ValueSetOID or valueSetName must be present. No value set name can be named “STATIC” or “OR”.

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

ValueSetEffectiveDate will be specified with the literal syntax for the XML ITS of the HL7 Version 3 Point in Time (TS) data type.

Examples of design-time static binding:

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode OR ValueSet 1.2.34.1.26 SnomedCtDocumentTypeCode STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet 1.2.34.1.25 LoincDocumentTypeCode STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHALL be selected from ValueSet 1.2.34.1.25 STATIC 20061017.

Or

The value for “ClinicalDocument/code” SHOULD be selected from ValueSet LoincDocumentTypeCode STATIC 20061017.

Table form for design-time static binding

Path	Strength	Value Set OID	Name	Flexibility	Effective Date
ClinicalDocument/code	shall	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	static	20061017
ClinicalDocument/code	shall	2.16.840.1.113883.11.XXXXX	SnomedCtDocumentTypeCode	static	20061017
ClinicalDocument/code	should	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	static	20061017
ClinicalDocument/code	shall	2.16.840.1.113883.11.217892		static	20061017
ClinicalDocument/code	should	1.2.34.1.25	LoincDocumentTypeCode	static	20061017

Narrative Syntax for Single-code binding (design-time static binding to one exact code)

The value for (“pathName of coded element”) SHALL be (code [“displayName”] codeSystemOID [codeSystemName] STATIC [effective date]

The effective date SHALL be specified when it is necessary for distinguishing the proper meaning of the code.

No code system name can be “STATIC”.

Example for design-time static binding to one exact code

The value for “ClinicalDocument/code” SHALL be 42134-7 “DischargeSummary” 2.16.840.1.113883.6.1 LOINC STATIC 20061017.

Table form for design-time static binding to one exact code

Path	Strength	code	codeSystemOID	codeSystemName	Flexibility	Effective Date
ClinicalDocument/code	shall	42134-7	2.16.840.1.113883.6.1	LOINC	static	20061017

Syntax for Runtime Binding of Value Sets to Concept Domains in Static Models

General description of the syntax and reserved words

Runtime binding involves splitting the binding operation into a step that is done at design time, and a step that is done later, at message instance generation time. At design time, a coded attribute or datatype property is bound to a concept domain. There is no flexibility to this binding, but subdomains may be created and attributes bound accordingly as the design is further constrained as described in the V3 Vocabulary Conformance section of the HL7 V3 Standard. At the time of message instance generation, all coded attributes or datatype properties are either design time bound to value sets, or runtime bound to an explicit concept domain.

Part of the implementation statement for a particular model will describe the Realm-specific binding of a concept domain to a value set, in much the same way that a coded attribute is bound to a value set in design-time binding. Therefore, in the Runtime Binding syntax there are two statements: the first is the binding of a code attribute or datatype property to a concept domain, and the second is the binding of the concept domain to a value set. The statements must be separate as they are defined at different times and generally by different stakeholders.

The key words "SHALL", "SHOULD", and “MAY” in this syntax are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. Furthermore

SHALL equates to CNE as defined in other HL7 documents SHOULD equates to CWE as defined in other HL7 documents

The keywords "DYNAMIC" and "STATIC" shall be interpreted as defined above.

Narrative Syntax for concept domain runtime dynamic binding:

The VocabularyDomain for (“pathName of coded element”) (SHALL ) be (DomainName) The ValueSet for (DomainName) in (RealmName) (SHALL | SHOULD) be ([valueSetOID] | [valueSetName] | [OR ([valueSetOID] | [valueSetName]]) DYNAMIC.

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

Example for concept domain binding:

The ConceptDomain for “DocumentType/code” SHALL be MyDocumentType The ValueSet for MyDocumentType in NorthAmerica SHALL be 2.16.840.1.113883.11.217892 LoincDocumentTypeCode DYNAMIC.

Or

The ConceptDomain for “DocumentType/code” SHALL be MyDocumentType The ValueSet for MyDocumentType in NorthAmerica SHALL be 2.16.840.1.113883.11.217892 LoincDocumentTypeCode Or 2.16.840.1.113883.11.XXXXX SnomedCtDocumentTypeCode DYNAMIC.

Table representation of runtime dynamic binding information in the terminology server:

Model	Path	Domain	Realm	Value Set OID	ValueSetName	Flexibility
TPLTCD3	DocumentType/code	MyDocumentType	NorthAmerica	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	Dynamic

Note that the leftmost three columns are the design-time binding elements, and the rightmost five columns are the runtime binding elements (the concept domain is the common element)

Narrative Syntax for concept domain runtime static binding:

The VocabularyDomain for (“pathName of coded element”) (SHALL) be (DomainName) The ValueSet for (DomainName) in (RealmName) (SHALL | SHOULD) be ([valueSetOID] | [valueSetName] | [OR ([valueSetOID] | [valueSetName]]) STATIC (valueSetEffectiveDate).

If the “OR” syntax is used, the order in which the value sets are listed expresses the order of preference for the value sets.

Example for concept domain dynamic binding:

The VocabularyDomain for “DocumentType/code” SHALL be MyDocumentType. The value set for MyDocumentType in NorthAmerica is 2.16.840.1.113883.11.217892 LoincDocumentTypeCode STATIC 20061017

Or

The VocabularyDomain for “DocumentType/code” SHALL be MyDocumentType. The value set for MyDocumentType in NorthAmerica is 2.16.840.1.113883.11.217892 LoincDocumentTypeCode OR 2.16.840.1.113883.11.XXXXX SnomedCtDocumentTypeCode STATIC 20061017

Table representation of runtime static binding information in the terminology server:

Model	Path	Domain	Realm	Value Set OID	ValueSetName	Effective Date || Flexibility
TPLTCD3	DocumentType/code	MyDocumentType	US	2.16.840.1.113883.11.217892	LoincDocumentTypeCode	20061017	Static

Note that the leftmost three columns are the design-time binding elements, and the rightmost six columns are the runtime binding elements (the concept domain is the common element).