HL7 data is health information formatted according to standards created by Health Level Seven International, a nonprofit organization that develops rules for how medical software systems share clinical and administrative data. When a hospital’s lab system sends test results to a doctor’s electronic health record, or when a pharmacy receives a prescription from a clinic, HL7 standards define exactly how that information is structured so both systems can read it correctly.
What “Level Seven” Means
The “7” in HL7 refers to the seventh layer of a widely used networking framework called the OSI model. This framework breaks network communication into seven layers, from the physical cables at the bottom to the applications people interact with at the top. Layer 7 is the application layer, where software services like email, file transfers, and web browsers operate.
HL7 works at this top layer because it doesn’t concern itself with how data physically travels across a network. Routers, cables, and internet protocols handle that. HL7 focuses entirely on the meaning and structure of the data itself: what fields a message contains, how they’re organized, and what each piece of information represents. It ensures that when one healthcare application sends a message, the receiving application understands exactly what every piece of data means.
HL7 Version 2: The Workhorse Standard
HL7 version 2 (v2) is the most widely deployed health data messaging standard in the world. It has been in use since the late 1980s, and despite newer alternatives, it still powers the majority of data exchange between hospital systems today.
A v2 message is a block of text made up of segments, each on its own line. Every segment starts with a three-letter code that identifies what kind of information it carries. For example, a PID segment contains patient identification details like name, date of birth, and medical record number. An OBX segment carries an individual observation or test result. Segments are further divided into fields separated by a pipe character (|), with subfields separated by carets (^). A single lab result message might look like a dense string of text filled with pipes and carets, but each position in that string has a defined meaning that both the sending and receiving systems agree on.
This pipe-delimited format is lightweight and fast to transmit, which is one reason v2 has persisted for decades. It’s also flexible. Hospitals can customize messages with optional fields to fit their specific workflows, though that flexibility sometimes creates compatibility headaches when two organizations have configured their systems differently.
Common HL7 Message Types
HL7 v2 defines dozens of message types, each designed for a specific clinical or administrative event. Three of the most common are:
- ADT (Admit, Discharge, Transfer): Sent whenever a patient is admitted to a hospital, discharged, transferred between departments, or has their registration information updated. These messages keep every system in a facility aware of where a patient is and what their current status is.
- ORM (Order): Generated when a provider places an order for a lab test, medication, imaging study, or other treatment. The message carries details about what was ordered, for whom, and by which provider.
- ORU (Observation Result): Sent when results are available, typically from a lab or diagnostic system. An ORU message might contain a single blood glucose reading or a full panel of lab values, each in its own observation segment.
These messages fire constantly in a busy hospital. A single patient visit can generate dozens of HL7 messages as they move from registration to triage to a bed, have labs drawn, receive results, and eventually get discharged.
Clinical Document Architecture
Not all HL7 data travels as short messages. The Clinical Document Architecture (CDA) is an HL7 standard for structured clinical documents like discharge summaries, progress notes, and referral letters. A CDA document uses XML formatting and has two main parts: a header and a body.
The header contains metadata about the document, including patient identity, the healthcare providers involved, confidentiality status, encounter details, and relationships to other documents or orders. Every CDA document requires at least one patient, one or more document originators, and one or more participating healthcare providers. The body holds the clinical content itself, organized into sections, paragraphs, lists, and tables. CDA was designed in three levels of increasing structure, with Level One defining the basic framework, Level Two adding templates and constraints, and Level Three enabling the most granular, machine-readable clinical content.
FHIR: The Modern Standard
HL7’s newest and fastest-growing standard is FHIR (Fast Healthcare Interoperability Resources, pronounced “fire”). FHIR was built by combining the simplicity of v2 messaging with modern web technologies like JSON, XML, HTTP, and the same authentication tools used by popular web apps.
The core concept in FHIR is the “resource,” a small, self-contained unit of healthcare data. A Patient resource contains demographic information. An Observation resource holds a single clinical measurement. A Medication resource describes a drug. These resources can be used individually or combined to handle complex scenarios. This modular approach means that when a system requests data, it gets back just the relevant resource rather than an entire document or record that then needs to be searched through.
FHIR uses a RESTful API, the same architectural style that powers most modern websites and mobile apps. Developers who have built any kind of web application will find FHIR’s approach familiar, which dramatically lowers the barrier to entry compared to older HL7 standards. FHIR Release 4, published in 2019, was the first version to include content formally designated as stable and production-ready. In 2020, the U.S. Office of the National Coordinator for Health IT established FHIR R4 as the required standard for health IT certification under the 21st Century Cures Act. Release 5 expands the normative content further, with over 30 resources nominated for that stable status.
Why HL7 Standards Matter
Without shared data standards, every connection between two healthcare systems would require custom programming to translate one system’s format into another’s. HL7 standards eliminate that by giving all parties a common language. The practical impact on patient care is measurable. One study published in PLOS One found that implementing HL7-based data integration in an emergency department reduced the time to identify patients from over 10 minutes to just 18 seconds. The overall patient journey time dropped by more than 14 minutes, and the percentage of patients meeting the department’s time targets jumped from less than 1% to nearly 56%.
These gains come from removing manual steps. When systems can exchange HL7 data automatically, staff spend less time re-entering information, patients wait less, and the risk of errors from manual data handling drops. HL7 standards also support data confidentiality, with built-in fields for flagging sensitivity levels on documents and messages, so organizations can enforce access controls as data moves between systems.
How the Standards Relate to Each Other
HL7 v2, CDA, and FHIR aren’t competing standards that replace each other overnight. They coexist across the healthcare landscape. V2 remains deeply embedded in hospital infrastructure and continues to handle the bulk of real-time messaging. CDA is widely used for document exchange, particularly in care transitions and public health reporting. FHIR is the clear direction for new development, especially for patient-facing apps, health information exchanges, and any system that needs to work with modern web and mobile platforms.
FHIR was intentionally designed to maintain continuity with existing workflows built around v2 messages and CDA documents, so organizations can adopt it incrementally rather than replacing their entire infrastructure at once. In practice, many health systems today use all three standards simultaneously, with integration engines translating between them as needed.