What is HL7? An overview of the organization and standards family

1. What is HL7? A quick definition

HL7 commonly appears in admission, order, result, clinical-document, and record-exchange API workflows. It is not used by every healthcare connection: devices may use vendor protocols or other standards; medical images use DICOM; and Vietnam's current BHYT adjudication output uses XML 4210. HL7 is therefore an important interoperability standards family, not a generic label for all data moving through a hospital.

HL7 (Health Level Seven International) is a non-profit organization headquartered in Ann Arbor, Michigan, in the United States. It was founded in March 1987 at a workshop hosted by the University of Pennsylvania, with a core goal: helping healthcare software from different vendors exchange information under shared conventions.

HL7 does not sell HIS or EHR products; it develops and publishes standards that describe data structures, message formats, and semantic rules. A product's use of an HL7 artifact does not itself create certification or guarantee conformance. Many published standards are available without charge under their applicable IP policy; FHIR core is CC0, while terminologies, Implementation Guides, and third-party dependencies may retain separate licenses.

In the cited sources, hl7.org/about reports more than 1,600 members from over 50 countries, including more than 500 corporate members; the 2024 annual report (annual-report.hl7.org) lists 44 countries with an HL7 Affiliate. These figures should be read as source-dated snapshots. ANSI accredited HL7 as a Standards Developing Organization in 1994, and ISO has published several HL7-derived standards, including ISO/HL7 21731 for the HL7 v3 RIM.

2. A short history — why "Level 7"?

The name "Level Seven" often puzzles newcomers. It is a technical reference to the seven-layer OSI model, the classic networking reference model. Layers 1 through 6 describe how bits, frames, packets, and sessions move through hardware and network protocols. Layer 7, the Application layer, is where two applications talk to each other about the meaning of data. By naming the organization "Health Level Seven", the founders sent a clear message: we are not concerned with cabling or TCP/IP — that is the business of the lower layers — we are concerned with helping two pieces of healthcare software agree on exactly what "Patient.gender = M" means clinically and legally.

The first workshop in 1987 brought together about 12 organizations, including hospitals and software vendors, at the University of Pennsylvania. They tackled a concrete problem: how could a hospital information system (HIS) talk to a laboratory information system (LIS) without building a custom adapter for every pair of products? The result was the first version — HL7 V2.0, released in September 1988. It was a document describing pipe-delimited syntax for ADT (Admission, Discharge, Transfer), ORM (Order Message), and ORU (Observation Result) messages.

Two years later, HL7 V2.1 was released in March 1990, solidifying the syntax with the now-iconic |^&~\ delimiters. In March 1997, HL7 published V2.3. Multiple v2 versions continue to coexist in production; each interface should declare its exact version, message profile, and local conventions rather than relying on the label “HL7 v2”.

In 2005, HL7 released two major products: HL7 v3, built on the Reference Information Model (RIM), and CDA Release 2, the standard for XML-based clinical documents. v3 introduced a more tightly specified information model than v2, while requiring substantial modeling and implementation constraints.

The next inflection point came from Grahame Grieve, an Australian engineer at HL7. Between 2011 and 2013, Grieve championed a project initially called "Resources for Health" — later renamed FHIR (Fast Healthcare Interoperability Resources). FHIR combines experience from earlier HL7 lines with web patterns such as REST, JSON, and OAuth. FHIR DSTU1 was released on September 30, 2014. R4 (4.0.1), released in 2019, contains important normative content and is the base for many current Implementation Guides; FHIR R5 was published in March 2023. Systems should declare a specific version and IG rather than merely claim “FHIR support”.

3. The four main HL7 standards

When someone says "the HL7 standard" without specifying a version, practitioners usually have to ask back. HL7 has four parallel product lines, each addressing a different problem, and a modern hospital may be using all four at the same time.

3.1. HL7 v2.x — a message-based standard with a large installed base

HL7 v2 is the original line. It uses a lightweight pipe-delimited syntax; segment structures such as MSH, PID, and OBX are foundational knowledge for HL7 integration work. v2 messages are commonly transmitted over MLLP (Minimal Lower Layer Protocol) on TCP for admission-discharge-transfer (ADT), orders (ORM), results (ORU), and document-management (MDM) scenarios. Actual use should be established from each organization's interface inventory; this page does not assume a global or Vietnam deployment percentage.

