A product manager asked us last year whether her team should "go with FHIR or stick with HL7."
It is the most common question in healthcare integration and it contains a hidden error, because FHIR is HL7. Same organisation, different standard, about twenty years apart. Asking which to pick is a little like asking whether to buy a Toyota or a car.
Clearing that up resolves most of the confusion. What remains is a genuinely useful question: which of HL7's standards does your integration need, and why do hospitals still run the old one?
Must Read: HL7 Integration Services: What You're Actually Paying For
Three things called HL7
HL7 International is the standards organisation. Founded 1987. It writes healthcare data standards, and it wrote both of the things below.
HL7 v2 is a message format first released in 1989. Pipe-delimited text, segment-based, sent over a transport called MLLP. When a hospital says "we will send you an HL7 feed," this is almost always what they mean.
FHIR is HL7's newer standard, pronounced "fire." REST, JSON, resources, OAuth. It looks and behaves like an API a modern developer would recognise.
So "FHIR vs HL7" is really "FHIR vs HL7 v2." Everything below uses that framing.
What they actually look like
A patient admission in HL7 v2:
MSH|^~\&|EPIC|MERCYHOSP|INTAKE|CLINICAPP|20261020083012||ADT^A01|MSG00412|P|2.5.1
PID|1||4471190^^^MERCY^MR||CHEN^SARAH^L||19840312|F|||12 PALM ST^^MIAMI^FL^33180
PV1|1|I|4WEST^412^B||||1234^RIVERA^ANA
Position matters. Field 5 of PID is the name because field 5 is defined as the name. There is no label telling you so.
The same patient as a FHIR resource:
{
"resourceType": "Patient",
"id": "4471190",
"name": [{ "family": "Chen", "given": ["Sarah", "L"] }],
"gender": "female",
"birthDate": "1984-03-12"
}
Self-describing, and you can read it without the specification open on the other monitor. That difference is most of why developers prefer FHIR.
Side by side
| | HL7 v2 | FHIR | | --- | --- | --- | | First released | 1989 | 2014 as a draft; R4, the first release with normative content, in 2019 | | Format | Pipe-delimited text | JSON or XML | | Transport | MLLP over TCP | HTTPS / REST | | Direction | Push: events arrive as they happen | Pull: you request what you need | | Learning curve | Steep, specification-dependent | Shallow for anyone who knows REST | | Tooling | Interface engines | Ordinary HTTP tooling | | Hospital coverage | Near-universal | Growing, uneven by vendor and version | | Best at | High-volume event streams | On-demand queries, apps, patient access |
The push and pull distinction in that table is the one that decides architectures, and it gets missed more than the format difference does.
Why v2 refuses to die
If FHIR is better, why does anyone still send pipe-delimited text?
Because the v2 interfaces already work. A large hospital may run hundreds of them: lab, radiology, pharmacy, billing, scheduling, bed management. Each was built, tested, validated and signed off, often a decade ago. Each moves real patient data that clinicians depend on at 3am.
Nobody gets promoted for replacing an interface that works. They get fired for breaking one.
There is also a capability gap people underestimate. V2 is event-driven by design. When a patient is admitted, the message is pushed to every subscribed system within seconds, with no polling. FHIR has subscription mechanisms, but support across real deployments is patchier than the specification suggests. For a high-volume real-time feed, v2 is frequently still the pragmatic answer.
Where each one wins
Reach for FHIR when you are building an app a clinician launches inside the EHR, giving patients access to their own records, querying specific data on demand, or integrating with any product designed in the last few years. Patient-facing work in particular is strongly FHIR-shaped, partly because US regulation has pushed vendors to expose FHIR APIs for patient access.
Reach for v2 when you need a continuous stream of events as they occur, you are connecting to an ancillary system like a lab or pharmacy instrument, or the hospital's integration team hands you a v2 specification and no alternative. That last case is common and is not negotiable.
Expect both on anything substantial. A typical real project takes an ADT feed over v2 for real-time patient events, then uses FHIR to pull detail on demand.
What FHIR does not fix
This is where teams lose months, so it is worth stating plainly.
FHIR standardises the envelope. It does not standardise what is inside it.
It will not tell you that the Sarah Chen in this response is the same person as the S. Chen in that one, because the US has no national patient identifier. It will not reconcile a hospital's local lab codes against LOINC. It will not tell you whether a resource reflects this morning or a document imported in 2019. And FHIR servers vary in which resources and versions they support, so "supports FHIR" from two vendors can mean materially different things.
Those four problems are the actual work: identity, terminology, freshness, provenance. They are yours in either standard. We went through them in clinical data integration.
Does a migration make sense?
Occasionally a team proposes replacing working v2 interfaces with FHIR equivalents. It is usually the wrong project.
Reasons to leave them alone: they work, they are validated, the hospital's team knows them, and the benefit is developer comfort rather than clinical capability.
Reasons that do justify FHIR work: a new capability v2 handles poorly, a patient-facing feature, an app that needs to launch in the clinician's workflow, or a hospital actively retiring an interface.
The sane pattern is additive. Leave v2 doing what it does well, add FHIR for new use cases, and accept that you now maintain both. That is not a transitional state anyone is embarrassed about. It is the steady state at most US health systems, and will be for years.
The short version
FHIR and v2 are both HL7 standards, so the question is never which organisation to follow. V2 is a 1989 event-streaming format that still carries most hospital traffic and is not going away. FHIR is a modern REST API that is better for queries, apps and patient access, and it is growing.
Most real integrations use both. Neither solves patient identity, terminology mapping, data freshness or provenance, which is where the effort actually goes. Pick based on what the hospital supports and what your feature needs, not on which one is more pleasant to write against.
Trying to work out which standard your integration actually needs? Tell us what you are building and we will give you a straight answer, including when the answer is "both." No pitch.
Must Read: EHR Integration Services: What the Work Actually Involves
Blogs:
Explore all blog
Healthcare Data Integration: Choosing an Architecture Before You Need One
Nobody chooses point-to-point integration. You arrive at it, one urgent connection at a time, until the diagram has forty lines on it and nobody will touch it. Here is how the architecture decision actually gets made.
What Epic Actually Costs, and Why Nobody Can Quote You a Number
Search for Epic's price and you will find numbers ranging from $1,200 to $30 million on the same page. Both are sort of true, which is the problem. Here is what can actually be verified.
HL7 Integration Services: What You're Actually Paying For
A CTO told us his platform was FHIR-native, so HL7 wasn't his problem. Two weeks later the hospital sent over a spec for an ADT feed over MLLP. Here's what HL7 integration work actually involves, and what makes one interface cost three times another.