Vocabulary Portion of Core Principles

4 Vocabulary 4.1 Code System 4.2 Concept Domain 4.2.1 Examples of Concept Domains 4.2.2 Sub-Domains 4.3 Value Sets 4.3.1 Introduction 4.3.2 Value Set Specification 4.3.3 Nested Value Sets 4.3.4 Sub-value Sets 4.3.5 Value Set / Code System Relationship 4.3.6 Value Set Versioning 13.2 Vocabulary Conformance 13.2.1 Vocabulary Binding 13.2.2 Static and Dynamic Binding 13.2.3 Unbound domains 13.2.4 Additional notes on domains and value-sets 13.2.5 Value Set Binding in Implementation Guides 13.2.6 Binding Strategies 13.2.7 Binding Syntax

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.

DISCUSSION:

why do we have this a bullet point? I'm not even sure what it's trying to accomplish. and I think that while the comment about ANY is potentially true, most people would be confused by it? It's not like we allow a binding on ANY anywhere. Do we? --GrahameGrieve 14:58, 23 February 2008 (CST)

This was a footnote in the original document, and it came in as streaming text inline when the paste was done - that is not a bullet, it is a footnote mark. The asterisk was by a former reference to a 'coded element' in the original document, which was removed when we modified the nomenclature to 'coded attribute' in this document. I left this in here because I don't know if we want to keep any of this text somewhere in this document if not in this Vocabulary section; the salient point is that vocabulary is bound in lots of different kinds of models, not just the RIM ones. You can completely remove this if you'd like, or slide it in somewhere else where it might be more appropriate. This should most likely be part of the discussion on 'coded attributes' in the 'to do' list below. --Tklein 11:22, 10 March 2008 (CDT)

ii - k CLOSED Issue 11

Vocabulary Conformance (§ 13.2 )TODO: note this is the first set of pasted material, and is now all of the material from the value set binding document. I have not yet cleaned it up, nor put in the changes from San Antonio. --Tklein 18:32, 23 February 2008 (CST)

ii - p Known Issue 16

HL7’s Implementation of value sets (§ 13.2.4.2 ) TODO: --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.

TODO: :: I need to go over this fine point with Stan and Russ - we have gone back and forth over this property being part of the value set definition or part of the binding definition. I think it is now in the value set definition, but need to verify. --Tklein 12:34, 10 March 2008 (CDT)

ii - q Known Issue 17

X-Domain (X-Value Set) [Deprecated] (§ 13.2.4.3 ) TODO: 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

ii - r Known Issue 18

Strategy for Model Binding to a Single Code (§ 13.2.6.3 )TODO: --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

the code may be retired from a code system, and there are MANY code systems used in HL7 and in the Healthcare IT community that do not follow the rules, and the semantics of a particular code sometimes does change meaning in these. --Tklein 12:49, 10 March 2008 (CDT)

ii - s Known Issue 19

Strategy for Context Binding to a Single Code (§ 13.2.6.4 ) TODO: --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. (lower down)TODO: --66.18.217.179 23:13, 13 April 2007 (PDT)Question: As above Strategy for Dynamic Context Binding of Value Sets (§ 13.2.6.5 )TODO: --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above Strategy for Static Context Binding of Value Sets (§ 13.2.6.6 )TODO: --66.18.217.179 23:13, 13 April 2007 (PDT)Question: as above

ii - t Known Issue 20

Strategy for Dynamic Context Binding of Value Sets (§ 13.2.6.5 ) TODO: --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).

Without getting into the complexities of multiple-thread environment evaluation whilst evaluating all the wrappers and whatever templates are in effect at the time, should this wording be changed from this latest? It is clear that at any point in the parse, a particular coded attribute will have a particular RealmCode in effect at that moment; that is the one to be passed to the terminology server. How should this be worded so that it is not so confusing? --Tklein 12:58, 10 March 2008 (CDT)

ii - u Known Issue 21

Syntax for Model Binding of Value Sets to Attributes in Static Models (§ 13.2.7.1 ) TODO: [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]+)

ii - v Known Issue 22

TODO: Other items to be covered:

• coding strength

should the section on Domains be here rather that up in the vocabulary section? --Tklein 18:21, 23 February 2008 (CST)

3 Realms

Known Issue 08 (§ 2.8 )

For HL7, with respect to Vocabulary, Realm (previously also referred to as Context of Use) refers to a named interoperability conformance space, meaning that all static models within a particular Realm share the same conformance binding. This is also commonly referred to as a Binding Realm, especially where other types of realms are being discussed. A Realm has a string name which is unique in the HL7 Standards space. In order to enable conformance, the name of a Realm is carried in a model instance.

In the interest of maximizing interoperability, and making the spaces within which interoperability is maximized as large as possible, Realms are preferred to be large-grained. The term "Realm" used in different ways. In the context of HL7 Vocabulary, it is used to indicate a Binding Realm: that 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.

