This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Product V2

From HL7Wiki
Jump to navigation Jump to search

Product Brief - V2 - Version 2 Messaging Standard

back to Main_Page

Product Name

Health Level Seven Standard Version 2 - An Application Protocol for Electronic Data Exchange in Healthcare Environments

Topics

Patient Administration
Orders
Queries
Financial Management
Observations
Master Files
Medical Records
Scheduling
Patient Referral
Patient Care
Clinical Lab Automation
Application Management
Personnel Management
eClaims
Materials Management

Standard Category

Health Information Exchange Standards

Integration Paradigm

Messages

Type

Normative, ANSI Standard

Releases

  • ANSI/HL7 V2.2-1996
  • ANSI/HL7 V2.3-1997
  • ANSI/HL7 V2.3.1-1999
  • ANSI/HL7 V2.4-2000
  • ANSI/HL7 V2.5-2003
  • ANSI/HL7 2.5.1-2007
  • ANSI/HL7 2.6-2007
  • In-process: HL7 V2.7 see Project # 204

Implementation Guides

Summary

The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. First released in October 1987 as An Application Protocol for Electronic Data Exchange in Healthcare Environments, Version 2 is a messaging standard that allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Version 2.6, representing the latest update to the Version 2 Standard, was published in January 2008. Version 2.7 is in the final stages of balloting and is expected to be released later this year.

Description

HL7’s Version 2.x messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world. There have been seven releases of the Version 2.x Standard to date.

The HL7 Standard covers messages that exchange information in the general areas of:

  • Patient Demographics
  • Patient Charges and Accounting
  • Patient Insurance and Guarantor
  • Clinical Observations
  • Encounters including Registration, Admission, Discharge and Transfer
  • Orders for Clinical Service (Tests, Procedures, Pharmacy, Dietary and Supplies)
  • Observation Reporting including Test Results
  • The synchronization of Master Files between systems
  • Medical Records Document Management
  • Scheduling of Patient Appointments and Resources
  • Patient Referrals—Specifically messages for primary care referral
  • Patient Care and problem-oriented records.

Version 2.6 represents a major revision to Versions 2.5 and 2.5.1, refining and updating existing messages and adding new messages and domains all based upon proposals submitted and accepted by the HL7 membership. Modifications from Version 2.5.1 include:

  • The addition of a new segment, UAC – User Authentication Credential, to ALL messages
  • The replacement of the TS – Timestamp data type with the DTM – Date/Time data type
  • The replacement of the CE – Coded Element data type with either the CNE – Coded with No Exceptions data type or the CWE – Coded with Exceptions data type
  • The deprecation of the CNN, NDL, LA1 and LA2 data types
  • The inclusion of “external” tables referencing a set of coded values defined and published by another standards organization assigned an HL7 number but without designation as an HL7 table (as was previously the practice)
  • The revision of examples in all chapters to support HIPAA compliance
  • The inclusion of a new chapter supporting electronic messaging transactions of claims and reimbursement data (which is produced for implementations of HL7 outside of the United States; in the United States, HIPAA law mandates an already in-use set of implementation guides of X12 messages for these purposes)
  • The inclusion of a new chapter supporting electronic messaging transactions of supply chain management data within healthcare facilities

Meanwhile, Version 2.7 is currently being balloted at the normative level. Due to its widespread use, Version 2 will, no doubt, continue to play an integral part in healthcare messaging, even with the HL7 Version 3 Normative Edition. HL7 is committed to supporting and extending Version 2 in parallel with Version 3, providing continuity for current installations.

Business Case (Intended Use, Customers)

  • Healthcare Computer Software Vendors to support healthcare facility workflows.

Benefits

  • The V2.x Standards support the majority of the common interfaces used in the healthcare industry globally as well as a framework for negotiations for what is not in the standard. The use of the standard reduces implementation costs and each V2.x version is generally backward compatible.

