Core Principles and Properties of HL7 Version 3 Models, Release 2

Normative Ballot 2
HL7 CPPV3MODELS, R2
HL7 Version 3 Standard: Core Principles and Properties of Version 3 Models, Release 2
Last Ballot: Normative Ballot 1 - 2015January
Responsible Group Modeling and Methodology Work Group
HL7
Primary Contributor and Methodology & Modeling Co-Chair Grahame Grieve
Kestral Computing Pty. Ltd.
Primary Contributor and Vocabulary Co-Chair W. Ted Klein
Klein Consulting, Inc.
Primary Contributor and Modeling & Methodology Co-Chair George Beeler, Jr., PhD.
Beeler Consulting LLC
Contributor Russ Hamm
Apelon, Inc.
Contributor and Methodology & Modeling Co-Chair Lloyd McKenzie
LM&A Consulting Ltd.

Content Last Edited: 2014-12-03T09:20:00


View Revision MarksHide Revision Marks

Table of Contents

Preface
    i Notes to Readers - Reason for Re-ballot
    ii Arguments with respect to Negative Ballot
The Rationale for V3 - Semantic interoperability
    1.1 Models: the Foundations of Semantic Interoperability
    1.2 Defining the Core Models and Stitching Them Together: the Rationale for Core Principles
Models: RIM and its derivatives
    2.1 Basic Features of the RIM
    2.2 How the RIM is maintained
    2.3 Instances
        2.3.1 What is a model "instance" (a brief aside)
        2.3.2 Serialization
        2.3.3 Requirements for Serialization Algorithms
    2.4 V3 information models other than the RIM
        2.4.1 DIM : Domain Information Model
        2.4.2 SIM : Serializable Information Model
        2.4.3 LIM : Localized Information Model
Types - model classes, data types & semantic types
    3.1 How HL7 core models fit together
    3.2 Data Type Flavors
    3.3 Null Flavor - Expressing exceptional values
        3.3.1 Note about the name nullFlavor
    3.4 Identifying classes and data types in instances
        3.4.1 Kinds of Type Models for Classes
            3.4.1.1 Expressed Models
            3.4.1.2 Implied Models
            3.4.1.3 Applied Models
Identifying Elements
    4.1 Referencing Objects
    4.2 Identifying Objects
    4.3 Global Uniqueness
    4.4 OID Registry
    4.5 OID Conflict Resolution
    4.6 HL7 OID Types
    4.7 Specifying Identity with Instance Identifiers and Concept Descriptors
Coded Model Elements and their Vocabularies
    5.1 HL7 Vocabulary
        5.1.1 Concepts and Codes
        5.1.2 Code Systems
            5.1.2.1 Post-Coordination in Code Systems
            5.1.2.2 Code System Versions
        5.1.3 Value Sets
            5.1.3.1 Value Set Definition Methods
            5.1.3.2 Unique Meaning Rule
            5.1.3.3 Value Set Expansion
            5.1.3.4 Value Set Versioning
            5.1.3.5 Value Set Immutability
        5.1.4 Concept Domains
            5.1.4.1 Examples of Concept Domains
            5.1.4.2 Sub-Domains
        5.1.5 Binding Realms
            5.1.5.1 HL7 International Defined Binding Realms
    5.2 Vocabulary Conformance
        5.2.1 Vocabulary Declaration
        5.2.2 Value Set Assertion
            5.2.2.1 Value Sets Declared In Assertion
            5.2.2.2 Coding Strength
            5.2.2.3 Stability Level
            5.2.2.4 Expression of Value Set Assertions
        5.2.3 Conformance with Value Set Assertions
    5.3 Vocabulary Binding
        5.3.1 Model Binding
        5.3.2 Context Binding
        5.3.3 Choosing a Binding Type
        5.3.4 Binding Syntax
    5.4 Additional Notes
        5.4.1 Concept Domain and Value Set Naming Conventions
        5.4.2 X-Domain (X-Value Set) [Deprecated]
        5.4.3 HL7 Vocabulary Model
Special Topics on Implementation and Representation
    6.1 Context Conduction in Serialized information models
        6.1.1 Context Conduction of Class Content
        6.1.2 Context Conduction of Selected Act Attributes
    6.2 Update control
        6.2.1 Snapshot
        6.2.2 Update Mode
            6.2.2.1 updateMode Property
            6.2.2.2 Update Mode Guidance
    6.3 Accountability
    6.4 Model References - Linking Models Together
        6.4.1 CMETs
        6.4.2 Stubs
        6.4.3 Direct Model References
    6.5 "isDocumentCharacteristic" Property on Act Attributes and Association Type Codes
        6.5.1 Definition and Assignment of "isDocumentCharacteristic" Property
        6.5.2 Interpretation of "isDocumentCharacteristic" Property in Relation to Various Moods and Negation
        6.5.3 Communicating about Document Characteristics
    6.6 Negation Indicators in RIM Classes
A  Annex: Glosssary Content for: Core Principles and Properties of HL7 Version 3 Models, Release 2
Endnotes

This is the final draft of content prepared to satisfy ballot reconciliation for Release 2 of "Core Principles". All Negative balloters, except one withdrew their Negatives. The final Negative had been found "Not related" (out of scope) and the authors attempted to gain withdrawal by presenting the reationale for the "Not related" findings In the end, we tried too long, through periods of unreturned phone calls, until the "clock ran out" at ANSI and we could no longer publish even if the withdrawal was received. As a conseqiuence MnM created a project to Re-ballot this final content with no changes other than this preface in order to gain a stable and consistent version of the specification. Speifics of the "arguments" relative to the "Not related" ballot follow,

The asserted scope of the ballot for Release 2 was expressly limited to two topics that had been deferred from Release 1, in oder to avoid "scope creep". Eventaully the titles for these topics became became "6.5 'isDocumentCharacteristic' Property on Act Attributes and Association Type Codes" and "6.6 Negation Indicators in RIM Classes".

Asserted without reference to a specifc section of the document: "The ballot does not appropriately address the issue of backward compatibility with release 1 data types. Why has the proposed solution for backward compatibility not been adopted"

"This ballot comment refers to an activity that is currently the responsibility of the TSC, and which has no linkage to any part of this document, much less to the constrained scope of this ballot."

Can you provide more details on how it is not in scope of the document? We believe that backward compatibility would be expected to be in a document outlining core principles.

There are several answers, and in the service of understanding, I'll provide them all:

  • First, most direct: This ballot was a "limited scope" ballot covering two specific topics. The scope limitation was noted in the Preface/Notes to Balloters as: In order to "complete" the content of Core Principles, Release 2 brought forward two items that had been declared "out of Scope" for the final stages of Release 1 balloting. The Ballot2012May cycle led to negative comments on one of these topics which, after reconciliation, is again up for ballot, and July Harmonization discussions revealed an error in the way another topic was represented. A technical correction to this subject brings that topic "back on the table" for the Ballot2012Sep cycle.

  • Second, more broadly germane: The full title of the document in question is "Core Principles and Properties of V3 Models." It focuses on the coordination and use of the Version 3 foundation models - RIM, Data Types and Vocabulary. Backwards compatibility has never been an element of these principles, as it was covered elsewhere and involves other elements of the V3 product family.

  • Third, historically: HL7 voted on and accepted a document entitled "V3 Principles" in the late 1990s. That document is reproduced in the Introduction to every V3 Ballot and Normative Edition as section "5.2 V3 Principles" under the "Package Notes to Readers". It does explicitly talk about backwards compatibility of the information models.

I apologize that the disposition in the ballot spread sheet did not adequately reflect the rationale behind the "Not Related" finding, which is the term used for material that is out of scope for a particular ballot. I hope that with this explanation you will see your way clear to withdraw your Negative, and thus avoid the requirement for a "recirculation ballot."


The primary objective of the HL7 Version 3 standards is to define a computational environment in which computer systems supporting health care practice and management can communicate with the assurance that independent systems can achieve "semantic interoperability." In HL7's view, interoperability requires that the systems be able to "exchange" information reliably and securely ("functional interoperability") and be able to correctly and consistently interpret the information being exchanged ("semantic interoperability").

In the 21st Century, "functional interoperability" is increasingly easy to accomplish. what with the availability of carefully integrated computational and communication environments in which to implement. "Semantic Interoperability," however, poses major challenges, particularly for the enterprise of health care in which:

  • the intellectual space continues to expand so rapidly that most individuals cannot keep pace;
  • the interpretation of any given data element is inexorably linked to the context in which that element was discovered, and the whole of the other data about the same subject;
  • the data content requires precise, and frequently extensive scientific representation;
  • a large, fraction of the data encoded in rich terminologies that are both vast, and continually expanding; and
  • human life and well-being depend upon the rapid, correct interpretation of the information.

True semantic interoperability requires the communication of information from one system to another in a form that clearly establishes the meaning of the information within the context in which it was communicated. When creating Version 3, HL7 recognized that in order to accomplish this goal and to have standards that would remain robust and consistent over time, the standards needed to be based on a common, defined set of high-level models. The models that meet this goal must have the following attributes:

  • definitive — must contain the complete definition of the information elements they model in order to establish their core semantics;
  • technology-independent — must be independent of any particular technology for creating "instances" of the model, in order that the information can be communicated in the variety of technologies used to support health care computing;
  • broadly adoptable — established in a fashion that is not specific to any particular realm, in order to meet the broadest set of needs and to be applicable throughout the HL7 International community;
  • abstract and specializable — must use the concepts of abstraction and specialization in order that they can evolve over time and accept new concepts without requiring that prior information structures be redefined; and
  • able to be refined by constraint — must provide for a process to derive subsidiary models that refine and constrain the parent model in order to allow a general "universal" model to be constrained to the meet the needs of a particular realm and/or the requirements of a specific clinical setting.
  • plug-and-play substitution — models must be consistently designed and represented in order that individual model "pieces" can be readily re-used and/or substituted in order to build new designs.

The essential feature of HL7 Version 3 is that its specifications (standards) SHALL be based on a set of common models, and that, to the extent possible, these models will be based on the object modeling facilities of the Unified Modeling Language (UML). In HL7 Version 3, the information models for the specifications (standards) are based on three "core" models that are published as individual specifications but have been developed and maintained though careful collaboration and coordination within the HL7 community. These models are:

  • HL7 Reference Information Model (RIM) is an "information model" covering all information that must be communicated in support of health care. The RIM uses an abstract representation that can be readily extended through the additions to model-controlling terminologies. The class attributes in the RIM are "typed" by the HL7 Abstract Data Types. Where RIM attributes are typed with a "coded" data type, the constraint for that attribute is defined in the HL7 Vocabulary Model.
  • HL7 Abstract Data Types Model is a robust specification of data types that is currently finishing balloting as Release 2. The specification has been vetted in numerous implementations around the world, and the balloting of Release 2 included the collaboration of both ISO and CEN committees, for whom it will also be a standard.

  • HL7 Vocabulary Model is a set of HL7-defined and maintained Concept Domains, Code Systems and Value Sets that both underlie the definition of the RIM and Data Types models, and allow the refinement and localization of HL7 models through the definition of function-specific and realm-specific elements.

Together, these three models constitute the:

A V3 Reference Platform is defined as a The V3 Reference Platform is the combination of the HL7 Reference Information Model (RIM); the data types model used to type the the attributes of the RIM classes; and the controlling vocabulary that provides values for any RIM attribute or data type component whose data type is "coded simple" (CS). All HL7-conformant derived models SHALL have this these three models at the root of their derivation tree..

As Version 3 was launched, the development of the three core models — RIM, Data Types and Vocabulary — proceeded in parallel guided by the stipulations in the Version 3 Development Methodology, and a growing set of understandings as to how best to apply these models to health care communication. As Version 3 matured, the responsible work groups realized that there was a "missing" specification that should be voted on by the HL7 membership. This "missing" specification should specify what are the essential features of these models and how should they used in a coordinated fashion both to develop and to implement the Version 3 specifications. "Core Principles" (this document) is that "missing" specification. This document specifies:

  • How each of the three models is conceived and represented and what is its role in supporting V3 specifications.
  • How and when the linkages or bindings between these models are defined and maintained.
  • How these models and their bindings are represented in instances of communication.
  • The responsibilities of developers and implementers for these models.

The underlying requirements for the RIM and uses of the RIM are documented in its introduction. Starting with the balloting for RIM Release 3 in May 2010, the primary features of RIM representation, their relationship to UML specifications and the definition of HL7-specific properties to more tightly control these elements have been made Normative and subject to ballot as part of the RIM. The relevant sections within the RIM specification can be found at:

From 1996 through 2008, the RIM was developed and maintained within HL7 using a process known as Harmonization. In this process, change proposals are developed by individual Work Groups that are developing content for forthcoming ballots. These change proposals are announced to the co-chairs of all HL7 Work Groups for their review. Subsequently, the proposals are taken to a scheduled Harmonization Meeting, where they are discussed and voted upon by representatives of all of the Working Groups involved in ballot development. The results of those meetings are announced, and are subject to appeal at the Technical Steering Committee, although there has never been such an appeal to date.

Beginning in 2009, HL7 decided to adopt the "ANSI Continuous Maintenance Process" for the RIM, which amounts to a continuous balloting process. For the present, the Methodology and Modeling Work Group (M&M) has determined that it wishes to continue using Harmonization as the primary method of adopting RIM and Vocabulary content changes. As a consequence, any RIM changes needed to reconcile negative ballots will be documented and submitted for review at the next-available Harmonization Meeting. The specific process is as follows:

  • In a ballot reconciliation meeting, the Methodology and Modeling Work Group will review each negative comment and determine a recommended action that is documented in the ballot reconciliation spreadsheet.
  • For each reconciliation action that would require Harmonization review, whether or not the change was found persuasive, M&M will seek to have a formal harmonization change proposal made to implement that change. The vote of M&M during reconciliation, will be noted as the "Interested Committee's Position" on the issue.
  • The change proposal will then be reviewed and acted upon at the next Harmonization Meeting.
  • If the Harmonization Meeting does not agree with the recommendations from the M&M reconciliation meeting, the reconciliation group will be reconvened to consider what action to take next.

The fundamental notion of V3 is that of data exchange. Systems exchange serialized streams of data that are an "instance" of a V3 model under a set of rules that describe why and when the data is exchanged.

V3 models are made up of classes linked by associations. The classes and associations are defined in the RIM. The classes have a series of named attributes that are assigned a type defined in the data types. Some attributes are associated with controlling vocabularies that provide clearly defined semantic meaning to the information models. Thus, the models derive from the previously defined V3 Reference Platform.

Because of the refinement process and derivation rules imposed on HL7 models, all V3 model instances are also instances of the Reference Information Model, and conform to the rules of the RIM. V3 models also conform to one or more additional constraint models that describe how the V3 Reference Platform is used to describe particular administrative or clinical health care information.

Instances of V3 models may have many forms of expression and be used in many contexts, such as a CDA document, a message payload in a message associated with an HL7 defined interaction, or a payload as part of a service interaction, etc.

Instances of V3 models are exchanged in the context of a behavioral model that specifies why and when the data is exchanged.

As noted in the HL7 V3 Glossary, "an instance of a class is an object", or, alternatively, it is the set of data that provides a data value for each attribute of the class so as to represent one particular instance of that class. For example, a class representing this document would likely have a "title" attribute. The instance of that class that represents this document, would have a value for the "title" attribute that is "Core Principles and Properties of HL7 Version 3 Models".

Extending this, an instance of a class model, is the set of data that provides values for all of the attributes in all of the classes of that model as well as the data needed to represent the associations that are expressed in the model. In practice, an "instance" of a model is expressed as a serialized string of data that associates each data element with the specific model element that it values, and a "valid" instance is one in which each data element conforms to the rules and specifications defined in the model.

Many communication technologies require that serialized strings of data be organized in a particular order. Therefore, HL7 must define the order of serialization to ensure interoperability. This is done by defining a normative method for ordering (or serializing) the content of the model.

HL7 models define content to be exchanged. This exchange frequently occurs in a serial manner with bytes of information being communicated in a particular order. In order for systems to exchange the instances of a V3 model, they need a normative specification for ordering (or serializing) the content of the model. In HL7, these specifications are called Implementable Technology Specifications (ITS). As a response to industry demand, HL7 offers a defined representation of the V3 instances in XML, known as the XML Implementable Technology Specification for V3 Structures, Release 1 and Release 2. Other forms of representation could be imagined, such as XMI, HUTN, ASN.1 and so forth, but there has not been sufficient demand to justify the creation of alternatives to the standard XML form.

The ITS defines not only how the instance is serialized, but also how the links from the instance to the many models that contribute to defining the meaning of the instance are expressed and/or derived from the serialized representation.

Serialization of a model is a process that takes an arbitrary structural class model and arranges the elements as a reproducible, predictable sequence of element representations that can be communicated electronically. The process is defined by an algorithm, and the common result is a representation as a string of characters that are usually readable.

