header

Health Level Seven (HL7)

What is Health Level Seven (HL7)?

Hl7 refers to the health standard developed by the all-volunteer non-profit organization which is also called HL7.  Health Level Seven is an ANSI-accredited Standards Developing Organizations (SDOs) on providing standards for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of healthcare services. Their mission is to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems.

Membership is made up of providers, vendors, payers, consultants and government agencies interested in the advancement of clinical and administrative standards for healthcare. They adheres to operating procedures that ensures consensus, openness and balance of interest. The end product of their efforts are messaging specifications that enables applications to exchange, management and integration of clinical and administrative data.

What Does the Name HL7 Mean? 

"Level Seven" refers to the highest level of the International Standards Organization's (ISO) communications model for Open Systems Interconnection (OSI)  the application level. The first six deal with 1. Physical Layer; 2. Data Link Layer; 3. Network Layer; 4. Transport Layer; 5. Session Layer; 6. Presentation Layer. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application, and supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.

Why is this important

In an environment where health constituents are inter-dependent for the swift delivery of quality healthcare it is imperative that their communications be efficacious, rapid and accurate. Their goal is technological interoperability. Hospitals and other healthcare provider organizations have many different computer systems and application (from diagnostics, reporting, records, billing, patient tracking). These systems should communicate with each other - however one can only surmise the challenge of interfacing with so many multiple systems and nodes and data structures.  This is where HL7 becomes essential by setting out flexible standards, guidelines, and methodologies by which various healthcare systems can communicate with each other, and allow information to be shared and processed in a uniform and consistent manner. It is about structuring and packaging data.
HL7 develops several set of standards that can be grouped as Conceptual Standards (e.g., HL7 RIM), Document Standards (e.g., HL7 CDA), Application Standards (e.g., HL7 CCOW), and Messaging Standards (e.g., HL7 v2.x and v3.0).

Challenges and Answers.

Medical data needs to be delivered and received: its structure, content and source and uses are so diverse that any platform looking to facilitate its packaging, shipping and reception needs to be very flexible, in particular in the fast moving world of digitization, wireless connectivity and and speed. And this is where HL7 makes its case (and shortfall). While looking to manipulate diverse data segments and connect system handshakes it proposes flexible rules and options that can be integrated in their own system communication. This flexibility opens up yet the adoption of protocols personal to each user.

So while providing great flexibility, its plasticity engenders problems with validation and integrity of connections and forces parties to ensure conformance of options and readiness of their respective interfaces. This, unfortunately must be done on a piecemeal basis.

Version 3 addresses this issue in part by setting a reference  methodology that will facilitate the testing a nodes’ conformance. It uses a Reference Information Model (RIM) by setting the representation of the semantic and lexical connections that exist between the data fields of HL7 messages.

The HL7 Standards

Version 2.x Messaging Standard

V2 Messages is an interoperability specification for transactions produced and received by computer systems to support administrative, logistical, financial as well as clinical processes (labs, pharmacy). Since 1987 the standard has been updated seven times and are referred collectively as version 2.x. The v2.x standards are backwards compatible: this means that a message based on version 2.3 will be understood by an application that supports version 2.6.

Version 3 Messaging Standard

V3 Messages is an interoperability specification for transactions that are derived from the HL7 V3 Foundation models and vocabulary and define communications produced and received by computer systems. V3 Messages include the concepts of message wrappers, sequential interactions, and model-based message payloads. The v3 standard, as opposed to version 2, is based on a formal methodology and object oriented principles. The diffusion of V3 is the RIM (see above)

Version 3 Rules/GELLO

GELLO is a standard expression language for decision support. GELLO was designed to leverage the semantics of the RIM models, in combination with HL7 Vocabulary and Data Types,

Arden Syntax

Arden is a "rules syntax" specification that allows rules to be individually published independently of a computer system and subsequently imported into computer systems for healthcare use. Arden implementation guides are published in a modular format by content providers, a guide for each rule.

CCOW / Visual Integration

Visual Integration Messages are an interoperability specification for visual integration of applications that allows users to experience an integrated computer-user session on the desktop. Messages are specified that flow between presentation-level applications that synchronize the user identifier, patient identifier, and/or observation identifier across multiple applications for a "single sign-on, single-patient-look-up user experience."

Claims Attachments

Standard Electronic Attachments, either to the claim or other healthcare transactions are a means of electronically exchanging additional information to augment another healthcare transaction, such as a healthcare claim, prior authorization, referrals, or public health reporting.

Clinical Document Architecture (a V3-based standard)

The CDA Release 2.0 provides an exchange model for clinical documents (such as discharge summaries and progress notes) - and brings the healthcare industry closer to the realization of an electronic medical record. By leveraging the use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies, the CDA makes documents both machine-readable - ;so they are easily parsed and processed electronically - and human-readable - so they can be easily retrieved and used by the people who need them. CDA documents can be displayed using XML-aware Web browsers or wireless applications such as cell phones. While Release 2.0 retains the simplicity of rendering and clear definition of clinical documents formulated in Release 1.0 (2000), it provides state-of-the-art interoperability for machine-readable coded semantics. The product of 5 years of improvements, CDA R2 body is based on the HL7 Clinical Statement model, is fully RIM-compliant and capable of driving decision support and other sophisticated applications, while retaining the simple rendering of legally-authenticated narrative.

Electronic Health Record / Personal Health Record

The HL7 EHR System Functional Model provides a reference list of functions that may be present in an Electronic Health Record System (EHR-S). The function list is described from a user perspective with the intent to enable consistent expression of system functionality. This EHR-S Model, through the creation of Functional Profiles, enables a standardized description and common understanding of functions sought or available in a given setting (e.g. intensive care, cardiology, office practice in one country or primary care in another country).

Structured Product Labeling (a V3-based standard)

Often know as "product labels", "package inserts", or "prescribing information", these documents contain the authorized published information that accompanies any medicine licensed by a medicines licensing authority.

Application and Interfaces

Clinical care facilities typically deploy an array of complex software applications from multiple vendors.  The de facto protocols used to move this data between applications is HL7.


When facilities build HL7 interfaces to interact with other systems, they have a choice of building them on a point-to-point basis or using an HL7 interface engine.

 An HL7 interface requires a sending and receiving module. For applications to connect, even when using the HL7 message format, they must ensure that the messages can synch. An interface platform will reduce the number of export and import endpoints, optimize data use, facilitate maintenance and management of applications, and log and monitor communication flow.

Contact us today toll free at (800) 983-3581 or by using the button below for pricing quotes, personalized demos, free trials, transcription consultations and additional information about our 100% HIPAA compliant medical transcription and digital dictation services.

Free Quote Request

bar