PURPOSE

This document contains the specifications for Version 2.9 of the Health Level Seven (HL7) Standard for electronic data exchange in all healthcare environments, with special emphasis on inpatient acute care facilities (i.e., hospitals). It summarizes the work of a committee of healthcare providers (i.e., users), vendors and consultants established in March 1987 on the occasion of a conference hosted by Dr. Sam Schultz at the Hospital of the University of Pennsylvania. Its participants, who represent users as well as vendors and a wide variety of other segments in the international healthcare market, share a common goal of simplifying the implementation of interfaces between computer applications from different, and often competing, vendors. This committee, which subsequently became known as the HL7 Working Group, endeavors to standardize the format and protocol for the exchange of certain key sets of data among healthcare computer application systems. Meetings are held approximately every four months in scattered locations throughout the United States, and, increasingly, in international locations. At present, HL7 sanctioned national groups exist outside of the United States, including Argentina, Australia, Austria, Bosnia, Brazil, Canada, China, Croatia, Czech Republic, Denmark, Finland, France, Germany, Greece, Herzegovina, Hong Kong, India, Italy, Japan, Korea, Malaysia, Mexico, New Zealand, Norway, Pakistan, Phillippines, Puerto Rico, Romania, Russia, Singapore, Slovenia, Spain, Sweden, Switzerland, Taiwan, The Netherlands, Turkey, The United Kingdom and Uruguay.

This document is being presented to interested parties. It is a status report that is periodically published to solicit the involvement of the broadest possible group of participants as this protocol is being put into use. Comments are solicited on all aspects of this and other HL7 Standards.

HL7 Version 2.9 represents HL7’s latest development efforts to the line of Version 2 Standards that date back to 1989. HL7 Version 2.9 is deemed necessary to incorporate changes required by work groups, regulation changes, and new requirements of membership, as demonstrated by proposals submitted. All chapters were updated with respect to ACK choreography. In addition, the proposed changes are modifications or additions to the Chapter 2C, Chapter 4, Chapter 4A, Chapter 7, Chapter 8, Chapter 13 and Chapter 17.  

1. General

   1. Applied the errata that were identified with V2.8.2.

   2. Deprecated ROL segment with inclusion of PRT segment as more robust and flexible.

2. Chapter 2C

   1. Chapter 2C generated with updated content

   2. Other changes as identified in V2 proposals tracker at https://gforge.hl7.org/gf/project/v2-ballot-pkg/tracker/?action=TrackerItemBrowse&tracker_id=1035.

3. Chapter 3

   1. Added Occupational Data for Health content

   2. Updated fields for ARV segment for security

4. Chapter 4

   1. Order Entry: General, Laboratory, Dietary, Supply, Blood Transfusion – updates to events and segments such as OMG, OML, ORC, OBR, BPO

5. Chapter 4A

   1. Order Entry: Pharmacy/Treatment, Vaccination – updates to events and segments such as RGV, RDE, RRE

6. Chapter 7

   1. Observation Reporting – updates to messages such as OUL, ORU, OBX, SPM, Patient-connected medical device reporting, and usage notes

7. Chapter 8

   1. Master Files - a new Contract master file message related to Materials Management supply item messaging, clarifications to OM3, OM4, and OM5

8. Chapter 13

   1. Laboratory Automation - a new DST segment for the EAC message structure to support transport destination, INR/ACK – new trigger event and message structure, clarification of SAC-8, SAC-16, and INV segments, and a new field to TCD segment

9. Chapter 17

   1. Materials Management – new fields added to ITM, VND, and PKG segments.

The HL7 balloting effort continues to yield standards that are open to all who develop healthcare data processing systems. The experience gained as this and other HL7 Standards have been put into production is reflected in this latest revision of the Version 2 Standards.

HL7 is operating under formal bylaws and balloting procedures. These procedures are modeled on the balloting procedures of other relevant healthcare industry computer messaging standards organizations (e.g., ASTM) and are designed to conform to the requirements of the American National Standards Institute (ANSI). ). In June 1994, HL7 became an ANSI Accredited Standards Developing Organization (SDO). HL7 is a founder of the ANSI SDO Charter Organization (SCO) and chaired it in 2011-2012. The other members of the SCO include: The National Council for Prescription Drug Programs (NCPDP), X12N (ASC X12 Insurance Committee), ADA (The American Dental Association), GS1 (International Standards for Bar Codes and Supply Chain), ISO TC 215 (International Medical Informatics), IHE, Regenstreif Institute’s Logical Observation Identifiers, Names and Codes (LOINC), National Library of Medicine for US Systemized Nomenclature for Medicine (SNOMED). And “Standards Related Groups" including IHE (Integrating the Health Enterprise), HIMSS (Health Information Management Systems Society), and WEDI (Workgroup for Electronic Data Interchange).

