Package Note to Readers

This 2012 Health Level Seven International V3 Publication is copyrighted by Health Level Seven International (HL7) and is therefore protected by the Copyright Laws of the United States and copyright provisions of various international treaties. The effect of such laws and treaties is that you may not, without a license from Health Level Seven International, copy or distribute HL7's publication Product. HL7 International Organizational members are authorized to reproduce the publication for internal use in their organizations. This authorization use does not include reproduction of any part of this publication for inclusion in products for direct commercial resale. HL7 International Individual members may not reproduce or redistribute any part of this publication.

The content of this document is not intended to be an alternative to, or replacement for, standards mandated for use within any jurisdiction.

In addition to acknowledging the Work Group Co-chairs and Facilitators, special credit is due a number of contributors:

Special thanks go to George (Woody) Beeler for serving as the V3 project leader, Publishing Co-Chair and tools developer, Lloyd McKenzie with IBM for developing the Visio tool set for development of CMETs and Austin Kreisler with SAIC for development of the Publication Database. The following individuals are also acknowledged for their intellectual contributions: Wes Rishel with Gartner Group, Jim Case with University of California, Ken McCaslin with Quest Diagnostics, and Dale Nelson with Zed-Logic Informatics, LLC. The following individuals are acknowledged for their technical support in the production of this publication: Don Lloyd and Karen Van Hentenryck with HL7.

If you have questions regarding this publication you may contact the HL7 office at:

Health Level Seven, Inc. 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104, USA

(+1) 734-677-7777 (phone) (+1) 734-677-6622 (fax)

Email: HQ@HL7.org Internet:

The 2012 Normative Edition contains those Version 3 Standards that are ANSI Approved, those that have passed Membership Level Ballot and are awaiting final ANSI Approval, and Draft Standards for Trial Use (DSTU).

If you look at menus that appear in the documents, you will notice that six colors are used. The colors indicate the type of document. The different types are enumerated below:

Icon	Description
	Yellow identifies an informative document. Informative documents are balloted according to a procedure outlined by HL7. While calling for consensus, the ballot procedure for informative documents is not as stringent as that for normative documents. Information documents are not submitted to ANSI for approval.
	Green identifies a reference document. Reference documents are not balloted and are included with the ballot material to assist with understanding and comprehension. The Glossary, for example, is a reference document.
	Red identifies a normative document. Normative documents are balloted according to procedures that adhere to ANSI's procedures. Normative documents must pass a full normative level ballot. Normative documents, once they've passed normative ballot, are submitted to ANSI for approval.
	Blue identifies a group of documents that fall into one or more of the categories listed above. Many of the domain documents are grouped together under a blue section heading. This is simply an easy way to group documents.
	Gray identifies a draft only document. Ultimately, this document may become normative, informative or reference but at the time of balloting, a gray book means that this document or document group will be draft only and not ballotable.
	Purple identifies a normative document that is (or will be) Draft Standard for Trial Use (DSTU).

Within the documents, you may find several icons that are designed or colored in such a way as to introduce the status of that particular item. Most commonly, main headings will have an icon for their ballot status. By hovering over the icons, you will find a descriptive term to better understand what this icon means. Here is a list of the ballot status icons used in these documents.

HL7's mission is to provide standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems.

HL7 is one of several ANSI-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as clinical data, pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven's domain is clinical and administrative data.

HL7 is a not-for-profit volunteer organization. Its members - providers, vendors, payers, consultants, government groups, pharmaceutical and others who have an interest in the development and advancement of clinical and administrative standards for healthcare - develop the standards. Like all ANSI-accredited SDOs, HL7 adheres to a strict and well-defined set of operating procedures that ensure consensus, openness and balance of interest. A frequent misconception about HL7 (and presumably about the other SDOs) is that it develops software. In reality, Health Level Seven develops specifications, the most widely used being a messaging standard that enables disparate healthcare applications to exchange key sets of clinical and administrative data.

