![]() HL7 V3 GUIDE, R1 HL7 Package Note to Readers August 2012 |
Responsible Group | V3 Publishing Work Group HL7 |
HTML Generated: 2012-08-31T10:16:56
HL7® Version 3 Standard, © 2005-2012 Health Level Seven® International All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.
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:
Welcome to the Normative Edition 2012of the Version 3 (V3) messaging standard. This package is the result of many years of work within the HL7 community and an increasingly focused effort with each new publication cycle. We believe it is a major step forward for global health information standards.
The document you are currently reading is the Package Note to Readers document, which contains the following sections:
The HL7 Introduction section provides a brief overview of the HL7 Organization, its mission and philosophy.
Review this section to understand what HL7 V3 is, why we developed HL7 V3, and the principles underlying the V3 Standard.
The V3 Publication is composed of two types of documents: Foundation and Domain. The Foundation documents are those documents that are broader in scope and tend to apply to all domain documents. The V3 Guide, the HL7 Vocabulary Domain and Reference Information Model, for example, are Foundation documents. Domain documents are produced for a specific domain such as pharmacy or scheduling and contain the messages relevant to that domain.
Below is a graphical representation of the Foundation documents.
Version 3 Domains contain specifications for dealing with functional areas of healthcare. For example, Patient Administration, or Medical Redords.
Each Domain document has a common structure and contains a common set of artifacts.
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).
Foundation Documents are the basis for all of the other specifications. The RIM is the model on which all V3 Standards are based. Vocabulary defines terms and code sets. The Data Types Abstract Specification specifies the HL7 Version 3 Data Types on an abstract layer, independent of representation. Refinement, Constraints and Localization specifies what the HL7 Work Groups are permitted to do as part of the Version 3 Refinement process. GELLO is intended to be a standard expression language for decision support.
The Master File / Registry domain is comprised of the classes and attributes needed to support Master Files and Registries. The Message Control Act Infrastructure covers the alternate structures of the message Trigger Event Control Acts in the HL7 Composite Message. The Query Infrastructure domain specifies the formation of information queries and the responses to these queries. Transmission infrastructure describes the information model, messages and interactions related to the assembly of an HL7 V3 composite message.
Transport Specifications detail how the messages are sent "over the wire."
The ITS:XML Datatypes specification defines standard representations for data values in XML. The ITS:XML Structures document describes how HL7 V3 compliant messages can be expressed using XML. This UML ITS implements the semantics of the Abstract Data Types specification using UML in such a way that HL7 data types are mapped into the core UML and OCL kernel data types where such mappings are appropriate.
The HL7 Common Terminology Services (HL7 CTS) defines an Application Programming Interface (API) that can be used by HL7 Version 3 software when accessing terminological content. The Resource Location and Updating Service (RLUS) defines a set of interfaces allowing health data to be located, accessed and updated, regardless of underlying data structures, security concerns or delivery mechanisms. The Entity Identification Service (EIS) provides a set of capabilities to manage and retrieve identifying information for various kinds of entities (people, organizations, devices, etc.) thereby providing a foundation component for many healthcare interoperability scenarios. The Decision Support Service (DSS) defines a service functional model for a service that can be queried by a DSS client. Conceptually, a DSS is a 'guardian' of one or modules of medical knowledge capable of utilizing coded patient data to arrive at machine-interpretable conclusions regarding the patient information under consideration. The Service Oriented Architecture and HL7 V3 Methodology document defines an approach for implementing healthcare services within the Healthcare Services Specification Project (HSSP), but provides an additional interim method of defining and implementing web services based on HL7 V3 artifacts.
CMETs (Common Message Element Types) are a work product produced by a particular work group for expressing a common, useful and reusable concept. Shared Messages are a work product produced for expressing common, useful and reusable message types.
Administrative Management Domains contain specifications that support Administrative Functions in healthcare facilities.
The Health and Clinical Management Domains contain specifications from a variety of healthcare focus areas.
The HL7 V3 Normative Edition is best viewed online due to the size of the document and the availability of extensive supporting materials. We are also making the entire package available on CD-ROM. You may also download the documents from the HL7 website.
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 V2.x development process is entirely ad hoc. There is no explicit methodology. Members receive no formal guidance in constructing messages. Trigger events and data fields are described solely in natural language. The structural relationships among data fields are not clear. Segments are reused in many messages and message definitions are reused for many trigger events. In order to accommodate this extensive reuse, most data fields are optional. Chapters are inconsistent in their use of trigger events versus status codes. There is no specification as to when a specific kind of healthcare information system should be expected to honor a trigger event or accept a message.
With V2.x, a Work Group creates messages by editing word processing documents directly. The metadata is not available in a structured form until the staff and volunteers tediously extract it from the word processing documents after publication.
In summary, there is substantial need to improve this old process in order to handle the breadth and complexity of the challenges HL7 faces today. Our industry will benefit because this new process results in a more rigorous specification.
Fortunately, software practitioners have learned a lot since 1987. There are better methodologies. Computer support is far more available and cost-effective. However, HL7 cannot take advantage of these developments solely by minor tweaks to the old process.
HL7 spent four years characterizing its revised goals and creating a methodology to adapt modern analysis techniques from system building to message design. Initially, the HL7 Board of Directors chartered an independent task force to establish the broad outline of the approach. In January 1996, the Technical Steering Committee (TSC) agreed to adopt the main features of the approach and take over its management. Planning work continued in the Modeling and Methodology Work Group and the Implementation/Conformance Work Group. At the completion of V2.3, in the spring of 1997, the HL7 Work Groups all began to use the V3 process.
The HL7 V3 standard development methodology is based on a set of principles providing a common philosophy for all HL7 V3 standard developers.
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.
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.
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).
When a Work Group undertakes a project to develop new material in V3 it creates a brief description of the project for approval by the process defined in the Project Scope Statement Template, at //www.hl7.org/permalink/?ProjectScopeStatement. The project scope statement contains a concise description of the needs to be met by the transactions. This project scope statement is also be used for coordination of projects with other standards organizations. In fact, project scope statements must be reported to the ANSI so that ANSI can fulfill its standards coordination role. [1]
Project scope statements are reviewed by the Architectural Review Board (ARB) and must be approved by the HL7 Technical Steering Committee.
The development of V3 messages follows the methodology specified by the HL7 Modeling and Methodology Work Group. HL7 may amend the methodology from time to time. The methodology includes a definition of work products delivered by the Work Groups. Portions of these work products are designated for one of three different treatments:
The methodology specifies the following requirements. These are annotated to indicate the work products described in the V3 Guide that meet the requirements. The annotations further state whether the work product is normative or informative.
Requirement | V3 Guide Construct(s) | Level |
---|---|---|
A means of providing context to the definitions of trigger events | Storyboards, state diagrams | Informative |
A means of specifying the information content of messages through a common information model that clarifies the definitions and ensures that they are used consistently across all V3 messages defined by all Work Groups | Reference Information Model | Reference |
A means of specifying responsibilities of the senders and receivers of messages | Interaction model | Normative |
A common description of the exact fields of a message and their grouping, sequence, optionality, and cardinality | Hierarchical Message Descriptions | Normative |
Separate syntax specifications, describing the algorithms used to encode and transmit the messages in an XML based character stream syntax | Implementation Technology Specifications | Normative |
The Modeling and Methodology Work Groups does not have the right to determine the contents of work products created by the other Work Groups. It serves to facilitate their development and to negotiate changes among the functional Work Groups to ensure standard-wide consistency. If disputes cannot be resolved by the Work Groups and/or the Modeling and Methodology Work Group, they shall be resolved by the TSC.
In order to ensure the highest quality of the work products produced during the course of V3 message development, the HL7 Board of Directors has created the Architectural Review Board (ARB).
The ARB works with the Work Groups and Modeling and Methodology Work Group to define quality measures for the HL7 work products, measure the work products again them, and ensure that adherence to the defined message development process is documented in a manner consistent with HL7 bylaws and procedures. The ARB does not have the right to amend work products or disallow their distribution. It does have the right to include with any work product a statement describing areas where it has determined that the work product has not met established measures of quality.
As a general matter, the ARB is expected to include a statement of its findings in an HL7 general ballot package. However, in order to assist Work Groups, and to avoid delaying the balloting process, the ARB attempts to make any significant comments as early in the ballot cycle as possible.
Disputes with the findings of the ARB are resolved through the TSC and, if necessary, the Board of Directors.
The Getting Started section provides guidelines and recommendation for how you should approach the HL7 V3 Publication. Each section below depicts a type of HL7 customer based on his or her relationship to the HL7 standard/organization. Locate the type of user that most closely reflects your experience level. The documentation includes recommended reading that will help you build the HL7 V3 knowledge base you desire.
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.
Learning the basics means becoming familiar with the basic terminology and methodology behind HL7. You would expect to learn the basic principles upon which HL7 V3 was constructed. Upon completion of this use case, you would be prepared to learn more detailed information about V3.
While learning the basics, refer to:
Managers are responsible for hiring qualified HL7 analysts and programmers. They must supervise interface development and implementation efforts. They do not need to understand all of the details of creating an HL7 message, but they need to understand the concepts enough to review contacts, conformance statements, and assess the skills of their team.
The Project Manager is responsible for ensuring the project is completed within budget, on time, and within scope. Project Managers are not interested in all the details of creating an HL7 V3 message, but they need to understand the concepts enough to review contacts, conformance statements, and assess the skills of team members.
A Marketer is responsible for selling HL7 interfaces. Marketers do not need to know the details, but must understand the major concepts and terminology.
Constructing a site agreement involves creating a specification for two or more parties to communicate using HL7 messages and documents.
When constructing a site agreement, refer to:
The deal requires HL7 interfaces, so in order to sign it a basic understanding of trigger events and message types, but not a detailed understanding of message fields, is required.
When signing a deal, refer to:
Interface Analysts review the interface requirements and write detailed interface specifications.
Interface Programmers code and test interface based on the interface specifications.
Developing an interface requires gathering the interface requirements, analyzing those requirements, developing detailed interface specifications, coding, and testing the interface against the interface specifications and defining a conformance statement.
When developing an interface, you must identify the application section you are working within:
Once you identify the section you can drill down through to the domain messages.
To complete your message development analysis, you will also need to fully understand:
For additional reference, be sure to review:
Standard Developers attend HL7 Working Group Meetings and participate in the creation of the HL7 V3 Standard Specification.
Developing the HL7 Standards involves an understanding of the HL7 Organization and its development methods.
Before committing to HL7 Standards development, review:
Identify the section in which you are most interested.
Once you identify the section you can drill down to the domain messages.
XML Implementation Technology Specification - The XML Implementation Technology Specification defines the representation of HL7 V3 data types and messages in XML, including the method to derive XML DTDs plus additional processing rules from HL7 V3 Hierarchical Message Descriptions (HMDs).
Return to top of page |