What HL7 v2 is and why it is still everywhere
HL7 version 2 is a messaging standard from HL7 International. It describes how one healthcare system tells another that something happened: a patient was admitted, a test was ordered, a result is ready. It dates from the late 1980s, and its 2.x versions are designed to stay compatible with each other.
That longevity is the reason it is everywhere. Laboratory analyzers and middleware, radiology systems, pharmacy systems and hospital information systems speak it, and so do several national exchange platforms in the region. A hospital that connects more than two systems will meet HL7 v2 sooner or later.
Anatomy of a message
An HL7 v2 message is plain text. It is a sequence of segments, one per line, and each segment starts with a three-letter code. Fields inside a segment are separated by a pipe character, components inside a field by a caret, and repeating values by a tilde. The first segment is always MSH, the message header.
| Segment | What it carries | Fields you will look at first |
|---|---|---|
| MSH | Message header: who sent it, to whom, which message type, which version | MSH-3 and MSH-4 sender, MSH-9 message type, MSH-10 control ID, MSH-12 version |
| EVN | The event that triggered the message | EVN-1 event code, EVN-2 recorded time |
| PID | Patient identification | PID-3 identifier list, PID-5 name, PID-7 date of birth, PID-8 sex |
| PV1 | Patient visit (the encounter) | PV1-2 patient class, PV1-3 location, PV1-19 visit number |
| ORC and OBR | The order and the requested procedure | ORC-2 placer order number, OBR-4 service identifier |
| OBX | One observation or result value | OBX-3 observation code, OBX-5 value, OBX-6 units, OBX-8 abnormal flag |
MSH-9 holds the message type and the trigger event, written for example as ADT^A01. MSH-10 is a control ID that the receiver echoes back in its acknowledgement, and it is the field you search for when you investigate a missing message.
The messages a hospital meets
Most hospital interfaces use a small set of message types. The table lists the ones you will meet first.
| Message | Used for | Typical sender and receiver |
|---|---|---|
| ADT | Admit, discharge, transfer and patient updates (A01 admit, A02 transfer, A03 discharge, A04 register, A08 update) | Hospital system to laboratory, radiology, pharmacy and exchange platforms |
| ORM and OML | New, changed and cancelled orders | Hospital system to laboratory or radiology |
| ORU | Results and observations | Laboratory or analyzer middleware to hospital system |
| MDM | Documents such as discharge summaries | Hospital system to document and exchange systems |
| RDE | Pharmacy and treatment orders | Hospital system to pharmacy |
| VXU | Immunisation records | Hospital system to immunisation registries and exchanges |
| SIU | Appointments | Scheduling and hospital systems |
| DFT | Financial transactions for charges | Hospital system to billing |
Transport and acknowledgements
HL7 v2 defines the message, not the network. The usual transport is MLLP, the minimal lower layer protocol. It opens a TCP connection and wraps each message in a start byte and an end sequence so the receiver knows where the message stops. MLLP has no security of its own, so it is normally run inside a VPN or wrapped in TLS.
The receiver answers with an ACK message. Its MSA segment carries the result: AA when the message was accepted, AE when it was accepted with an error, AR when it was rejected. Some platforms use the enhanced acknowledgement mode, where the codes are CA, CE and CR for the commit stage. Whichever mode applies, the sender must read the answer. An interface that sends and never checks the acknowledgement loses messages without anyone knowing.
Where HL7 v2 interfaces fail in practice
The standard is flexible by design, and flexibility is where the problems come from. These are the failures that repeat across projects.
- Local variations. Two systems that both claim HL7 v2 still differ in which fields they fill, which they require and which custom segments they add. Agree a written message specification for each interface.
- Code sets that do not match. A test code, a unit or a location code that one system sends and the other does not know is rejected or, worse, accepted and misread. Map codes explicitly and review the mapping.
- Identity. Patient identifiers, visit numbers and facility identifiers must be the ones the receiver expects. A message with the wrong assigning authority is a different patient.
- Order of events. An update that arrives before the admission it refers to, or a cancellation that arrives after the result, needs a defined behaviour.
- Time and encoding. Send an explicit time zone offset. Declare the character set in MSH-18 and test Arabic names end to end before go-live.
- Silent errors. Negative acknowledgements that nobody reads, and retries that create duplicates, are the most common cause of "missing" data.
A short test plan for an HL7 v2 interface
- A written specification for every message type, with example messages that contain no real patient data.
- A code-set mapping reviewed by the clinical owner of each code.
- Positive tests for each trigger event and negative tests for malformed and duplicate messages.
- A test of every acknowledgement code, including what the sender does on AE and AR.
- A test with Arabic and English names, long values and special characters.
- Monitoring that alerts a named person when messages queue, fail or stop arriving.
- A downtime procedure and a method to resend messages without creating duplicates.
How Ventrecs approaches HL7 v2
Ventrecs keeps the clinical system and the transport separate. The hospital system records events such as admissions, discharges and transfers, orders and results as part of the patient record. A governed integration layer, Ventrecs Connect, turns those events into the messages a partner expects, sends them through a durable outbox with retry, logs every exchange and supports reconciliation.
Each HL7 v2 interface is scoped per project. We agree the message types, the code mapping, the owners and the test plan with you and with the partner, and we test it against the partner's environment before go-live. We do not claim a pre-built connection to a specific platform or instrument.
Sources
Frequently asked questions
What is an HL7 v2 message?
A plain-text message made of segments, each starting with a three-letter code such as MSH or PID. Fields are separated by pipes and components by carets. It tells another system that an event happened.
What is MLLP?
The minimal lower layer protocol. It frames an HL7 v2 message on a TCP connection with a start byte and an end sequence. It does not encrypt, so it is usually run inside a VPN or wrapped in TLS.
What do AA, AE and AR mean?
They are acknowledgement codes in the MSA segment: AA accepted, AE accepted with an error, AR rejected. Some platforms use CA, CE and CR for the commit stage.
Is HL7 v2 being replaced by FHIR?
Not quickly. FHIR is growing, but a large share of hospital and laboratory interfaces still use HL7 v2, and many platforms accept both. See our comparison of HL7 v2 and FHIR R4.
Related Ventrecs pages
- Integrations How Ventrecs scopes, tests and supports each connection.
- Ventrecs Connect The governed integration hub: monitoring, retries and reconciliation.
- Ventrecs Lab Specimens, results and instrument connectivity in one governed workflow.
- The Ventrecs platform Six products on one patient record, one set of controls and one integration layer.
Planning a deployment?
Tell us which systems need to exchange messages. We can list the message types, the owners and the test plan before any interface is built.
More insights
- HL7 v2 or FHIR R4? How to choose for a hospital integration Most hospitals will use both. The useful question is which standard each partner publishes, and where to translate between them.
- Laboratory analyzer integration checklist: what to define before connecting your LIS Most analyzer problems come from details nobody wrote down. Use this checklist to define each instrument connection before configuration starts.
- Healthcare integration readiness: scope every interface before go-live Most delays in a healthcare deployment come from interfaces nobody scoped. Use this guide to agree each connection, its owner and how it is tested before go-live.