FHIR & HL7 Standards
HL7 vs FHIR: What's the Difference and Why It Matters
HL7 and FHIR are often spoken about as if one replaces the other. In practice, most healthcare teams are dealing with both, and the real challenge is knowing where each standard fits, where it breaks, and what that means for operational reliability.WeHub
Reading time: ~8-10 minHere’s the practical version of HL7 vs FHIR: HL7 v2 is the older messaging standard that still powers a huge amount of live healthcare data exchange, especially between operational systems; FHIR is a newer, resource-based standard designed to make data easier to structure, query, and use through modern APIs. In the NHS, both matter. HL7 v2 often keeps the lights on, while FHIR is increasingly central to newer API-led interoperability patterns, including FHIR UK Core and NHS API design. The real issue is not choosing a winner. It’s knowing what you already run, where the fragility is, and where a FHIR-first approach actually improves the workflow instead of just changing the vocabulary.
HL7 vs FHIR is not a simple replacement story
A lot of people talk about FHIR as though it simply replaces HL7. That's too neat, and it leads teams into bad assumptions.HL7 is not one thing. It is a family of standards. In day-to-day operational conversations, people usually mean HL7 v2, a long-established messaging standard used widely for clinical and administrative data exchange.FHIR is also an HL7 standard, but it works differently. It takes a more modern, resource-based approach and is designed to support interoperability through APIs and more structured data exchange patterns.So the question is not really "HL7 or FHIR?" in the broadest sense. It is more accurately:- HL7 v2 message-based exchange or FHIR resource/API-based exchange?
- Existing interface estate or newer interoperability design?
- Operational compatibility now or cleaner reuse later?
- Point-to-point message handling or a more reusable API/data model?
What HL7 v2 actually is in practice
HL7 v2 became popular because it was practical enough to be implemented across lots of healthcare systems. It is message-driven. A system emits a message when something happens: an admission, discharge, transfer, order, result, scheduling event, and so on.That matters because it matches real operational events.A patient is registered. A referral is created. A lab result is available. A clinic slot changes. HL7 v2 is very good at moving those event-style messages between systems that already understand that pattern.That is why it is still everywhere.It also explains why so many integrations are fragile. HL7 v2 allows flexibility, local variation, and implementation-specific choices. In theory, that helps adoption. In practice, it often means one supplier's "HL7 compatible" message is not quite the same as another's. Interfaces end up relying on mapping rules, local assumptions, and quiet tribal knowledge that lives with one integration engineer and one service desk person who really should not have to carry that much risk.The hidden cost is not just technical debt. It is operational dependency.What FHIR changes
FHIR takes a different approach. Instead of thinking mainly in terms of long event messages, it organises healthcare data into reusable resources such as Patient, Observation, Appointment, Practitioner, Medication, and Encounter.That gives teams a few practical advantages.First, data becomes easier to expose in smaller, more understandable chunks. You do not always need to parse a large message to find one useful detail.Second, the model is more reusable across different use cases. The same Patient resource can support multiple services if governance and profiling are handled properly.Third, it fits more naturally into API-led architecture, which is one reason NHS-facing APIs increasingly use FHIR patterns. In the UK context, FHIR UK Core is especially relevant because it helps standardise how FHIR is profiled and used across services.That does not mean FHIR is automatically simpler.FHIR can be easier to understand conceptually, but real implementation still involves profiles, extensions, terminology, version control, conformance, security, and governance. A badly governed FHIR programme can create a newer-looking mess rather than a better one.The real difference is message exchange versus usable data models
This is where the HL7 v2 vs FHIR comparison gets practical.HL7 v2 is often best understood as a standard for moving messages about events.FHIR is often best understood as a standard for working with structured healthcare data in a reusable way.That difference affects the sort of problems each one is better at solving.If your goal is to send ADT-style operational events from one established system to another, HL7 v2 may still be the quickest route.If your goal is to let multiple systems retrieve, validate, update, and reuse consistent patient, appointment, medication, or clinical data through modern APIs, FHIR is usually the better fit.The mistake teams make is assuming technical connectivity equals operational usefulness. It does not.A message can arrive successfully and still be hard to validate, hard to audit, hard to reuse, and hard to explain during a DPIA, an incident review, or a supplier handover. That is where healthcare interoperability standards stop being architecture diagrams and start affecting governance, support burden, and patient-facing reliability.Supporting Diagram
HL7 v2 Message Flow vs FHIR Resource Flow
Point-to-point event messaging on one side. Reusable API and resource-based exchange on the other.
Legacy Messaging
Modern API Exchange
HL7 v2
Point-to-point event messaging
Systems send structured event messages directly to other systems. It works, but usually depends on mappings, interfaces, and local assumptions.
🏥
PAS
Admission / discharge / transfer events
ADT / SIU / ORM messages
→
🩺
EPR
Consumes and routes updates
Interface-specific mapping
→
🧪
Lab System
Orders and results messages
Typical characteristics
- • Event-driven message exchange
- • Point-to-point integration patterns
- • Often supplier- or site-specific mappings
- • Strong operational fit, but fragile reuse
🔄
Governed interoperability layer
Mapping, validation, security
The layer that translates, checks, secures, and exposes data in a more usable way.
Standards
Audit
Transform
Validate
FHIR
Reusable resource and API-based flow
Structured resources are exposed through cleaner, reusable API patterns, making data easier to consume across multiple applications and services.
Patient
Appointment
Observation
Medication
REST / API / Resource access
💻
Clinician Portal
Reuses the same structured data
📱
Patient App
Consumes relevant resources via API
⚙️
Integration Service
Supports governed downstream reuse
Typical characteristics
- • Resource-based data model
- • API-friendly interoperability approach
- • Better reuse across multiple applications
- • Stronger fit for modern governed exchange
Key idea: HL7 v2 is usually about moving messages between systems when events happen. FHIR is usually about exposing reusable, structured data through a cleaner interoperability model.
Why NHS teams often end up dealing with both
If you work in or around NHS digital delivery, this is the part that matters most: you are unlikely to be choosing between a pure HL7 world and a pure FHIR world.You are usually dealing with a mixed estate.Some systems still exchange operational messages through HL7 v2. Meanwhile, newer NHS API patterns are increasingly built around FHIR. So the real-world picture is often:- legacy or established systems sending HL7 v2 messages
- newer supplier APIs using FHIR
- local integration layers translating between them
- governance teams asking how data lineage, traceability, and access are controlled
- operational teams only noticing the problem when something fails visibly
Where teams get stuck in practice
The hardest part is usually not the standard itself. It is the layer around it.A few common examples:1. They mistake format modernisation for workflow improvement. Moving from HL7 v2 to FHIR does not automatically fix a broken process. If the underlying workflow still has unclear ownership, poor validation, weak monitoring, or manual fallbacks, you have just wrapped the same problem in newer syntax.2. They underestimate profiling and local variation. FHIR is flexible, but that flexibility needs governance. Without agreed profiles, terminology, and validation rules, "FHIR-based" can still turn into supplier-specific interpretation.3. They ignore support and auditability. When an appointment, referral, or patient demographic update goes wrong, your service desk and operational teams need to know what happened. Message traces, API logs, validation errors, retry behaviour, and audit records are not optional extras. They are what keeps an interoperability layer governable.4. They treat interoperability as an IT-only issue. It is not. It affects admin time, booking accuracy, patient communications, duplicate data entry, and clinical confidence in the record.What good looks like in practice
Good does not mean replacing everything at once.Good usually looks like this:- you know which workflows still depend on HL7 v2
- you know where FHIR adds real value rather than fashionable complexity
- you have a clear mapping layer between standards where needed
- you profile and validate consistently
- you align terminology and data definitions early
- you make traceability visible to delivery, IG, and support teams
- you design for governance, not just transport
So which one should you use?
The honest answer is: it depends on the workflow you are solving.Use HL7 v2 where:- you are integrating with systems that already depend on it
- the event-message model fits the job
- replacing it would introduce more risk than value right now
- you need modern API access to structured clinical or operational data
- you want reuse across multiple services or applications
- you need alignment with current NHS API direction and FHIR UK Core patterns
- you want a cleaner long-term interoperability model for governed data sharing
- your estate is mixed
- your roadmap is phased
- your operational reality does not allow clean greenfield decisions
The bottom line
The most useful way to think about HL7 vs FHIR is not as a winner-loser debate. It is as an architecture and operating decision.HL7 v2 still matters because healthcare operations still run on it in many places. FHIR matters because modern interoperability, especially in NHS API design, increasingly depends on it.So the next move is not to ask, "Should we switch to FHIR?" in the abstract.Ask this instead: Which workflows are fragile today, which standard do they currently rely on, and where would a FHIR-based approach genuinely reduce operational burden, reuse data better, or improve governance?That question is much less glamorous. It is also the one that gets you to a plan.Keywords
HL7 vs FHIRHL7 v2 vs FHIR comparisonFHIR healthcare standard explainedhealthcare interoperability standards
Ready to fix this in your workflow stack?
Related Blogs
Turn healthcare workflow ideas into production-ready delivery
Whether you're exploring interoperability, workflow automation, HL7, FHIR, ESR, or internal operational delivery, WeHub helps teams design, govern, and run workflows without unnecessary complexity.
- Built for healthcare integration and operations
- Faster delivery with reusable workflow components
- Better governance, visibility, and scale