HL7 (Health Level Seven International)

One-sentence definition: HL7 is an international standards development organization, founded in 1987, that creates the frameworks and messaging standards — including FHIR, v2, and CDA — used to exchange, integrate, and share electronic health information across healthcare systems worldwide.

Full Definition

HL7 stands for Health Level Seven International. The “Level Seven” in the name refers to the seventh layer of the ISO OSI networking model — the application layer — signaling that HL7’s work sits at the level where healthcare applications exchange meaningful clinical and administrative data, not at the network plumbing level below.

HL7 International is a non-profit standards development organization (SDO) founded in 1987 and headquartered in Ann Arbor, Michigan. It counts more than 1,600 member organizations across 50+ countries, including EHR vendors, health systems, payers, government agencies, and academic institutions. Members participate in Work Groups that draft, review, and ballot the standards HL7 publishes.

HL7 produces voluntary consensus standards for clinical and administrative health data exchange. Its best-known product today is FHIR (Fast Healthcare Interoperability Resources), but its portfolio also includes HL7 v2, HL7 v3, CDA (Clinical Document Architecture), and a growing collection of domain-specific Implementation Guides. US regulatory programs — Meaningful Use, ONC certification, USCDI — and their global equivalents reference HL7 standards as the baseline for certified health IT systems.

Context and Usage

Where This Term Appears

HL7 appears across the healthcare IT landscape:

• Product documentation and marketing materials (“HL7-compliant”, “HL7 FHIR R4”)
• Job postings for health IT engineers, architects, and analysts
• Regulatory filings and certification criteria (ONC, CMS)
• Vendor contracts and RFP responses specifying interoperability requirements
• Implementation guide citations and specification documents

Common Usage Examples

In conversation: “We’re using HL7 FHIR R4 for the patient portal API — it’s what our EHR vendor supports.”

In documentation: “The system is certified against HL7 FHIR R4 as required by ONC’s certification program.”

In technical contexts: An HL7 v2 ADT^A01 message notifies downstream systems that a patient has been admitted — the ADT segment structure is defined in the HL7 v2 specification.

Why HL7 Exists

In the 1980s, every healthcare system spoke its own language. A lab system used one proprietary message format; the ADT (admit/discharge/transfer) system used another. Connecting two systems required a custom point-to-point integration built by hand — and repeating that effort for every new pair of systems in every hospital.

HL7 was founded in 1987 specifically to solve this problem: create shared message formats so any compliant system could communicate with any other without bespoke translators. If your lab system and your ADT system both spoke HL7, they could exchange data without a custom interface.

That founding mission has driven HL7’s evolution across three major generations of standards: HL7 v2 (pipe-delimited messages, 1987 onward), HL7 v3/RIM (XML-based, more formal, early 2000s), and FHIR (REST/JSON, developer-friendly, 2014 onward). Each generation addressed limitations of the previous one while the older standards remained in widespread use.

HL7 Standards Family

FHIR (Fast Healthcare Interoperability Resources)

FHIR is HL7’s modern REST/JSON standard, first published in 2014 and now the dominant choice for new development. FHIR R4 (published 2019) is widely adopted and required by ONC certification and CMS rules. FHIR R5 (published 2023) adds enhancements and is beginning to see production adoption. FHIR’s developer-friendly design — standard HTTP, JSON payloads, a rich ecosystem of open-source tools — made it the standard of choice for mobile health apps, payer APIs, and EHR integrations alike.

HL7 Version 2.x

HL7 v2 is the most widely deployed health data standard in the world, measured by transaction volume. Pipe-delimited messages like ADT^A01 (patient admission), ORU^R01 (lab results), and ORM^O01 (orders) move billions of records daily through hospital systems. Despite being decades old, v2 has an enormous installed base — most lab result feeds and ADT interfaces in US hospitals today run on v2. Version 2.9 is the current release. v2 isn’t going away soon; it coexists with FHIR in most real-world production environments.

HL7 Version 3 / CDA

HL7 v3 introduced a formal Reference Information Model (RIM) expressed in XML. It proved too complex for widespread direct adoption, but one important product emerged from it: CDA (Clinical Document Architecture). CDA is used for C-CDA documents — Continuity of Care Documents (CCDs), discharge summaries, and progress notes — which are still required by regulations and exchanged widely by HIEs and EHRs. If you’ve ever received a patient summary document from another provider, it was likely a C-CDA.