ANSI approval dates HL7’s Version 2 standards are noted below:

• Version 2.2 - February of 1996.

• Version 2.3 - May of 1997.

• Version 2.3.1 - April of 1999.

• Version 2.4 - October 2000.

• Version 2.5 - July of 2003.

• Version 2.5.1 - Feburary of 2007

• Version 2.6 – October 2007

• Version 2.7 – February 2011

• Version 2.8 – February 2014

• Version 2.8.1 – April 2014

• Version 2.8.2 – July 2015

As an organization, HL7 has experienced significant growth over the last several years. Currently, HL7’s membership consists of approximately 2200 members in all membership categories and regularly attracts 450-500 members and non-members to each of its three yearly meetings.

For a current listing of all HL7 ANSI-approved standards, please refer to the HL7 web site (hl7.org).

BACKGROUND

The HL7 Working Group is composed of volunteers who give their time on a personal basis or under sponsorship of their employers. Published standards (including this HL7 V2.9 Standard) and other products are freely available to everyone who registers and agrees to the terms of HL7's IP policy. Members have the added advantage of having access to all materials immediately upon publication while, in general, non-members must wait three months from the date of publicat to access materials. In addition, members have the right to use HL7 standards in their products and to create derivitive works; non-members have the right to read the standards, but not use them in their products. Those wishing more information are referred to the IP Compliance policy on HL7's web site at hl7.org/legal/ippolicy.cfm.

Membership in the HL7 Working Group has been, and continues to be, open to anyone wishing to volunteer and contribute to the development and refinement of any HL7 Working Group Standard and the work that supports those Standards.

The term “Level 7” refers to the highest implementation protocol level for a definition of a networking framework as presented in the Open System Interconnection (OSI) model of the International Standards Organization (ISO) and CCITT (French Acronym for the Consultive Committee for Interntational Telephone and Telegraph). 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 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 (or at least in an attempt to be clear), 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 HL7 Version 2 Standard currently addresses the interfaces among various healthcare IT systems that send or receive patient admissions/registration, discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, clinical observations, billing, master file update information, medical records, scheduling, patient referral, patient care, clinical laboratory automation, application management and personnel management messages. It does not try to assume a particular architecture with respect to the placement of data within applications. Instead, HL7 Version 2.9 serves as a way for inherently disparate applications and data architectures operating in a heterogeneous system environment to communicate with each other. As an example, HL7 Version 2.9 is designed (and used) to support a central patient care system as well as a more distributed environment where data resides in departmental systems.

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 that 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 for Version 2.9 to be a complete standard for these interfaces, built on a generic framework that is sufficiently robust to support many other interfaces. The HL7 Version 2.x family of standards has been put into production and is being used as a basis for extending the existing interface definitions and also adding other definitions.

It is expected that one result of publishing this specification will be the recruitment of more Working Group members with special interests in some newer and not yet fully specified areas. Some of the areas that have already been identified are:

1. decision support

2. additional specific ancillary departments

3. information needs associated with healthcare delivery systems outside of the acute care setting

4. clinical genomics

5. pediatrics

6. emergency medicine

The above notwithstanding, the Working Group members feel that the interfaces addressed here are sufficient to provide significant benefits to the healthcare community. Active Work Groups exist for the domain areas listed above. All interest in contribution to future development of this Standard, these specified growth areas or any other areas of Medicin or Health Information Technology are welcome to join HL7 and work with us.

This document is structured as follows. The balance of this chapter contains a rationale for developing the HL7 Version 2.9 Standard, the goals of the Standard, and issues that have been considered by the Working Group pertaining to scope and operational approach. It is hoped that this will help the readers understand the basis for decisions that have been made in developing the Standard. Subsequent chapters specify, respectively:

• Chapter 2 – Control – overall structure for all interfaces including a generalized query interface.

• Chapter 2A – Data Types – provides definitions for all HL7 V2 data types.

• Chapter 2B – Conformance – using message profiles for conformance.

