HL7 v2 and FHIR in plain English
Two standards carry almost all clinical data between systems. They look nothing alike, they are both very much alive, and most real practices end up using both.
Two standards carry almost all clinical data between systems. They look nothing alike, they are both very much alive, and most real practices end up using both at once. Here is the difference in terms that matter for a project.
HL7 v2
Dating from the late 1980s and still the workhorse of hospital and lab integration. A message is pipe-delimited text sent over a persistent connection, typically as a continuous stream of events:
MSH|^~\&|LAB|HOSP|EHR|CLINIC|20260829||ORU^R01|MSG001|P|2.5.1
PID|1||12345^^^MRN||DOE^JANE||19800101|F
OBX|1|NM|GLU^Glucose||99|mg/dL|70-110|N
Each line is a segment; MSH is the header, PID the patient, OBX a result. You will meet a handful of message types constantly: ADT (admit/discharge/transfer, and demographic updates), ORM (orders), ORU (results), SIU (scheduling), DFT (billing).
FHIR
Pronounced “fire”. A modern web API standard: data is modelled as resources — Patient, Observation, Encounter, MedicationRequest — retrieved over ordinary HTTPS and returned as JSON.
GET /Patient/12345 returns that patient. GET /Observation?patient=12345&code=glucose returns their glucose results. Any developer who has used a web API is immediately productive, which is much of the point.
FHIR is request-driven where v2 is event-driven: you ask for what you need, rather than receiving a stream of everything that happens.
Side by side
| Shape | v2: pipe-delimited messages pushed on events. FHIR: JSON resources pulled on request. |
|---|---|
| Transport | v2: a raw TCP connection, usually across a VPN. FHIR: HTTPS, with OAuth for authorisation. |
| Best at | v2: high-volume system-to-system flow — lab results, ADT feeds. FHIR: apps, patient access, dashboards, targeted queries. |
| Ecosystem | v2: universal in hospitals and labs. FHIR: universal in new development, and mandated for certified EHR APIs in the US. |
| Effort | v2: cheap where an interface already exists, painful to build fresh. FHIR: quick to start, and the standard everything new is built against. |
Terms you will hear
- C-CDA — a structured clinical document (a summary of care), commonly exchanged at referral or transition. Document-shaped rather than message- or resource-shaped.
- SMART on FHIR — a standard way for an app to authenticate and launch inside an EHR. This is what “an app that runs in the chart” usually means.
- US Core — the profile that pins down which FHIR fields are actually required in the US, so implementations agree.
- Interface engine — middleware sitting between systems, translating and routing. Where the local quirks get absorbed.
- Information blocking — the rules constraining vendors and providers from unreasonably restricting access to electronic health information. Relevant leverage when a vendor is uncooperative.
Which does your project need?
- Receiving lab results — almost certainly HL7 v2 ORU. The lab will tell you their spec.
- Feeding demographics to another system — v2 ADT, usually.
- Building or buying an app that reads the chart — FHIR, via SMART.
- Giving patients their data — FHIR; certified EHRs are required to expose it.
- A dashboard across several systems — FHIR where available, an interface engine for the rest.
FAQ
Our vendor says they “support HL7”. Is that enough to plan on?
No. Ask which version, which message types, which direction, over what transport, and whether there is a fee per interface. “Supports HL7” is close to meaningless without those answers — and per-interface fees are where budgets get surprised.
Can we skip the interface and export spreadsheets?
For a one-off analysis, sometimes. For anything ongoing it is a trap: manual exports break, drift, get forgotten, and move PHI through email and desktops. Automate it properly.
Is FHIR secure enough for PHI?
Yes — it runs over HTTPS with OAuth-based authorisation and scoped access, which is a stronger position than a plain v2 feed over a VPN. As always, the standard is only as secure as the implementation and the BAAs around it.