Other HL7 Standards

HL7 also publishes and maintains several complementary frameworks built on FHIR:

• SMART on FHIR: an authorization framework for healthcare applications built on OAuth 2.0 and FHIR; used for EHR app launch and patient-facing apps
• Clinical Quality Language (CQL): a human-readable and machine-executable expression language for quality measures and clinical decision support
• Structured Data Capture (SDC): FHIR-based specifications for form-driven data collection using Questionnaire and QuestionnaireResponse
• Da Vinci IGs: a suite of FHIR Implementation Guides focused on payer/provider data exchange, prior authorization, and coverage discovery

Organizational Structure

HL7 operates through a committee structure:

Work Groups (WGs) are domain-specific committees — Patient Administration, Orders and Observations, Financial Management, Clinical Quality Information, and many others — that draft and maintain the standards in their area. Members with relevant expertise participate in WG calls, ballots, and Connectathons.

Balloting is the formal process for approving changes to HL7 standards. Proposed normative content goes through a member vote; sufficient negative votes require resolution before a specification advances. This process ensures broad consensus but also means standards take time to evolve.

Connectathons are testing events — typically co-located with HL7 Working Group Meetings — where implementers bring real systems and test interoperability against published specifications. Connectathon results feed back into specification clarifications and errata.

Relationship to Other Terms

Related Terms

• FHIR — HL7’s modern REST/JSON standard; the most actively developed product of the organization
• Resource — the atomic unit of FHIR data exchange, defined in the FHIR specification
• Profile — a StructureDefinition that constrains a FHIR resource for a specific context

Contrasting Terms

• HL7 vs FHIR: HL7 is the organization; FHIR is one standard it publishes. Like saying “IEEE” vs “802.11 Wi-Fi” — the organization produces the standard.
• HL7 v2 vs FHIR: v2 uses pipe-delimited text messages over point-to-point connections; FHIR uses RESTful APIs with JSON over HTTP. Both are HL7 standards; they serve overlapping but distinct use cases in current production environments.

Common Misconceptions

Misconception 1: HL7 is Just FHIR

• Incorrect belief: HL7 and FHIR are the same thing; using one term means the other.
• Reality: FHIR is one standard within HL7’s portfolio. HL7 v2 still processes billions of messages daily in hospital systems. CDA documents are still exchanged widely by HIEs and required by some regulations. HL7 is the organization; FHIR is a product of it.
• Why it matters: When a vendor says “HL7-compliant,” ask which HL7 standard they mean. v2 support, FHIR support, and CDA support are distinct capabilities. Each requires different implementation work.

Misconception 2: HL7 is a Software Product

• Incorrect belief: HL7 is software you install, a system you connect to, or a vendor you buy from.
• Reality: HL7 International is a standards development organization. It publishes specifications. EHR vendors, health IT companies, and others implement those specifications in their software. There is no “HL7 system” to install or “HL7 server” to connect to — only HL7-compliant implementations built by others.
• Why it matters: Contracts and RFPs that require “HL7 support” need to specify which HL7 standard and which version. “Supports HL7” alone is not a meaningful interoperability commitment.

Why HL7 Matters

HL7 standards are the lingua franca of health data exchange. Every US EHR certified under ONC criteria implements HL7 FHIR. Every lab result arriving from a reference lab likely travels as an HL7 v2 ORU message. Every patient summary document shared through a health information exchange is likely a C-CDA, an HL7 standard.

Understanding HL7 as an organization — not just as “the FHIR people” — contextualizes why these different standards exist, how they relate, where they’re used, and where to find authoritative specifications when implementations disagree. The portfolio has depth because the problem space has depth: decades of installed infrastructure, diverse clinical workflows, and global variation in regulatory requirements all shape which standard applies where.

Cross-References

Related Glossary Terms

• FHIR — The modern REST/JSON standard produced by HL7
• Resource — The atomic unit of FHIR data exchange
• Profile — How FHIR resources are constrained for specific use cases
• Extension — How FHIR adds flexibility beyond base resource definitions

---

Last reviewed: February 15, 2026 Definition authority: HL7 International Content status: Canonical reference