HL7 v2 — Health Level Seven Messaging

The dominant clinical data exchange standard since 1989. Pipe-delimited, pragmatic, omnipresent in hospital information systems worldwide.

What is HL7 v2?

HL7 v2 is an application-level messaging standard for clinical, administrative and financial healthcare data exchange. It defines how to encode a clinical event — patient admission, laboratory order, lab result, financial movement — as a text message delimited by reserved characters (|, ^, ~, \, &), and how to route it between two applications (HIS, LIS, RIS, PACS, hospital ERP…) over a transport protocol (MLLP over TCP, sFTP, JMS queues, HTTPS).

The standard owes its success to its pragmatism: it was crafted by and for clinical integrators in the early 1990s — back when every hospital system spoke its own dialect — and favoured syntactic flexibility over semantic rigour. The outcome: virtually every major vendor (Epic, Cerner/Oracle Health, Allscripts, MEDITECH, Maincare, Dedalus…) speaks v2, but each with local extensions that sector-specific Implementation Guides (IGs) constrain.

HL7 v2 remains, in 2026, the most deployed clinical norm despite FHIR's rise: the software ecosystem exchanges tens of billions of messages per day worldwide, and one FHIR project in three actually relies on v2↔FHIR bridges for real-time flows.

Anatomy of an HL7 message

An HL7 v2 message is a sequence of segments separated by <CR> (0x0D). Each segment starts with a three-letter identifier (MSH, PID, PV1, OBR, OBX…), followed by its fields separated by |. Fields themselves can be broken into components (^), subcomponents (&) and repetitions (~). Below is a minimal patient admission message (ADT^A01, version 2.5.1):

MSH|^~\&|HIS|HOSP01|EHR|CLINIC02|20260514102530||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260514102530|||DRJONES^Jones^Sarah
PID|1||MRN567890^^^HOSP^MR||DOE^JOHN^A^^MR.||19720515|M|||100 MAIN ST^^ANYTOWN^CA^90210^USA||(555)555-1234|||S||ACCT123456
PV1|1|I|ICU^101^A^HOSP01|EM|||DRSMITH^Smith^James^A^^DR.|||CAR|||1|||DRSMITH^Smith^James^A^^DR.|ADM|VIP|||||||||||||||||||HOSP01|||||20260514102530

The MSH (Message Header) segment is mandatory and always first. It carries:

• MSH-1 — field separator (conventionally |).
• MSH-2 — encoding characters (^~\&).
• MSH-3 / MSH-4 — sending application and facility.
• MSH-5 / MSH-6 — receiving application and facility.
• MSH-7 — date and time of message (CCYYMMDDHHMMSS).
• MSH-9 — message type (here ADT^A01^ADT_A01).
• MSH-10 — unique message control identifier (the v2 equivalent of EDIFACT's UNH).
• MSH-11 — processing ID (P=Production, T=Test, D=Debug).
• MSH-12 — standard version (2.5.1).

Subsequent segments depend on the message type. For an ADT: EVN (Event Type), PID (Patient Identification), PV1 (Patient Visit), and optionally NK1 (Next of Kin), GT1 (Guarantor), IN1/IN2 (Insurance), AL1 (Allergy), DG1 (Diagnosis).

Versions

HL7 International has been publishing the v2 branch since 1989. Versions coexist in production: a single integrator routinely receives v2.3.1 from one partner and v2.5.1 from another.

Message families

HL7 v2 organises its messages into broad families, identified by the three-letter code in MSH-9 and its trigger event:

Use cases

• Patient identity management (ADT) — every patient movement (admission, transfer, discharge, demographic update) yields an ADT message broadcast from the HIS to all downstream consumers (clinical EHR, PACS, lab system, pharmacy).
• Laboratory order cycle (OML/ORU) — the clinician orders a test: an OML is sent from the EHR to the LIS; the result returns as an ORU once validated by the biologist.
• Medical imaging (OMI/ORU) — the request flows as OMI to the RIS, the authored report returns as ORU. The pixel data itself flows in DICOM, outside HL7.
• Hospital pharmacy — prescriptions and drug administration messages flow via OMP / RDS / RDE depending on the moment in the cycle.
• Hospital billing (DFT) — every billable act or supply generates a DFT flow to the billing module of the hospital ERP.

Comparison with EDIFACT

HL7 v2 and EDIFACT share the idea of a segment-based syntax delimited by reserved characters, but stand apart in philosophy:

Worth noting: EDIFACT did publish healthcare messages (MEDRPT, MEDPRE, MEDRUC) in parallel with HL7 during the 1990s, but never displaced HL7 v2 in this space. European cross-border healthcare data flows (PEPPOL healthcare, the eHDSI programme) are migrating toward FHIR rather than EDIFACT.

Further reading

Detailed HL7 v2 message pages on ediverse:

• ADT^A01 — Admit / Visit Notification
• ORM^O01 — Order Message

Related standards on ediverse:

• HL7 FHIR R5 — the modern REST/JSON layer of HL7
• X12 transactions 270/271/278/834/835/837 — the HIPAA administrative layer in the US
• EDI definition — ediverse glossary

Official specifications:

• HL7 v2.5.1 — Product Brief (HL7 International, free access with registration).
• List of HL7 v2 Product Briefs covering every release of the v2 branch.
• HL7 InM Working Group which maintains the Infrastructure & Messaging layer.
• Caristix — Online HL7 Definition v2.5.1 a public, navigable reference (segments, fields, tables).