• Chapter 2C-Code Tables – a listing of all tables of information used in the standard.

• Chapter 3 – Patient Administration - admission, discharge, transfer and registration

• Chapter 4 – Order Entry – messages for the transmission of orders or information about orders between applications that capture the order, by those that fulfill the order, and other applications as needed. These services include medications from the pharmacy, clinical observations (e.g., vitals, I&Os) from the nursing service, tests in the laboratory, food from dietary, films from radiology, linens from housekeeping, supplies from central supply, an order to give a medication (as opposed to delivering it to the ward), etc.

• Chapter 4A – Order Entry: Pharmacy/Treatment, Vaccination – messages for the transmission of orders or information about orders specific to pharmacy/treatment and vaccines.

• Chapter 5 – Query - defines the rules that apply to queries and to their responses.

• Chapter 6 – Financial Management - patient accounting (billing) systems

• Chapter 7 – Observation Reporting – clinical observation data, such as laboratory results, that are sent as identifiable data elements (rather than display-oriented text)

• Chapter 8 – Master Files – a generalized interface for synchronizing common reference files (master files)

• Chapter 9 – Medical Records/Information Management – medical information management

• Chapter 10 – Scheduling – patient and resource scheduling

• Chapter 11- Patient Referral – patient referral messages for referring a patient between two institutions

• Chapter 12 – Patient Care - patient care messages that support communication of problem-oriented records, and to provide functionality for the implementation of clinical pathways in computer information systems

• Chapter 13 - Clinical Laboratory Automation – messages that communicate information essential for a Laboratory Automation System (LAS) to control the various processes and to ensure that each specimen or aliquot has the correct tests performed in the proper sequence.

• Chapter 14 – Application Management - messages that provide a means to manage HL7-supporting applications over a network

• Chapter 15 – Personnel Management – messages for transmitting new or updated administration information about individual healthcare practitioners and supporting staff members.

• Chapter 16 – messages to support Claims and Reimbursement (CR) for the electronic exchange of health invoice (claim) data outside of the US.

• Chapter 17 – Materials Management – messages for communicating various events related to the transactions derived from supply chain management within a healthcare facility.

NEED FOR A STANDARD

The organization and delivery of healthcare services is an information-intensive effort. It is generally accepted that the efficacy of healthcare operations is greatly affected by the extent of automation of information management functions. Many believe that healthcare delivery agencies that have not automated their information systems are also not able to participate effectively in the healthcare market of the 21st Century.

In the past four decades, healthcare institutions, and hospitals in particular, have begun to automate aspects of their information management. Initially, such efforts were focused towards reducing paper processing, improving cash flow, and improving management decision making. In later years a distinct focus on streamlining and improving clinical and ancillary services has evolved, including bedside (in hospitals and other inpatient environments) and “patient-side” systems (in ambulatory settings). Within the past 15 years, interest has developed in integrating all information related to the delivery of healthcare to a patient over his or her lifetime (i.e., an electronic medical record). In the last 5 years we have begun focusing on the challenges of integrating the health data in these electronic medical records (or electronic health records (EHRs)) among patient care organizations, and most recently among countries. We can now envision an electronic medical record that can be communicated electronically, in part or in whole, anywhere as needed.

Today, growing numbers of hospitals have installed computer systems to manage a wide range of their information needs – admission, discharge and transfer; clinical laboratories; radiology; billing and accounts receivable, to cite a few. Often these applications used for specific areas have been developed by different vendors or, occasionally, by in-house groups, with each product having highly specific information format. As hospitals have gradually expanded information management operations, a concomitant associated need to share critical data among the systems has emerged. Comprehensive systems that aim at performing most, if not all, healthcare information management are in production by many vendors. These systems may be designed in a centralized or a distributed architecture. Nevertheless, to the extent that such systems could be and are implemented as truly complete, their use would lessen the need for an external data interchange standards such as HL7.

There are, however, many pressures on an institution to develop or acquire individual departmental applications on a modular basis. One source of such pressure is the special departmental needs that may not be addressed well (or perhaps at all) by a comprehensive vendor (i.e., so called “best-of-breed”). Another is the need to evolve the overall systems environment of a hospital through a series of incremental, departmental decisions rather than in a single, revolutionary acquisition. These pressures could be met by an environment containing a comprehensive system supplemented by departmental systems, or one consisting entirely of separate and discrete systems.