The HL7 Working Group is composed of volunteers who give their time on a personal basis or under sponsorship of their employers. Membership in the HL7 Working Group has been, and continues to be, open to anyone wishing to contribute to the development and refinement of the HL7 standards.

The term "Level 7" refers to the highest level of the Open System Interconnection (OSI) model of the International Organization for Standardization (ISO). This is not to say that HL7 conforms to ISO defined elements of the OSI's seventh level. Also, HL7 does not specify a set of ISO approved specifications to occupy layers 1 to 6 under HL7's abstract message specifications. HL7 does, however, correspond to the conceptual definition of an application-to-application interface placed in the seventh layer of the OSI model.

In the OSI conceptual model, the functions of both communications software and hardware are separated into seven layers, or levels. The HL7 Messaging Standard is primarily focused on the issues that occur within the seventh, or application, level. These are the definitions of the data to be exchanged, the timing of the exchanges, and the communication of certain application-specific errors between the applications. However, of necessity, protocols that refer to the lower layers of the OSI model are sometimes mentioned to help implementers understand the context of the standard. They are also sometimes specified to assist implementers in establishing working HL7-based systems.

The standard does not try to assume a particular architecture with respect to the placement of data within applications, but is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Rather than addressing specific issues of application architecture, HL7 serves as a way for inherently disparate applications and data architectures operating in a heterogeneous system environment to communicate with each other.

If we consider the multitude of healthcare information systems applications as well as the variety of environments in which healthcare is delivered, it is evident that there are many more interfaces which could benefit from standardization. The interfaces chosen were considered to be of high priority by the members participating in the standards writing process. HL7's intent is to prepare a complete standard for these interfaces, built on a generic framework that is sufficiently robust to support many other interfaces.

HL7 V3, like V2.x, is a standard for exchanging messages among information systems that implement healthcare applications. However, V3 strives to improve the V2 process and its outcomes. The original process for defining HL7 messages was established in 1987. It has served well since. However, as HL7 membership grew and its standards became more widely used, HL7 has become aware of opportunities to revolutionize healthcare interface computing. HL7 interfaces substantially reduce costs and implementation times when compared to the industry's experience with proprietary interfaces. However, these costs and times vary considerably by vendor, and the industry sees a need for improvement. Substantial optionality in HL7 makes it difficult to specify precise contract terms for HL7 interfaces. This can lead to unrealistic expectations that hurt vendors and buyers equally. The development principles behind HL7 V3 lead to a more robust, fully specified standard.

The HL7 V3 standard development methodology is based on a set of principles providing a common philosophy for all HL7 V3 standard developers.

• Internationalization: V3 shall include mechanisms that support the need for local variants of HL7 messages to be used by HL7 Affiliates. It shall be possible for affiliates to use the messages created by the worldwide HL7 organization. It shall also be possible for affiliates to develop and use localized variants.
• Legacy Systems Support: As with prior versions, V3 shall be designed using a technological approach that permits implementation in "legacy systems." These are systems that have been implemented in technical environments that do not necessarily conform to or provide support for recent or pending "open systems" standards, such as those published by ISO, Open Systems Foundation, Object Management Group, etc. Similarly, HL7 will not require proprietary features of any operating system or software vendor. In practical terms, this means that V3 shall be able to exchange messages formatted in strings of printable characters, as is the case for all previous versions. This does not preclude HL7 from deciding to develop variants of its specification that make use of the modern technologies provided that 1) System builders will not be required to buy software from a sole source in order to implement V3, and 2) Messages generated in these formats have the same data content so that translation between the printable character format and other formats is easy.

• Loosely Coupled Systems: As with HL7 V2.x, V3 shall not be a standard for the functionality of the systems that exchange HL7 messages. However, where V3 includes a requirement to accept or send certain data or to send specific messages in response to trigger events or other messages, the application system may have to develop functionality to support those requirements.

  V3 messages may be sent using many modes and topologies. Messages may be sent in a manner that requires an immediate response, as unsolicited updates through a store and forward network, or in batches where the manner and timing of message transfer is not specified. V3 includes support for "one-to-many," store-and-forward distribution of messages by an external software agent.