v2 allows substantial variation through optional fields, implementation-defined Z-segments, and profile-dependent terminology constraints. Implementations therefore often differ in fields, codes, and business rules. Each integration needs an explicit message profile, mapping, test cases, and error-handling agreement.

3.2. HL7 v3 and the RIM

HL7 v3 was created to reduce variation found in v2. The v3 family is based on the RIM (Reference Information Model) and derived models with tightly specified semantics. A common model does not eliminate the need to align vocabulary, templates, cardinality, transport, and testing. Adoption of v3 messaging varies by program, while v3-derived assets—especially CDA—continue alongside FHIR.

3.3. CDA — Clinical Document Architecture

CDA Release 2 is a document standard based on the HL7 v3 RIM. While v2 and FHIR are often used for messages or resources, CDA represents clinical documents with human-readable narrative and machine-processable structure. A CDA document can be digitally signed and governed as a legal record when applicable law, profiles, and infrastructure provide for that; CDA alone does not determine legal status. CCD (Continuity of Care Document) is a prominent template in the United States care-summary exchange ecosystem.

3.4. FHIR — the modern API standard

FHIR (Fast Healthcare Interoperability Resources) is a web-oriented HL7 standard developed after v2, v3, and CDA. FHIR packages clinical data into modular Resources: Patient, Encounter, Observation, MedicationRequest, Condition, DiagnosticReport, and many more. FHIR R4 (4.0.1) defines 146 resource types; FHIR R5 expands this to 157 resources. Each Resource can be serialized to JSON, XML, or Turtle (RDF), and accessed via an HTTP REST API with operations such as GET /Patient/123, POST /Observation, GET /Encounter?patient=123.

{
  "resourceType": "Patient",
  "id": "vn-example-001",
  "identifier": [{
    "system": "http://fhir.hl7.org.vn/core/sid/cccd",
    "value": "001234567890"
  }],
  "name": [{"family": "Nguyen", "given": ["Van", "An"]}],
  "gender": "male",
  "birthDate": "1985-03-12"
}

Adoption analysis should separate the installed base of v2 interfaces from API choices for new projects. No single global percentage applies to every market. One sourced example is the United States ONC Cures Act Final Rule, where standardized API requirements for certified health IT accelerated FHIR-based API implementation. Vietnam-specific conclusions require a separate survey.

For a detailed comparison of the four standards, see the page comparing HL7 v2, v3, and FHIR.

4. HL7 in practice: where is it used?

Hospital IT teams typically encounter HL7 at five main touchpoints. The first is HIS integration with LIS, RIS, and PACS — the flow of orders and results. HL7 v2 is common when source and destination products support compatible message profiles; image content remains a DICOM concern. The second is HIS integration with pharmacy and prescribing systems — particularly important for hospitals with clinical pharmacy services or outpatient e-prescribing.

The third is the data exchange channel between healthcare facilities and the health insurance payer. In the United States, administrative transactions commonly use X12, while FHIR Claim may participate in specified workflows. In Vietnam, the current KCB output-data chain remains the required receiving format for applicable Vietnam Social Security workflows (see Decision 3176/QĐ-BYT). An internal adapter or structural mapping may transform that payload to FHIR Claim/EOB; ConceptMap applies only to code relationships. Neither changes the receiving format without corresponding authority.

The fourth is provincial or national health information exchanges (HIE). Depending on architecture, an HIE may combine FHIR, CDA, IHE profiles, and identity infrastructure. The fifth is EMR-facing channels for mobile or AI applications: some platforms provide FHIR APIs and SMART on FHIR, but access scope, data coverage, and conformance must be verified per product.

5. HL7 and other healthcare standards

HL7 is not the only healthcare standard. In a real-world project, HL7 typically works alongside other standards families, each addressing a different domain. The table below summarizes several common relationships:

FHIR defines an information model and exchange mechanisms, while terminology systems supply codes for domain concepts. For example, a FHIR Observation may use LOINC 2339-0 for “glucose [mass/volume] in blood” and UCUM mg/dL for the unit. The profile, terminology binding, unit, and test method must align for consistent interpretation by the receiver.

6. HL7 in Vietnam — current state and roadmap