Implementations/ Case Studies (Actual Users)

  • Too many to mention!
    • Over 95 % of US healthcare organisations use HL7 V2.x
    • More than 35 countries have HL7 V2.x implementations

Resources

Work Groups

Education

Certification Available
  • V2.6 Certified Control Specialist

Presentations

Relationship to/ Dependencies on, other standards

Protocols of interest include the ASC X12 Standards for Electronic Document Interchange, the ASTM 1238 88 Standards for laboratory data reporting, the ACR/NEMA DICOM Standards for imaging and other aspects of Radiology Information Systems, and the IEEE P1157 Standards for Medical Data Interchange (MEDIX). The Working Group has given considerable attention to the relationship of the HL7 Standard and other protocols. A considerable liaison effort is underway. This is described below:

  • a) ACR/NEMA DICOM. The HL7 Working Group maintains an on going liaison with the ACR/NEMA DICOM working group. HL7 and ACR/NEMA DICOM are both members of ANSI’s HITSP.
  • b) ASC X12 Standards for Electronic Document Interchange. ASC X12 is a family of standards that provides both general and specific descriptions for data interchange within a number of industries. The HL7 Version 2.6 Encoding Rules are modeled on the X12 standards, although there are differences. The HL7 Standard needs to accommodate online exchange of individual transactions on LANs. This difference, along with certain applications issues, is responsible for the variance from X12. X12 has recently decided to follow the UN/EDIFACT encoding rules for all X12 standards produced in 1995 or later. X12N transactions that facilitate the transfer of healthcare claims and remittance information as well as benefit coordination, enrollment and verification are enjoying dramatically increased use. HL7 has elected to assume that all new business transactions between institutions regarding the interchange of claims, benefits, or other financial information are the responsibility of ASC X12N, the insurance subcommittee of X12.
In 2005, HL7 and X12 signed an update to a long-standing agreement between the organizations to create and extend comprehensive standards in the healthcare community.
  • c) ASTM 1238.94 Laboratory Data Reporting. An active liaison effort between the ASTM committee and the Working Group has resulted in minor changes in the ASTM specification to enhance compatibility, changes in the HL7 Version 2.6 control specifications to enhance compatibility, and the development of the entire Ancillary Data Reporting chapter, developed jointly by the committees and built on the ASTM Standards. This liaison has extended to the point where both groups now have the permission to freely use the contents of each others' standards efforts “in whole” within their own published standards.
Some distinctions are more in the terminology chosen than the actual message content. For example, the ASTM “sub field delimiter” is generally used to separate repetitions of homogenous values. It is called a “repetition separator” in HL7 Version 2.6. HL7 and ASTM are both members of ANSI’s HITSP.
  • d) IEEE P1157 (“MEDIX”). The MEDIX committee has defined an application-level protocol similar in scope to HL7 but built strictly on the ISO protocol stack, up to and including the Remote Operation Service Element (ROSE). HL7 varies from this approach by the decision not to depend on ROSE nor use the ASN.1 BER syntax notation. Despite the difference in approaches, the HL7 Working Group has regular liaison with the MEDIX committee. The Working Group has devised a format for the HL7 Standard that is relatively independent of the encoding rules chosen and easily translated into the ASN.1 notation. The transactions defined in this manner should be directly transferable to the MEDIX effort, and transaction messages encoded using the HL7 scheme should be translatable to transactions encoded using the BER. This should facilitate the creation of gateways between the HL7 and future environments.
In addition, HL7 and MEDIX have agreed on a course for convergence. This will occur within the HL7 Version 2.6 and HL7 Version 3 abstract message definitions. MEDIX has further agreed to use the HL7 abstract message definitions as defined in Version 2.1 as a starting point for the MEDIX message definitions.


HL7, IEEE, and X12 are ANSI-approved standards developers.

Links to current projects in development

  • In-process: HL7 V2.7 see Project # 204