HL7 is a standards development organization which has developed a number of standards relating to interoperability in healthcare informatics. Informally, the term often refers to version 2 of the HL7 messaging standard. "HL7 interfaces" using the HL7 v2 messaging standard power much of the connectivity between various systems such as EHRs, ancillary, laboratory, and billing.
HL7, the organization
Health Level Seven International (HL7) is a non-profit, standards development organization which develops and promulgates standards for interoperability in clinical practice. The organization has more than 1,600 members from around the world, including corporate members representing healthcare providers, government stakeholders, payers, and various commercial interests. 
HL7 is accreditated by ANSI (the American National Standards Institute), an umbrella organization for Standards Development Organizations in the US.
The term "Level Seven" refers to the seventh level in the seven-layer OSI model Open Systems Interconnection (OSI) communications model - the application level. The application level interfaces directly to and performs common application services for the application processes. HL7's protocols largely exist at the application layer, providing the infrastructure for various applications to interconnect seamlessly.
HL7 Messaging Standard Version 2
Currently the most common iteration of the HL7 standard is version 2.x. Messages in this version rely on “triggers” to define the exchange of data. Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, and so on. For example, upon admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”. This message is populated with demographic information, visit information, and diagnoses about the admitted patient, and is then sent to the various systems in a healthcare organization that need to know about the admission. The concept of event-based triggers is central to HL7 v2; other event types include ORU ("unsolicited observation message"), OMG ("General clinical Order Message"), OML ("Laboratory Order Message"), and scores of others. The HL7 standard specifies what content must (or may) be included in each of these message types.
An HL7 message is structured as a ordered set of reusable “segments”. For example, Patient Identifiers are placed in a segment beginning with PID. Within that segment, discrete pieces of information are separated by “delimiters” into fields, which is typically the | (pipe) character. The fields can be further divided into subfields. For example, the contents of the name field might be
DUCK^DONALD D with the last name and first name separated into subfields. Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient. The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.
An example of an HL7 message follows. Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:
MSH|^~\&|||||200501100455||ADT^A01|ADT66561|P|2.3||||||| PID|||10006579||DUCK^DONALD D||19241010|M|||111^QUACK ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234 PV1||I|PREOP^101^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452 DG1|1|||OSTEOARTHROS NOS-L/LEG
HL7 v3 Reference Information Model
Unlike HL7 v2 which is a messaging spec, HL7 v3 is fundamentally a data model. While HL7 v2 was a communication protocol which evolved over time to encompass more and more use cases, the HL7 v3 RIM was designed top-down as a data model to accomodate all the needs of healthcare data. In addition, while HL7 v2 allows a lot of flexibility in how it is used (especially in terms of the semantics of the data), v3 specifies a lot of semantic aspects of data encoding.
Unlike HL7 v2 which was adopted very widely across healthcare, HL7 v3 did not have similar levels of adoption. One aspect that did gain significant adoption was the [Clinical Document Architecture (CDA)]. CDA is an architecture for XML documents which can be viewed and exchanged across EHRs. A feature of the CDA is its ability to be viewed in a browser using a single style sheet, ensuring everyone can read the record. Structured information can also be recorded and be used in different systems. The information is recognizable by different systems through use of shared terminology, such as SNOMED and LOINC.
The HL7 Clinical Document Architecture (CDA) is an ANSI standard with release 2 being published early in 2005 . Like other HL7 standards it is based on the reference information model (RIM) and is designed to capture information as a document and then be stored in EHR systems.
Version 3 also included other enhancements over v2:
- Top-down message development emphasizing reuse across multiple contexts
- Representation of complex temporal and non-temporal relationships
- Formalisms for vocabulary support
- Support for large scale integration
- Solving the identifiers problem
- Solving re-use and interoperability across multiple domain contexts
- Expanded scope to include community medicine, epidemiology, veterinary medicine, clinical #genomics, security, etc.
The below 23 lines are excerpted and deidentified from a 784-line CDA document representing a single outpatient visit. In an HL7 v2 message, this information would all be represented as part of the PID segment. In this message (which is in XML) every single piece of data is explicit, including references to the vocabularies specifying each element. For example, one could look up the code system used for the race code at https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238 , which shows 966 coded options for race.
<recordTarget> <patientRole classCode="PAT"> <id root="2.16.840.1.113883.4.391.21502" extension="10150" assigningAuthorityName="eClinicalWorks" /> <addr> <city>Kalamazoo</city> <streetAddressLine>123 Main Street #2</streetAddressLine> <state>MI</state> <country>USA</country> <postalCode>12345</postalCode> </addr> <telecom value="333-444-5555" /> <patient> <name> <family>Mouse</family> <given>Mickey</given> </name> <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" /> <birthTime value="19720301" /> <raceCode code="2106-3" codeSystem="2.16.840.1.113883.6.238" displayName="White" /> <ethnicGroupCode code="2186-5" codeSystem="2.16.840.1.113883.6.238" displayName="Not Hispanic or Latino" /> </patient> </patientRole> </recordTarget>
- Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2005 Oct 12;
- Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006 Jan-Feb;13(1):30-9. Epub 2005 Oct 12.
Submitted by Leah Lewis
Updated by Michael Kopinsky