FHIR vs HL7: The Differences That Matter

What FHIR stands for

FHIR stands for Fast Healthcare Interoperability Resources. It is pronounced "fire," which is the only fun part of this subject.

It is a modern interoperability standard for moving health data over ordinary web APIs, published by the same organisation that produced the older standards it is often compared against.

The unit of work is the resource. A Patient, an Observation, a MedicationRequest — each is a self-contained object with a defined shape and its own address.

FHIR is designed so a developer who has used any REST API can be productive quickly, rather than needing months of healthcare-specific training first.

What HL7 actually refers to

Here is the confusion at the root of most FHIR vs HL7 conversations: HL7 is both an organisation and a family of standards.

Health Level Seven International is the standards body. It has published several standards over four decades, and FHIR is one of them.

So when people say "HL7" in casual conversation they almost always mean HL7 v2, the message-based standard from the late 1980s that still carries most hospital traffic.

That makes "FHIR vs HL7" slightly the wrong framing. FHIR was developed by HL7 International too. The real comparison is FHIR against HL7 v2.

It matters practically, because a vendor claiming "HL7 support" might mean either one, and you need to ask which.

Key differences between HL7 v2 and FHIR

Five differences explain nearly everything else.

Direction. An HL7 v2 message is pushed at you when an event happens. FHIR is pulled — you request what you want, when you want it.

Format. HL7 v2 uses pipe-delimited segments that are compact and unfriendly to read. FHIR returns JSON or XML that any modern tool handles natively.

Transport. HL7 v2 typically runs over a persistent connection inside a hospital network. FHIR runs over ordinary HTTPS, so it works across the internet.

Granularity. An HL7 v2 message carries an event and its context. A FHIR resource is addressable on its own, so you can fetch exactly one thing.

Learning curve. HL7 v2 requires specialist knowledge and usually specialist staff. FHIR is closer to ordinary web development.

The difference between HL7 v2 and FHIR is less about capability than about fit. Each was designed for the problem of its era, and both problems still exist.

HL7 vs FHIR at a glance

If you only remember one paragraph, make it this one.

The HL7 v2 standard pushes messages when events happen, inside a trusted network, in a compact format built for machines in 1989.

The FHIR standard answers questions on demand, over the open web, in a format built for developers in the 2010s.

Both are HL7 standards. Both move healthcare information. Neither is going away this decade.

Standards like these are tools rather than teams to support. The useful question is never which is better, only which fits the job in front of you.

Where each fits in an electronic health record estate

Inside a hospital, the electronic health record sits at the centre and everything negotiates with it.

HL7 v2 feeds are how that record learns things. An admission, a discharge, a finalised lab result — each arrives as a message, unprompted.

FHIR is how other software asks the electronic health record questions. What medications is this patient on, what were the last three results, who is their care team.

Health data exchange between organisations is a third case again, handled by networks built on top of both.

A product connecting to a hospital usually needs the first two. Treating either as optional is how integration timelines slip.

Common misconceptions

A few beliefs cause most of the confusion in this area, and they are worth naming directly.

"HL7 is old, FHIR is new, so use FHIR." FHIR was developed by HL7 International. Both are current, and HL7 fhir support is normally a single conversation with the same vendor.

"If a vendor supports FHIR, we are done." Support varies by resource and by site. Ask which resources, which version, and read or write.

"We can skip HL7 v2 entirely." Occasionally true for a purely patient-facing product. Rarely true for anything used inside a hospital.

"Migrating everything to FHIR will simplify things." It will simplify some things and create a parallel system to maintain during the transition.

Is FHIR replacing HL7?

Partly, slowly, and not everywhere. Anyone giving you a cleaner answer is selling something.

FHIR is clearly taking over anything an application needs to query, and regulation accelerated that. The 21st Century Cures Act pushed certified systems to expose FHIR APIs, and CMS extended similar expectations to payers.

But HL7 v2 keeps carrying the high-volume event traffic inside hospitals, and there is no clinical benefit to replacing an interface that works.

The realistic picture is coexistence for years. Most healthcare organizations run both, and most integration projects touch both.

Treating it as a migration deadline leads to wasted budget. Treating it as two tools with different jobs leads to better architecture.

