What is HL7, and why laboratories still run on it
HL7 v2 is a messaging standard from the late 1980s that remains the working language of laboratory interfaces. It is frequently described as outdated. It is also what is carrying your orders and results right now, and it will be for a long time yet.
What an HL7 message actually is
An HL7 v2 message is a text structure of segments, each segment a line beginning with a three-letter code, each line split into fields by a delimiter. A message has a header segment identifying what it is and who sent it, followed by segments carrying patient identity, the order, the observations and so on.
It is deliberately unglamorous. Its longevity comes from being simple enough to implement in almost any environment, and flexible enough that any two parties can agree on a variant that meets their needs.
The message types laboratories care about
- ADT — patient administration. Registrations, updates, merges. Often the source of patient demographics.
- ORM — order messages. An order placed with the laboratory. Newer versions use OMG/OML variants.
- ORU — observation results. The result going back to the ordering system. The laboratory's main outbound message.
- ACK — acknowledgement. The receiver confirming it got the message, and whether it accepted it.
The flexibility is the problem
HL7 v2's optionality is why it works everywhere and why every interface is a project. The standard permits enormous variation: optional segments, locally defined Z-segments, differing code sets and differing conventions for which field carries which piece of information.
The practical consequence is that 'we support HL7' is not an integration statement. Every counterparty connection involves mapping their segments, fields and code sets to yours, agreeing what happens with the fields neither side populates, and testing against real messages rather than specification examples.
Any vendor who tells you an HL7 interface is plug-and-play has either not built one or is describing a counterparty they have already mapped.
Where interfaces break in practice
- Test code mismatches — their code is not in your catalog, and the order fails or, worse, maps to the wrong test
- Silent failures — a message rejected at the far end with nobody watching the acknowledgements
- Character encoding and delimiter collisions in free-text fields
- Timezone and date-format assumptions that differ between systems
- Patient identifier assumptions, particularly around which identifier is authoritative
- Volume behaviour — an interface that works fine at ten messages an hour and falls over at a thousand
What good interface handling looks like
The single most valuable property is visible failure. A message that cannot be processed should queue with the reason attached and appear in a monitored exception list. The failure mode to design against is not an error — it is silence, where messages stop arriving and nobody notices for three days.
The second is mapping that lives in configuration rather than in code, so onboarding a new counterparty does not require a release.
HL7 and FHIR together
FHIR is the modern successor, and it is a genuine improvement — resource-based, API-shaped, far easier to build against. It is also not going to displace v2 in laboratory interfaces quickly, because the installed base is enormous and works.
The realistic position for a laboratory platform is to run v2 properly today while being structured for FHIR exchange as counterparties become ready for it. Anyone claiming to have replaced v2 has not looked at what their interfaces actually send.