HL7 vs FHIR: Complete Comparison for Healthcare Developers (2026)

Key Takeaways:

• HL7 v2 is a 30-year-old messaging standard that still powers 95% of hospital system communication today
• FHIR (Fast Healthcare Interoperability Resources) is the modern REST API-based standard built for web and mobile
• HL7 v2 and FHIR are not competitors — most enterprise healthcare systems use both simultaneously
• The 21st Century Cures Act mandates FHIR R4 APIs for patient data access — compliance is not optional
• Choosing between HL7 and FHIR isn’t the right question — knowing when to use each one is

What Is HL7?

HL7 — Health Level Seven — is a set of international standards for the exchange, integration, sharing, and retrieval of electronic health information. The “Level Seven” refers to the seventh layer of the ISO OSI network communication model, which is the application layer.

HL7 has been around since 1987. Version 2 (HL7 v2), released in 1989 and still widely used today, is the most deployed healthcare IT standard on the planet. If you have worked with any hospital system, EHR, lab, or pharmacy system in the US, you have almost certainly worked with HL7 v2 messages whether you knew it or not.

HL7 v2 is a pipe-delimited, text-based messaging format. A typical HL7 v2 message looks like this:

MSH|^~\&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260215120000||ADT^A01|MSG001|P|2.5
EVN|A01|20260215120000
PID|1||123456^^^MRN||Smith^John^A||19800101|M|||123 Main St^^Chicago^IL^60601

It is not pretty. It was not designed to be. It was designed to move clinical data between systems reliably, and it has done that job for over 30 years. That is why it is still everywhere.

HL7 v3 was an attempt to modernize the standard using XML. It was technically more rigorous but far more complex to implement, and it never achieved the adoption that v2 had. Most developers working in healthcare today deal with v2 and largely skip v3 entirely.

For a deeper technical breakdown of how HL7 works in real integrations, see our guide on HL7 integration.

What Is FHIR?

FHIR — Fast Healthcare Interoperability Resources, pronounced “fire” — is a standard developed by HL7 International (the same organization) and published in 2014. It is a complete rethinking of how healthcare data should be exchanged in a modern, web-connected world.

Where HL7 v2 is a messaging standard built around documents and events, FHIR is a RESTful API standard built around resources. Each clinical concept — a patient, a medication, an observation, a diagnosis — is represented as a discrete FHIR resource with a defined schema, accessible via standard HTTP methods (GET, POST, PUT, DELETE).

A FHIR API call to retrieve a patient looks like this:

GET /Patient/123456

The response comes back as JSON or XML:

{
  "resourceType": "Patient",
  "id": "123456",
  "name": [{"family": "Smith", "given": ["John"]}],
  "birthDate": "1980-01-01",
  "gender": "male"
}

Any developer who has worked with REST APIs can immediately understand this. That accessibility is intentional. FHIR was designed to make healthcare data as easy to work with as any modern web API.

FHIR R4 is the current production standard, released in 2019 and mandated by the 21st Century Cures Act for patient data access. FHIR R5 was published in 2023 and adds significant improvements, though R4 remains the regulatory baseline.

For implementation details and real-world FHIR API development, see our guide on FHIR API development in healthcare.

HL7 vs FHIR: Side-by-Side Comparison

HL7 v2 Message Types Every Developer Should Know

If you are building any system that touches a hospital or large clinic, you will encounter these HL7 v2 message types:

ADT Messages (Admit, Discharge, Transfer). These are the most common HL7 messages in any hospital environment. ADT^A01 is patient admission. ADT^A02 is patient transfer. ADT^A03 is patient discharge. ADT^A08 is patient information update. Every downstream system — billing, lab, pharmacy, radiology — listens for ADT messages to keep patient records current.

ORM Messages (Order Messages). ORM^O01 is used to send clinical orders from a physician order entry system to a lab, radiology department, or pharmacy. When a doctor orders a blood test, an ORM message carries that order to the lab system.