Based on the public affiliate lists reviewed in June 2026, Vietnam does not yet have an officially recognized HL7 Affiliate. Meanwhile, HL7/FHIR demand is visible through HIS-LIS-PACS integration, electronic medical records, and open API interoperability needs; however, no unified national document yet defines how HL7 v2, CDA, or FHIR should be applied across the system.

One notable public artifact is VN Core IG, published in 2024 by the Department of Information Technology (Vietnam Ministry of Health) at github.com/hl7vn/vn-core-ig. Readers should inspect the repository's current status, releases, and history directly because those details can change. A community-hosted copy exists at fhir.chiaseyhoc.vn; the mirror's existence alone does not establish its maintenance scope or governance.

An important current driver is Circular 13/2025/TT-BYT (Ministry of Health) on electronic medical records, issued on 06/06/2025 and effective from 21/07/2025. The circular requires hospitals to complete EMR adoption by 30/09/2025 at the latest, and other healthcare facilities by 31/12/2026. It does not mandate a specific HL7 standard. FHIR is one candidate for the exchange layer, but it should be evaluated against existing systems, receiver specifications, IHE/DICOM/CDA where applicable, and governance, security, and testing requirements. The full legal context is documented in the legal corpus.

The hl7.org.vn initiative is led by Omi HealthTech, aiming to build a high-completeness trial-use VN Core IG that is ready for Working Group review and an HL7 Affiliate Vietnam preparation path once governance conditions are met. This version uses the canonical URL http://fhir.hl7.org.vn/core/, is based on FHIR R4, and is developed under an open model (CC-BY-4.0) similar to JP Core, KR Core, and CH Core. The goal is not to replace the Ministry of Health's version; any comparison or canonical convergence should go through a national Working Group and formal governance decision.

7. Frequently asked questions

Is HL7 the same as FHIR?

No. FHIR is one HL7 standards product line within a broader portfolio; v2, v3/CDA, and FHIR are families commonly compared for interoperability. When someone says "we use HL7", ask for the version, product family, Implementation Guide, and contract — those details materially change the integration.

Should my hospital use HL7 v2 or FHIR?

The two lines support different exchange models and may coexist. If source and destination systems already have supported v2 interfaces, maintaining or extending v2 may minimize change. If a use case needs resource-based APIs, application authorization, and a shared Implementation Guide, FHIR may fit better. Decide from actual capabilities, lifecycle cost, safety, and partner specifications rather than assigning v2 to internal traffic and FHIR to external traffic by default.

Is HL7 free?

Many published HL7 standards can be downloaded and used without charge under the applicable IP policy. FHIR core is published under CC0, but its license does not grant rights to every referenced terminology or third-party dependency. Membership, voting, education, certification, events, and some services have separate eligibility or fees; check the license for the exact artifact and version.

Is HL7 mandatory in Vietnam?

According to the VN Core legal registry reviewed in June 2026, no Vietnamese legal document mandates a specific HL7 standard by name (v2, FHIR, CDA). Circular 13/2025/TT-BYT requires interoperability and retrieval, while Decree 102/2025/NĐ-CP addresses data connectivity within its scope. FHIR R4 is a technical option with an international ecosystem, but production use still requires national or use-case profiles, terminology, conformance testing, and an authoritative governance decision.

I am new to the field — should I learn HL7 v2 or FHIR first?

Learn FHIR first if your work centers on resource-based APIs or Implementation Guides. Learn v2 first if your task is to operate, analyze, or extend existing v2 interfaces. Hospital integration roles benefit from both, together with DICOM, IHE, terminology, and security principles relevant to the use case.

8. References and further reading

Primary sources

• HL7 International — About HL7 (organization, history, membership).
• HL7 Annual Report 2024 — membership and Affiliate figures.
• HL7 Terminology — V2 Code Systems (v2 version timeline).
• FHIR R4 Resource List — the 146 resources.
• FHIR specification (R4 and R5).
• ONC Cures Act Final Rule — FHIR API requirement for certified health IT in the United States.

Vietnam references

• Circular 13/2025/TT-BYT — Electronic medical records (issued 06/06/2025, effective 21/07/2025).
• Decree 102/2025/NĐ-CP — Managing digital health data (issued 13/05/2025, effective 01/07/2025).
• VN Core IG repo (Department of IT, Ministry of Health, 2024).
• fhir.chiaseyhoc.vn — community-hosted VN Core IG mirror.

Further reading in the knowledge hub