As discussed below, there have been a number of Realms defined in HL7.

3.1 Defined Realms
3.1.1 Affiliate Realms

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

3.1.2 Combination Realms

There is a need for some Realms that combine more than one country. North America represents a shared interoperability space for Cancer Registries for both the US and Canada. This Realm has been created as a combination of the US Realm and the Canadian Realm. Any Realms may be combined for such a purpose to make an interoperability space that extends beyond one country.

3.1.3 Sub-Realms

In some circumstances, a Realm has a requirement to make smaller interoperability spaces within its own borders. This is discouraged, as it impedes broader interoperability. However, the mechanisms exist for any Realm to create such a Sub-Realm for models that are used wholly within that smaller subdivision differ from the conformance requirements of models in other Sub-Realms.

3.1.4 Generic Realms

Four Generic Realms have been defined that are not specific to an International Affiliate or a geographic area. 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.

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

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

3.1.4.3 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

3.1.4.4 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

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

4 Vocabulary

Coded elements in Static Models contain Vocabulary, ie they may contain one or more Coded Concepts drawn from Coding Systems. The process and mechanisms for assigning collections of these concepts to the coded elements in the Static Models is described in the Conformance section below. This section will provide definitions required for the mechanisms implementing Conformance.

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 data 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) may also categorized as coded elements because the ANY datatype can be constrained to CD or any of its specializations, although vocabulary can not be bound to such an attribute or property until such constraining has occurred.

4.1 Code System

Within HL7, a code system is defined as a collection of coded concepts. each having 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; therefore a concept is uniquely identified by the tuple (codeSystem, code). A code must be unique within a Code System, but the same string of characters may appear in other code systems associated with a different concept. Given this definition, each table having enumerated codes 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.

Some code systems have 'synonyms', where there more than one code that references the same concept in the code system. For instance, ISO 3166-1 has one collection of numeric codes representing each country in the world, a second set of 2-character alphabetic codes, and another set of 3-character alphabetic codes. In ISO 3166-1, the United States of America is represented as "US", "USA" and "840"; each of these can be thought of as a set of synonyms. In HL7, each of these strings is considered a code; the coded concept is the code system together with the code value.

A Code System is sometimes referred to as a terminology, an ontology, a vocabulary, or a classification. In the vocabulary community, these are used for different purposes, and include further differentiation such as reference terminolgies and interface terminologies for those that are used for specific purposes. In HL7, we refer to any of these as a Code System; the purposes that the coded concepts are used for are specified by the models and the structures within HL7, which may support or require any of these different types of vocabulary collections.

4.2 Concept Domain

An HL7 Concept Domain is a named category of like concepts (a semantic type) that will be bound to one or more attributes in a static model whose datatypes are coded. Concept Domains exist to constrain the intent of the coded element while deferring the association of the element to a specific coded terminology until later in the model 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. The coded concept names must be sufficient to illustrate the intent of creating the concept domain. This can be accomplished by at least one of the following:

   * Including three example concepts as part of the narrative definition;
   * Binding the domain in the Example Realm to a value set containing at least three example concepts; or
   * 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.

Known Issue 09 (§ 2.9 )

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

4.2.1.1 TODO:

CLOSED Issue 10 (§ 2.10 )

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

4.3 Value Sets
4.3.1 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. A concept representation may be a single concept code, or a combination of codes to be post-coordinated.

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. Identical codes from different code systems are allowed because they can be disambiguated by identifying the code system they come from.

Ideally, a given concept should be represented only by a single code. However, in unusual circumstances, a given concept can have more than one code. (e.g. in some cases where different case is used to signify the same concept, as 'l' and 'L' in UCUM for 'litre').

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.

Note that this implies that all value Set specifications must be able to be machine-resolved at a point in time to their contained coded concepts. Another implication is that an HL7 Terminology Service must be able to perform this resolution on any valueSet definition in HL7.

4.3.2 Value Set Specification

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

4.3.2.1 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. The following table shows a flat list of codes that might be used as values for the coded attribute Gender. Table 1: Example Extensional Value Set Code Value Description M Male F Female U Unspecified

More complex variations might relate to hierarchical coding systems such as the following fictitious example: Table 2: Example Extensional Value Set (fabricated) 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

4.3.2.2 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 at a particular point in time.

The intentional definition must be specific enough that it is always possible at a point in time (within a specific version of the code system) to determine whether a given value (including post coordinated collections of codes) is a member of the value set. 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:

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

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 whenever it is 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. Note that the resolved content of an intensionally defined value set may change without the value set version changing if the version of the underlying code system(s) are not specified, and those code systems change the coded concepts that are included within the value set.