ORU Messages (Observation/Result). ORU^R01 carries lab results, radiology reports, and other clinical observations back to the ordering system and the EHR. When your lab results come back, they travel as ORU messages.

DFT Messages (Detail Financial Transaction). DFT^P03 carries charge information from clinical systems to the billing system. Every billable service generates a DFT message. If your medical billing automation is broken, a misconfigured DFT interface is often the reason.

MDM Messages (Medical Document Management). MDM^T02 carries clinical documents — discharge summaries, operative reports, transcribed notes — between systems.

SIU Messages (Scheduling Information Unsolicited). SIU^S12 through S26 handle appointment scheduling events. When an appointment is booked, modified, or cancelled, SIU messages notify connected systems.

Understanding which message type handles which workflow is foundational to healthcare interoperability work.

FHIR Resources Every Developer Should Know

FHIR organizes all clinical and administrative data into typed resources. These are the ones you will use constantly:

Patient. Demographic information about an individual. Name, DOB, gender, address, identifiers. The foundation of every clinical workflow.

Practitioner and PractitionerRole. Provider information — who the clinician is, and what role they play at a specific organization or location.

Encounter. A clinical contact between a patient and a provider. Inpatient stays, outpatient visits, emergency department visits, telehealth sessions are all Encounters.

Observation. Clinical measurements and findings — vital signs, lab results, social history responses, assessment scores. One of the most heavily used FHIR resources.

Condition. Diagnoses, problems, and health concerns. Maps to ICD-10 coding in US implementations.

MedicationRequest. A prescription or medication order. Replaces the ORM message for medication orders in FHIR-based workflows.

DiagnosticReport. Lab and radiology reports, including references to the raw Observation resources that make up the report.

Claim and ExplanationOfBenefit. Billing and reimbursement data. Critical for EHR integration with billing systems.

DocumentReference. Pointers to clinical documents stored outside the FHIR server — PDFs, CDA documents, images.

Coverage. Patient insurance information — payer, plan, member ID, group number.

When to Use HL7 vs FHIR

This is the practical question that actually matters for most development projects.

Use HL7 v2 when:

You are integrating with existing hospital systems that already speak HL7 — which is almost every EHR, lab system, radiology system, and pharmacy system currently in production. Real-time event-driven messaging inside a hospital network (patient ADT events, lab orders and results, charge capture) is where HL7 v2 still dominates and will continue to for years. You are not building something new from scratch — you are connecting to something that already exists.

Use FHIR when:

You are building a patient-facing application that needs to pull data from an EHR. You are building a third-party app that needs to launch within an EHR workflow (this is what SMART on FHIR is designed for). You need to comply with CMS or ONC regulations that mandate FHIR APIs for patient data access. You are building new infrastructure and want to use modern web standards. You need to pull bulk clinical data for analytics or population health (FHIR Bulk Data Export). You are building integrations with payers, who are now required by CMS to expose FHIR APIs.

Use both simultaneously when:

You are building an HMS or enterprise clinical platform that needs to receive real-time events from hospital systems (HL7 v2) while also exposing modern APIs for patient-facing apps and third-party integrations (FHIR). This is the reality of most enterprise healthcare IT projects today.

Can HL7 and FHIR Work Together?

Yes — and in most real-world healthcare environments, they have to.

The typical enterprise architecture looks like this: HL7 v2 messages flow between internal hospital systems via an integration engine. That integration engine transforms and routes messages, translates HL7 v2 data into FHIR resources where needed, and exposes FHIR APIs for external and patient-facing applications.

This is exactly what Mirth Connect is designed to do. Mirth Connect can receive HL7 v2 messages via MLLP, transform them using JavaScript or built-in transformers, convert them to FHIR resources, and expose them via REST. It can also do the reverse — receive FHIR API calls and translate them into HL7 messages for legacy systems that don’t speak FHIR natively.

