Written and maintained by CASRAI Editorial Board
Last updated
The HL7 standard (Health Level Seven) is the foundational suite of international healthcare data exchange specifications developed and maintained by Health Level Seven International, a not-for-profit Standards Developing Organization (SDO) founded in 1987 and accredited by the American National Standards Institute (ANSI). Spanning four decades of hospital and clinical informatics engineering—from pipe-delimited HL7 v2 ADT and laboratory feeds to XML-based C-CDA clinical summaries and modern RESTful HL7 FHIR APIs—HL7 standards define how disparate electronic health record (EHR), laboratory, radiology, pharmacy, payer, and clinical research systems package and exchange health data.
What Does Health Level Seven (HL7) Stand For?
Health Level Seven (HL7) derives its name directly from Layer 7 (the Application Layer) of the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) seven-layer communications reference model:
- Why Layer 7? In the OSI model, Layers 1 through 6 govern physical cabling, data-link framing, IP routing, TCP transport reliability, session state, and character presentation. Layer 7 (Application Layer) governs the semantic meaning, business trigger events, data field definitions, and structural formatting of data exchanged between software applications.
- Transport Independence: By specifying healthcare interoperability at Layer 7, HL7 standards separate clinical data content (such as what constitutes a patient admission event, a potassium lab observation, or a medication order) from the underlying network transport mechanism—allowing HL7 payloads to travel over Minimal Lower Layer Protocol (MLLP/TCP), HTTPS REST, SOAP web services, or secure file transfer.
How Are HL7 Standards Developed and Balloted?
As an ANSI-accredited Standards Developing Organization (SDO), Health Level Seven International develops specifications through open, multi-stakeholder technical Work Groups (such as Patient Administration, Orders & Observations, Clinical Decision Support, Structured Documents, FHIR Infrastructure, and Biomedical Research and Regulation [BR&R]) and Accelerator programs (such as the Argonaut Project, Da Vinci Project, Vulcan for clinical research, and CodeX for oncology):
- Project Scope Statement (PSS) & Working Draft: A Work Group charters a specification or Implementation Guide (IG) and tests reference implementations iteratively at live HL7 Connectathons before going to ballot.
- Consensus Ballot Levels (Informative, STU, and Normative): During tri-annual HL7 ballot cycles, organizational and individual members (EHR vendors, health systems, government regulators such as ONC and CMS, and pharmaceutical sponsors) vote and submit line-by-line negative or affirmative comments:
- Standard for Trial Use (STU): Formally balloted and reconciled for real-world production implementation and field testing (for example, HL7 FHIR US Core Implementation Guide STU releases).
- Normative Standard: The highest ANSI maturity level; every negative ballot comment must be formally dispositioned and approved by consensus, and future releases are bound by strict backward-compatibility rules (such as the core resources in HL7 FHIR Release 4).
What Are the Core HL7 Standards Families (v2, v3, CDA, and FHIR)?
An enterprise hospital integration engine (such as Mirth Connect / NextGen Connect, Rhapsody, or InterSystems HealthShare) typically processes three generations of HL7 standards concurrently:
| HL7 Standard Family | Wire Format & Transport | Core Architectural Model | Primary Healthcare & EHR Use Cases |
|---|---|---|---|
| HL7 Version 2 (v2.x) (e.g., v2.3, v2.5.1, v2.8) |
Pipe-and-hat delimited ASCII/UTF-8 text (|^~&) over MLLP/TCP |
Event-driven trigger messages composed of 3-letter segments (MSH, PID, PV1, OBR, OBX) |
Real-time patient registration (ADT), lab orders/results (ORM/ORU), scheduling (SIU), and immunization reporting (VXU) |
| HL7 Version 3 (v3) | XML over SOAP / MLLP | Top-down object-oriented Reference Information Model (RIM) (Act, Entity, Role, Participation) | FDA Individual Case Safety Reports (ICSR E2B(R3)), SPL drug labeling, and national HIE messaging in select countries |
| HL7 CDA & C-CDA (Clinical Document Architecture) |
XML documents exchanged via IHE XDS.b / XCA, Direct Secure Messaging, or API | HL7 v3 RIM-derived document header + human-readable XHTML block + coded XML entries | Summary of Care exchange (Continuity of Care Document [CCD], Discharge Summary, Referral Note) across Carequality and TEFCA |
| HL7 FHIR (R4 / R5) (Fast Healthcare Interoperability Resources) |
JSON (application/fhir+json), XML, or NDJSON over RESTful HTTPS + OAuth 2.0 |
Modular, web-addressable Resources (Patient, Observation, Condition) with SMART on FHIR app launch |
ONC 45 CFR § 170.315(g)(10) patient/clinician APIs, mobile apps, CMS payer APIs, and EHR-to-EDC clinical trial data extraction |
Inside an HL7 v2 Message vs. a C-CDA Document vs. a FHIR Resource
- HL7 v2 Segments and Z-Segments: An HL7 v2 message is triggered by a real-time hospital event—such as
ADT^A01(Admit/Visit Notification) orORU^R01(Unsolicited Observation Result). Each line is a 3-character segment (`MSH` Message Header, `PID` Patient Identification, `PV1` Patient Visit, `OBR` Observation Request, `OBX` Observation/Result) with fields separated by pipes (`|`) and components by carets (`^`). While fast and ubiquitous, HL7 v2 permits site-specific optionality and custom **`Z-segments`**, requiring per-hospital interface mapping. - HL7 CDA and Consolidated CDA (C-CDA): Derived from the HL7 v3 Reference Information Model (RIM), CDA Release 2 and the U.S. **Consolidated CDA (C-CDA 2.1)** Implementation Guide standardize complete, signed clinical documents. Every C-CDA section contains both a human-readable narrative table (guaranteeing any web browser can display the clinical summary) and machine-processable XML “ blocks bound to SNOMED CT, LOINC, and RxNorm codes.
- HL7 FHIR and the Vulcan Accelerator for Clinical Research: HL7 FHIR replaces whole-document parsing with granular RESTful resource calls and connects directly to CDISC ODM/SDTM clinical trial standards through the **HL7 Vulcan Accelerator** (covering RWD-to-EDC extraction, electronic medicinal product information [ePI], and FHIR `ResearchStudy` / `Schedule of Activities` profiles).
Frequently Asked Questions
What does Health Level Seven (HL7) stand for?
Health Level Seven (HL7) refers to Layer 7 (the Application Layer) of the ISO Open Systems Interconnection (OSI) seven-layer communications model. Founded in 1987, Health Level Seven International is the ANSI-accredited standards organization that defines application-level clinical data structures, trigger events, and semantics for healthcare software interoperability.
How are HL7 standards developed and balloted?
HL7 standards are developed by multi-stakeholder technical Work Groups and HL7 Accelerators (such as Argonaut, Da Vinci, and Vulcan), tested in live Connectathons, and subjected to formal ANSI consensus balloting—progressing from Informative drafts to Standards for Trial Use (STU) and finally backward-compatible Normative standards.
What are the core HL7 standards families (v2, v3, CDA, FHIR)?
The four primary HL7 standards families are: (1) HL7 Version 2 (v2.x), a pipe-delimited event-driven messaging standard for ADT, lab, and order interfaces; (2) HL7 Version 3 (v3), an XML standard based on the abstract Reference Information Model (RIM); (3) HL7 CDA and C-CDA, XML clinical document standards used for Continuity of Care Documents (CCDs) and discharge summaries; and (4) HL7 FHIR (Release 4), the modern RESTful JSON/XML API and modular resource standard mandated under ONC and CMS interoperability regulations.