Is HL7 still relevant?

Very. It is infrastructure, and infrastructure outlives fashion.

Interfaces built fifteen years ago still run in production because they work, and because touching them carries risk without reward. An established standard like HL7 v2 tends to outlive predictions of its death.

Any digital health product selling into hospitals will meet HL7 v2 whether it planned to or not. Products that only speak FHIR quietly lose deals to products that speak both.

The skill shortage is real too. Fewer engineers learn HL7 v2 each year, which makes the people who know it more valuable rather than less.

Advantages of FHIR

The developer experience is the headline. Standard web patterns mean a smaller team can build something useful faster.

Granular access is the second. Fetching one resource instead of parsing a whole message is both simpler and cheaper.

Reach is the third. Because FHIR travels over HTTPS, it works for mobile apps and patient-facing tools in a way HL7 v2 never could.

And the ecosystem is growing. Profiles, test servers, and open-source tooling all exist, which was not true a decade ago.

Disadvantages of FHIR

This part gets skipped in most comparisons, and it is the part that costs projects money.

Optionality. The specification allows a great deal of variation. Two systems can both be compliant and still not work together without adjustment.

Uneven coverage. A vendor may support the resources you do not need and lack the one you do. Write access is patchier than read access almost everywhere.

Poor fit for high-volume events. Polling a FHIR API for constant admission updates is inefficient. That is what messaging was good at.

Performance at scale. Per-patient calls do not work for population analytics, which is why bulk access exists as a separate mechanism.

Version churn. The standard has moved considerably, and older implementations linger.

None of these are reasons to avoid FHIR. They are reasons to scope carefully rather than assume the standard removes all friction.

When to choose HL7, FHIR, or both

The choice usually makes itself once you name the use case.

Choose FHIR when an application or a user is asking a question, when the traffic crosses organisational boundaries, or when you are building anything patient-facing.

Choose HL7 v2 when you need high-volume event notification inside a healthcare system, or when the far end simply offers nothing else.

Choose both when you are connecting a real product to a real hospital, which is most of the time.

The wrong approach is picking a standard first and finding a use case for it second.

How they work together in practice

A typical arrangement looks like this.

An HL7 v2 message tells your system that a patient has been admitted. That is the trigger, delivered instantly without anyone polling.

Your application then calls the FHIR API to fetch the details it needs — problems, medications, recent results.

When the work is done, it writes a document or observation back, either through FHIR or as an HL7 v2 message, depending on what the health systems on the other end accept.

That pattern — messaging for events, APIs for detail — covers a large share of real healthcare data exchange.

Migrating from HL7 to FHIR

Migration is a real project and worth doing selectively rather than wholesale.

The strongest case is an interface that has become unmaintainable, or one where the receiving side has moved on.

The mechanics involve mapping HL7 v2 segments to FHIR resources, which is rarely one-to-one. Fields that were free text need structure, and codes need reconciling.

Run both paths in parallel and compare outputs before cutting over. Skipping that step is how silent divergence gets into patient records.

Budget for the identity work. Matching patients across the old and new paths is the part that consumes time.

Versions worth knowing

HL7 v2 is still evolving in minor versions, with 2.5.1 the most widely deployed in the United States.

HL7 v3 existed and largely failed to gain traction, which is part of why FHIR was designed the way it was. CDA, the document standard, came out of that era and is still used.

FHIR reached maturity at R4, which is what nearly all US work targets, constrained by US Core profiles. Later releases exist but adoption lags the specification by years.

When someone says they support FHIR, ask which version and which profiles. The answer changes what you have to build.

Security and compliance differences

Both carry protected health information, so HIPAA applies equally. How they protect it differs.

HL7 v2 has essentially no built-in security. It relies on the network around it — private connections, VPNs, and firewalls doing the work.

FHIR inherits web security. OAuth 2.0 scoped tokens, TLS, and per-request authorisation are part of how it is used.

That makes FHIR safer to expose outside a network and HL7 v2 dependent on never being exposed at all.

Audit logging matters for both. If you cannot show who accessed which record, neither standard will save you in an investigation.

If you need this built rather than compared, our FHIR integration and HL7 integration pages cover the engineering, and our guide to EHR integration costs covers the budget.