Written for the mixed and entry-level reader: new integration analysts, digital PMs and clinicians moving into informatics who need working vocabulary fast. Deliberately lean by design; this piece exists to anchor the deeper HL7-to-FHIR mapping and lab results articles, so it explains just enough to make those useful and resists the temptation to go segment-by-segment. Senior architects will skim it and that's fine; it isn't for them.
Somewhere in your Trust right now, a patient has moved from AMU to a ward. Within seconds, a short pipe-delimited message has told the EPR, the pathology system and the bed board about it. Nobody saw it. Nothing announced it. But if that message stops flowing, half the hospital notices within the hour.
That message is HL7 v2, and if you work anywhere near NHS integration, this is the vocabulary you need before anything else makes sense.
In brief
HL7 v2 remains the workhorse of NHS system-to-system messaging. Messages are built from segments, identified by a type and trigger event in the header, and the handful you'll meet constantly are ADT (patient administration), ORU (results), ORM (orders), SIU (scheduling), MDM (documents) and ACK (acknowledgements). The standard is old but not going anywhere soon, and the practical challenge isn't learning the spec: it's learning each sender's dialect of it.
Why HL7 v2 still matters in the NHS
FHIR gets the conference slots, but walk into any Trust's integration engine and the live traffic is overwhelmingly HL7 v2, usually versions 2.3 or 2.4, usually flowing over MLLP between the PAS, the EPR, pathology, radiology and a long tail of departmental systems. New national APIs are FHIR. The estate underneath them is v2, and it will be for years, because you can't retire an interface until every system on both ends of it can speak something newer.
So the realistic position for an NHS integration team isn't "v2 or FHIR". It's both, with v2 doing the volume.
How a v2 message is put together
A v2 message is plain text, split into segments, one per line. Each segment starts with a three-letter name and carries fields separated by pipes. The ones you'll see everywhere:
- MSH: the header. Sender, receiver, timestamp, and crucially the message type and trigger event (for example ADT^A01), which tells the receiver what this message is and why it was sent.
- PID: patient identity. NHS number, local hospital number, name, date of birth.
- PV1: the visit. Ward, bed, consultant, admission type.
- OBR / OBX: the order being reported on, and the individual observations under it.
Trusts and suppliers also add Z-segments: locally invented segments for data the standard didn't anticipate. They're legal, common, and almost never documented as well as you'd hope.
ADT: the messages that move patients
ADT stands for Admit, Discharge, Transfer, and it's the pulse of a hospital. The trigger events you'll meet most:
- A01: admit. A02: transfer. A03: discharge. The core three.
- A04: patient registered (outpatient or A&E attendance rather than an admission).
- A08: update patient information. The catch-all, and the highest-volume message in most Trusts.
- A28 / A31: add and update person information, used for demographic feeds.
- A40: merge patient records. The one that deserves fear and respect, because a mishandled merge quietly corrupts downstream systems for years.
If your Trust has one feed it cannot live without, it's the ADT feed out of the PAS.
ORU and ORM: results and the orders behind them
ORM (order message) is a system asking for something: a blood test, an imaging request. **ORU** (observation result, almost always ORU^R01) is the answer coming back, with OBR carrying the order context and a stack of OBX segments carrying the actual values, units and reference ranges.
In the NHS, ORU is the language of pathology. Every result landing in a GP system or an EPR results screen almost certainly travelled as an ORU somewhere along the way. Mapping these cleanly into UK Core FHIR is its own discipline, and one we cover separately.
SIU, MDM and ACK: the supporting cast
SIU carries scheduling: appointments booked, amended, cancelled. MDM carries documents, typically a discharge summary or clinic letter, sometimes with the document embedded. ACK is the acknowledgement: the receiving system saying "got it" (AA), "got it but it's broken" (AE) or "rejected" (AR). Teams that ignore ACK handling find out about failures from clinicians instead of from monitoring, which is the expensive way.
Where teams trip up
Three patterns account for most v2 pain. First, assuming the spec is the contract: in practice every sender speaks a dialect, and the field a supplier "always" populates is the one that arrives empty at 2am. Second, undocumented Z-segments that carry something clinically important. Third, treating parsing as a string-splitting exercise; escape characters, repeating fields and component separators punish that approach eventually. This is why WeHub Studio treats HL7 parsing as a first-class operation rather than a regex problem, and why any serious integration layer should.
The bottom line
You don't need to memorise the HL7 v2 spec. You need to recognise the ten or so message types above, know what each one carries, and treat every new feed as a dialect to be learned rather than a standard to be assumed. Start by pulling one real ADT^A08 from your engine and reading it segment by segment. Twenty minutes with a live message teaches more than any reference guide.
