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

1. What is HL7? A quick definition

When a hospital sends a lab result from a chemistry analyzer to the hospital information system (HIS), that data almost always travels through an HL7 message. When an electronic medical record (EMR) needs to order medication for an inpatient, the prescription order is typically packaged in HL7 format. When a social health insurance gateway receives a claim from a public hospital, the accompanying clinical data also flows through HL7. In short, HL7 is the shared language of healthcare software — and most hospitals around the world are still speaking this language today, whether they realize it or not.

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 single goal: to make healthcare software from different vendors understand each other. The mission sounds simple, but it has become HL7's life work for nearly four decades.

HL7 does not sell software and does not certify products. The organization develops and publishes standards — open technical specifications that describe data structures, message formats, and semantic rules. Software vendors, hospitals, regulators, and developer communities then adopt those standards in their own products. Since 2013, all HL7 standards have been published free of charge, with no membership required to read or implement them.

According to hl7.org/about, HL7 has 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 — the national chapter that represents HL7 International in its country. The American National Standards Institute (ANSI) accredited HL7 as a Standards Developing Organization in 1994, and many HL7 standards have been adopted by ISO as international standards (for example, ISO/HL7 21731 for 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. By March 1997, HL7 published V2.3 — a version that became the default standard in tens of thousands of hospitals worldwide for more than two decades. To this day, V2.3, V2.4, and V2.5 remain the most common v2 versions deployed across hospitals in Asia, Europe, and the United States.

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 promised a tightly specified information model, but its complexity made it hard to deploy outside a few Nordic countries and the United Kingdom.

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). The FHIR philosophy is straightforward: inherit the pragmatism of v2, borrow the modeling rigor of v3, and repackage everything using modern web patterns (REST, JSON, OAuth). FHIR DSTU1 was released on September 30, 2014. R4 (4.0.1), released in October 2019, is now the de facto baseline for any serious FHIR deployment, while FHIR R5 was published in March 2023.

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 — the most widely deployed message-based standard

HL7 v2 is the original line. Its lightweight pipe-delimited syntax let legacy systems run on modest hardware; segment structures such as MSH, PID, and OBX have become foundational knowledge for every HL7 integrator. v2 messages are typically transmitted over MLLP (Minimal Lower Layer Protocol) on TCP, in classic scenarios: admission-discharge-transfer (ADT), placing lab orders (ORM), returning results (ORU), and document management (MDM). Across hospitals in operation today, more than 90% of HIS-LIS and HIS-PACS interfaces still run on HL7 v2.

The weakness of v2 is its "deliberate looseness". The standard allows many variations: optional fields, vendor-defined Z-segments, and very few constraints on terminology. As a result, no two HL7 v2 deployments are exactly alike — a half-joke in the integrator community: "When you have seen one HL7 v2 interface, you have seen exactly one HL7 v2 interface." Every new integration still requires careful field-by-field mapping between the two sides.

3.2. HL7 v3 and the RIM

HL7 v3 was created to solve the looseness of v2. The entire v3 family is built on a single Reference Information Model (RIM), encoded in tightly constrained XML, with semantics specified down to each attribute. In theory, two independent v3 systems can exchange data without manual mapping. In practice, the complexity of the RIM made most v3 projects prohibitively expensive, and adoption was significant only in the United Kingdom (NHS), some Nordic countries, and the Netherlands. Outside those special cases, FHIR has effectively replaced v3 in the field.

3.3. CDA — Clinical Document Architecture

CDA Release 2 is the most important derivative of HL7 v3 RIM. While v2 and FHIR focus on messages or resources, CDA focuses on complete clinical documents: discharge summaries, referral letters, e-prescriptions, and consult notes. Each CDA document is an XML file with both machine-readable structure and human-readable narrative, digitally signed and stored as a legal unit. The most popular template is the CCD (Continuity of Care Document) — the de facto standard for medical record summaries in the United States. CDA is still widely used in South Korea, Taiwan, Germany, and Japan.

3.4. FHIR — the modern API standard

FHIR (Fast Healthcare Interoperability Resources) is the youngest and fastest-growing HL7 standard. 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 a standard HTTP REST API with natural operations: 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"
}