The primary algorithms used by HL7 stem from an algorithm defined by CEN TC 251 in the early 1990s. Characteristics of that algorithm, and of the others used by HL7 include:

  • The process begins with a single, defined entry point, which is the class in the model at which the representation must begin. (Normally serializations are also a hierarchical representation, and the entry point is the "root" of that hierarchy".)
  • Determines how to express the name of the class and its definition,
  • Determines how to express the attributes of the class. The representation of attributes may differ if those attributes have different fundamental uses within the model, such as acting to define model meta-data rather model content.
  • Determines the order in which to express the attributes.
  • Determines how to represent the associations that are "navigable". Normally this representation is as another "class" and thus establishes the hierarchy of the serialization.
  • Determines the order in which to represent the associations.
  • Determines how to express a "loop" within the model wherein a subsequent association is directed to a class that is already included in the serialization.

In order for a model to be "serializable" there are a set of constraints on the model including the following:

  • The model must have a single, defined entry point.
  • Each association in the model must be constrained so that it is navigable in only one direction.
  • Each class in the model must be "reachable" by "walking the graph" of the model following the associations in their navigable direction.
  • Uniqueness:
    • Each class must have a name that is unique within the model.
    • The names of all attributes and associations within a class must be unique within the single attribute-association namespace defined by that class.

With the exception of the RIM itself, all V3 information models are statements of constraint against the RIM. These models are expressed using a modeling formalism and representation developed by HL7 for the purpose. This is fully defined in the HL7 Development Framework. (HDF) and the HL7 Model Interchange Format (MIF). However this is only one possible form of expression. Other forms of expression have been imagined and proposed or are under development.

Information models may be considered or represented as a direct statement of constraint, as a class model (UML) or as some form of typing model (i.e. schema). The difference in these three is largely an implementation issue; the semantics are always clear: all instances are instances of the V3 Reference Platform, and all other information models are constraints on that platform. The degree of success at representing an information model as a typing model depends on the target platform.

The first level of constraint below the RIM is a Domain Information model. This model is created by mapping a domain analysis model to the RIM, data types and HL7 Terminology specifications to meet the requirements of a particular problem domain. A DIM may have multiple entry points. As such, a DIM is not a directly implementable model, and is a fairly general statement of a domain with fairly general vocabulary bindings. It is possible to derive one DIM from another DIM such that the derived DIM covers a subsection of the parent model, usually in greater detail. This can result in a hierarchy of inter-related domain information models. (Many current HL7 documents use the term "Domain Message Information Model (DMIM)" to refer to artifacts that are properly DIMs, as defined here.)

SIMs represent a second level of constraint, based on specific use cases. SIMs must have single entry points and navigation paths that allow them to be traversed and unambiguously serialized for a specific implementation target (e.g. XML, Java, etc.). SIMs are therefore suitable for use as implementation constructs on information systems. SIMs are generally focused on specific operation or capability rather than an entire subject area or topic. (The requirements for a SIM are listed above.)

SIMs are either derived from a DIM directly, or from another SIM. Although technically, a SIM could also be derived from the RIM directly, this is a deprecated practice in order to encourage consistent design and re-use of existing design patterns.

SIM cascades can be as deep as desired, but in most domains HL7 only defines a DIM and one layer of SIMs. (Many current HL7 documents use the terms "Refined Message Information Model (RMIM)", "Hierarchical Message Description (HMD)" and "Message Type model (MT) to refer to artifacts that are properly SIMs, as defined here.)

Like SIMs, LIMs are a constraint model that has a single entry point. However LIMs differ from SIMs in that LIMs may be incomplete models. An incomplete model is one that addresses constraints for only a sub-set of the elements that are contained in the SIM (DIM or RIM) from which it is derived. The absence of other model elements does not exclude them from instances that conform to the SIM. The LIM, quite simply, does not impose constraints on the "missing" elements.

LIMs are Applied Models that provide constraint patterns or templates used in defining communication instances. LIMs are never used as Expressed Models. (Many current HL7 documents use the terms "Static Profiles" and "Templates" to refer to artifacts that are properly LIMs, as defined here.)

The notion of a "type" is widely used in information technology discussion, but rarely is it well-defined. In the sense of this section, two of the definitions for the noun "type" from the Webster dictionaries (at www.merriam-webster.com) are pertinent:

  • 1(c) "a lower taxonomic category selected as a standard of reference for a higher category". [Thus, a human is a type of animal.]

  • 4(a) "qualities common to a number of individuals that distinguish them as an identifiable class"

In the parlance of computing, every piece of information conforms to some specified "model", "type" or "class" that determines what are the contents that make up that information and how they must be represented. In the world of object models, the content model is a "class." In XML-encoded communications, the content model is either a "complex type" or a "simple type." Moreover, these models are used recursively, such that the "type" of an XML "element" may require that the element contains other "elements", each with its own "type," etc.

In HL7's core models, there are several forms of "type" specification:

  • Model — An information model derived from the RIM may establish the "type" for the information to be carried in a CDA document or a message. In general, the sub-types in the model are the classes of the model.

  • Class, as defined in the HL7 RIM, where the properties (sub-elements) of each class include their attributes and the associations from the class to other classes in the models. The "type" of an attribute is a data type, whereas the "type" of an association is yet another RIM class.

  • CMET, Common Model Element Type, in which the class structure of the "entry" class in a model serves as the type for an association in another model.

  • Data type, as defined in HL7 Data Types: Abstract where the properties (sub-elements) of each data type are their components. The "type" of the components is another data type.

  • A Semantic type as defined by a Concept Domain is assigned to, and a part of the definition of, every coded attribute in the RIM.

For data types, the binding to an attribute is asserted using the formal "name" assigned to the data type itself. In general, the type in derived models must be the same as the type from the RIM, though constraints on the RIM type may be used as well. The Expressed Model for data types is always that specified in the abstract data types. This policy exists to ensure that implementations of the data types are robust for use in all the environments that V3 is used.

Data types may also have additional constraints associated with them. These constraints are referred to as data type flavors. Data type flavors are very similar to applied models, but only one flavor can be specified.

Reference: The Refinement, Constraint and Localization and Abstract Data Types, Release 2 specifications should be consulted for further information about data types flavors.

It is common to encounter missing or incomplete information in health care records. In some circumstances, why, how, or in what way the information is missing or incomplete may have some semantic significance that may make a difference to the work flow or clinical management that depends on the information. In general, each class or attribute in a model has a:

A value domain is defined as a For a class, the value domain is the set of all possible conformant instances of that class. For an element whose type is a data type (such as an attribute or data type component) the value domain is the complete set of allowed values for that element as specified by the definition of the assigned data type. Thus the value domain for an element typed as INT (Integer) is all integer numbers and "1" is a member of that value domain, whereas "1.1" is not..

Because it commonly happens that a system needs to communicate, but may be unable to express a value for a particular class or attribute that is within the defined "value domain" for that class or attribute, all data types and RIM classes have a property called "nullFlavor" which, when applicable, may be used to specify why the information does not exist, is not known or available, or cannot be expressed in the allowed value domain. This notion of nullFlavor was first elaborated in the data types specifications. The currently accepted values that the nullFlavor property may have are documented in the data types specification and are maintained formally as the HL7 NullFlavor Code System.

A data type or a class is known as a "null" element if it has a value for its nullFlavor property or is omitted from the instance and does not have a non-null default value. Null values are improper values that do not conform to the proper or expected value domain as described by the applicable specification (usually any model to which the type claims conformance - see typing below). The information may either be missing or partially present, or even completely present but not valid with respect to the constraints imposed by the models it conforms to. While null values may not conform to the "value domain" for the data type asserted in the specification, they must conform to all the rules for NULL values, and SHALL only be used as specified by the information and data type models.

For example, "Other" may not be a valid code, and thus is not part of the value domain for a coded attribute, but may be communicated as a NULL Flavor for that attribute. However, as per the Abstract Data Types specification, use of the "OTH" NULL Flavor requires that either the "codeSystem" property or the "valueSet" and "valueSetVersion" properties for the attribute SHALL be asserted.

In this sense, null is used to create a two level conformance strategy. In some cases, a properly acceptable value domain is defined, and only information that completely conforms to the specified value domain may be provided. In other cases, a properly acceptable value domain is defined, and some information must be provided, but it is acceptable for the data content to not conform to the narrow value domain provided that the instance explicitly declares that it does not conform by declaring a null flavor. See the data types conformance section for further details.

The property is named nullFlavor because of the similarities between the concept of a null value and the concept and behavior of null in implementation technologies, particularly SQL and OCL. As in SQL and OCL, the value null is in the value domain of all the types, and nullFlavors will generally propagate through operations such as comparison (i.e. the result of a comparison operation between a null value and some other value is usually null).

However there are some important differences between the implementation of nulls in such technologies and the HL7 nullFlavor. Most notably, in most implementation technologies, a null instance has no further information associated with it (some variation of the concept of a null pointer). This is not true of the HL7 concept of null; if a data type or class is null, the nullFlavor property is not null, and any of the other properties might not be null.

Note: the nullFlavor property functions in a reverse sense to the data type or class; if the value is not null the nullFlavor will be null, and if the value is null, then the nullFlavor is not null - it will specify an actual nullFlavor that provides more detail as to in what way or why no proper value is supplied.

Note: In OCL, null is an instance of OclVoid which is a super type of all types. nullFlavor is not modeled the same way in HL7: a null value is still a valid instance of a particular type (see discussion of types below). If a true null is encountered in an implementation environment (i.e. the class is not represented in the XML when using the XML ITS, or is present with an xsi:nil="true" attribute), it is semantically equivalent to a null-value of "NI" (no information), and all other properties not related to nullFlavor will also have nullFlavor "NI".

As noted earlier in this section there are numerous "types" defined in HL7 V3 models. For this discussion, the primary types are "class" and "data type".

All HL7 models are constraints on a combined V3 Reference Platform built from the classes defined in the RIM and the data types defined in the abstract data types.

The V3 Reference Platform is further constrained by additional constraint models that associate new names for particular constraints on the associations and classes. These constraint models may come from a linear sequence of constraints where each model is an additional constraint on another model (and when the instance conforms to a model it also conforms to the models on which that model is derived), or an instance may conform to multiple different constraints that are not related to each other.

Thus any given type is an instance of the class or data type as specified in the V3 Reference Platform, while at the same time conforming to multiple other different constraints in the design specifications within this cascading hierarchy of models.

All classes and data types SHALL declare conformance to a single master type. This requirement exists to ease the path of implementations in common target technologies. The type is a duple: the name of the model, and the name of the type/constraint definition in the model. Both the name of the model and the name of the type may be defined by some applicable design contract rather than expressed directly as an attribute of the class.

ITSs that describe how to represent V3 models SHALL make clear how the both parts of the type may be determined from examination of the instance, and what other resources are required at design and/or run-time to unambiguously resolve the type of the class or data type.

Note: The InfrastructureRoot class in the RIM defines the notional attribute typeId to represent the type of the class. ITSs are not required to represent this attribute directly; some other method of representation may be chosen that is more appropriate with the base technology and consistent with the way the ITS specifies that the type information is determined from the instance.

For classes, the type need not be the type from the V3 Reference Platform. There are three ways that a model can relate to an instance. The following bullet list summarizes these and shows the relationship between the adjectival names for the models and the manner in which the models relate to the instance. Following this short list are three sub-sections that provide a more robust characterization of these three model types.

  • an expressed model determines how an instance is expressed - what are the names of its elements, etc.;
  • an implied model is one of the models from which the instance was derived; and
  • an applied model is referenced from the body of the instance and asserts that the instance conforms to this model.

The expressed model is the model that determines the names and structure of the instance (i.e. It governs how the instance is "expressed"). The expressed model is not determined at design time. Rather it is determined by the selected ITS, or for some ITSs, it is determined at run-time. The expressed model is the model that determines the "wire format" of the instance.

Note: The existing XML ITS fixes the expressed model for all of the classes in an instance to be the information model associated with the interaction identifier specified in the root element of the interaction or from "ClinicalDocument" for CDA. The type of a class is not usually represented directly; instead the names of the associations in the expressed model are used, and the type (including the particular leaf class in choice hierarchies) is determined by implication from the association name.

Note: Only serializable models with one entry point (SIMs) may be used as expressed models.

The implied models are specified by the derivations contained in the definition of the expressed model. All expressed models SHALL specify derivations from the RIM. Additional derivations from other models may also be specified. For example, if the wire format for an instance is determined by model A, and model A is a constraint on models B and C, and model C is a constraint on model D then model B, model C and model D would be "implied" models for that instance.

Note: this means that the RIM is always an implied model.

Implementation Note: A processor can correlate the instance data against an implied model by reading the full information model for the expressed model and tracing the derivations from the expressed model to the implied model of choice. This can also be done by the developer by hard coding the derivations in the application. HL7 XML ITS schemas also provide a partial link to the RIM level definition. The implied RIM model is of such consequence that a separate pattern for identifying the RIM classes in the instance exists, using structural codes.

Applied models are other models to which the class conforms but that are not explicit or implicit in the type the class conforms to. These models are sometimes referred to as templates, implementation guides or profiles. The applied model may be invoked explicitly in the instance, or by specifying it in some form of design contract (e.g. interaction profile). Note that it is not necessary to declare all the potential applied models to which a class conforms.

Note: The InfrastructureRoot class defines an attribute called templateId which is used to represent the set of applied models to which that a class conforms. Like the typeId attribute, the templateId is notional; ITSs may define alternate methods for representation of the applied models.

ITSs that describe how to represent V3 models SHALL make clear how the applied models may be determined from examination of the instance, and what other resources are required at design and/or runtime to unambiguously resolve the applied models.

Note: If an applied model specifies derivations, then the models specified in the derivations are also implied models.

Reference: The templates specification should be consulted for further template related information.

One of the founding principles of V3 models is the importance of the correct identification of objects.

When source and destination systems share sufficient information to permit it, the source system may simply refer to an object rather than providing full details of the object. Rather than updating the object in either snapshot or update mode (see Update Control), the destination system should use the information provided to identify an existing instance of data.

It is not necessary for the destination system to already have information, only for the system or the appropriate users to know how to locate the information that the reference pertains to.

For this reason, object references are used widely. The concept of reference is also closely related to the concept of update mode - an object will either be passed as a snapshot, an update, or a reference. These modes are discussed further in the sub-section on Update Control.

Whether an object is being conveyed using snapshot mode, update mode, or as a reference, the first step for most processing systems is to correctly locate an existing record for the concept that the object represents, if one exists.

In order to accomplish this, the system must correctly identify the object. In most cases, the identification will be implicit or explicit in the contracts that control the system communication. However in some cases it will be necessary for the source system to clearly indicate the attributes that should be used to identify the object.

For example, a source system may wish to indicate which of several identifiers associated with an object should be used to identify the object. The semantic properties of the identifiers - scope and reliability - are generally preferred as the criteria for choosing which identifier should be used, but in some cases it may be necessary to specify a particular attribute.

Another case is where the source system does not know the relevant identifiers for the object, but is able to define some key criterion for identification of the concept. For instance, the source system may know that the patient had an episode of care on a given date, but not the destination system's identifier assigned to the episode of care.

A source system should clearly identify the attributes of an object that it expects to be used to identify the object correctly, if it does not assume that identifier scope and reliability (within the II data type) suffice.

The general implication of these rules is that when an object is sent using update mode or as a reference, only the information that is required in order to correctly identify the object is sent, along with any specific updates for update mode, and that all the information provided should be clearly labeled. However it isn't always clear how much information is required to correctly identify the reference, so additional useful information is always allowed. Generally, it would be expected that this additional information would be of use in some human intervention procedure if automated resolution of the reference failed.

As objects, Data Types are identified by their unique name in the appropriate published data types specification. For a more complete discussion of data types, please refer to the Abstract Data Types Specification.

In the absence of any explicit agreement or information in the instance, the default method for resolving identity is that at least one of the identifiers in the source object must match at least one of the identifiers of the destination object for identity to be resolved.

For HL7 purposes, all identifiers must be unique within their namespaces to avoid misidentification.

Globally unique identifiers may be created as either Universally Unique Identifiers (UUIDs — see ISO/IEC 11578:1996) or Object Identifiers (OIDs — see ITU-T X.660 or ISO/IEC 9834-3). The method of UUID generation ensures that it is extremely unlikely that the same UUID is generated more than once. OIDs are globally unique if the OID registration procedures defined by ISO in the 9834 series of standards are followed. A set of local identifiers may be made globally unique by prefixing them with a common global identifier. OIDs are created by an ISO Registration Authority, as specified in the ISO standards. HL7 is such a Registration Authority, and creates and issues OIDs for use in identifying objects in HL7 standards and implementations.

The instance identifier (II) data type has a root property, which must always be populated in any instance of this data type, and an extension property which is optional. The definition of this data type specifies that, taken together, the root and extension properties must form a globally unique identifier, i.e. it identifies one and only one object instance globally in any context.

Note that there are specific situations where only a local identifier is available. A typical example is on a point of care device. In these cases, either the context of use assigns a global identifier root, or the identifier is incomplete (some flavor of null).

For some scenarios, it is not enough that the identifier be globally unique; the identification must also be consistent among a group of systems exchanging V3 instances. Some concepts must be consistently identified, such as Social Security Numbers in the USA. Other concepts, notably shared standards such as HL7-defined concepts, ISO standards, and ICD and SNOMED terminologies, need to be consistently identified by all systems producing and consuming V3 instances. If consistent identifiers are not used then interoperability is degraded because communicating systems would have no way to realize when they were talking about the same thing.

One way to produce common consistent identification of these various kinds of objects is to maintain a central system where these identification concepts are registered. HL7 maintains an OID registry for this exact purpose. Any identifiers of interest to HL7 implementers may be registered on the HL7 OID registry, which includes

  • OIDs created and issued by HL7 that refer to objects or concepts defined by HL7 and maintained internally,
  • OIDs created and issued by HL7 that refer to externally defined objects or concepts, and
  • OIDs created and issued by Registration Authorities other than HL7 that refer to externally defined objects or concepts.

Note that the presence of an OID on the HL7 OID registry does not mean that HL7 claims responsibility for the object identified, only that it is of interest to some HL7 customer. If the OID is in the HL7 OID branch, then HL7 has issued the OID and accepts responsibility for working with the owner of the object or concept to maintain the meta data set of the Registry entry for the concept.

HL7 assigns an OID to each of its Code Systems, as well as to external standard coding systems that are being used with HL7 and HL7 Affiliate specifications. HL7 also assigns OIDs to public identifier-assigning authorities (e.g., U.S. State driver's license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, other countries' Social Security Administrations, Citizen ID registries, etc.).

One of the primary objectives of the HL7 OID registry is to ensure that there is only one authoritative OID to be used for a given concept in HL7 instances. For example, there is only one OID registered for the LOINC code system in the HL7 OID registry. While any organization that is an ISO Registration Authority and manages an OID root may create their own OID for the LOINC code system, these additional OIDs cannot be added to the HL7 OID registry because they would result in multiple OIDs for the same concept. Furthermore, if an OID has been registered with HL7 for a given code system or identifier namespace, that OID SHALL be used when referencing that code system or identifier namespace in conformant HL7 instances. This ensures that HL7 conformant systems can rely on code systems and common public identifiers always being identified consistently in HL7 V3 instances. (Note: In some cases duplicate registrations may be introduced inadvertently. Refer to OID Conflict Resolution below to see how this is handled.) HL7 Affiliates managing a Binding Realm may declare alternate OIDs within their Realm where necessary for statutory or regulatory reasons; these may be registered in the HL7 OID Registry and if so will be identified as Realm-specific alternatives.

HL7 strongly encourages people to register the OIDs to be used in the code system property of coded data types, or in the root property of identifier data types. The requirement for the OIDs that must be registered is part of conformance rules for HL7. Other HL7 registered OIDs, such as those used for organizations and local namespaces, are also encouraged, although there are no fundamental requirements to do so. Note that these organizations may have other OIDs assigned by other registrars in use elsewhere.

HL7 will assign OIDs in its branch for HL7 users and vendors upon their request for a 'root' to be used to issue OIDs themselves independent of the HL7 OID creation process. When this is done, the registration authority (RA) for all OIDs under this assigned OID is delegated to the person or organization so assigned. The understanding is that they will have sole responsibility for further OID assignment under their new root and will perform such assignment consistent with the ISO standards governing OIDs. Any objects that are subsequently assigned by these RA delegates may be registered in the HL7 OID registry. Once this is done, the OID so registered can be used in conformance claims about the identity of the object in subsequent HL7 messages.

In some cases, technical errors may have been made during the OID assignment and registration processes, and sometimes an OID that has been registered for some time for HL7 purposes must be decommissioned and a different OID for the object being identified must be registered. A retired status is associated with the OID entry in the registry. This does not mean that the OID has been retired (the OID is merely "used up" for HL7 purposes), it means that the entry representing the OID registration in the HL7 OID Registry has been retired. In these cases, the erroneous OID entry is identified as "Deprecated," and the OID that replaces it is identified in the OID registry. After a period of 2 years, the deprecated OID will be set to "Retired," but both it and its identified replacement shall remain in the HL7 OID registry.

Note that the registration of an OID is separate from the creation of an OID by a Registration Authority. Any OID created by any authority may be registered in the HL7 OID Registry. There is no concept of 'ownership of an OID'. The Contact Person and Responsible Body meta-data in the HL7 OID registry identify those that are responsible for maintaining the accuracy of the meta-data for the entry in the HL7 OID registry. OIDs are global identifiers, and once created, are not 'owned' by anyone. When a request is made for creation of an OID by HL7, the newly created OID is automatically registered in the HL7 OID Registry. Once an OID has been issued by a Registration Authority, it is valid forever. It may be deprecated, which is interpreted to mean that a replacement OID should be used instead.

Some Code Systems are published with more than one Code for their concepts. In these cases, HL7 strongly urges that a recommendation as to which of these Codes should be used in the code property of the coded data types when communicating these concepts be included in the description and/or usage notes when registering the Code System in the HL7 OID Registry. Authorities formulating rules regarding the use of certain Code System within their jurisdictions are free to mandate a set of particular Codes for use in the code property of the HL7 coded data types.

There is an FAQ with more information about the use of the HL7 OID registry that may be found at OID Registry Frequently Asked Questions.

When assigning OIDs to third parties or entities, HL7 investigates whether an OID is already assigned for such entities through other sources. If a preexisting OID is found, HL7 records the OID in the registry, and HL7 will not assign additional OIDs for the same object. If no OID is found, HL7 will create one in the HL7 branch. If an appropriate third party can be identified, HL7 will notify the party when an OID is being assigned for that party in the HL7 branch.

Though HL7 exercises due diligence before assigning an OID in the HL7 branch to third parties, it is not possible, given the lack of a global OID registry mechanism, to make absolutely certain that there is no preexisting OID assignment for such third-party entities. Furthermore, external assigning authorities may encounter the same issue, failing to discover that HL7 has assigned an OID and assigning a duplicate. When such cases of multiple assignment are discovered, HL7 works to resolve this situation via the deprecation process outlined above for technical errors.

The HL7 root OID is 2.16.840.1.113883. All OIDs that HL7 assigns are issued within this space defined by this OID, as per ISO standards on OIDs. In order to make searching a very large number of OIDs in the HL7 OID Registry easier, registered OIDs are assigned a 'type' when they are registered. This can be used as a filter when searching for OIDs. When OIDs are created by the HL7 website software, the decimal value immediately after the HL7 OID is set to be the same as the OID Type. This can be overridden by the registrant, and does not apply to OIDs created by bodies external to HL7, so there is only a loose association between the numeric clauses in the OID value immediately below the HL7 root 2.16.840.1.113883 and the numeric value of the OID type, and this should be kept in mind if attempting to deduce meaning from the sequence of OID integer clauses. OIDs should be treated as meaningless identifiers. These OID Types are summarized in the table below:

Defined HL7 OID Types
Identity Use
0 HL7 Root OID
1 HL7 registered internal objects (other than organizational bodies)
2 HL7 organizational bodies and HL7 Groups
3 External groups that have been issued an HL7 OID root for their own use as Registration Authorities
4 Registered externally maintained identifier systems
5 HL7 Internal Coding Systems
6 Registered coding systems maintained externally to HL7 (but with an HL7 issued OID)
7 HL7 published document parts and artifacts
8 No longer used.
9 HL7 Registered conformance profiles
10 HL7 Registered Templates
11 HL7 defined and registered Value Sets
12 HL7 Version 2.x tables (may be code systems, value sets, or concept domains)
13 Externally authored and curated Value Sets, HL7 registered
14 Ontological branch in OID tree, used as sub-type meta-data
15 Sets of codes, defined and maintained external to HL7 (not code systems).
17 Unspecified type defined externally to HL7
19 HL7 Examples Root used for published examples; meaningless identifier, not to be used for any actual entities

Both the Instance Identifier (II) and the Concept Descriptor (CD) data types are used to define how object identities are expressed in HL7 class attributes. Their basic structures are similar: each includes a namespace and an identifier class attribute, with other optional information in the case of the CD. In a CD, the namespace is the "codeSystem" attribute, and the identifier is the "code" attribute. In an II, the namespace is the root attribute and the identifier attribute is the extension. Via the linkage to a terminology and its richer set of attributes, the CD class allows the system to make usage of behaviors of terminologies (e.g. synonyms, language specificity, relationships and reasoning logic), while the II data type can only identify a unique object.

Due to their similar basic identification attributes, a guideline is offered to help modelers decide which data type to use for a given entity.

  • When the entity described by the class attribute is a concept (a class of entities) and/or the modeler wants to allow machine behavior to be applied to the concept instance at run time, the data type CD should be chosen (e.g. SNOMED CT code for headache).
  • If the purpose of a class attribute is to uniquely identify an object, and it resolves only to a single object within a class of entities, then the modeler should choose an II (e.g. drivers license number).
  • If, at design time, the purpose does not clearly fall into usages 1 or 2 above (e.g. because two perspectives allow to see one entity as class or as concrete object), a CD or II can be used arbitrarily. This does not impede interoperability, as the data type is defined in the model.

In HL7, an information model identifies and describes the information that can be recorded and exchanged in the form of classes and their attributes and associations. A data type specification defines the types that can be used in HL7 information models by specifying their properties and relationships.

A class attribute or data type property includes a description of the characteristic that the attribute represents, a cardinality constraint that identifies whether or not the attribute must always be present in an instance of the class and whether the attribute can appear more than once, and a data type that defines the range of possible values for the attribute or property. Certain data types employ enumerated lists of values to represent controlled sets of concepts: these are expressed as Coded Model Elements. In HL7 Version 3, a coded model element is represented using data types such as: CD, CE, CV, CS, CO, CR, PQ, and SC (see HL7 Abstract Data Types). [1] In HL7, the possible values for these elements and their associated meanings are defined in Code Systems, from which both the representations and the associated meanings are drawn. The set of codes that are allowed for a particular coded model element is referred to as a Value Set.

The following section (HL7 Vocabulary) describes the structural properties of Concepts, Code Systems, and Value Sets, while the section after that (Vocabulary Conformance) describes the usage of these concepts in the business context of HL7 information models and data types.

There is a collection of nomenclature used to describe this component of HL7, and definitions exist for all of these terms. These can be found in the HL7 Glossary and also at the ISO SKMT glossary. The intent is to have all the definitions come from a single source, but they may be voted upon in this document.

In HL7, the term Vocabulary is used to describe any of the terminological objects in common use in Health Information Technology. For the purposes of use in HL7 models, the differences between a terminology, ontology, taxonomy, or classification do not affect the technical means by which coded components of these are handled; they are treated the same technically in the instances of the coded data types (although implementers should be cognizant of the semantics impact on using these different resources appropriately in their models). Refer to the HL7 Glossary and/or the ISO SKMT for descriptions and definitions of these items.

A Concept is defined as a A Concept is a unitary mental representation of a real or abstract thing – an atomic unit of thought. It should be unique in a given Code System. A concept may have synonyms in terms of representation and it may be a singleton, or may be constructed of other concepts (i.e. post-coordinated concepts).

Concepts, as abstract, language- and context-independent representations of meaning, are important for the design and interpretation of HL7 V3 models. They constitute the smallest semantic entities on which HL7 V3 models are built. The authors and the readers of a model use concepts and their relationships to build and understand the models; these are what matter to the human user of HL7 V3 models. The rest of the vocabulary machinery exists to permit software manipulation of these units of thought.

A Concept Representation is defined as a A Concept Representation is a vocabulary object that enables the manipulation of a Concept in HL7. A Concept Representation exists in some form that is computable, and can be used in HL7 models and specifications. Concept Representations can take on a number of different roles in the structure and processing of vocabulary in HL7; these roles and functions are described below.
A Concept Identifier is defined as a A Concept Identifier is a Concept Representation that may be published by the Code System author, and unambiguously represents the concept internally within the context of that Code System. Such an object used for identification, when combined with the unique identifier of the Code System itself (a machine-processable unique string), provides a globally unique and language-independent identification for the particular concept. This globally unique identification can be used in transactions and data records that span both space and time. In some cases, multiple synonymous identifiers may be present for the same concept.
A Code is defined as a A Code is a Concept Representation published by the author of a Code System as part of the Code System. It is the preferred unique identifier for that concept in that Code System for the purpose of communication (preferred wire-format identifier), and is used in the 'code' property of an HL7 coded data type. Codes are sometimes meaningless identifiers, and sometimes they are mnemonics that imply the represented concept to a human reader. In Code Systems that contain more than one Concept Identifier, the one that should be used in HL7 as the Code should be explicitly declared as part of the HL7 Code System registration process (see § 4 above).

The meaning of a Code within a particular Code System entity is valid only within that Code System. For example, each table having enumerated codes in the HL7 Version 2.x standards represents a different Code System, since codes are sometimes used in different Code Systems to have different meanings. One example is the code "M" in the v2.x table 0001 Administrative Sex which signifies "Male," whereas the code "M" in the in the v2.x table 0002 Marital Status signifies "Married". Another example is the code "1609-7" which signifies the Native American tribe "Sioux" in the Race & Ethnicity – CDC Code System(2.16.840.1.113883.6.238), and the code "1609-7" which signifies "Prolactin^1.5H post dose insulin IV" in the LOINC Code System (2.16.840.1.113883.6.1). Codes do not have explicit semantics without their Code Systems, and cannot be referenced without identifying the code system in which they are published.

A Designation is defined as a A Designation is a Concept Representation that may be published by the Code System author, and is a language symbol for a concept that is intended to convey the concept meaning to a human being. A Designation may also be known as an appellation, symbol, or term. A Designation is typically used to populate the 'displayName' property of an HL7 coded data type.

The following table may help to clarify the differences in meanings and uses of these Concept Representations.

Some Names and Uses for Concept Representations
Name Definition Primary HL7 Use Examples
Code A concept representation intended for use when representing a concept in a computable manner. For example, passing into a decision support tool or for use in data exchange. Some code systems use human-readable mnemonics for these. Generally carried ‘on the wire' in instances of coded attributes of models passed between or shared by different systems. HL7 AdministrativeGender:
  F

LOINC:
  6690-2

SNOMED CT:
  DE-10116
  X100J
  233607000
  53084003:246075003=9861002
   (all these codes represent the same SNOMED CT concept; the first is an IHTSDO Legacy Code, the second is an IHTSDO Read Code, the third is an IHTSDO Concept ID, and the last is an IHTSDO post-coordinated expression)

UCUM:
  L
  mg/L

Concept Id A concept representation that is unique within the code system and that is used internally by the code system when referencing concepts. Many code systems use the same value for Concept Code and Concept Identifier, therefore the Concept Identifier may be used in CD.code; however, it is often used as a component of maps and ontologies outside of HL7 interoperability standards. Some Code Systems have more than one Concept Identifier for a concept. HL7 AdministrativeGender:
  F

LOINC:
  6690-2

SNOMED CT:
  233607000

UCUM:
  m
  g
  L

Designation Human consumable representation of the concept; may or may not be a string of characters (could be multimedia); generally subject to language variants. Human language representation of the concept. A concept has 1..m of these, and they represent the set of candidates for the CD.displayName (v3) or CWE.Text/CWE.Alternate Text (v2). Sometimes used in CWE.Original Text depending upon the application. Often language-dependent, i.e. a set of English designations, a set of French designations, etc. HL7 AdministrativeGender:
  F
  Female

LOINC:
  Leukocytes [#/volume] in Blood by Automated Count
  WBC #Bld Auto
  Leucociti

SNOMED CT:
  Pneumococcal pneumonia (disorder)
  Bacterial pneumonia (disorder) {Causative agent (attribute) Streptococcus pneumoniae (organism)}

UCUM:
  Litre
  mg/L
  L
  milligram/Litre
  gram/Litre

A Code System is defined as a A Code System is a managed collection of Concept Representations, including codes, but sometimes more complex sets of rules and references, optionally including additional Concept Representations playing various roles including identifiers of the concepts, designations, etc. Code Systems are often described as collections of uniquely identifiable concepts with associated representations, designations, associations, 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 concept identifier must resolve to one and only one meaning within the Code System; i.e. Code Systems used in HL7 must not have homonymy. In the HL7 Terminology Model, a Code System is represented by the Code System class.

Although Code Systems may be differentially referred to as terminologies, vocabularies, or coding schemes, HL7 considers all such collections ‘Code Systems' for use in Version 3 as described in this document. At a minimum, Code Systems have the following attributes:

  • An identifier that uniquely identifies the Code System. For HL7 conformant model instances, this SHALL be in the form of a UID. This UID will take one of three forms: an ISO OID, a UUID or an HL7 RUID. If the code system is identified by an OID, this OID SHALL be registered in the HL7 OID registry, unless the code system is a local code system, in which case it MAY be registered in the HL7 OID Registry. The HL7 OID Registry may be found at http://www.hl7.org/oid/index.cfm
  • A description consisting of prose that describes the Code System, and may include the Code System uses, maintenance strategy, intent and other information of interest.
  • Administrative information proper to the Code System, independent of any specific version of the Code System, such as ownership, source URL, and copyright information.

The Concept Representations in a Code System may also be augmented with additional text, annotations, references and other resources that serve to further identify and clarify what a concept is. A Code System also may contain assertions about relationships that exist between concepts in the Code System.

A Code System is typically created for a particular purpose and may include finite collections, such as concepts that represent individual countries, colors, or states. Code Systems may also represent broad and complex collections of concepts, e.g., SNOMED-CT, ICD, LOINC, and CPT. Where possible, HL7 modelers faced with a requirement for a coded concept will reference an existing Code System. Some of these Code Systems are replicated within the HL7 standard repository for stability or convenience, while others are documented as references. HL7 will only create a new Code System when an appropriate existing Code System is not available for use in HL7. Such is the case with Class Codes, which are defined and maintained by the HL7 organization. There are also cases where an otherwise appropriate external resource is not available due to licensing or other restrictions.

Code Systems may provide a capability for the composition of complex concepts consisting of two or more existing concepts and formal relationships between them, using a defined syntax. A complex concept which has been assigned a unique concept identifier or code and is published in the Code System is referred to as "pre-coordinated". A representation of a complex concept that is created externally to the Code System (i.e., by an outside entity or user) is called a post-coordinated expression. [2] Note also that it is possible (although discouraged) for a post-coordinated expression to be constructed that represents a concept which already exists and is published in the Code System. Some commonly used code systems in health care IT, such as SNOMED-CT and UCUM, provide a formal mechanism for post-coordination. The mechanism (syntax) that permits this construction of new concept representations is referred to as a grammar for post-coordination.

A simple example to illustrate post-coordination is a case where there exists a concept code for the anatomical object 'arm', a concept code for the laterality identifier 'left', and a code used in post coordinated expressions for 'has laterality'. Although the code system may not have any code for 'left arm', it can be represented in the code system with the three codes, e.g. 'arm' - 'has laterality' - 'left'. HL7 permits the use of such expressions in the coded data types for representation in model instances. Another example is the concept "excision of pituitary gland" which may be pre-coordinated in the code system with a unique identifier and a designation of "hypophysectomy". An alternative definition for this concept can be obtained by post-coordinating codes for "brain excision" and "pituitary gland," without adding a reusable designation to the source system. Post-coordination allows us to derive complex composite terms by combining the concepts they are derived from, which reduces the number of concepts in the source system. Post-coordination requires the explicit resolution of complex questions of context and semantic precedence (e.g., the preposition "of" in this example).

Code Systems evolve over time. Changes occur because of corrections and clarifications, because the understanding of the entities being modeled evolves (e.g., new genes and proteins are discovered), because the entities being modeled change (e.g., new countries emerge; old countries are absorbed), or because the assessment of the relevance of particular entities within the knowledge resource change (e.g., the addition of new parent-child relationships to existing codes in SNOMED-CT). Depending upon how well the Code System adheres to good vocabulary practices, the changes in meaning could be significant. Therefore it can be important to know which version of a given Code System was used in the creation of HL7 model instances, the recording of coded data, or in some cases the creation of the HL7 models.

The HL7 model depends on the meaning of a specific concept identifier remaining constant over time, independent of the particular version of the knowledge resource. In cases where the knowledge resource itself doesn't enforce this (e.g. older versions of ICD-9-CM, where codes were retired and subsequently re-used to represent something different), then the version of the Code System in which the code is associated with the desired meaning must be included in the HL7 data type carrying the instance of the Code. Where codes do not change meaning over time (or where the meaning change is sufficiently subtle that any such meaning changes are deemed by the user as immaterial for the purpose for which the code is being carried), the version of the Code System is not required to be noted with the Code and the Code System. Some code systems have changes that are significant over time, and for these a new code system has been designated rather than a new version of the same code system. This is the case, for example, with the German diagnostic classification codes: ICD10GM2009 is NOT a new version of ICD10GM2008, but a completely new code system, with its own independent versioning.

Code Systems employ a variety of mechanisms to signify a particular version; these are defined by the author and/or distributor of the Code System. Most use a number, or set of numbers, others may use alphanumeric strings or dates. There exists no standard representation of version identifiers that has been adopted by authors of Code Systems. Any version identifier that can be represented in an HL7 string data type can be used in HL7. When a code system is registered in the HL7 OID Registry so that conformance may be tested and/or measured, the registration should include precise and detailed information on how code system versions are defined and identified. The registration information should be explicit enough to ensure that independent applications recording the code system version used to capture a particular data element will be recognized by other applications with whom they exchange information. Considerations include factors like use of upper-case vs. lower-case characters, the presence and types of separators, use of leading characters, order of components, and potentially even character set. For example "02.5" would not match with "2-5"; "2001/03/05" would not match with "05-03-2001", etc. The registration should indicate enough information about versioning and the syntax of the version string so as to make the machine machine processing of the version string a reasonable expectation.

The machinery for Value Sets (see below) and for conformance must operate over multiple code systems that use these various different means to specify their versions. In order for this to operate properly across these different mechanisms, all HL7 internal machinery uses the effective date for a particular code system version when doing such processing. In order for this to work correctly, for externally maintained terminologies that have named or numbered releases, a table must be maintained that shows the modification dates for the named or numbered releases. For externally maintained terminologies that maintain modification dates for each individual code change, no additional information is needed.

 5.1.3Value Sets

A Value Set represents a uniquely identifiable set of valid concept identifiers, where any concept identifier in a coded element can be tested to determine whether it is a member of the Value Set at a specific point in time. A concept identifier in a Value Set may be a single concept code or a post-coordinated expression of a combination of codes.

Value Sets exist to constrain the permissible content for a particular use, e.g. for use in analysis, display to a user, etc. For HL7, value sets constrain the permissible content for a coded element in an HL7 information model or data type specification. Thus, at implementation time, a coded element must be associated with a list of codes that represent the possible concepts that can be represented in that element at the time of use. Value Sets cannot have null content, and must contain at least one Concept Representation. [3] 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 in a Value Set should be represented only by a single code. However, in unusual circumstances, a given concept in a Value Set can have more than one code (e.g. where a different case is used to signify the same concept, as 'l' and 'L' in UCUM for 'litre'); it is generally rare that Code Systems from which Value Sets are drawn contain multiple codes for the same concept.

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 implicit post-coordinated expressions drawn from multiple Code Systems. A Value Set may include concepts directly defined in code systems, and may also include concepts defined with post coordinated expressions (using those code systems that support post coordination).

A sub-Value Set is a sub-set of a parent Value Set (the superset). A sub-Value Set is generally created as part of the successive constraining process of HL7 V3 development.

Because the collection of codes in a Value Set may be unbounded, and may be dependent upon the time the collection is used, a Value Set is only persisted as its Value Set Definition, which is a machine-processable set of 1 or more formalisms that permit a specific collection of coded concepts at a given point in time to be reliably reproduced. The collection of codes that is generated from the Value Set Definition are called the Value Set Expansion. Whether or not the generated collection, the Value Set Expansion, is also persisted is an implementation choice. Value Set Definitions permit the expanded collection of Codes to change over time with no change to the definition, if the user so desires. Value Set Definitions can also be revised over time to reflect changes to underlying code systems, improved understanding of the requirements for the Value Set, etc. However, changes to a Value Set Definition must ensure that the Value Set Expansion remains consistent with the use of the Value Set; i.e. changes to a Value Set Definition should not cause issues with specifications or implementations that are already using the Value Set and that may not make reference to the specific version of the definition. Even with this caveat, such changes should still be approached with great care, as changes in value set expansions may have adverse effects on some applications using the value set.

A Value Set optionally has a description, but this is not intended to describe the semantics of the Value Set; a Value Set has no intrinsic semantics separate from its Value Set Expansion. The description should capture its intended use, which is needed for ensuring integrity for its use in models across future changes.

HL7 International defines Value Sets as part of its vocabulary maintenance procedures, and the definitions of these are incorporated within the published HL7 vocabulary artifacts; these are commonly called HL7 Value Sets or Internal Value Sets. Other organizations also define Value Sets for their own use in HL7 models, and these are referred to (in HL7) as External Value Sets. In most circumstances, HL7 International only defines and maintains Value Sets that are bound in Binding Realms (see Bindings) controlled by HL7 International or are used in specifications published by HL7 International.

Two approaches can be used to define the contents of a Value Set:

  • Extensional Definition: Explicitly enumerating each of the Value Set concepts.
  • Intensional Definition: Defining an algorithm that, when executed by a machine (or interpreted by a human being), yields such a set of elements.

An Extensional Definition is an enumeration of all of the concepts within the Value Set. Value Sets defined by extension are composed of explicitly enumerated sets of concept representations (with the Code System in which they are valid). The simplest case is when the Value Set consists of only one code.

An Intensional Definition is a set of rules that can be expanded (ideally computationally) to an exact list of concept representations at a particular point in time. While the construction rules can potentially be quite elaborate, HL7 has identified a small set of rules as explicit formalisms that appear to be useful in most circumstances where HL7 models are used. In order to share Value Set Definitions between systems if needed, HL7 strongly recommends that the HL7-created definition formalisms be used whenever possible.

If any of the definition statements in the collection making up the Value Set Definition is intensional, then the entire Value Set is considered to be intensional.

Some examples of the HL7-created Value Set Definition formalisms available to specify Intensional Definitions are:

  • All active unique identifiers from a given coding system (e.g. "All codes from ISO3166-1 Country Codes")
  • All unique identifiers that participate in a specified relationship with a given concept in a coding system, which may or may not include the specified code itself (e.g. "All LOINC codes having a SYSTEM of BLD")
  • The transitive subset of a given code along a given relationship type, including or excluding the code itself (e.g. "All subtypes of 112283007 Escherichia coli in SNOMED CT" including the head code)
  • All codes matching a particular Regular Expression
    [4]
  • A nested Value Set definition in which a Value Set entry references another Value Set (a child 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). A Value Set whose definition includes nested Value Sets is always considered intensionally defined. (e.g. "Include the Value Set of Category A NIAID agents and the Value Set of Category B NIAID agents")
  • An explicit set of enumerated codes from a coding system (as in an Extensional Definition above) (e.g. "US, CA, UK, DE, JP codes from ISO3166-1 2-character country codes")
  • Unions, intersections and exclusions of any of the above.

Note that these are examples of some Intensional Definition functions. Many others are possible, and HL7's formalisms will be extended over time as the marketplace requires. Those used in support of HL7 vocabulary that is part of the HL7 ballot publications may be found in the MIF (Model Interchange Format) definition. Note that definitions that are not part of the current HL7 meta-model definition are local extensions, and are not fully HL7 compliant.

The Intensional Definition must be specific enough that it is always possible at a point in time (within specific versions of the Code Systems referenced) 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 specializations of the SNOMED CT concept ‘Diabetes Mellitus.'"

A common method for specifying an Intensional Definition is to identify a concept (often referred to as a root concept or head code) that has descendants, indicating that the Value Set Expansion contains all of the descendants of the identified concept. The Intensional Definition may also specify whether the tree of the concepts to be included in the expanded Value Set includes or excludes this root concept. If this root concept at the top of a tree of concepts is to be included in the expanded set, the Intensional Definition is considered Specializable. If it is explicitly excluded, and is identified just as a referent for the included tree of subordinate concepts, the Intensional Definition is termed Abstract.

Being Abstract or Specializable indicates that for an intensionally defined Value Set whose definition indicates including a hierarchical tree of concepts from a single root concept, the root concept of the tree may not be populated in the model element to which the Value Set is bound. The root concept may also be thought of as 'non-selectable', i.e. the root concept will not be included in the Value Set Expansion. While the terms 'abstract' and 'specializable' have been used historically in HL7, and many existing tools display the Value Set in this way; these are simply convenient labels. Note that two different Value Sets may have what appear to be identical definitions, but one is abstract and the other specializable. These are two distinct Value Sets and two distinct definitions, as they will produce value set expansions that differ by the root concept. A Value Set Definition may be made up of more than one definition statement of various kinds.

HL7 International recommends that, whenever possible, a Value Set be drawn from a single Code System. This is not always practical, however, and when a Value Set Definition includes references to more than one Code System, designers should never incorporate two identical concepts from two different Code Systems in the same Value Set Definition in order to ensure that the set does not contain more than one globally unique identifier that denotes the same concept. Care must be taken to ensure that every concept represented in the Value Set has only one possible globally unique identifier. However, designers may choose to use multiple concepts that are very similar as long as there has been consideration of the impact, and how these may be differentiated by users of application systems.

For example, both CPT and LOINC have codes that represent Hematocrit, meaning that there are two possible globally unique identifiers with approximately the same meaning: 2.16.840.1.113883.6.1#4544-3 (for LOINC) and 2.16.840.1.113883.6.12#85014 (for CPT-4). If both of these are possible choices in a Value Set, data encoded with one code may be missed when searching using the other code, and interoperability in general may suffer. Further, dividing semantic stewardship for the Value Set can introduce semantic traps: the different source system owners may define their concepts with differences that escape one user's notice, but have a significant effect on another user's interpretation. In the above example, the CPT code specifies a test order, but does not require that the test be filled by a specific method: it refers to any Hematocrit. The LOINC code, on the other hand, specifies the automated count method, specifically excluding packed cell volume tests. Equating these codes may be permissible in some contexts, but would be incorrect in others.

Extra care must be taken to assure that overlapping references do not appear in intensionally defined Value Sets, especially as there is no easy way to automatically determine when this situation exists. Again, the easiest way to avoid this is to avoid the use of multiple Code Systems in a single Value Set wherever possible.

To obtain a list of enumerated concepts, Value Sets must be expanded. This means that the Value Set Definition must be converted to a list of concept representations at a point in time. This list usually consists of codes so that the Value Set Expansion may be used in populating or validating communicated model instances, but may alternatively be a list of designations. While this is straightforward for extensional Value Set Definitions, an intensional Value Set Definition must be resolved to a Value Set Expansion by processing the rules contained in the Value Set Definition. This process should record the exact set of definitional rules used to resolve the Value Set using the specified definition version (see below). Value Set Expansion can be done as early as the point of Value Set definition or as late as run time. For statistical, legal, and analytical purposes, good practice dictates that a system which captures a coded value should be capable of reconstructing the Value Set Expansion that was in effect at the time a given code was selected.

A Value Set Definition does not prescribe the structure of a post-coordinated expression in a Value Set Expansion, as there is often more than one way to specify a specific concept that is legal within a post-coordination grammar. Also multiple valid Value Set Definitions could result in the identical Value Set Expansion. For intensional Value Sets, the set of concepts contained in the expansion will generally change when the definition is changed (a new version of the Value Set Definition), but also may change with the identical version of the definition if the underlying code systems change, and the changes are part of the Value Set Expansion. This can be controlled if the definition statement refers to specific code system versions, thereby prohibiting the expansion from changing when the code system changes with a new version release.

Some intensionally defined value sets, particularly those that permit post-coordinated expressions, cannot be expanded in the usual sense because their expansions are infinite (or at least so large as to make enumerating all possible values impractical). For example, the UCUM post-coordination grammar allows units to be combined together by multiplication, such as m, m2, m3, etc. The grammar places no upper limit on what multiplication is possible, so m57 and m2341688 are also legal (though highly unlikely) codes. A value set whose definition includes "all codes from UCUM" could thus never be fully enumerated (expanded). In these circumstances, implementations must instead use the algorithms that can process the formalisms in the Value Set Definition to evaluate a specified code to see if it meets the constraints of the Value Set rather than fully expanding the Value Set and performing a simple look-up on the resulting list.

A Value Set Definition can change over time. New codes may be added to or removed from an Extensional Value Set definition, and/or the rules used to construct an intensionally defined Value Set may be changed. When a Value Set Definition changes, it should be done in a way that ensures both the old and new versions are available for comparison, and for the use of models that explicitly reference the old version.

There are multiple strategies for tracking Value Set versions. Two of the most common are:

  1. to increment the version number each time a change is made to the Value Set Definition
  2. to track modification dates for each change to the Value Set Definition.

In HL7 standards, Value Set versions are determined by effective date (the date at which the Value Set version became effective), and not by available date (the date the Value Set version was made available within an organization) or by a version number. This policy has the following implications:

  1. For enumerated Value Sets maintained by HL7, the activation date and deactivation date for individual codes in the Value Set must be maintained as part of the Value Set.
  2. For intensionally defined Value Sets, the activation date and superseded date must be recorded (tracked) each time the logic of the definition is changed.

A Value Set Version thus contains a specific Value Set Definition, and may also contain descriptive and administrative information, as well as data to assist in curation.

The set of codes comprising the expansion of an intensionally defined Value Set at a point in time may change at different points in time, even using the same definition (e.g. when the underlying Code System changes in certain ways). These different expansions are not different versions of the Value Set; versioning pertains to modifications of the Value Set Definition. The curation needs of persisted Value Set Expansions are outside the scope of this specification, as there are performance, architecture, and synchronization issues surrounding persistence of Value Set Expansions.

At the time a Value Set is defined, the business Use Case or information model design may require that the definition of the Value Set never change. In order to support this, a Value Set has a property called "immutability" which is a Boolean and refers to the Value Set Definition. If TRUE, the Value Set Definition may not be changed in the future. A new Value Set must be created. (There can be no new versions of the Value Set). If FALSE, the Value Set may be changed, and the versioning mechanism will permit traceability of such changes. Note that an immutable intensional definition may still result in an expansion that changes over time if the definition does not explicitly identify the versions of the code systems that it references, thus an isImmutable property set to TRUE will not necessarily make a Value Set expansion unchangeable over time. Therefore, to completely freeze a Value Set expansion, it must have the isImmutable property set to TRUE and the definition must either be Extensional or Intensional where reference is only to specific versions of the underlying code systems.

An HL7 Concept Domain is a named category of like concepts (a semantic type) that is specified in the Vocabulary Declaration of an attribute in a information model or property in a data type, whose data types are coded or potentially coded, and may be used in a Context Binding. Concept Domains exist to constrain the intent of the coded element while deferring the binding of the element to a specific set of codes until later in the specification development process. Thus, Concept Domains are independent of any specific vocabulary or Code System. Concept Domains are hierarchical in nature, and each hierarchy represents a constraint path from a broader to a narrower semantic category. In HL7's base models – the RIM and the Abstract Data Types specification – all coded elements are tied to these abstract definitions of the allowed types of concepts.

The deferral of the association between a coded element and its allowed coded values is useful because it may not be possible to achieve consensus on the Value Set to be used within a model at the level at which the model is being developed. For example, it may be possible to gain international consensus on messages for submitting insurance claims for health care services. However, gaining international consensus on a single set of billing codes is unlikely any time soon.

Concept Domains are universal in nature (independent of any Binding Realm), so the name for a Concept Domain should never contain any reference to a specific Binding Realm. Concept Domains are also present to permit binding to more than one specific terminology (in general), so the names also should not contain a reference to a specific coding system. Concept Domains are registered with HL7 International: they are proposed as part of the HL7 standards development process and are approved by the RIM harmonization process. Both processes are described in the HL7 Development Framework (HDF).

A Concept Domain is documented by specifying a name and a narrative definition. In addition, at least three concept examples that represent possible values for the attribute or data type property are required to illustrate the semantic space. [5] The examples should represent concepts that characterize the intent and purpose of the Concept Domain. This can be accomplished in one of the following ways:

  • Including three example concepts as part of the narrative definition;
  • Context Binding the Concept Domain to a Value Set that contains at least three example concepts in the context of the Example Binding Realm; or
  • Context Binding the Concept Domain with a Value Set that contains a set of concepts which completely cover the intended meaning of the domain, using either the Universal or Representative Binding Realm as a context.

The Concept Domain named 'HumanLanguage' carries the description, "Codes for the representation of the names of human languages". The set of concept identifiers that represent different human languages can be drawn from different Code Systems, depending on which Binding Realm or sub-Binding Realm is creating the message. For example, the United States Binding Realm may choose to use a Value Set that includes concept identifiers for various Native American languages, while New Zealand may find such a Value Set inappropriate.

 5.1.4.2Sub-Domains

One Concept Domain may be defined to be "sub-domain" of another. This means that the intended meaning and reference of the sub-domain is intended to be narrower than the meaning of the parent. For example, there is a domain ObservationMethod, with a sub-domain of GeneticObservationMethod. This is not intended to be an ontological assertion; its primary purpose is to indicate that all of the coded identifiers in a Value Set that is associated with the sub-domain should also be valid identifiers for the parent domain, though the reverse may not be true.

A Binding Realm refers to a named interoperability conformance space, meaning that all information models within a particular Binding Realm share the same conformance bindings. In non-technical terms, it can be considered a dialect where speakers use the semantics of the language but agree to use certain terms that are specific to their community; it is a context of use for terminology in HL7 models. Binding Realms may be defined by jurisdictional boundaries and are often HL7 Affiliates, or sub-national jurisdictional entities within the Affiliate purview. Binding Realms may also be based on other factors such as type of patient (e.g. human vs. veterinary, pediatric vs. geriatric), type of medicine (e.g. dentistry vs. psychiatry), etc..

The Binding Realm is in effect for each section of the instance where it is declared. For example a message or document might declare one Binding Realm for the 'root' of the instance, and may declare a different Binding Realm for some fragment within the instance. All model instances must declare a particular Binding Realm (or sub-Binding Realm) based on the context used to determine the terminologies for that instance or instance fragment. A Binding Realm is used to provide and manage the bindings of Value Sets to reflect rules within the interoperability conformance space.

Each Binding Realm has a unique code and is under the stewardship of either HL7 International or an HL7 Affiliate. For example, the Binding Realm Germany has a code of DE, and the steward is HL7 Germany. The set of all Binding Realm codes is maintained by HL7 International. In order to enable conformance, the Binding Realm, declared in the RIM in InfrastructureRoot.realmCode, is in effect for each section of the instance where it is declared. In the interest of maximizing interoperability, interoperability spaces should be as large as practical: Binding Realms are preferred to be large-grained. As an extreme, if each hospital department had its own Binding Realm, chances for semantic interoperability would be very low.

Binding Realms can be defined as a poly-hierarchy where broad Binding Realms might be sub-divided into narrower, more precise Binding Realms. For example, a Binding Realm of "Canada Human Dental" might be a sub-Binding Realm of both "Canada Dental" and "Canada Human", which would in turn be sub-realms of "Canada" which is itself a sub-realm of Universal. This hierarchical structure reflects the relative containment of the interoperability spaces being defined and allows for consensus on different types of codes at different levels of the interoperability environment. The hierarchical relationship between sub-Binding Realms is determined by the Affiliate responsible for those Binding Realms.

A number of Binding Realms exist by default (declared by HL7 International), including Affiliate Binding Realms (a new Affiliate Binding Realm is established by HL7 International every time a new Affiliate is recognized). Each HL7 International Affiliate has authority for the Binding Realm bounded by geographic scope of the Affiliate.

Following are the types of Binding Realms defined and used by HL7 International:

A Affiliate Binding Realms is defined as a Each HL7 International Affiliate has authority for the Binding Realm bounded by geographic scope of the Affiliate.
A Sub-Binding Realms is defined as a In some circumstances, an HL7 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 (e.g., regions, states, provinces, etc.) or by type of implementation (e.g., human vs. veterinarian, etc.). Sub-Binding Realms can only be created by HL7 International Affiliates.

Sub-Binding Realms have the same steward as the affiliate that maintains the parent Binding Realm. Because the purpose of sub-Binding Realms is to allow the use of different Value Sets for the same specification within an Affiliate, they can cause interoperability issues within the Affiliate. They should therefore only be introduced after careful consideration of the interoperability consequences.

A Combination Binding Realms is defined as a These are Binding Realms created by one or more HL7 International Affiliates as a combination of the Binding Realms of each of the separate Affiliates. Any Binding Realms may be combined for such a purpose to make an interoperability space that extends across affiliate realms. The HL7 International Affiliates who agree to do so are the joint stewards of the combination Binding Realm. Some examples of this could be "North America" (combining the US and Canada), or "Southern Europe" combining several European Affiliates.

Four Generic Binding Realms

In addition to Affiliate Binding Realms, four Generic Binding Realms have been defined that are not specific to an HL7 International Affiliate (or to a delegated subset or coordinated alliance of HL7 International Affiliates). These Generic Binding Realms should not appear in "production" model instances that are in use in implementations. They are only used in the standards creation and documentation process.

These Generic Binding Realms should never be referenced directly in an instance. They have no "parent" Binding Realms.

A Universal Binding Realm is defined as a The Universal Binding Realm constitutes the core HL7 Binding Realm that is, by definition singular and fixed, and is the "root" Binding Realm for all other Binding Realms. Structural elements (e.g., Act.classCode) and most data types are examples of content in this Binding Realm. Content from domain technical committees is rarely included in the Universal Binding Realm and, when introduced, must go through special processes to ensure full international consensus on the universal constraint to a single binding.

All Binding Realms that are defined in an instance are in a tree whose topmost root parent is the Universal Binding Realm.

A Representative Binding Realm is defined as a The Representative Binding Realm exists for bindings that are intended to be to complete and implementable Value Sets and that properly represent the coded coverage of the semantic space defined by the Concept Domain. Unlike universal bindings, there is no expectation that all (or any, necessarily) affiliates will choose to adopt the Representative Binding Realm bindings. Representative Binding Realm bindings provide a starting point and a focus for consensus, while recognizing that cultural and political variations between HL7 International Affiliates may result in alternative bindings. To qualify for Representative Binding Realm designation, candidate content must be sufficiently comprehensive and internally consistent to be adoptable and implementable by specialized Binding Realms. A Representative Binding Realm has no official force in an affiliate unless the affiliate chooses to adopt it with an Affiliate-specific binding; it is not used in specific conformance claims. When an Affiliate does choose to use a binding from the Representative Binding Realm, the binding definition is copied into the Affiliate Binding Realm: there is no persistent link that may result in unintended cascading changes.

The Representative Binding Realm should never be referenced in an instance. It has a "parent" Binding Realm of Universal.

A Example Binding Realm is defined as a The Example Binding Realm is used for bindings to Value Sets 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: a Concept Domain definition must include three examples. They may also be used in the construction of Binding Realm-independent example instances, and as examples in published documents, manuals, and presentations. Example Binding Realms are not generally needed when appropriate Representative Binding Realm bindings exist.

The Example Binding Realm SHALL only be referenced in example instances. It has a "parent" Binding Realm of Representative.

A Unclassified Binding Realm is defined as a The Unclassified Binding Realm accommodates content that is new and in the process of being refined, as well as legacy content that has not yet been promoted to its destination Binding Realm and is still undergoing development work. The Unclassified Binding Realm may also serve as a transition point for content contributed from other Binding Realms. The Unclassified Binding Realm exists for HL7 administrative purposes and has no effect on implementations. This is intended as a temporary state, and items bound to the Unclassified Binding Realm should be either removed or promoted to a non-temporary Binding Realm as quickly as is feasible.

The Unclassified Binding Realm should never be referenced in an instance. It has no "parent" Binding Realm.

A key aspect of interoperability specifications is the ability to define conformance expectations. Conformance expectations allow authors of RFPs or similar requests to express exactly what they expect a system to be able to do. Similarly, they allow software vendors to identify exactly what a system is capable of doing. Finally, detailed documentation of conformance allows the comparison of the profiles of sending and receiving applications to identify how well they will inter-operate.

Vocabulary Conformance is the documentation that identifies the expected behavior of a system in handling different coded values. For sending systems, the behaviors can be categorized into supported vocabularies (those that can be captured and transmitted) and non-supported vocabularies (those that cannot be supported or captured). For receiving systems, the non-supported vocabularies can be sub-categorized further into non-permitted vocabularies (those codes that might result in an error if they are received) and ignored vocabularies (those codes that will be accepted without generating an error, but will not be persisted or otherwise processed). Finally, particularly in higher level specifications, conformance expectations might be unspecified, i.e. implementers have the choice of whether to support a given code or not, or to defer the detailed specification of the expected system behavior to a downstream document.

For example, if a transmitting system supports a given code (and therefore might transmit it), there will be different interoperability implications depending on whether the receiving system also supports the code, ignores the code, or might raise an error when receiving the code.

Testing of interoperability is limited when specifications include aspects where the conformance expectations are unspecified. By the time a model or data type specification has been constrained down to an implementable level, coded elements must be associated with an exact set of permissible concept codes that may be carried in those elements, i.e. there remain no codes which are ‘conformance undeclared'. HL7 Vocabulary Conformance provides a specific description of the expected behavior of the application for codes both within and outside the set of permissible codes.

There is a collection of conformance criteria that enable Vocabulary Conformance. These criteria are implemented with Vocabulary Declarations and Value Set Assertions, and consists of specifying Concept Domains, Coding Strengths, Value Sets, and Stability Levels, as described in the following sections.

When HL7 structural information models and data types specifications are designed, coded elements must be associated with a specification identifying what type of vocabulary is allowed to be used in the coded expressions for those elements. The specification is known as a Vocabulary Declaration. The Vocabulary Declaration identifies the constraints on the coded expressions that can be used as well as the vocabulary conformance expectations for implementers of the data element. A Vocabulary Declaration is the semantic constraint for a coded model element or data type property. Every coded element (or potentially coded element – e.g. Observation.value with a data type of ANY) must declare the type of vocabulary expressing the semantics allowed for use in that data element. This may be done in one of three alternative ways:

  1. A reference to the Concept Domain that defines the category of concepts that can be used for the element without defining the specific codes to be used. This is done by specifying the name of the Concept Domain.
  2. A reference to a Value Set Assertion that defines Value Sets as well as other information such as conformance expectations around the use of them. The specific data elements included in a Value Set Assertion are listed below (see § 5.2.2.4).
  3. A reference to a specific fixed code within a specific code system that acts as the fixed value for the coded element. This is done by specifying the code and either the code system UID or code system name as it exists in the HL7 OID registry. In some cases, the Code System version might also be specified to ensure that the semantics associated with the single code do not ever change.

As mentioned previously, the HL7 RIM and Abstract Data Types specify Concept Domains for all coded elements. When derived HL7 information models are produced, the modelers determine how to handle the vocabulary constraint for each coded element. The rules for what may be done further with the constraint in the Vocabulary Declarationare as follows:

If the parent model has a Vocabulary Declaration of a Concept Domain (1 above), model developers may choose to:

  • Do no further constraining - retain the Concept Domain that was specified in the Vocabulary Declaration for the coded element in the parent model; or
  • Substitute a sub-domain of the Concept Domain in the Vocabulary Declaration of the parent model, thereby restricting the possible values that can go in the associated coded element; or
  • Create a Model Binding (see § 5.3.1) for the element by replacing the constraint with one or more Value Set Assertions, indicating that the codes (or code expressions) resulting from expanding the Value Set(s) in the associated Value Set Assertions must be used in this particular model.

    If a Context Binding (see § 5.3.2) exists in the Binding Realm expected to be used for the model for the Concept Domain being replaced with this reference to Value Set Assertions, the new Value Set Assertions must be the same set as that referenced in the Context Binding or a proper constraint on it;

    or
  • Create a Single Code Binding for the element by replacing the constraint with a single code from a specified Coding System.

    If a Context Binding exists for the Binding Realm expected to be used for the resulting model, the selected code must be one of those allowed within the Value Set Assertion that is specified by the Context Binding.

Note that the first two above are constraints on Concept Domains. The other two involve replacing the Concept Domain constraint in the Vocabulary Declaration with a Value Set Assertion or a single code constraint. These latter two approaches should only be used for elements that are bound in the Universal Binding Realm when creating HL7 UV (universal) specifications. If a Universal Context Binding does not exist, the International Council must be consulted before Value Set Assertions or single-code bindings are asserted.

If the parent model has a Vocabulary Declaration of a list of Value Set Assertions (2 above), one may choose to:

  • Retain the list of Value Set Assertions that was specified in the parent model; or
  • Substitute a list of Value Set Assertions that is a proper constraint (a narrower set) on the parent model's Value Set Assertion list; or
  • Bind the element with a single code from a coding system. The code must be one of those allowed by the Value Set Assertion of the parent model.

If the parent model has a Vocabulary Declaration of a single code (3 above), the derived coded element must reference only that specific code; no further constraint or modification is permitted.

When a model has not been constrained further than a Vocabulary Declaration containing the name of a Concept Domain (it cannot yet be implemented until a Vocabulary Binding is asserted), a further piece of information may be included in the Vocabulary Declaration by the model designers: Terminology Guidance. Terminology Guidance in a Vocabulary Declaration provides information on assumptions made as part of the model design about the characteristics of terminologies that would be appropriate for this element. It may be prose advice, or it may go as far as advocating a specific terminology for use in this element in this model for implementation, where failure to adhere to this guidance may render the model unsafe for use (the semantics may be ambiguous or incorrect). Its primary purpose is to inform the later creation of a Binding where the model's semantic integrity is believed to be dependent upon a particular terminology to be used in the specified coded model element.

A Vocabulary Declaration is thus made up of one of either of the following components:

  • A Concept Domain reference (by name), which may optionally include Terminology Guidance (name of code system or other guidance);

- or -

  • A Vocabulary Binding (a list of Value Set Assertions or a fixed single code).

A Value Set Assertion is the mechanism to express the coded vocabulary constraint for a coded model element or data type property. It defines the Value Set Expansions for the vocabulary to be used in a particular coded element or data type property, including conformance conditions around the use of those Value Set Expansions, and whether the collections of codes are always the same, or are changeable. It also defines whether or not the Value Set Expansions may be locally extended. The Value Set Assertion is part of the conformance claim for a model.

A Value Set Assertion declares this information by identifying at least one and up to three Value Sets to be used to define vocabulary conformance for a coded model element: MAX, MIN and IGNORED. The Value Set Assertion also identifies whether the collection of codes defined by processing the Value Set(s) declared in the Value Set Assertion is fixed (i.e. 'locked') or may change over time. This is referred to as Stability Level and there are two kinds: Static Stability and Dynamic Stability. These make use of a time stamp known as "Static Date". Finally, the Value Set Assertion defines the Coding Strength of each of the Value Sets identified; these are described in detail below.

A value set assertion has at least one required value set declared; it is mandatory. This is the MAX value set (see above and § 5.2.3). It may have up to two additional Value Set(s) also declared, for the MIN and IGNORED (see above and § 5.2.3). The identification of the value set is done using the UID or the name of the Value Set.

For each of the Value Sets that are declared in the Value Set Assertion the optional version of the Value Set may also be declared. As value set definitions may change over time, this permits the Value Set Assertion to declare a specific persisted version in a set of versioned definitions, if desired. This is an optional parameter.

For each of the Value Sets that are declared in the Value Set Assertion, the Coding Strength must be declared for that Value Set.

When referencing a Value Set in a Value Set Assertion, there needs to be an indication of Coding Strength. There are two possible values: CWE(Coded With Extensibility) and CNE (Coded with No Extensibility).

Coded With Extensibility (CWE) means that the set of codes resulting from processing the components of the Value Set Assertion is not necessarily complete for its intended use-case. There may be some concepts that need to be communicated that cannot be represented within the Value Set Expansions of the Value Set(s) specified in the Value Set Assertion. Implementers therefore have permission to send local codes or original text within the coded element if an appropriate code cannot be found within the resolved Value Set Assertion. There is, however, an expectation on implementers to feed back these "missing concepts" to the maintainers of the Value Sets or referenced Code System(s) to have the necessary concept added and to transition to the 'official' code when one is added.

Coded with No Extensibility (CNE) means that the Value Set Expansion is considered to be complete for the intended model use. Populating local codes or free text in non-null coded elements model element to which it is bound is not permitted. (Local codes and free text can still be used if the coded element has a null flavor of OTH – Other.)

When creating a "constrained" Value Set Assertion based on another Value Set Assertion, the Coding Strength of any of the referenced Value Sets may be tightened from CWE to CNE.

Code Systems and Value Sets change over time. When defining Vocabulary Conformance a key decision to be made is how stable the collection of concepts in a Value Set Expansion is over time so that it can be measured, and conformance can be precisely specified. The mechanism to accomplish this is to define a Stability Level as part of the conformance criteria. The Stability Level applies to all Value Sets in the Value Set Assertion. There are two different stability levels:

A Static Stability is defined as a Static stability means that the processing of the Value Set(s) identified in the Value Set Assertion results in a fixed list of concepts (Value Set Expansion) regardless of when the processing takes place in time. The expansion is determined by evaluating the referenced Value Sets (MAX, MIN and IGNORED) as of a particular date and generating their expansions. This includes determining the Value Set versions (if not explicit in the Assertion) as well as the versions of all Code Systems referenced by those Value Sets, including Value Sets embedded in intensional definitions. As a result, the expansions of the Value Sets declared in the Value Set Assertion do not change automatically as the Value Set definitions and underlying Code Systems are changed, and the Value Set Expansions may be included in an implementation guide. A Value Set Assertion has static stability when it includes a Static Date.

For references to specific codes, the reference is considered to be "static" if it includes the Code System Version, which is expressed in the Value Set Assertion as a date. Static references to fixed codes are only necessary if there is concern that the meaning of the code may change in the Code System over time.

A Dynamic Stability is defined as a Dynamic stability means a Value Set Assertion does not have a Static Date. As a result, the allowed values for a coded item automatically change as the Value Set definitions or their underlying Code Systems (or included nested Value Sets) are maintained over time. This means that the binding is to the most current version of the Value Set Definition available. The documented or persisted expansions of the Value Sets declared in the Value Set Assertion must always be checked for currency before use when evaluating a binding with dynamic stability, as changes to underlying code systems referred to in the Value Set Definition may imply changes requiring a new generation of the expansion before use. Note that it is possible to have a Value Set Assertion that references specific versions of one or more of the referenced Value Sets. Similarly, intensional Value Sets may be constructed with other Value Sets that might also reference explicit versions. However, because not all versions of all Code Systems and Value Sets are "locked", the binding would still be considered to have dynamic stability. In theory, all referenced Value Sets and all referenced Code Systems could all include their respective version references in the Value Set Definition, which would accomplish the same objective as binding with static stability – a fixed expansion at all points in time. However, because no Static Date would be present in the list of data items defining the Context Binding, the binding would still be identified as having dynamic stability.

A Context Binding (see § 5.3.2 below) listing Value Set Assertions with dynamic stability may be constrained to having static stability by asserting a static binding date (or for single codes, by asserting a Code System Version).

A Value Set Assertion is expressed via the following ten (10) elements:

  • MAX Value Set UID and/or name (mandatory)
  • MAX Value Set version date/time (optional)
  • MAX Value Set Coding Strength (CNE or CWE – mandatory)
  • MIN Value Set UID and/or name (optional)
  • MIN Value Set version date/time (optional)
  • MIN Value Set Coding Strength (CNE or CWE – conditional)
  • IGNORED Value Set UID and/or name (optional)
  • IGNORED Value Set version date/time (optional)
  • IGNORED Value Set Coding Strength (CNE or CWE – conditional)
  • STABILITY StaticDate (optional)

Note that a Value Set version date or time SHALL ONLY be specified if the Value Set UID is specified. The Coding Strength for a Value Set SHALL be specified if the Value Set UID is specified. Note also that Coding Strength is defined separately from the Value Set only to simplify maintenance. The same Value Set Definition might be used in multiple circumstances where different Coding Strengths would be required. Combining Coding Strength into the definition of the Value Set would consequently require potentially doubling the number of Value Sets that must be maintained.

The mechanism for defining conformance with vocabulary includes the specification of 3 sets of code collections: MAX, MIN and IGNORED. This mechanism functions as follows:

  • The maximum Value Set (MAX) contains all concepts explicitly supported for the model element. This principal Value Set for the binding is required in the Value Set Assertion. Its purpose is to define the set of codes that have appropriate meaning within the Use Case that the associated model element is (or elements are) to be used for. No concepts may be populated in a conformant coded model element that are not included in the Value Set Expansion of the bound MAX Value Set unless the element has explicitly declared extensibility CWE with the Coding Strength (see above).

    If the MAX Value Set has a coding strength of CNE, then no codes outside the MAX Value Set can be used unless the coded element has a null flavor of OTH. If the MAX Value Set has a coding strength of CWE, then additional codes are permitted, but those codes cannot be used for concepts that are represented by codes within the MAX Value Set.

    For example, if the MAX Value Set were specified as "All codes from ISO 639-1", it would be acceptable to have a local code for some local language dialect that is not listed in the ISO 639-1 Human Language Code System. However, it would not be acceptable to send a local code for "English", or even the more refined concept "English – Brooklyn slang", because the concept for "English" is represented in ISO 639-1 with the code "en". (However, a translation from "en" to a local code conveying the more detailed semantic of "Brooklyn slang" could also be sent.)

    In many circumstances, the MAX Value Set might be the only one used. In this case, the contents of the MAX Value Set would be considered "conformance undeclared" (all of these codes are permitted but are optional). In situations where more detailed system behavior relative to conformance must be expressed for the vocabulary, such as when making the final implementation profile where all optionality has been removed, up to two additional Value Sets may additionally be specified: MIN and IGNORED

  • The minimum Value Set (MIN) whose expansion contains those concepts that must be supported by conformant applications, and used in some useful manner by the systems sending, receiving, or otherwise processing the model element. This MIN Value Set, also known as the 'required' Value Set, may be optionally identified in the binding statement; if not present, there is no MIN Value Set, and there is no lower boundary on how much the MAX may be further constrained to a smaller set of concepts for locally declared conformance claims. The MIN and the MAX may be the same Value Set, which means that all of the concepts in the expansion are required to be supported.

  • The ignored Value Set (IGNORED), which is a Value Set whose expansion contains concepts that are identified as not used in any useful manner by a system sending, receiving, or processing the model element, but if sent must not cause an error to be raised.

The MIN and IGNORED Value Sets must be proper subsets of the MAX Value Set (i.e. MIN and IGNORED cannot contain any codes that are not part of the MAX Value Set). In addition, the intersection of MIN and IGNORED must be empty – there cannot be any codes that appear in both MIN and IGNORED. Note that additional care must be taken in circumstances where the MIN and/or IGNORED Value Sets are defined Intensionally (with an expression) and without referencing a specific Value Set version. If the expressions of either of these two Value Sets are revised such that they overlap or they contain codes that are outside the MAX set, then the Vocabulary Binding is invalid and expected system behavior must be negotiated on a site-to-site basis.

Like the MAX, MIN and IGNORED also have a Coding Strength. However, to respect the rules above, there are dependencies between the Coding Strength of MIN and IGNORED and the Coding Strength of MAX. Specifically, if MAX is CNE, then MIN and IGNORED SHALL be CNE. If MAX is CWE, then either MIN or IGNORED >MAY be CWE (but both must never be). And it is acceptable for MAX to be CWE while both the MIN and IGNORED Value Sets are CNE. If IGNORED is CWE, it means that all of the specified 'local' codes will be ignored. If MIN is CWE, it means that all specified 'local' codes must be supported.

The codes that exist within the maximum Value Set (MAX) but do not exist in MIN or IGNORED are considered to be conformance undeclared. This collection of codes may be further constrained (making them either required, not permitted, or ignored) by defining constrained value sets derived from those in the Value Set Assertion and moving codes to the MIN or IGNORED value sets, or removing them from the MAX, and creating a new Value Set Assertion for this tighter constraint. As a specification is tightened and approaches an implementation profile, the MIN and IGNORED Value Sets will tend to increase in size and the MAX Value Set may decrease in size such that, for a complete implementation profile, the union of the MIN and IGNORED Value Sets will contain the same set of codes as the MAX Value Set.

The implementable profile SHALL have no remaining conformance undeclared codes (see Implementable profiles in the Overview section of HL7 Refinement Constraints and Localization, Release 2. for information on implementable profiles). This implies that for a fully conformant model instance, no sending system may have a coding strength other than CNE for coded elements, the MAX Value Set is exactly equal to the union of the MIN and IGNORED Value Sets, and the intersection of the MIN and IGNORED Value Sets is null. Note that receiving systems may have coding strength of CWE for their coded element Value Set Assertions.

When creating constrained artifacts, including Binding RealmContext Bindings (where a binding in the Universal Binding Realm or other higher-level binding exists) and constrained information models, the Value Set bindings must represent a narrowing of the content of the higher level Value Set. This implies that no concept code contained in the resolved Value Set is not also in the higher level Value Set. This can be summarized by the following rules:

  • When constraining, the MAX Value Set may be left the same or made narrower;
  • The MIN Value Set may be left the same or made wider (i.e. concept codes that are not contained within the resolved MIN Value Set may be added, but the added codes must be contained in the resolved MAX Value Set);
  • The IGNORED Value Set may be left unchanged, or made wider;

At all times the sets of concept codes in the resolved MIN and IGNORED Value Sets are mutually exclusive and must be proper subsets of the set of concept codes in the MAX Value Set Expansion.

This process is illustrated in the following diagrams. The upper case letters A-J, and 'Local-1' and 'Local-2' represent concepts that are identified in the formalisms for defining Value Sets:

Use of MIN, MAX, and IGNORED in Value Set Assertion

In these diagrams, the MAX value set is shown in yellow. The big yellow oval shows the complete set of allowed codes (including any CWE content). The smaller dashed circle shows the set of codes explicitly defined within the MAX Value Set that the implementers are constrained to use. The MIN and IGNORED sets appear in green and pink, and in the last diagram, the IGNORED Value Set is also CWE, with an outer solid-lined ellipse showing the total set of codes that will be ignored, while the inner dashed ellipse shows the codes explicitly within the IGNORED Value Set.

The purpose of having a coding strength of CWE on both the MAX and IGNORED Value Sets in the Value Set Assertion is the result that errors will not be triggered by any codes that are sent, but codes that are not explicitly identified in the MAX, MIN, and IGNORED value sets will not be processed.

The complexity of strict vocabulary conformance declarations is not needed by everyone. For some specifications, even agreeing on a set of permitted codes is a challenge. Nailing down exactly which codes all systems must support may not be achievable. This will be particularly true for vocabularies selected at the international level. In these circumstances, the MIN and IGNORED Value Sets will generally be left unspecified.

The purpose of these additional Value Sets is to make it clear exactly which of the allowed codes must be fully supported by applications claiming conformance with a specification and to define how non-supported vocabulary will be treated. For example, must an application be capable of sending or receiving and processing every single ICD10 diagnosis code, or can it restrict to some subset and ignore or even reject others? Being able to differentiate expected receiver behavior for "non-supported" codes is important when defining interoperability. An application that rejects non-supported codes will have a very different effect on runtime behavior than an application that ignores non-supported codes. Because of this, the capability of defining the MIN and IGNORED Value Sets must be part of the methodology.

Vocabulary Binding is the mechanism of identifying specific codes to be used to express the semantics of coded model elements in HL7 information models or coded data type properties. Vocabulary Binding may bind the coded element or data type property to a single fixed value code, or may bind it to a Value Set Assertion. The description of the collection that is bound, along with parameters controlling other aspects of the use and stability of the collection, are called a Value Set Assertion (described in the preceding section). Vocabulary binding is required to specify Vocabulary Conformance (described above).

There are two approaches for Vocabulary Binding: Model Binding and Context Binding.

Model Binding is directly binding a coded attribute or data type property to a list of one or more Value Set Assertions or fixed codes in the Vocabulary Declaration for the coded element. A Model Binding is performed when the Concept Domain referenced in the Vocabulary Declaration is replaced with the list of Value Set Assertions or a fixed single code. Note that binding to a single code may only be used for Model Binding, and the binding may only be to one code; if a tree of codes or other type of collection is desired, then the collection must be defined with a Value Set and be bound using a Value Set Assertion.

A single Model Binding consists of either a single code reference, or a sequenced list of Value Set Assertions. If the Model Binding is to more than one code, it consists of sets of the following four arguments (generally only one however), contained in the Vocabulary Declaration of a coded model element or data type property:

  • Value Set Assertion (required);
  • effective date (required);
  • end date (optional);
  • sequence (optional).

When the Model Binding is to a single code, the Vocabulary Declaration contains one set of the following four arguments:

  • Code (required)
  • Code System (required)
  • effective date (required);
  • end date (optional);

Context Binding is the association between a Concept Domain, a Binding Realm, and the Value Set Assertion published separately from information models and data type specifications that reference those Concept Domains. Context Binding is used when the Value Set Assertion to be used for a particular instance of the model is not known at model design time. Because the Binding Realm associated with the instance is identified within the instance, it is possible for a receiver of an instance who knows the model specification (and thus the Concept Domain) to determine the appropriate Value Set Assertion to validate against. The Context Binding may be a relation between a single Concept Domain, Binding Realm, and Value Set Assertion, or it may be a list of these relations where the only argument in the list that varies is the Value Set Assertion.

It is important to understand that after an HL7 V3 model is complete and has been approved it may still not be implementable, as certain coded attributes may not have been constrained beyond Concept Domains (to be implementable, every coded attribute must be bound to a Value Set Assertion of permissible codes). Context Binding is the mechanism whereby an abstract model specification can be made implementable by decoupling the Value Set Assertion specification from model development. A key characteristic of this type of Binding is that different Binding Realms may specify different Value Set Assertions to be used with the identical information model. Note also that while a Model Binding constrains a single coded model element in a particular model everywhere that particular model is used, a Context Binding binds Value Set Assertions to a single Concept Domain, which may be associated with more than one coded model element in more than one model (but within the scope of a single Binding Realm). A Context Binding is valid for all models in use in the Binding Realm in which it is asserted, and all those coded model elements whose Vocabulary Declaration identifies that Concept Domain. This ensures consistency of vocabulary across multiple independently-authored models.

Implementations make use of the hierarchical nature of Binding Realms to determine the specific Value Set Assertion. Specifically, for each Concept Domain for which there is a need to determine the associated code collection, processing must start with the Binding Realm declared at that point in the model instance. If no Context Binding is found for that Binding Realm, the parent of that Binding Realm in the hierarchy is examined, and this continues up the tree, until a binding is found. The top of the tree of all Binding Realms is the Universal Binding Realm. For example, if the Binding Realm is "Canada Human Dental" and no binding exists, the application would then check "Canada Dental" and "Canada Human", then "Canada", then "Universal".

If no Context Bindings are found as this path is traced upward through the tree of Concept Domains, the Concept Domain specified in the model for this coded element is considered un-bound. The determination of the codes to use remains subject to site-specific negotiation until an applicable binding is created universally or for that Binding Realm. Conformance claims cannot be made for coded model elements whose Vocabulary Declarations are not constrained beyond Concept Domain and the Concept Domain remains unbound.

Affiliates must take care to ensure that there is no situation where a Binding Realm has multiple parents and a binding exists for the same Concept Domain for more than one of those parents. If this situation occurs, which binding applies is undefined and must be negotiated by site-specific agreement. (This is a good reason for affiliates to be extremely cautious when introducing poly-hierarchies into their Binding Realm definitions.)

The constraint mechanism to produce the hierarchy of Binding Realms also has the effect that any Context Binding for a given Concept Domain must be a proper constraint on any Context Bindings for the same Concept Domain for Binding Realms that are ancestors of the Binding Realm in the current binding. For example, if a Context Binding exists for the Concept Domain AddressPartType in the Australian Binding Realm, the Value Set Assertion must be a proper constraint on the Universally bound Value Set Assertion for the Concept Domain AddressPartType.

A Context Binding may go into effect at some time subsequent to publishing the document containing the conformance bindings (generally published by some Binding Realm authority), so therefore also may contain an optional effective date and end date.

A Context Binding also may optionally include a sequence number to differentiate and prioritize the entries in a Context Binding that has a list of Value Set Assertions, rather than a single one. Some jurisdictions may have a statutory need to define alternative Value Sets that are context bound. For example, in some areas of Canada, the regulatory environment dictates that a sender may identify a diagnosis with either a SNOMED-CT code, or an ICD10-CA code, however the systems must always use either one Value Set or the other. The sequence number also serves to identify which of the alternatives are 'preferred'.

A single Context Binding consists of generally only one, but possibly a (sequenced) list, of sets of these six arguments:

  • Context Domain or sub-Domain (required);
  • Binding Realm (required);
  • Value Set Assertion (required);
  • effective date (required);
  • end date (optional);
  • sequence (optional).

It should be noted that a Context Binding cannot be to a single code (unlike Model Binding). If there must be a binding to a single code, then a Value Set Assertion whose expansion contains only that single code must be defined, and used in the Context Binding statement. Also note that the Value Set Assertion itself consists of a minimum of 2 and up to 10 individual items. If a Context Binding exists which specifies UV (universal) as the Binding Realm, any bindings in other binding realms are constrained to drawing from the set of codes permitted by the Universal binding.

The distinction between Model Binding and Context Binding affects the timing of activities, represents a different scope for the binding, and is driven by the fact that complete consensus for the use of specific vocabularies everywhere is often unachievable despite the desire to standardize terminologies at the international level. Model Binding is performed by model developers, and it pertains to all uses of the specific coded elements in the model universally. Context Binding is performed by the Binding Realm authority, and it pertains to all coded model elements using the Concept Domain in any model or artifact within the Binding Realm.

The precise human-readable syntax for the persistent data expression of the Binding (including Vocabulary Declarations and Value Set Assertions) is determined by the Implementation and Conformance work group; there is a current joint project between Vocabulary and I&C to define the form for this. It is a deliverable for this joint project, and will be documented in the V3 Ballot Foundation Section, Refinement, Constraint, and Localization chapter, Conformance subsection, and replaces earlier draft syntax examples in older ballots of this document. Note that there is a machine-processable syntax for representing Binding in the MIF.

HL7 International Concept Domains and Value Sets will be named according to naming rules published with the instructions and guidelines for Vocabulary Harmonization. At the time of publication of this ballot, these rules are captured on the HL7 Wiki under Vocabulary, and document the decisions made in recent Harmonization and Working Group meetings. These documented guidelines are intended for Vocabulary Facilitators and may change as the Vocabulary Harmonization process continues to mature. The HL7 Wiki for Vocabulary may be found at HL7 Vocabulary Work Group Wiki Page

Although no longer newly created, historically, HL7 had Value Sets that were called "X-domains". These were typically Value Sets created for structural codes (e.g. ActClass, EntityDeterminer) and consisted of an arbitrary list of codes that did not represent any semantic grouping in the code system. The naming convention for such Value Sets was to prefix them with "x_". As HL7 has clarified its understanding of the various terminology artifacts and developed tooling that allows the various terminology artifacts to be displayed and maintained separately, the need for the term "X-domain" has been eliminated. Therefore, the use of this term is deprecated. There is no longer a requirement to follow a special naming convention when creating arbitrary enumerated Value Sets, though existing Value Sets with the "x_" prefix will likely be retained to avoid issues for artifacts that reference the Value Sets by these names.

The following diagram provides a graphic representation of Code Systems, Concept Domains, Value Sets and their associated properties, along with the other key concepts described above. Note that this is a high-level information model of HL7 Vocabulary that does not show the detailed content and characteristics of each of the main entities; the full detailed HL7 Vocabulary Model is outside the scope of this document. The intent of this model diagram is to illustrate the concepts described above, not to serve as an implementation blueprint. The HL7 Vocabulary Model is published by the HL7 Vocabulary Work Group.

HL7 Vocabulary Model

At the time of publication of this document, the most complete and correct implementation of the HL7 Vocabulary Model is in the Model Interchange Format (MIF), defined in the mifVocabulary.xsd schema file. For more information, refer to the balloted MIF documents.

This chapter or section contains a set of topics that affect how the HL7 core models relate to each other and how they may be used to address specific representation needs. None of the topics can be readily assigned to a single place in the documentation of the structural and data types models, and each was deemed of sufficient import to warrant an detailed discussion and set of rules within the Core Principles document. The topics, which introduce themselves, follow.

A serialized information model is one that has been transformed to a hierarchical structure according to the rules of an ITS. (See above.) In such a model, every element of the model becomes a child or descendant of the root class of the model in question with the traversal from one class to its descendants occurring along the unblocked associations of the model. In such a hierarchy, the question arises as to which properties of a parent element can be considered to have been conducted to (inherited by) a child element.

For example, if there is an instance of an order made up of a parent order with multiple "component" child orders, and the parent order was "authored" by Dr. Jones, can one safely assume that the component orders were also authored by Dr. Jones? The answer to this question is found in the following "rules" surrounding context conduction.

Note: The RIM has contained a mechanism for specifying context conduction almost since its inception. During 2009, however, it became clear that the mechanism in place was ill-understood, and difficult to use, with the result that it was frequently ignored or misused. After reviewing proposals to correct or replace the prior mechanism, that mechanism was deprecated in March 2010, and the mechanism described here was adopted for use with all future models.

The rules surrounding vocabulary-based context conduction, as newly defined, center around the following definitions and principles:

  1. context — the context of particular Act is defined as the set of ActRelationship and Participation relationships that are properties of that Act, whether they stem directly from the Act in question or were conducted to it across an ActRelationship leading into the class.
    [Note: discussions of this topic at one time included attributes of the Act with "isDocumentCharacteristic=true" as part of the context. The definitions as adopted in March 2010 do not include these attributes in "context".]

  2. descendant — a descendant class is the one being navigated to along an ActRelationship within the serialization hierarchy

  3. ancestor — the ancestor class is the class from which serialization is proceeding in the association.

  4. conductible context — the conductible context of an Act is that portion of its context that may be conducted to descendant Acts; whether or not a given ActRelationship or Participation of the Act or its ancestors is part of the conductible context of the Act is determined by the value of the "conductible" property of the code asserted for the given element's typeCode.

    The "conductible" concept property is a Boolean whose default value is true. If true, it "indicates that ActRelationships or Participations of the specified type (and any specializations thereof) will normally conduct." Thus, absent a specific declaration, a concept inherits the "conductible" property of the concept that it specializes.

  5. context conduction style — Because extant models cannot be assumed to have adopted the vocabulary-based mechanism of context conduction control that is documented here, each model must identify the style of context conduction that is used for all of its relationships by setting the appropriate value in a new model property "contextConductionStyle" being added to the definition of a serializable information model.

    As defined, the conductionStyle model property SHALL be declared if the model is using the V (vocabulary-based) conduction style as defined here. If the property id unspecified, it defaults to either C (conduction-indicator-based) if the model contains the now-deprecated contextConductionCode or contextConductionInd attributes or I (inferred) if those attributes are not present;

  6. presumption of conduction — Unless otherwise constrained by the following items in this list, all "conductible context" within a model using vocabulary-based conduction is presumed to conduct to descendant acts;

  7. blocking selected context elements — Selected elements of context can be blocked from conduction by listing their type codes in either the ActRelationship.blockedContextActRelationshipType or the ActRelationship.blockedContextParticipationType attribute.

    An element of context is blocked if its type code is listed in the attribute or if a generalization (ancestor) of its type code is listed. All other context elements conduct.

    An element of context that is blocked in an ActRelationship is not part of the context of any descendant class reached through that ActRelationship. It is, therefore, also blocked from the context of descendant classes.

  8. conducted context is not overridden by new context in the descendant classes — In the prior context control structure, one could "override" a particular context element (such as a primary performer) by declaring override context element(s). In the vocabulary-based system, there is no automatic override. Thus, for example, the assertion of a different primary performer for a descendant class simply means that there will be two such performers listed - the conducted performer and the addition. In this example, when using the current (new) context control structure, one can accomplish the equivalent of a participation "override" (from the prior context control structure) by blocking conduction of the "PRF" participation code in the ActRelationship leading to the descendant, and by including a new performer Participation in the descendant. (Note that the new performer then becomes part of the conductible content of the Act for which the performer has been overridden.)

The rules surrounding context conduction of individual attributes of the Act class, as newly defined, include the following definitions and principles:

  1. Selected attributes of instances the Act class may be selected for conduction to other instances of acts connected via ActRelationships by the actAttributeContextBlockedInd attribute of ActRelationship. This attribute defaults to "false". Thus by default the selected attributes conduct.

  2. Selection of attributes which will conduct are determined by the conductible property of these attributes as defined in the RIM. (See RIM section on attribute properties.) At present, only two Act attributes have this property set true: confidentialityCode and languageCode.

  3. Unlike Context Conduction of Class Content, context conduction of selected attribute content can be overridden in an instance. Thus, for example, if there is an Act with its langaugeCode set to "en" (English) in some portion of an instance, and there is another Act (further down in the serialization hierarchy) with languageCode of "fr", the new value overrides the previous one and the child Act is in French and all of its descendants are also assumed to be in French.

HL7 information models are used to represent information about the real world when it is exchanged between systems. The objects in the instance represent real world concepts about which a certain amount of information is known. There are two primary methodologies for dealing with these objects — snapshot and Update Mode — as discussed in the following.

Although complex scenarios involving combinations of these modes can be envisaged, HL7 does not support combining modes in order to reduce processing complexity. If an object is passed as a reference, there SHALL be no expectation that any updates to the object may occur. If an object is represented using update mode, any information provided as part of the object that has no associated update instructions is ignored.

 6.2.1Snapshot

Snapshot is a methodology in which the sending system includes all the data it has into the message with no specific indications of which data items were added, replaced, or removed. The term was chosen because the source system sends a snapshot of the objects as it knows them.

Snapshot is typically used when information is exchanged between systems where the destination system is not known, or where it is not clear how much information the destination system already has about the real world concept.

When a receiving application processes an object that is represented using a snap shot, and it already has information about the real world concept that matches this object, the application should match objects in the instance with the information it already has, and then appropriately process the information from the message to the information it has on file (for instance, in some cases it would make sense to merge all the attributes and associations of the objects).

Potential Advantages:

  • Can be easier for senders to implement
  • Many sending systems implement Version 2 messages in this fashion

Potential Disadvantages

  • Typically more complicated for receivers to process appropriately
  • Easier for relevant data to be deleted

Update mode is a methodology in which the message designer specifies the allowable update mode values for items within the message and the message sender specifies the specific update mode value for items within the message.

In some contexts, the destination system is well known and there is an implicit or explicit contract between the source and destination systems that ensures the information the destination system holds is well known to the source system. In such contexts, it is possible to only send the changes that have occurred on the source system or should occur on the destination system. These changes may be additions, deletions, and revisions to existing data. This practice is known as "update" mode.

Another use for update mode is where the source application includes all the same data items in the message specification as it would for snapshot node, but marks each value for each data item in the message specification that indicates whether it is added, replaces another item, or has not changed.

Where update mode can be used, it offers several advantages. Potential Advantages (depending how it is used):

  • reduced instance size;
  • receiver does not need to compare data to determine what changes the sender has made;
  • where the receiver gathers data from multiple sources, it does not need to store ‘images’ of data received from a particular sender to ensure that it can adequately compare to the previously sent data when determining changes;
  • reduced processing time;
  • simpler implementation of decision making;
  • conveys important information for how the sending system has processed the information; and
  • allows query responses to document accountability information in terms of what changes were performed (See Accountability).

Potential Disadvantages:

  • update mode offers the opportunity for two systems to get information out of sync, (thus so modelers and implementers must always be careful with this); and
  • typically requires additional effort for the source system

The normal mode for V3 instances is snapshot; update mode is only allowed when the constraining model design specifically allows update mode.

Update Control interpretation depends on the context of the message type:

  1. When used in a message driven by a state-transition notification or a state-transition fulfillment request trigger event (where the focal class is an object owned by the sending system), the update control represents the change that occurred on the sending system as a result of the state change associated with the trigger event. The recipient is not bound to make the same changes as those done on the sending system.
  2. When used in a message driven by a state-transition request trigger event (where the focal class is an object owned by the receiving system), the update control represents the change that is desired by the sending system as a result of that trigger event. If the recipient accepts the request, they must make the requested changes.
  3. When used in a query response message, the update control represents the most recent change that has occurred to the sender's object, potentially back to a specified time. The work group design may allow the time from which changes are reported to be specified by a query parameter or fixed by the query definition. If not otherwise specified, the start time is the first time the system became aware of the object.

HL7 provides a single property called updateMode to support the concepts defined in Update Control, Referencing Objects, and Identifying Objects.

Note: a more appropriate name might be useCode, but the property name is updateMode for backwards compatibility reasons.

Note: The updateMode property actually applies to associations and attributes, not to classes and data types, though it is formally defined on the classes.

The value of the updateMode property identifies how the attribute or association contributes to the processing of the instance. HL7 models strictly control the use of the updateMode attribute; it may only be populated with a value that the constraining model allows. If there is no value, then the constraining model should be consulted for guidance on how the instance should be processed.

The updateMode property can have one of the following values in the HL7UpdateMode code system

Notes on these values:

  1. R (replace) and AR (add or replace) may not be applied to multiple attribute values within one of the collection data types (DSET, BAG or LIST). If a single attribute value is marked with a R (replace) is used to update a collection, the single value replaces all the items in the collection
  2. R (replace) and AR (add or replace) may not be applied to multiple attribute values within one of the collection data types (DSET, BAG or LIST). If a single attribute value is marked with a R (replace) is used to update a collection, the single value replaces all the items in the collection
  3. REF (reference) may only be applied to associations, not attributes, because it is intended to refer to a complete object whose type is the type of the association.
  4. U (unknown) is semantically equivalent to a nullFlavor of NI. However due to some methodological issues in V3, a specific code is required in some circumstances.
  5. If an item is deleted from a collection, all matching items should be deleted from the collection

This section is intended for people designing information models, typically HL7 domain work groups.

When designing a model, a committee may allow updateMode to be used on attributes and associations identified by the committee. To enable updateMode, the committee must select the set of permitted updateMode values.

In addition to identifying the allowed set of values, the committee may also choose to identify a default updateMode for the attribute or association. This is the updateMode that will be assumed by the receiver if none is specified in the instance.

The "updateMode" property may not be used to "replace" an identifier attribute (e.g. Entity.id, Role.id, Participation.id, and Act.id attribute). If an identifier was captured erroneously, the incorrect submission should be nullified and the record resubmitted with the correct identifier. If a new identifier has been issued, replacing the old identifier, then the object with the new identifier may supersede or replace the old object.

If no updateMode set is enabled for an attribute or association, it is the same as if the updateMode were set to ‘Unknown’. I.e. the current element value is specified with no indication of whether it was changed or not.

The allowed updateMode value set available for RIM attributes is empty by default. This means that work groups must specifically enable Update Mode by declaring an allowed set of updateMode values within their design for each attribute or association in their DIM where they want them to be used. Once an updateMode set has been defined in the DIM, it must be kept the same or constrained in any derived models (SIM, serialized information models or serialized message models). I.e. updateMode values may be removed from the allowed set, but never added.

If a committee defines updateMode values for a particular attribute or association, implementers must support the allowed update mode set to be conformant. (Failure to support the complete set defined by the committee may result in interoperability problems.) Implementers should be able to document what update modes they support in their conformance profile, but failure to support those identified by the committee that defined the artifact is considered non-conformant.

The committee does not need to define a default updateMode, and may define a default at any derived model. Once a default is defined, it may not be removed or changed in any subsequently derived models. I.e. if a default is defined in a SIM, it may not be changed or removed in SIMs derived from that SIM. Because of this restriction, work groups are discouraged from defining a default updateMode at the DIM level.

Update modes should not be specified in LIMs, as they are intended to be used across multiple different information models that make their own rules about use of updateMode.

Notes:

  1. updateMode is not a concept that should appear in all, or even in most models developed by work groups. It should be treated as an advanced modeling concept’, and only employed in models where the facilitator is certain that the concept is needed to adequately reflect the needs identified by their committee. Furthermore it should only be enabled on those attributes or associations where there is an identified need. When a facilitator has identified a perceived requirement for updateMode in their model, they are encouraged to bring the requirement to the Modeling and Methodology Technical Committee for review.
  2. updateMode will primarily be used for trigger events where the state transition is “revise” and for query responses; however, it may be appropriate in other circumstances. Work groups are encouraged to discuss additional patterns for usage so that they may be reflected in this document.
  3. updateMode should not be enabled in Transmission or ControlAct wrappers or in structured documents.
  4. For a BAG, an update mode of "D" will remove all elements from the BAG that are equal to the provided element. Therefore, there is no way to remove only one of several identical elements from a BAG.
  5. Id attributes should never be sent with an updateMode value of Replace. If such a use-case arises, it will addressed as a future methodology change.

In addition to using updateMode to describe the changes that have happened or should happen, instances can also carry accountability information relating to the information in the message, both associations and attributes. The accountability information can include the time range during which the information was or is valid, and a link to the control act associated with the value. The control act can describe who made the change, when the change was made, what application made the change, and some context for the change in the overall behavioral model.

Generally, this form of accountability history is used in registry-type systems where there is a strong need for the receiver to establish the authority on which a particular piece of data is being changed. Understanding the details can be important in helping a receiver make the determination whether they wish to adopt the change.

Accountability information will be handled by using the History Item (HXIT) generic type extension in the Abstract Data Types. This extension will be applicable to both attributes and to associations. To provide support for accountability information in addition to a time stamps, the HXIT extension was modified in Data Types Release 2 to allow for the presence of either a simple time stamp or a ControlAct.id reference. The reference will allow the changes to an individual attribute or association to be associated with the ControlAct that changed it. The ControlAct can be used to convey such information as event time, author, authoring organization, data-enterer, reason, and any other accountability information deemed to be important.

When working with interactions triggered by a state-transition notification, a state-transition request or a state-transition fulfillment request, the individual ControlAct classes associated with the changes to each attribute or association will be sent as ‘Components’ of the ControlAct in the ControlAct wrapper. When working with query response interactions, the ControlAct classes will be attached to the focal class of the query response via a subject association.

Multiple associations and attributes may reference a single ControlAct, or each may reference a separate one.

Work groups must explicitly enable by exposing the HXIT or HIST extensions for a given attribute or association.

HL7 models do not have to be fully self-contained. There are a number of reasons why it makes sense to split content across multiple models:

  • It allows common content to be re-used
  • It allows models to be "simpler" – easier to maintain and understand
  • It allows committees to draw on resources constructed by other committees who may know a particular content area better

HL7 provides 3 distinct mechanisms for embedding content from one model inside another model: CMETs, Stubs and Model Refs. Each of these mechanisms behaves differently and is appropriate in different circumstances. The following sub-sections provide descriptions of each mechanism and guidance on how and when they should be used.

 6.4.1CMETs

CMETs (Common Model Element Types) [6] (see CMET ballot domain) are common references that are likely to be made by multiple models and where there is a desire for the references to all be consistent within a given release. Examples include such concepts as Patient, Provider, Location, Annotation, etc. CMET references can exist for Act, Entity, Role and "Other" [7] classes. The reference identifies the name of the CMET. CMET names are distinguished from the names of "standard" classes by being prefixed by "A_", "E_", "R_" or "O_", depending upon which base class is associated with the CMET.

The determination of which model a given CMET name points to is determined as part of the release generation process. Each release will have an "interface definition" file (previously known as CMETInfo.txt) that defines all of the CMETs supported in that release as well as what models each CMET should resolve to. If the interface definition file indicates that the CMET R_AssignedPersonUniversal resolves to the model PRPA_MT123456UV, that means that all information models that reference the CMET named "R_AssignedPersonUniversal" will all in practice be pointing to the model PRPA_MT123456UV when published for that release. In the next release, the CMET definition in the interface definition file could be revised to point to PRPA_MT123400UV and all of those same models would use the new binding. No change to the referencing model would be required. Similarly, a realm could define their own interface file, resulting in the use of different information models for CMETs in that realm without needing to update all of the universal models.

 6.4.2Stubs

Like CMETs, stubs allow embedding a reference point in a given model. However, unlike CMETs, the referenced model will not necessarily be the same for all information models within a release. In fact, it will not even be consistent for all of the different places the model is used. Instead, the decision about what model should be substituted in place of the stub reference is determined when the interaction (or document or services definition) is created. For example, the message transport wrapper has a single stub for the "ControlAct" conveyed by the message. There are a number of ControlAct models that could be used. Which one gets used for a particular interaction is chosen by the designer of the interaction. The list of available stubs is maintained within the Interface Definition file.

At the moment, stubs are only used within certain models due to limitations in the "publication data base" software that maintains interaction information. Once this tooling issue is addressed, stubs will be able to appear in other places. For example, a financial claim payload might have a stub for the type of act being billed for. An interaction might even use a stub to allow the interaction designer to choose the type of patient information model to use.

Model references are a new type of reference that is not yet supported by the development tools used to create HL7 Standards in the "Universal" (UV) realm. Model references allow one model to reference another information model directly. Unlike CMETs or stubs, the specific model being referenced is determined by the model designer, rather than by the release manager or the interaction designer. In order to change the information model referenced, it is necessary to revise the information model doing the referencing. This approach gives the model designer very strict control over the content referenced. However, it loses the ability to maintain consistency across a release or variation in behavior across realms or across releases without going in and revising a lot of information models.

The information content of an instance of the Act class (its attributes and associations) constitutes the documentation of a particular Act. Thus there is a distinction to be made amongst the attributes and associations of that documentation. Are they descriptive of the action being documented (such as its time of occurrence or result value) or are they properties of the documentation itself (such as its id or author)? Within the HL7 RIM, this distinction is expressed by the "isDocumentCharacteristic" property assigned to each attribute in the Act specialization hierarchy and to each type code for the associations of the Act (ActRelationship type codes and Participation type codes).

By default, this property is "false." If the the default is overridden and the property is true for any particular attribute or association, then that attribute or association is part of the documentation of the act. Conversely, when the property retains the default (is "false") for a particular attribute or association, then that attribute or association is descriptive of the action itself.

The attributes of Act for which the default is overridden and thus are considered to be documentation of the Act are: moodCode, id, title, text, availabilityTime, confidentialityCode, levelCode, uncertaintyCode, languageCode, and (from class ContextStructure), setId and versionNumber.

Phrased another way:

  1. Attributes and associations with "isDocumentCharacteristic=false" are descriptive of the desired/expected/predicted or actual Act as it will be in event mood. For example, if an order has an effectiveTime attribute, that attribute asserts when the fulfilling event is expected to occur, not the time the order is created. Similarly, a "performer" participation on a definition indicates who or what is allowed (or capable) of performing the eventual act event, not who performed the ordering.

  2. Alternatively, attributes and associations with "isDocumentCharacteristic=true" are descriptive of only the act in the current mood and have no bearing on the moods of instantiating or fulfilling acts. For example the identifier of an order need have no impact on the identifier of the resulting event. Similarly, the author of an act definition has no bearing on who will be the author of an actual event that satisfies that definition.

The designation of "isDocumentCharacteristic" as true is important in several circumstances including: the effect of various "mood" codes on the interpretation of the attributes of an Act, and the interpretation of asserted "negation" for an act.

  • The designation is important in understanding the semantics of an Act. For example, it designates that an order (moodCode="RQO") is not requesting the creation of a record (moodCode="EVN") with a particular id, but rather that the order itself has an "id"; or that a definition (moodCode="DEF") is not constraining that all events only be authored (Participation.typeCode="AUT") by a particular person, but rather that the definition itself has an author.

  • The relationship to negation can be understood with reference to the Usage Notes for the attribute Act.actionNegationInd, which state:

    The actionNegationInd negates the Act as described by the descriptive properties (including Act.code, Act.effectiveTime, Observation.value, Act.doseQty, etc.) and any of its components. The document characteristic properties [ones with "isDocumentCharacteristic=true"] such as Act.id, Act.moodCode, Act.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

In some cases, however, it will be necessary to actually communicate about Act attributes with "isDocumentCharacteristic" = true as if they were characteristics of the Act as it will be in event mood. For example, the definition for an Act to be ordered might need to indicate that a fulfilling document (the event) must be in a specific language or that it must have a particular value for confidentialityCode. (Both of these attributes are identified as "isDocumentCharacteristic = true" and thus would normally be expected to apply only to the definition act, not to the resulting event.)

The following diagram illustrates how a definition can require that a specific value for confidentialityCode ("V") apply to all Act events that instantiates that definition, by adding these attribute values to the definition of the Act, where they would otherwise have been unconstrained.. The model uses an ActRelationship with typeCode="META". As required by the constraint on the META type code, the target Act must have the isCriterion attribute set to true. The other attributes of this Act (as well as any associations hanging off of it) are intended to constrain event objects will be instantiated based upon the definition, not to constrain the definition itself.

Example of using META ActRelationship type to assert a constraint on a document characteristic of a defined act.

The HL7 Reference Information Model (RIM) contains several attributes whose name ends in "negationInd". As the name suggests, these attributes serve to negate all or some of the "semantics" of the class in question. These attributes have a profound impact on the meaning of HL7 v3 instances and therefore there are special guidelines on how these attributes are handled.

The attributes are as follows:

At one point, there was also an attribute called Act.negationInd. However, it was deprecated and has been retired on the grounds that it conflated the meaning of Act.actionNegationInd and Observation.valueNegationInd. For models that retain the use of this attribute (e.g. CDA R2), profiles should provide clear guidance about its intended use and meaning.

In all cases, the negation indicator attributes default to false. This default holds even if negation indicators are omitted from a model. Furthermore, negation indicators cannot be added into a new version of a model where they were not previously present, nor can they be added as local extensions because of their impact on the meaning of all other information in the model.

In all cases except for Observation.valueNegationInd, negation applies to the level of detail conveyed by the attributes (and possibly associations) of the class. An actionNegationInd of "true" on a SubstanceAdministration Event with only a subject specified would indicate "this subject has never been administered a substance". (Given that the subject has likely eaten at least once in their lifetime, it's unlikely the statement would actually be true.) On the other hand, if in addition the Act had an effectiveTime of 12:05 on January 6th, 2010 and a performer of John Smith, then it would say "this subject was not administered a substance on January 6th, 2010 at 12:05 by John Smith". It doesn't preclude the possibility of a substance having been administered by John Smith at 12:04 or 12:06, nor at 12:05 by Jane Smith.

For Acts, more specifically, all of the relationships and attributes that are not "documentCharacteristics" are negated. So a procedure event authored by Dr. Johnson with id 12345 indicating a code of "appendectomy" and an actionNegationInd of "true" indicates that the patient has not had an appendectomy. However the record number indicating that fact is still 12345 and the fact medical history observation that the patient has not had an appendectomy was in fact recorded by Dr. Johnson. This is true because both the "id" attribute and the "author" participation typeCode are document characteristics.

The three negation indicators appearing on the relationship classes (ActRelationship, Participation and Role) indicate that the relationship between the two classes described by the attributes on the relationship class does not exist. It makes no assertion about the existence of the source and target classes, nor of the characteristics of those classes., It merely establishes the presence or absence of a the relationship with its specified properties.

As a rule, Role.negationInd being true only makes sense when traversing from playing entity to scoping entity or vice versa. It is not appropriate for roles traversed to or from via participations.

The interpretation of Act.actionNegationInd varies by mood. In EVN mood, it indicates the event did not occur. In RQO, it's a request to not take an action. In permission mood, it indicates that the permission is not granted. Though rare, in definition mood, it would indicate that a particular type of act cannot be performed.

Observation.valueNegationInd is simpler. It simply indicates that the specified value was in fact *not* observed. This allows the statement of a negative finding, such as absence of a tumor, rash illness or other condition. The semantics are not influenced by any other attributes on the Observation. However, it is influenced by the level of detail specified in value. If the Observation.value is "severe, sudden onset rash", a negated observation only indicates that specific type of rash was not found. It says nothing about a moderate or slow onset rash.

Observation.valueNegationInd on observations whose values are encoded should only be used when the negation semantic cannot already be conveyed by the code system used to communicate the observation value itself.

As with human language, it is possible to combine multiple negation indicators in a single instance. However, just as with human language, this can cause confusion. "The patient did not have a lab test not performed by John Smith that did not observe elevated hemoglobin" is a legal statement. But the semantics are unlikely to be accurately interpreted by humans or many computer systems.

Short-cut to glossary terms:  A  C  D  E  L  R  S  U  V  

A.1 
Affiliate Binding Realms
Each HL7 International Affiliate has authority for the Binding Realm bounded by geographic scope of the Affiliate.

A.2 
Code
A Code is a Concept Representation published by the author of a Code System as part of the Code System. It is the preferred unique identifier for that concept in that Code System for the purpose of communication (preferred wire-format identifier), and is used in the 'code' property of an HL7 coded data type. Codes are sometimes meaningless identifiers, and sometimes they are mnemonics that imply the represented concept to a human reader. In Code Systems that contain more than one Concept Identifier, the one that should be used in HL7 as the Code should be explicitly declared as part of the HL7 Code System registration process (see § 4 above).

The meaning of a Code within a particular Code System entity is valid only within that Code System. For example, each table having enumerated codes in the HL7 Version 2.x standards represents a different Code System, since codes are sometimes used in different Code Systems to have different meanings. One example is the code "M" in the v2.x table 0001 Administrative Sex which signifies "Male," whereas the code "M" in the in the v2.x table 0002 Marital Status signifies "Married". Another example is the code "1609-7" which signifies the Native American tribe "Sioux" in the Race & Ethnicity – CDC Code System(2.16.840.1.113883.6.238), and the code "1609-7" which signifies "Prolactin^1.5H post dose insulin IV" in the LOINC Code System (2.16.840.1.113883.6.1). Codes do not have explicit semantics without their Code Systems, and cannot be referenced without identifying the code system in which they are published.


A.3 
Code System
A Code System is a managed collection of Concept Representations, including codes, but sometimes more complex sets of rules and references, optionally including additional Concept Representations playing various roles including identifiers of the concepts, designations, etc. Code Systems are often described as collections of uniquely identifiable concepts with associated representations, designations, associations, 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 concept identifier must resolve to one and only one meaning within the Code System; i.e. Code Systems used in HL7 must not have homonymy. In the HL7 Terminology Model, a Code System is represented by the Code System class.

Although Code Systems may be differentially referred to as terminologies, vocabularies, or coding schemes, HL7 considers all such collections ‘Code Systems' for use in Version 3 as described in this document. At a minimum, Code Systems have the following attributes:

  • An identifier that uniquely identifies the Code System. For HL7 conformant model instances, this SHALL be in the form of a UID. This UID will take one of three forms: an ISO OID, a UUID or an HL7 RUID. If the code system is identified by an OID, this OID SHALL be registered in the HL7 OID registry, unless the code system is a local code system, in which case it MAY be registered in the HL7 OID Registry. The HL7 OID Registry may be found at http://www.hl7.org/oid/index.cfm
  • A description consisting of prose that describes the Code System, and may include the Code System uses, maintenance strategy, intent and other information of interest.
  • Administrative information proper to the Code System, independent of any specific version of the Code System, such as ownership, source URL, and copyright information.

The Concept Representations in a Code System may also be augmented with additional text, annotations, references and other resources that serve to further identify and clarify what a concept is. A Code System also may contain assertions about relationships that exist between concepts in the Code System.

A Code System is typically created for a particular purpose and may include finite collections, such as concepts that represent individual countries, colors, or states. Code Systems may also represent broad and complex collections of concepts, e.g., SNOMED-CT, ICD, LOINC, and CPT. Where possible, HL7 modelers faced with a requirement for a coded concept will reference an existing Code System. Some of these Code Systems are replicated within the HL7 standard repository for stability or convenience, while others are documented as references. HL7 will only create a new Code System when an appropriate existing Code System is not available for use in HL7. Such is the case with Class Codes, which are defined and maintained by the HL7 organization. There are also cases where an otherwise appropriate external resource is not available due to licensing or other restrictions.


A.4 
Combination Binding Realms
These are Binding Realms created by one or more HL7 International Affiliates as a combination of the Binding Realms of each of the separate Affiliates. Any Binding Realms may be combined for such a purpose to make an interoperability space that extends across affiliate realms. The HL7 International Affiliates who agree to do so are the joint stewards of the combination Binding Realm. Some examples of this could be "North America" (combining the US and Canada), or "Southern Europe" combining several European Affiliates.

A.5 
Concept
A Concept is a unitary mental representation of a real or abstract thing – an atomic unit of thought. It should be unique in a given Code System. A concept may have synonyms in terms of representation and it may be a singleton, or may be constructed of other concepts (i.e. post-coordinated concepts).

Concepts, as abstract, language- and context-independent representations of meaning, are important for the design and interpretation of HL7 V3 models. They constitute the smallest semantic entities on which HL7 V3 models are built. The authors and the readers of a model use concepts and their relationships to build and understand the models; these are what matter to the human user of HL7 V3 models. The rest of the vocabulary machinery exists to permit software manipulation of these units of thought.


A.6 
Concept Identifier
A Concept Identifier is a Concept Representation that may be published by the Code System author, and unambiguously represents the concept internally within the context of that Code System. Such an object used for identification, when combined with the unique identifier of the Code System itself (a machine-processable unique string), provides a globally unique and language-independent identification for the particular concept. This globally unique identification can be used in transactions and data records that span both space and time. In some cases, multiple synonymous identifiers may be present for the same concept.

A.7 
Concept Representation
A Concept Representation is a vocabulary object that enables the manipulation of a Concept in HL7. A Concept Representation exists in some form that is computable, and can be used in HL7 models and specifications. Concept Representations can take on a number of different roles in the structure and processing of vocabulary in HL7; these roles and functions are described below.

A.8 
Designation
A Designation is a Concept Representation that may be published by the Code System author, and is a language symbol for a concept that is intended to convey the concept meaning to a human being. A Designation may also be known as an appellation, symbol, or term. A Designation is typically used to populate the 'displayName' property of an HL7 coded data type.

A.9 
Dynamic Stability
Dynamic stability means a Value Set Assertion does not have a Static Date. As a result, the allowed values for a coded item automatically change as the Value Set definitions or their underlying Code Systems (or included nested Value Sets) are maintained over time. This means that the binding is to the most current version of the Value Set Definition available. The documented or persisted expansions of the Value Sets declared in the Value Set Assertion must always be checked for currency before use when evaluating a binding with dynamic stability, as changes to underlying code systems referred to in the Value Set Definition may imply changes requiring a new generation of the expansion before use. Note that it is possible to have a Value Set Assertion that references specific versions of one or more of the referenced Value Sets. Similarly, intensional Value Sets may be constructed with other Value Sets that might also reference explicit versions. However, because not all versions of all Code Systems and Value Sets are "locked", the binding would still be considered to have dynamic stability. In theory, all referenced Value Sets and all referenced Code Systems could all include their respective version references in the Value Set Definition, which would accomplish the same objective as binding with static stability – a fixed expansion at all points in time. However, because no Static Date would be present in the list of data items defining the Context Binding, the binding would still be identified as having dynamic stability.

A.10 
Example Binding Realm
The Example Binding Realm is used for bindings to Value Sets 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: a Concept Domain definition must include three examples. They may also be used in the construction of Binding Realm-independent example instances, and as examples in published documents, manuals, and presentations. Example Binding Realms are not generally needed when appropriate Representative Binding Realm bindings exist.

The Example Binding Realm SHALL only be referenced in example instances. It has a "parent" Binding Realm of Representative.


Short-cut to glossary terms:  A  C  D  E  L  R  S  U  V  

A.11 
local code system
A local code system is one which is only used for communication within the organization that maintains the code system.

A.12 
Representative Binding Realm
The Representative Binding Realm exists for bindings that are intended to be to complete and implementable Value Sets and that properly represent the coded coverage of the semantic space defined by the Concept Domain. Unlike universal bindings, there is no expectation that all (or any, necessarily) affiliates will choose to adopt the Representative Binding Realm bindings. Representative Binding Realm bindings provide a starting point and a focus for consensus, while recognizing that cultural and political variations between HL7 International Affiliates may result in alternative bindings. To qualify for Representative Binding Realm designation, candidate content must be sufficiently comprehensive and internally consistent to be adoptable and implementable by specialized Binding Realms. A Representative Binding Realm has no official force in an affiliate unless the affiliate chooses to adopt it with an Affiliate-specific binding; it is not used in specific conformance claims. When an Affiliate does choose to use a binding from the Representative Binding Realm, the binding definition is copied into the Affiliate Binding Realm: there is no persistent link that may result in unintended cascading changes.

The Representative Binding Realm should never be referenced in an instance. It has a "parent" Binding Realm of Universal.


A.13 
Static Stability
Static stability means that the processing of the Value Set(s) identified in the Value Set Assertion results in a fixed list of concepts (Value Set Expansion) regardless of when the processing takes place in time. The expansion is determined by evaluating the referenced Value Sets (MAX, MIN and IGNORED) as of a particular date and generating their expansions. This includes determining the Value Set versions (if not explicit in the Assertion) as well as the versions of all Code Systems referenced by those Value Sets, including Value Sets embedded in intensional definitions. As a result, the expansions of the Value Sets declared in the Value Set Assertion do not change automatically as the Value Set definitions and underlying Code Systems are changed, and the Value Set Expansions may be included in an implementation guide. A Value Set Assertion has static stability when it includes a Static Date.

For references to specific codes, the reference is considered to be "static" if it includes the Code System Version, which is expressed in the Value Set Assertion as a date. Static references to fixed codes are only necessary if there is concern that the meaning of the code may change in the Code System over time.


A.14 
Sub-Binding Realms
In some circumstances, an HL7 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 (e.g., regions, states, provinces, etc.) or by type of implementation (e.g., human vs. veterinarian, etc.). Sub-Binding Realms can only be created by HL7 International Affiliates.

Sub-Binding Realms have the same steward as the affiliate that maintains the parent Binding Realm. Because the purpose of sub-Binding Realms is to allow the use of different Value Sets for the same specification within an Affiliate, they can cause interoperability issues within the Affiliate. They should therefore only be introduced after careful consideration of the interoperability consequences.


A.15 
Unclassified Binding Realm
The Unclassified Binding Realm accommodates content that is new and in the process of being refined, as well as legacy content that has not yet been promoted to its destination Binding Realm and is still undergoing development work. The Unclassified Binding Realm may also serve as a transition point for content contributed from other Binding Realms. The Unclassified Binding Realm exists for HL7 administrative purposes and has no effect on implementations. This is intended as a temporary state, and items bound to the Unclassified Binding Realm should be either removed or promoted to a non-temporary Binding Realm as quickly as is feasible.

The Unclassified Binding Realm should never be referenced in an instance. It has no "parent" Binding Realm.


A.16 
Universal Binding Realm
The Universal Binding Realm constitutes the core HL7 Binding Realm that is, by definition singular and fixed, and is the "root" Binding Realm for all other Binding Realms. Structural elements (e.g., Act.classCode) and most data types are examples of content in this Binding Realm. Content from domain technical committees is rarely included in the Universal Binding Realm and, when introduced, must go through special processes to ensure full international consensus on the universal constraint to a single binding.

All Binding Realms that are defined in an instance are in a tree whose topmost root parent is the Universal Binding Realm.


A.17 
Universally Unique Identifier
A globally unique string representing a DCE Universally Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. For more information, see Universally Unique Identifiers (UUIDs) or see ISO/IEC 11578:1996.

A.18 
V3 Reference Platform
The V3 Reference Platform is the combination of the HL7 Reference Information Model (RIM); the data types model used to type the the attributes of the RIM classes; and the controlling vocabulary that provides values for any RIM attribute or data type component whose data type is "coded simple" (CS). All HL7-conformant derived models SHALL have this these three models at the root of their derivation tree.


A.19 
value domain
For a class, the value domain is the set of all possible conformant instances of that class. For an element whose type is a data type (such as an attribute or data type component) the value domain is the complete set of allowed values for that element as specified by the definition of the assigned data type. Thus the value domain for an element typed as INT (Integer) is all integer numbers and "1" is a member of that value domain, whereas "1.1" is not.


Short-cut to glossary terms:  A  C  D  E  L  R  S  U  V  

  1. [source] Because the ANY data type can be constrained to most of these data types, the vocabulary constraints discussed in this section often apply to data elements with a type of ANY as well.
  2. [source] The Glossary linkage and layout for published specifications such as this is not yet complete; links to items such as this in italics will be established as soon as that work is complete.
  3. [source] Potentially a code system could change over time such that an intentional value set definition built on it could resolve to contain no codes any longer, but this should happen very rarely, if ever.
  4. [source] A regular expression (regex or regexp for short) is a special text string for describing a search pattern. More information may be found at Regular-Expressions.info.
  5. [source] In the special case where a very narrowly defined Concept Domain may be completely covered by less than three concepts in total, then it may be annotated with less than three example concepts.
  6. [source] Formerly known as "Common Message Element Types". "Message" was changed to "Model" because the CMET construct is perfectly appropriate when designing documents, services, templates and other non-"message" constructs.
  7. [source] Other classes are the dark-blue classes generally found at the bottom half of the RIM. The Visio RMIM Designer tool does not support CMETs with a type of "Other".

View Revision MarksHide Revision Marks Return to top of page