Network technology has emerged as a viable and cost-effective approach to the integration of functionally and technically diverse computer applications in healthcare environments. However, these applications have developed due to market structure rather than through a logical systems approach; they are therefore often ad hoc and idiosyncratic. At the very least, they do not possess a common data architecture; their combined data storage actually constitutes a highly distributed and severely de-normalized database and the processes that they support can vary significantly. Extensive site-specific programming and program maintenance are often necessary for interfacing these applications in a network environment. This occurs at considerable expense to the user/purchaser and vendor while often keeping vendor staff from other initiatives such as new product development. The need for extensive site-specific interface work could be greatly reduced if a standard for network interfaces for healthcare environments were available and accepted by vendors and users alike.

Finally, the lack of data (or inconsistent data) and process standards between both vendor systems and the many healthcare provider organizations presents a significant barrier to application interfaces. In some cases, HL7 becomes an effective template to facilitate negotiations between vendors and users but cannot, by itself, serve as an “off-the-shelf” complete interface.

In summary, it is important for both vendors and users to avoid the problem of supporting incompatible transaction/communications structures. Instead, at a minimum a framework must be developed for minimizing incompatibility and maximizing the exchange of information between systems. It is proposed that HL7 Version 2.8 can act as a superstructure in this environment to facilitate a common specification and specifications methodology. It is indeed both practical and economical to develop, and commit to, standard interfaces for computer applications in healthcare institutions.

GOALS OF THE STANDARD

As noted above, the specifications of this HL7 Version 2 Standard were developed in accordance with a priori specified goals. Future extensions of the Standard should also support these goals.

HL7’s purpose is to facilitate communication in healthcare settings. The primary goal is to provide standards for the exchange of data among healthcare computer applications that eliminate or substantially reduce the custom interface programming and program maintenance that may otherwise be required. This primary goal can be delineated as a set of goals:

1. The Standard should support exchanges among systems implemented in the widest variety of technical environments. Its implementation should be practical in a wide variety of programming languages and operating systems. It should also support communications in a wide variety of communications environments, ranging from a full, OSI-compliant, 7-level network “stack” to less complete environments including primitive point-to-point RS-232C interconnections and transfer of data by batch media such as tape, CD and USB Flash Drive.

2. Immediate transfer of single transactions should be supported along with file transfers of multiple transactions.

3. The greatest possible degree of standardization should be achieved, consistent with site variations in the usage and format of certain data elements. The Standard should accommodate necessary site-specific variations. This will include, at least, site-specific tables, local code definitions and possibly site-specific message segments (i.e., HL7 Z-segments).

4. The Standard must support evolutionary growth as new requirements are recognized. This includes support of the process of introducing extensions and new releases into existing operational environments.

5. The Standard should be built upon the experience of existing production protocols and accepted industry-wide standard protocols. It should not, however, favor the proprietary interests of specific companies to the detriment of other users of the Standard. At the same time, HL7 seeks to preserve the unique attributes that an individual vendor can bring to the marketplace.

6. While it is both useful and pertinent to focus on information systems within hospitals, the long-term goal should be to define formats and protocols for computer applications in all and among healthcare environments.

7. The very nature of the diverse business processes that exist within the healthcare delivery system prevents the development of either a universal process or data model to support a definition of HL7’s target environments. In addition, HL7 Version 2.8 does not make a priori assumptions about the architecture of healthcare information systems nor does it attempt to resolve architectural differences between healthcare information systems. For at least these reasons, HL7 Version 2.9 cannot be a true “plug and play” interface standard. These differences at HL7 Version 2.9 sites will most likely require some level of site negotiated agreements.

8. A primary interest of the HL7 Working Group has been to employ the Standard as soon as possible. Having achieved this, HL7 has also developed an infrastructure that supports a consensus balloting process and has been recognized by the American National Standards Institute (ANSI) as an Accredited Standards Organization (ASO).

9. Cooperation with other related healthcare standards efforts, which are outlined later in this chapter.

HISTORY OF HL7 Version 1.0 to 2.9 DEVELOPMENT