• V2.x Functional Compatibility: HL7 V3 goals cannot be achieved while maintaining full compatibility with previous versions. However, upon completion, V3 shall cover the information content of the last version in the V2.x series including attributes and trigger events. This should not be construed to mean that all attributes and trigger events will be included in V3 in exactly the same form as within the V2.x series.

  A network that includes a mixture of systems that implement V2 and V3 will require message translation. Because the V2 standards have substantial optionality, the translations will use rules specific to the systems on that network. It is expected that interface engines and other translation software will be able to provide the translations between site-specific interpretations of V2.x and any implementation of V3.

• Upward Compatibility Among V3.x: HL7 will provide the maximum degree possible of interoperability among systems operating on older and newer versions of HL7 protocols in the V3 family through compatible enhancement.

  • A message structure that is modified in a newer version of the protocol must be acceptable to a system designed for the prior V3 release. However, a system built for the prior release will only extract the information that was defined for that prior release.
  • A message structure created in accordance with an older version of the V3 protocol must be acceptable to a system designed for a later V3 release. In some cases, this will mean that the system built for the newer release will not receive certain information fields because they were not a part of the older version of the message structure in use by a specific sender.
  • Where compatible enhancement is not possible, HL7 will require evolution in the protocol to happen gradually, so that users can introduce the change into their networks gradually.
  • The messages associated with all interactions that are newly defined in a version of HL7 must not be sent to a receiver that conforms to the older version.
  • A message structure may be declared obsolescent in one release, with a stated alternative message structure. Both the obsolescent message structure and its alternative can be used by all systems supporting that release.
  • The obsolescent message structure may be declared obsolete and dropped when still another HL7 version is issued.
  • An obsolescent message structure may not be declared obsolete for at least two years from the date of the version that first declared it obsolescent.
  • The above notwithstanding, if a new Implementation Technology Specification (ITS) is introduced, HL7 may specify that conformance to the ITS does not require dealing with message structures that are obsolescent when the new ITS is introduced. To the maximum degree possible, these restrictions should not impose limitations on the evolution of the overall reference model. There are no restrictions on making changes to the information model if those changes do not impact the message structures that were described in a prior version of the Standard.

• Determining Conformance: Application roles are the basis for conformance claims. An application role is an abstraction that expresses a portion of the messaging behavior of an information system. Application role names are different than the names generally used to describe healthcare information system products, since they describe messaging interfaces as opposed to application behavior. A typical healthcare information system will probably fill several or many application roles.

  In making a conformance claim, a system developer identifies the application roles to which it wishes to claim conformance. For these application roles, the V3 specification will state directly the trigger events the system shall recognize, messages that the system shall send in response to trigger events or other messages, and the data content of these messages. The specification also states the messages that a system conforming to the application role shall receive and process.

  All conformance claims shall be sufficiently specific to be used as contractual terms in system acquisitions and to be the basis for testing by an independent testing organization.

  User sites may contract with vendors to implement deviations from the HL7 conformance claims. Such arrangements are outside the scope of HL7. Such an arrangement will not be considered a failure of the application to conform to HL7.

  All sequences of messages in V3 shall be related to a trigger event. The trigger event shall be clearly identified in a common field in all messages.

