Why do we require HL7?
Hospitals, doctors, and other healthcare centers around the world require the ability to send and receive healthcare data, including patient information and various lab reports. As a result, vast amounts of healthcare information are exchanged on a daily basis.
This information is normally stored in some non-standard format. To transmit the information, the data must be converted from one format to another.
Since the data is both time and content sensitive, there need to be a transparent solution to resolve the information conversion problem.
HL7 - The Solution
The language that has been developed to overcome these obstacles is HL7.
Utilizing the HL7 standard, a protocol designed specifically for health care sector, the issue of data exchange between systems can be addressed.
The HL7 protocol was developed by the Health Level 7 Organization, which consists of grammar and vocabulary that is standardized so that clinical data can be shared amongst all healthcare systems, and easily understood by all. By using the HL7 messaging protocol as a standard, all systems following the HL7 specifications are able to communicate easily with one another, without the need for information conversion.
New and Ongoing Initiatives
HIPAA
Health Level Seven's initial involvement in the HIPAA legislation began in 1996 with the formation of the Claims Attachments special interest group (since re-named simply the Attachment special interest group.) The Attachment Special Interest Group was formed to standardize the supplemental information needed to support health care insurance, and other e-commerce transactions. The initial deliverable of this group was six recommended Claims Attachments for the Notice of Proposed Rule Making (NPRM) process. Future attachment projects include, but are not limited to, Home Health, Skilled Nursing Facility, Durable Medical Equipment (DME), End Stage Renal Disease (ESRD), and Pre-Authorization and Referrals. An important effort as guided by the Board of HL7 the, Attachment special interest group is tasked with assisting in the implementation of the Administrative Simplification provisions of HIPAA mandates, providing on-going support, and to represent HL7 in the HIPAA Designated Standards Maintenance Organization (DSMO) efforts. Its purpose is to encourage the use of HL7 for uniform implementation of this supplemental information. This SIG coordinates industry input to produce and maintain guides for HL7 messages that can stand alone or be embedded within ASC X12N transactions.
Specifications
The Messaging Standard
Version 3.0
Version represents a significant departure from "business as usual" for HL7. Offering lots of optionality and thus flexibility, the V2.x series of messages were widely implemented and very successful. These messages evolved over several years using a "bottom-up" approach that has addressed individual needs through an evolving ad-hoc methodology. There is neither a consistent view of that data that HL7 moves nor that data's relationship to other data. HL7's success is also largely attributable to its flexibility. It contains many optional data elements and data segments, making it adaptable to almost any site. While providing great flexibility, its optionality also makes it impossible to have reliable conformance tests of any vendor's implementation and also forces implementers to spend more time analyzing and planning their interfaces to ensure that both parties are using the same optional features. Version 3 addresses these and other issues by using a well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date. Using rigorous analytic and message building techniques and incorporating more trigger events and message formats with very little optionality, HL7's primary goal for Version 3 is to offer a standard that is definite and testable, and provide the ability to certify vendors' conformance. Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.
Version 2.5
APPROVED AS AN ANSI STANDARD JUNE 26, 2003.
The HL7 Version 2 Messaging Standard - Application Protocol for Electronic Data Exchange in Healthcare Environments - is considered to be the workhorse of data exchange in healthcare and is the most widely implemented standard for healthcare information in the world.
HL7 Version 2.5 introduces a number of new events, segments and messages, as well as a significantly expanded chapter on Control. Version 2.5 is more consistent and supports more functionality than any of the previous versions. Modifications from Version 2.4 include:
* Improved documentation of the data types
* The definition of a message profile methodology
* Better support for imaging (IHE) by means of a new segment and a new order message
* Support for orders related to blood products
* A new message that supports diagnoses/procedure messages in 'update' mode
Version 2.4
APPROVED AS AN ANSI STANDARD OCTOBER 6, 2000.
HL7 v.24 introduces Conformance Query profiles in chapters 5, and adds messages for laboratory automation, application management and personnel management. Additionally, a new event, specific to OPPS and APC requirements was added. This event, Transmit Ambulatory Payment, includes two new segments, the Grouping/Reimbursement Visit Segment and the Grouping Reimbursement Procedure Segment.
Version 2.3.1
APPROVED AS AN ANSI STANDARD April 14, 1999.
HL7 V.2.3.1 includes an updated TQ (timing/quantity) datatype to manage order occurrences, updates to the OBR segments and ORU message to facilitate public health surveillance reporting, updates to tables, segments and data types to accommodate international paradigms for reporting names and pharmacy orders, and the addition of a new field to the ORC segment to satisfy the HCFA Medical Necessity requirements for outpatient services, and an update to the FT segment to satisfy federal requirements for Level 2 Modifiers.
Version 2.3
APPROVED AS AN ANSI STANDARD April 14, 1999.
HL7 V.2.3 includes an updated TQ (timing/quantity) datatype to manage order occurrences, updates to the OBR segments and ORU message to facilitate public health surveillance reporting, updates to tables, segments and data types to accommodate international paradigms for reporting names and pharmacy orders, and the addition of a new field to the ORC segment to satisfy the HCFA Medical Necessity requirements for outp atient services, and an update to the FT segment to satisfy federal requirements for Level 2 Modifiers.
The structure of the Version 2.3 publication is highlighted below.
APPROVED AS AN ANSI STANDARD May 13, 1997
HL7 V.2.3 introduces document management messages, messages for appointment servicing and resource scheduling, messages for patient referrals and messages to track patient goals.
With years of experience in successfully providing Custom healthcare Software Development solutions for clients across the globe, we have honed our processes and skills to cater to your specific business needs. For outsourcing your EMR software development requirements to Binary Spectrum, contact us with your project details at info@binaryspectrum.com. A senior member of our customer engagement team will get in touch with you within 24 hours. Become a member of family of clients that regularly do business with us.
