Written and maintained by CASRAI Editorial Board
Last updated
HL7, or Health Level Seven International, is the standards-development organization behind the messaging and document formats that let hospital systems, laboratories, pharmacies, and other health-data systems exchange patient information with each other. “HL7” refers both to the organization itself (an ANSI-accredited, not-for-profit standards developing organization, or SDO) and, informally, to the family of data-exchange standards it publishes — most notably HL7 Version 2 (HL7 v2) messaging, the Clinical Document Architecture (CDA), and, more recently, Fast Healthcare Interoperability Resources (FHIR). If a clinical system somewhere is sending a lab result, an admission notice, or a discharge summary to another system, there is a very good chance an HL7 standard is the format that message is written in.
What problem HL7 exists to solve
Healthcare data lives in a lot of different systems that were never designed to talk to each other: electronic health record (EHR) platforms, laboratory information systems, pharmacy systems, admission/discharge/transfer (ADT) feeds, billing systems, public-health reporting pipelines. Without a shared format, every pair of systems that needs to exchange data would need a custom, one-off integration — expensive to build and fragile to maintain. HL7’s standards give vendors and health systems a common structure to build against instead: a lab system that speaks HL7 v2 can send a result to any EHR that also speaks HL7 v2, without a bespoke interface for every combination.
The name comes from the OSI networking model’s seventh layer, the “application layer” — the layer at which two applications actually exchange meaningful data, as opposed to the lower layers that just move bits around. HL7’s founding focus, reflected in that name, was standardizing exchange at the application level between healthcare computer systems, first codified in HL7 Version 2, released in 1987.
The HL7 standards family
“HL7” is not one single format — it is an umbrella covering several generations of standards, each still in active use for different purposes:
- HL7 Version 2 (v2) — the oldest and still the most widely deployed standard, a compact, pipe-and-caret-delimited messaging format used heavily for real-time clinical events: admissions, transfers, discharges (ADT messages), orders, and lab results (ORU messages). Most hospital interface engines still move a large share of their traffic in HL7 v2 today.
- HL7 Version 3 / Clinical Document Architecture (CDA) — a later, XML-based generation built around a formal reference information model. CDA in particular became the basis for structured clinical documents such as the Continuity of Care Document (CCD) and, in the U.S. regulatory context, Structured Product Labeling (SPL).
- FHIR (Fast Healthcare Interoperability Resources) — HL7’s newest and now flagship standard, built around modern, web-native technology (RESTful APIs, JSON or XML payloads) rather than the older message- and document-centric approaches. FHIR is explicitly designed to be easier to implement and more extensible than v2 or CDA, and it is the standard most new interoperability work — including U.S. patient-access API requirements — is being built on.
These generations coexist rather than fully replace one another: a hospital today may run HL7 v2 for its core ADT and lab feeds while exposing FHIR APIs for patient-facing apps and newer integrations, with CDA documents still in play for certain regulatory and continuity-of-care use cases.
HL7 vs. FHIR: not two different things to choose between
A common point of confusion is treating “HL7” and “FHIR” as competing standards. They are not — FHIR is an HL7 standard, developed and published by HL7 International, and is best understood as the modern generation within the HL7 family rather than a separate organization or a rival format. Where they differ is in age, architecture, and typical use: HL7 v2’s older messaging format is deeply entrenched in existing hospital interface engines and is unlikely to disappear soon, while FHIR’s REST/JSON approach is where most new interoperability development, including app-based data access, is happening. For a deeper look at FHIR specifically — its resource-based data model, RESTful API design, and where it’s used — see CASRAI’s guide, What Is FHIR?
HL7 vs. CDISC: different scope, easy to conflate
HL7 and CDISC (the Clinical Data Interchange Standards Consortium) are both healthcare-adjacent standards organizations, and both produce data standards a research organization may encounter — but they solve different problems. HL7’s standards govern how clinical and operational health data moves between care-delivery systems: EHRs, labs, pharmacies, public-health reporting. CDISC’s standards (CDASH, SDTM, ADaM, and related implementation guides) govern how clinical trial data is collected, tabulated, and prepared for a regulatory submission such as an FDA or PMDA marketing application — a narrower, trial-specific scope aimed at supporting drug and device review rather than routine care delivery. The two do intersect in practice: a trial’s electronic data capture (EDC) system may need to import structured lab or EHR data that arrived over an HL7 interface before it is mapped into CDISC’s SDTM domains for submission. For the CDISC side of that pipeline, see CASRAI’s Clinical Data Management overview and the comparison of CDISC SDTM vs. ADaM.
Practical relevance for a research organization
Most research administrators will not write HL7 interface specifications themselves, but HL7 standards show up in the background of several things a research-administration function touches:
- Clinical data management and EDC teams evaluating or configuring an electronic data capture (EDC) system that needs to import structured data from a hospital EHR — lab values, vitals, medication lists — are usually receiving that data over an HL7 v2 feed or a FHIR API, and understanding which one shapes what the integration actually looks like.
- Research IT and informatics staff supporting investigator-initiated trials at an academic medical center, where the trial’s data flows are built on top of the institution’s existing HL7-based clinical interfaces rather than a greenfield system.
- Compliance and data-governance staff assessing a vendor’s interoperability claims, where “HL7 compliant” or “FHIR-enabled” in a vendor’s marketing material refers to conformance with a specific one of these standards, not an interchangeable buzzword.
- Anyone mapping real-world or EHR-sourced data into a clinical trial’s dataset, where the practical question is usually “which HL7 generation is the source system speaking, and how does that map into our CDISC-standardized trial data downstream.”
In short: HL7 is the standards layer that makes routine clinical data exchange possible in the first place, and it sits upstream of — and is distinct from — the trial-specific data standards (CDISC) that govern how that data is eventually packaged for a regulatory submission.
Frequently asked questions
Is HL7 a company or a standard?
Both terms are used in practice. Health Level Seven International is the not-for-profit, ANSI-accredited organization; “HL7” is also used informally to refer to the standards it publishes (HL7 v2, CDA, FHIR). Context usually makes clear which is meant.
Is FHIR replacing HL7?
No — FHIR is an HL7 standard, not a separate one. It’s the newest generation within the HL7 family, built on modern web technology, and it is where most new interoperability work is happening, but older HL7 v2 messaging remains heavily deployed in existing hospital systems and isn’t being wholesale replaced.
Do clinical trials use HL7 or CDISC?
Typically both, at different points. HL7 standards commonly govern how clinical data moves between care-delivery systems (EHRs, labs) that a trial may draw data from; CDISC standards govern how that data is ultimately structured for tabulation, analysis, and regulatory submission once it’s part of the trial’s own dataset.
Do I need to be HL7-certified to work with HL7 data?
No individual certification is required to work with HL7-formatted data, though HL7 International does offer certificate programs (for example, in FHIR) for people building interfaces or systems against the standards directly, such as interface analysts and health IT developers.