On adoption, an important distinction: HL7 v2 is still described by HL7 as the most widely deployed healthcare standard in the world, based on the installed base of interfaces running across tens of thousands of hospitals. FHIR is the modern API standard chosen for most new digital health programs from 2020 onward — adoption is growing rapidly, especially since the ONC Cures Act Final Rule in the United States required certified health IT products to support a standard FHIR R4-based API.

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 placing lab and imaging orders and returning results. This is the classic use case, and HL7 v2 is essentially mandatory for any hospital that wants to shorten the time from order to result. 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 this is the X12 family and FHIR Claim. In Vietnam, the XML 4210 format remains the standard data output for adjudication by Vietnam Social Security (BHXH) (see Decision 3176/QĐ-BYT). XML 4210 is not strictly HL7, but the long-term direction is to map XML 4210 to FHIR Claim/EOB to take advantage of the international standards ecosystem.

The fourth is provincial or national health information exchanges (HIE). Most modern HIEs use FHIR as the access protocol, combined with CDA for consolidated clinical documents. The fifth is EMR-facing channels for mobile and AI applications: from 2020 onward, most major EMR systems provide a FHIR API layer along with SMART on FHIR, allowing third-party applications to access data with patient-granted permissions.

5. HL7 and other healthcare standards

HL7 is not the only healthcare standard. In a real-world project, HL7 typically works alongside several other standards families, each owning a different domain. The table below summarizes how HL7 interacts with the most important ones:

Important note: HL7 provides the data container framework; SNOMED CT, LOINC, and ICD-10 supply the meaning of the values. A FHIR Observation carrying a blood glucose result will use the HL7 FHIR structure, the LOINC code 2339-0 to declare "this is plasma glucose", and the unit mg/dL. All three layers must align before a machine can interpret it correctly.

6. HL7 in Vietnam — current state and roadmap

As of April 2026, Vietnam does not yet have an officially recognized HL7 Affiliate in the HL7 International annual report. Meanwhile, HL7 standards have made their way into the Vietnamese healthcare sector in a fragmented manner: many class-I and special-class hospitals have deployed HL7 v2 for HIS-LIS-PACS integration, and several new EMR projects have selected FHIR R4 as their open API layer — but there is no unified national document defining how the standards should be applied.

The most recent official 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. The repository has 9 commits, draft status, and has not been updated since July 2024. A community mirror exists at fhir.chiaseyhoc.vn, indicating an active FHIR Vietnam community working outside the official channel.

The strongest 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. While Circular 13/2025 does not mandate a specific HL7 standard by name, the requirement for interoperability and retrieval — tied to the national personal identifier or VNeID (Vietnam's national digital identification app) account — places FHIR firmly in the position of "the most viable rail" for the integration layer. The full legal context is documented in the legal corpus.

The hl7.org.vn initiative is led by OmiGroup (through its subsidiary Omi HealthTech), aiming to build a community-driven, high-completeness VN Core IG that is ready for the procedural establishment of HL7 Affiliate Vietnam. 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 but to complement it and stand ready to merge once a national Working Group is in place.

7. Frequently asked questions

Is HL7 the same as FHIR?

No. FHIR is one of four HL7 standards. HL7 is the organization and the standards family (v2, v3, CDA, FHIR); FHIR is the youngest member of that family. When someone says "we use HL7", you should ask back: "v2 or FHIR?" — the answer changes how you integrate with them in major ways.

Should my hospital use HL7 v2 or FHIR?

The two lines address different problems, and most hospitals will use both. For internal integration between HIS, LIS, PACS, and RIS — where v2 drivers are already built into nearly every commercial product — HL7 v2 is still the fastest and cheapest choice. For open API channels (mobile applications, AI, patient portals, exchanges with national gateways or next-generation health insurance systems), FHIR is the right fit. A wise architecture typically uses v2 for the internal integration layer and FHIR for the public API layer.

Is HL7 free?

HL7 standards have been free of charge since 2013 — you can download the specification, read it, and implement it without paying. HL7 membership has a fee and unlocks the right to participate in Working Groups, vote on standards, and access early drafts. If you only need to read and implement, you do not have to be a member.

Is HL7 mandatory in Vietnam?

As of April 2026, no Vietnamese legal document mandates a specific HL7 standard by name (v2, FHIR, CDA). However, Circular 13/2025/TT-BYT on electronic medical records requires interoperability and retrieval, and Decree 102/2025/NĐ-CP on managing digital health data requires connection to the national database. Within those requirements, FHIR R4 is the most technically viable path and is the standard that regional peers (Japan, South Korea, Singapore, Taiwan) are choosing for the same problems.

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

Learn FHIR first if you are working on new projects (post-2024) or focused on APIs, mobile, or AI. Learn v2 first if you are joining a hospital that already runs an HIS-LIS environment built up over many years and your job is to maintain or extend those integrations. Ideally you should know both — v2 for historical depth and FHIR for future reach.

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