• Confidentiality of Patient Information: It is expected that healthcare application systems that implement V3 will be required to have significantly more functionality to protect the confidentiality of patient information than has been common in the past. The new functions may include, but are not limited to, limiting the right to view or transfer selected data to users with specific kinds of authorization and auditing access to patient data. V3 will seek out and adopt industry security standards that support conveying the necessary information from one healthcare application system to another, so that these systems may perform the confidentiality functions. The Functional Work Groups, the Infrastructure and Messaging Work Group, and the Modeling and Methodology Work Group shall consult with the Implementation/Conformance Work Group while developing the HL7 Data Model and V3 messages.
• Authenticated Authorization for Services: It is expected that the healthcare application systems that implement V3 will be required to have significantly more functionality to authenticate requests for services and reports of data than has been common in the past. The new functions may include, but are not limited to, electronic signature and authentication of users based on technologies more advanced than passwords. V3 will seek out and reference standards such as X.500 and RFC 1510 to support conveying the necessary information from one healthcare application system to another, so that these systems may perform the authorization and authentication functions. The functional Work Groups, the Infrastructure and Messaging Work Group and the Modeling and Methodology Work Group shall consult with the Implementation/Conformance Work Group while developing the HL7 Data Model and V3 transactions.
• Security, Privacy, Non-Repudiation and Integrity: It is expected that the technological platforms upon which V3 information systems developers implement applications that use HL7 will be required to have significantly more capability to protect the confidentiality and integrity of patient information than has been common in the past. The new functions may include, but are not limited to, public- and private-key encryption, and correspondent system authentication and non-repudiation. The Control Group is monitoring these developments to ensure that V3 can be implemented on technological platforms that support these new functions.

• HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles. HL7 employs a completely new development approach with V3. HL7 V3 uses an OO approach that is model and repository-based. This OO approach is supported with trained facilitators, formal education classes, and computerized tools. This approach leads to increased detail, clarity and precision of the specification and finer granularity in the ultimate message. This helps functional Work Groups meet the challenges of de novo interface design, and increases functional breadth and evolution of assumptions. It helps new members become productive in fewer meetings. This is an enormous aid to providing institutional memory and sharing work in progress across Work Groups and to the membership at large.
• HL7 isn't just Level 7 any more! After years of implementing HL7 V2.x, HL7 standard developers realized it was virtually impossible to develop a comprehensive standard without including other levels of the International Organization for Standardization (ISO) Open Systems Interconnect (OSI) Model. Today, Work Groups exist for XML, Security & Accountability, Modeling & Methodology, Arden Syntax, CCOW and Vocabulary.
• Reduced Optionality. Limiting optionality is a primary goal of HL7 V3. Within HL7 V2.x, almost every field is optional. This optionality is necessary since optionality is defined by segment and segments are reused in multiple messages. Declaration of a data field as optional within a segment allows that segment to be used in many different messages without any further definition. However, the wide use of optionality, while helpful in gaining consensus and in writing a somewhat more compact specification, imposes significant costs on interface implementers. In fact, optionality, as a "feature" of HL7 V 2.x, is associated with most of the issues that V3 is trying to solve. Optionality makes it harder to precisely define the semantics of a specific message and makes it virtually impossible to generate conformance claims for messaging.
• Conformance to HL7 V3 will be testable. It is difficult to measure compliance of HL7 V2.x interfaces. Often vendors claim compliance to HL7 without providing any supporting documentation of how they conform. Terms such as HL7-like or HL7-ish are used to describe HL7 interfaces. With HL7 V3, conformance is specified in terms of application roles. Application roles are abstractions that express a portion of the messaging behavior of an information system. A vendor of a healthcare application describes its conformance by asserting that it completely supports all trigger events, messages and data elements associated with one or more application roles. This level of specificity allows clearer pre-contractual understanding between vendors and buyers and will serve as a basis for conformance testing.

This section outlines the procedures used to develop the HL7 V3 messages. These procedures are based on the V3 Methodology and the HL7 Bylaws. The goal is to assure that the standard is developed expediently, with appropriate documentation, consistent with the requirements for an approval by a balanced consensus, and that it complies with the requirements for certification by the American National Standards Institute (ANSI).

A New Implementer is unfamiliar with HL7 terminology, methodology, and organization. A New Implementer may or may not be a member of the HL7 organization.

Standard Developers attend HL7 Working Group Meetings and participate in the creation of the HL7 V3 Standard Specification.