Follow one outpatient visit through a hospital and you'll see data change hands a dozen times: registration to the lab, the lab back to the doctor, the doctor to billing, billing to the insurer and the insurer's payment back again. Most of those hand-offs use one of three families of standards. Knowing which carries what is half of understanding provider systems.
HL7 v2 — the hospital's internal messages
HL7 version 2 is the long-standing workhorse inside hospitals. It's a compact, pipe-delimited message format sent between systems through an integration engine. The message types you'll meet first are:
- ADT — admit, discharge and transfer events. When a patient is registered, admitted or moved, ADT messages keep the lab, pharmacy, billing and bed-management systems in step.
- ORM / OML — orders, such as a blood test requested by the doctor.
- ORU — results coming back, such as that blood test's values.
HL7 v2 is flexible, which is both its strength and its risk: each hospital maps fields a little differently, so the same message can mean different things between two sites.
FHIR — the modern API layer
FHIR (Fast Healthcare Interoperability Resources) exchanges data as small, well-defined resources — Patient, Encounter, Observation, MedicationRequest — over web APIs, usually as JSON. It's what patient apps, portals and newer integrations use. FHIR sits alongside HL7 v2 rather than replacing it overnight, so most hospitals run both.
X12 — the money
In the US, the business side of a visit moves as X12 transactions between the provider, clearinghouses and payers:
- 270 / 271 — the eligibility question and answer: is this patient's cover active, and what does it pay for?
- 837 — the claim sent to the payer.
- 835 — the remittance advice that comes back, explaining what was paid, adjusted or denied.
Other countries use their own formats and schemes for claims — in India, cashless treatment involves pre-authorisation with the insurer or its TPA — but the business questions are the same.
Where they meet
The standards connect through identifiers. The medical record number (MRN) ties clinical messages to the right patient; the encounter or visit number ties orders, results and charges to one visit; member and claim IDs tie the money back. When an identifier is mapped wrongly, data lands in the wrong place — and in healthcare that can be a patient-safety event, not just a bug.
What to test
- Identity — the MRN and encounter number survive every hop, and duplicate patients are caught at registration.
- Reconciliation — every order has a result, every result has an order, and nothing is silently dropped or duplicated by the integration engine.
- Negative acknowledgements — what happens when a system rejects a message, and who is told.
- Mapping changes — any change to an interface mapping gets a regression test with real-looking messages, not just the happy path.
- Money — charges captured for the encounter reach the claim, and the 835 posts correctly against the patient account.
- Privacy — test messages use masked or synthetic data, never real patient information.
You don't need to memorise every segment. Learn what each standard is for, follow one visit end to end, and the rest becomes much easier to read.