The transformation between HL7 v2 and FHIR is not trivial. HL7 v2 segments don’t map directly to FHIR resources in every case. Local variations in how organizations implement HL7 v2 (and there are many — v2 allows enormous flexibility) mean that mapping tables need to be built and tested carefully for each integration. This is one of the main reasons experienced healthcare integration developers are hard to find and expensive when you do.

FHIR R4 vs R5: What’s Changed

FHIR R5 was published by HL7 in 2023. R4 remains the regulatory baseline in the US — the 21st Century Cures Act mandates R4, and Epic, Cerner, and most major EHRs have certified R4 implementations. R5 brings meaningful improvements but is not yet widely deployed.

Key changes in R5 worth knowing:

Subscription improvements. R5 significantly overhauled the Subscription resource, making real-time notifications from FHIR servers much more reliable and configurable. This matters for applications that need to react to clinical events as they happen.

Cross-version analysis resources. Better tooling for comparing data across different FHIR versions and implementations — important for large health systems running multiple EHR versions.

Improved modeling for complex clinical concepts. Several resources were refined based on years of real-world R4 implementation feedback, making them more accurate for clinical use cases.

New resources. R5 added resources for concepts that weren’t well covered in R4, including better support for formulary data, evidence-based medicine, and clinical trial data.

For new projects starting today, build on R4 — it’s the compliance baseline and has the broadest EHR support. Design your architecture to be version-aware so you can adopt R5 capabilities as EHR support matures. For a broader look at how this fits into EHR modernization strategy, that context matters a great deal when planning new integrations.

Common Integration Mistakes

These are the mistakes development teams make most often when working with HL7 and FHIR:

Assuming HL7 v2 is standardized. HL7 v2 allows enormous local variation. Two hospitals can both claim to send “standard” HL7 ADT messages and produce completely different message structures. Always get sample messages from the source system before building your interface, not after.

Ignoring acknowledgment handling. HL7 v2 uses ACK messages to confirm receipt. Systems that don’t implement proper ACK handling will silently lose messages. A missing ADT event downstream means a patient record that doesn’t get updated — with real clinical consequences.

Treating FHIR as a database. FHIR is an API standard, not a database architecture. Building an application that queries FHIR for every user interaction without caching will create performance problems at scale.

Underestimating FHIR profile complexity. US Core profiles, Da Vinci profiles, SMART on FHIR launch — FHIR in the US has a layered profile ecosystem that goes well beyond the base standard. US Core in particular adds must-support requirements and terminology bindings that every US implementation needs to handle.

Skipping HIPAA design for FHIR APIs. FHIR APIs expose PHI over HTTP. Every FHIR endpoint needs proper authentication (OAuth 2.0 / SMART), authorization scopes, TLS encryption, and audit logging to meet HIPAA technical safeguard requirements. This is not optional.

Building point-to-point integrations. Connecting System A directly to System B, then System A to System C, then System B to System D creates an unmaintainable web of integrations. Every new system adds exponential complexity. A central integration engine handles this properly.

The Bottom Line

HL7 v2 and FHIR are not opposing standards — they are complementary tools that solve different problems in healthcare interoperability. HL7 v2 is the language of existing hospital infrastructure. FHIR is the language of modern healthcare applications, regulatory compliance, and patient data access.

The developers and teams who build the best healthcare integrations are not the ones who pick a side. They are the ones who understand both deeply enough to use each one where it belongs — and who know how to build the translation layer between them when the architecture requires it.

If you are working on a healthcare integration project and need a team that has done this in production across Epic, Cerner, Athenahealth, and dozens of specialty systems, Taction Software’s integration team is the right conversation to have.

Related Reading:

• HL7 Integration: What It Is and How It Works
• FHIR API Development in Healthcare
• Healthcare Interoperability Solutions
• Mirth Connect Integration Services
• EHR Integration Services
• EHR Modernization Strategy