The HL7 Working Group has met approximately every three to four months since March 1987 to develop and review this specification and, as requirements and ideas have been brought to us over the years, other HL7 standards and work products. The Working Group is structured into Work Groups to address each of the functional interfaces under development, the processes that they support and the content they require, with additional committees to address the overall control structure and various administrative aspects of the group. These committees have the responsibility to author and maintain the chapters in the HL7 Standards. In addition, from time to time Work Groups are formed within HL7 to develop ideas, content and sponsor particular perspectives that are not covered by any single existing committee. (An example of this today is the HL7 FHIR (pronounced “fire”) initiative (hl7.org/fhir) If a Work Group’s activities warrant and a new chapter is considered necessary, they may petition the HL7 Technical Steering Committee Chair and the Board of Directors to form a new Work Group.

In the initial three meetings, a Version 1.0 draft Standard was prepared covering the overall structure of the interfaces, ADT, order entry, and display-oriented queries. Although the patient accounting system was recognized as very important, the time frame did not allow its charing and billing functions to be addressed in the first draft. This draft was presented to a plenary meeting of the overall group in Tyson’s Corner, VA, on October 8, 1987.

Version 2.0 was prepared subsequent to Plenary I in Tyson’s Corner and presented at Plenary II in Tucson in September 1988. Since Plenary II, editing and revisions for Version 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, and 2.8.2 have been ongoing and the Working Group has grown to about 500 individuals, far exceeding its original size of 12, and the following have been achieved:

1. Specifications for the various functional areas have been refined and expanded.

2. Formal agreements have been developed with several other standards efforts:

3. the ANSI HITSP for the coordination of healthcare standards efforts (which more recently has evolved into SCO) and the ASC X12N group for external EDI Standards,

4. The American Dental Association (ADA) Standards Committee on Dental Informatics (SCDI) for standards related to the acquisition, organization, storage and seamless exchange, privacy, security, and utilization of health informatics.

5. the ASTM E31.11 group for Clinical Data Exchange Standards,

6. the ACR/NEMA DICOM group for standards relating to imaging and other aspects of Radiology Information Systems, and the IEEE P1157 group for medical data interchange (MEDIX),

7. the Clinical Data Interchange Standards Consortium (CDISC), for standards to support electronic acquisition, exchange, submission and achiving of clinical trials data and metadata for medical and biopharmaceutical product develoopment

8. The National Council for Prescription Programs, for standards related to pharmacy insurance billing and ajudication as well as NCPDP’s Script Standard for ambulatory care electronic prescribing to retail and mail order pharmacies.

9. International Health Terminology Standards Development Organization (IHTSDO) which fosters the develop and use of suitble standardied clinical terminologies, notibly SNOMED;

10. And Several more…

Throughout the years HL7 has continued these formal agreements. The current list of organizations and the agreements that HL7 has with them can be found on the HL7 web site at: http://www.hl7.org/about/agreements.cfm.

1. The generic control structure was modified, on the basis of industry comments, to be adaptable to a wider variety of communications environments and to facilitate cooperation with other standards groups. (e.g. ISO TC 215 Electronic Health Record Functional Standard (13606) and ISO TC 215 Data Types (21090) both adopted from existing HL7 Standards.

2. A chapter on the interface to a patient accounting system has been added.

3. A chapter on the reporting of ancillary results, clinical trials, product experience and waveform data has been prepared, harmonized with the ASTM 1238-91 Standard and with the direct, active participation of members of the ASTM E31.11 committee.

4. A chapter with a set of transactions to support the synchronization of master files between related information systems has been added.

5. A chapter on the interface to applications that support medical record functions including transcription management, chart location and tracking, deficiency analysis, consents and release of information has been added.

6. A chapter on messages to support the communication of various events related to the scheduling of appointments for services or for the use of resources has been added.

7. A chapter defining the message set used in patient referral communications between mutually exclusive healthcare entities has been added.

8. A computerized data dictionary of all data elements and other message components has been created. Appendix A contains cross references and other information generated from this electronic data dictionary.

9. Extensive additions have occurred in the Order/Entry and Clinical Observations chapters to include data element oriented results, pharmacy orders and administrations interface.

10. Message acknowledgments have been extended to include a separate enhanced mode that defines the “accept acknowledgment.” While this mode of acknowledgment has always been allowed, it is now obvious how HL7 supports any environment when intermediaries exist in the network with implicit time delays (such as store and forward services, “Interface Engines” that perform fan out services, etc.). Immediate acknowledgments are available to release the sending system from the need to resend the message.

11. Distinctions have been documented between the HL7 abstract message definition which is purely a level 7 (application level) definition vs. the HL7 encoding rules for converting an abstract message into a string of characters that comprises an actual message. These encoding rules are actually a suggested potential alternative where a fully defined level 6 (presentation level) definition does not exist (e.g., ISO’s ASN.1 Basic Encoding Rules (BER)).

12. The Patient Care Work Group was created and designed messages to support the communication of problem-oriented records, including clinical problems, goals, and pathway information between computer systems. Patient Care healthcare messages are communicated between clinical applications for a given individual.

13. The Clinical Laboratory Automation chapter was created to develop messages to facilitate the integration or interfacing of automated or robotic transport systems, analytical instruments, and pre- or post-analytical process equipment such as automated centrifuges and aliquoters, decappers, recappers, sorters, and specimen storage and retrieval systems. In addition to the electrical and mechanical interfaces of these various components, the computers that control these devices or instruments must also be interfaced to each other and/or the Laboratory Information System (LIS). These are now found in Chapter 13 since HL7 Version 2.8

14. Specifications on Network Management that were previously contained in a non-normative appendix to the Standard were further developed to more accurately describe the purpose of the messages described herein. This chapter was named “Application Management” and does not specify a protocol for managing networks, à la TCP/IP SNMP. Rather, its messages provide a means to manage HL7-supporting applications over a network. As a technical chapter, this information is now normative beginning with the HL7 Version 2.8 standard and found in Chapter 14.

15. The Personnel Management Work Group was created to develop Personnel Management transactions set provides for the transmission of new or updated administration information about individual healthcare practitioners and supporting staff members. Since many systems (e.g., security, scheduling, orders, etc.) must be able to closely monitor changes in certain information regarding individual healthcare practitioners, the Personnel Management transaction set is used to clearly identify these events. For example, it is important to a Security System to be aware of when a staff member was hired or specific role has been terminated.
    
    Prior to Version 2.4, master file updates were the only method to update this information. However, when any of these changes are reported as master file update notifications, it is not obvious which of the specific items of data has been changed, and these changes are cumbersome to process efficiently. It should be noted that Personnel Management functions that do not affect healthcare administration (e.g. benefits) are not addressed in this chapter.

16. When HL7 Version 2.5 was created the Control Committee consolidated all definitions of data types that were previously distributed across all chapters of HL7 and created a second chapter 2 (2A) that is a dictionary of all data types used in HL7 Version 2.5 and now HL7 Version 2.9. These definitions were also removed from their previous chapters and corrections were made when two or more chapters had conflicting definitions of data types.

17. HL7 Version 2.5.1 — as an extension of Version 2.5 is due to a recent interpretation of the requirements of the Clinical Laboratory Improvements Amendment (CLIA) of 1988 related to the exchange of electronic laboratory information with supplemental agencies. HL7 was informed of a need to include a limited number of additional fields that were located in the OBX Segment of Version 2.5 to support compliance. Although we have not been able to confirm requirements throughout the European Union, the addition of these elements to the OBX may also facilitate meeting the laboratory reporting requirements stipulated by the United Kingdom Accreditation Service [UKAS] and Clinical Pathology Accreditation (UK) Ltd [CPA].

18. A chapter defining messaging specifications supporting claims and reimbursement for the electronic exchange of health invoice (claim) data has been added. These specifications are intended for use by benefit group vendors, third-party administrators (TPA) and payers who with to develop software that is compliant with an international standard for the electronic exchange of claim data. (This chapter is produced for implementations of HL7 outside of the United States where the HIPAA law mandates an already in-use set of implementation guides of X12 messages for these purposes.)

19. A chapter defining the abstract messages for purposes of communicating various events related to the transactions derived from supply chain management within healthcare facilities has been added. This chapter includes inventory and sterilization messaging. The inventory item master file segments published in this chapter are based on master file add and update messages between applications such as materials management, scheduling, and sterilization applications.

OVERVIEW

This section contains a description of the conceptual basis of the HL7 Version 2.9 Standard, the approach to accommodating intra-site variations and evolutionary changes, and the way it has been structured in order to accommodate varying current and future communications environments.

THE SCOPE OF HL7

It is useful to understand both what HL7 Version 2.9 is and what it is not. This chapter, up to this point, represents some effort to give the reader an overall understanding of HL7 by looking at purpose, history, and some of its overall features and architecture. It is also of value to understand the “edges” or limitation of HL7. HL7 Version 2.9 can, and routinely does, provide a considerable service in everyday use today in thousands of locations and in many different countries, However, there are certainly many areas of healthcare system integration that HL7 does not address or addresses with what may prove to be an inadequate or incomplete solution.

Many of these topic areas are being worked on today by HL7 and will, hopefully, appear in later versions of this balloted Standard or other HL7 balloted Standards. Some of these other topics may never be addressed by HL7 because they are being addressed by some other standards body. Still other areas may never be addressed by HL7 due to a lack of interest, or at least available energy by its members.

In any case, it is certainly useful for the analyst to understand what these boundaries are and to then either choose to solve them in some other way or to merely ignore them if they are deemed not sufficiently important. The following features listed in this section may well be best served by the participating applications themselves. However, it is possible to conceive of an architecture that expects these features to be present in the messaging standard itself. These potential deficiencies are included to give the reader a complete view.

REFERENCE DOCUMENTS

TECHNICAL EDITORS

The updates reflected in HL7 V2.9, were edited for technical content by:

For a list of editors of the chapters in V2.9, please see the individual chapter’s front page.

SUGGESTIONS AND COMMENTS

The HL7 Working Group welcomes comments and suggestions for improving the Standard. The Working Group is also open to new membership. Both feedback on the Standard and interest in membership should be sent to:

Errata

The item below constitutes the know errata at the time of publication. Users of the standard are advised to refer to the HL7 web site (www.HL7.org) for a current Errata listing.

Issue: Use of "etc." in various segment choices

• Resolution: The "etc." is used as a placeholder for various choice alternatives that may be represented in the abstract message syntax (AMS). "Etc." should be interpreted as meaning any segment can be used in this location; that is, "etc." does not limit your choice of segment or segment groups, except for MSH and other transmission control segments. In the future, explanation will be added to Chapter 2, section 12 proposing the use of "Hxx" as a formal representation in circumstance where a choice of any segment or segment group is allowed.

Issue: Use of Opening and Closing Angle Brackets around Segment Groups

• Resolution: In the standard, we have named required and non-repeating segment groups. The standard uses opening and closing angle brackets to delineate these segment groups. This is used to indicate that you have a choice of "one of one" in these representations, effectively making them required, named segments. This formalism allows for a better representation of the standard in languages such as XML and solves the problem of attaching a name to a group.

Issue: Incorrect Element Definition for REL-12 Negation Indicator in Chapter 12, Section 12.4.5.12

• Currently the definition for this element reads "This field contains the date range relevant to the assertion of the relationship." However, this is incorrect. The correct definition should read "This field, if populated and set to true, indicates that the given relationship is not true or does not exist."

• Resolution: As this change is substantive, a proposal to formally change the definition will be brought forward in Version 2.9. Until this correction can be made, users of the standard are advised to consider the alternate definition above when using this element.

Issue: Ambiguous Use of CWE Data Type in Element Definition for TCC-15 Test Criticality in Chapter 13, Section 13.4.9.15

• Currently the definition for this element indicates that a CWE data type is used; however, the definition also advises that the element can be populated with "a sequential number of the test sorted according to the criticality assigned by the lab". In general practice, the CWE data type references a table of assigned values, recognizing that those values are often assigned by the user. It is expected that the definition for this element will be reviewed and revised with the next release.

Additional Issues Carried Forward from Version 2.7

• Implementers of the standard should be aware that the length of MSA-2 Message Control ID in the Message Acknowledgement Segment (Chapter 2, section 2.14.8.2) is incorrectly identified as 20. This is out of alignment with MSH-10 Message Control ID in the Message Header Segment (Chapter 2, section 2.14.9.10) which has a length of 199. The correct length of MSA-2 Message Control ID should be 199 in order to bring it in to synchrony with MSH-10.

• HL7 International has discovered a backwards compatibility issue in Versions 2.6 and 2.7 related to the fields provided in the table below. Each of these fields is a telephone number, is of XTN data type and is repeating. The <preference order> component was added to the XTN data type in Version 2.6 to allow for an entity having multiple telecommunication addresses to indicate which is the "most preferred" (lowest number) to "least preferred" (highest number). In addition, the new XTN data type allows entry of more than telephone number (e.g., email address).
  
  To be fully backwards compatible the following fields, shall:

  • Be populated with data that is consistent with the field usage as described in the text (i.e., the business phone number field must identify business phone as the most preferred phone number)

  • Include only phone numbers; other information such as email addresses shall not be entered.

hiddentext