4.3.3 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). Any child value set that is references by this nesting may be either intentinally defined or extensionally defined. For any value set that includes child value sets, if any of the child value sets are intentionally defined, then the containing ('parent') value set is considered to be intentionally defined.

4.3.4 Sub-value Sets

A sub-value set is a sub-set of a ”parent” value set. It is a constraint on the content of a value set such that there are no coded concepts contained in the sub-valueSet that are not also contained with the "parent" valueSet. A sub-value set is generally created as part of the successfive constraining process of model development.

4.3.5 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 recorded 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.

4.3.6 Value Set Versioning

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.

Items left to do [tk]: more complete description/definition of Coded attributes in static models Properties of these coded attributes Binding to concept domains in the static models links to the conformance section

Vocabulary Conformance consists of defining collections of vocabulary that must be used in coded attributes, identifying the coded attributes and models in which they are located, and declaring the circumstances under which those collections must be used. Collectively, these are called Vocabulary Binding.

13.2.1 Vocabulary Binding

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:

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

Context Binding: this is binding a coded attribute or data type property to a collection of data including concept domain and realm (context of use) 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.

13.2.2 Static and Dynamic Binding

There are two types of binding of vocabulary to coded model elements, each of which may be used with the two mechanisms described above; these are Static Binding and Dynamic Binding. 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.

13.2.3 Unbound 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.

13.2.4 Additional notes on domains and value-sets
13.2.4.1 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 may be named by combining the name of the concept domain and/or other use context that will uniquely identify the value set; this is very helpful when a value set is appropriate for only a single subm-domain (which is most often the case). If a value set is expected to be used in more than one concept domain, then a more general name that clearly identifies the usage of the value set should be created.
   * For example, the following would be appropriate names:
         o Concept Domain: HumanGender
         o Value Set: HumanGenderUSRealm
         o Concept Domain: Country
         o Value Set: CountryFIPS

13.2.4.2 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.Known Issue 16 (§ 2.16 )

Value Sets Value Sets

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

Known Issue 17 (§ 2.17 )

13.2.5 Value Set Binding in Implementation Guides
13.2.5.1 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 Model Constrained 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 Model Constrained static binding to a specific code drawn from a specific code system, with optional inclusion of the version date. 12. 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.

13.2.6 Binding Strategies
13.2.6.1 Strategy for Dynamic Model Binding of Value sets

This method is used when binding a value set to a coded attribute or data type property in a static model at design time where the coded content of the value set is generated by terminology services based upon the binding date. Dynamic Model 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; the date of the expansion of the value set is the effective time of the model operation on the value set (such as validation).

13.2.6.2 Strategy for Static Model Binding of Value Set

This method is used when binding a static value set to a coded attribute or data type property in a static model at design time. Static Model 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. The date of the binding statement is the effective date of the expansion of the value set (for intensionally defined value sets).

13.2.6.3 Strategy for Model Binding to a Single Code

This method is used when 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.

Known Issue 18 (§ 2.18 )

13.2.6.4 Strategy for Context 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 propertyKnown Issue 19 (§ 2.19 )
   * 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 versionKnown Issue 19 (§ 2.19 )

13.2.6.5 Strategy for Dynamic Context 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:

  1. The identity of the static model
  2. The unique identity of the coded attribute or data type property in the static model (ClassName.attributeName[.datatypePropertyName]+)
  3. The concept domain that is bound to the coded attribute or data type propertyKnown Issue 19 (§ 2.19 )
  4. 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 Context Binding statement contained in the terminology server. The Binding-Realm is passed as part of the context as the message is parsed (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. Known Issue 20 (§ 2.20 )

13.2.6.6 Strategy for Static Context 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. Known Issue 19 (§ 2.19 ) 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 Situation Constrained 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.

13.2.7 Binding Syntax
13.2.7.1 Syntax for Model 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. Known Issue 21 (§ 2.21 )

Narrative Syntax for Model Constrained 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 Dynamic Model 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 Model Constrained dynamic binding Table 6: Table form for Model Constrained 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 Static Model 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 Static Model 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 Static Model Binding Table 7: Table form for Static Model 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 (Static Model 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 Static Model 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 Static Model Binding to one exact code Table 8: Table form for Static Model 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

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

General description of the syntax and reserved words

Context 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 model 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 Model Bound to value sets, or Context 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 Model Binding. Therefore, in the Context 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 Dynamic Context 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 Dynamic Context 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 Dynamic Context Binding information in the terminology server Table 9: Table representation of Dynamic Context 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 model binding elements, and the rightmost five columns are the context binding elements (the concept domain is the common element)

Narrative Syntax for concept domain Static Context 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 Static Context 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 Static Context Binding information in the terminology server Table 10: Table representation of Static Context 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 model binding elements, and the rightmost six columns are the context binding elements (the concept domain is the common element).