FHIR vs HL7: A Practical Comparison for Healthcare Software Teams

If you are building software that integrates with hospitals, clinics, health systems, or any EHR platform, you will encounter both HL7 v2 and FHIR. Understanding the difference between them is not just an academic exercise — choosing the wrong integration approach for a given environment can cost months of development time and produce an integration that no one can maintain.

This guide is written for engineering teams who need to make concrete decisions about healthcare integrations, not for readers who want a survey of standards bodies and working group history.

HL7 v2: What It Is and Why It Still Dominates

HL7 v2 is a messaging standard that has been in production use since 1987. It is pipe-delimited, segment-based, and looks like this:

MSH|^~\&|SendingApp|SendingFacility|ReceivingApp|ReceivingFacility|20260217142311||ADT^A01|MSG000001|P|2.5
EVN|A01|20260217142311
PID|1||12345^^^Hospital^MR||Smith^John^A||19800315|M|||123 Main St^^Tampa^FL^33601^US|||||||12345-6789
PV1|1|I|2NORTH^201^01^Hospital||||1234^Attending^Doctor|||||||||||V|2026001234

Each caret-delimited field is a segment. The message type (ADT^A01, in this case an admit notification) tells the receiving system what to do with the message. HL7 v2 has message types for every significant clinical event: admissions (ADT), laboratory results (ORU), orders (ORM), pharmacy (RDE), scheduling (SIU), and more.

HL7 v2 is not a modern standard. It predates JSON, REST, and modern API design patterns by decades. But it is the integration backbone of essentially every hospital built before 2015, and many built after. Epic, Cerner (Oracle Health), MEDITECH, and McKesson — the EHRs running most US hospitals — all speak HL7 v2 natively through their integration engines.

The reason HL7 v2 persists is not technical merit. It persists because hospitals have integration engines (Mirth Connect, Rhapsody, Infor Cloverleaf, Iguana) that process millions of HL7 v2 messages per day across connections that have been stable for years. Replacing that infrastructure is expensive and risky, and there is no compelling reason to do it when the existing system works.

What "Works" Actually Means

HL7 v2 interoperability is often described as "minimal interoperability" in the standards community, and this is fair. The standard permits significant field-level variation. The same concept may be encoded differently across hospitals, or even across departments in the same hospital. Z-segments — custom extensions — are common and non-portable.

What this means in practice: building an HL7 v2 integration involves not just implementing the standard but negotiating with the specific hospital's implementation of the standard, which will have its own field population patterns, message volume characteristics, and historical quirks. You do not implement HL7 v2 once and connect to every hospital. You implement HL7 v2 and then tune for each site.

This site-by-site variation is the primary cost driver for HL7 v2 integrations. Budget for discovery and customization at each new site.

FHIR: What It Actually Is

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a standard developed by HL7 International starting around 2011, with R4 reaching normative status in 2019. It is fundamentally different from HL7 v2 in both design and intent.

FHIR is REST-based and resource-oriented. Clinical data is modeled as typed resources (Patient, Observation, Encounter, Medication, DiagnosticReport, and hundreds of others), exchanged as JSON or XML, and accessed through a RESTful API:

GET /Patient/12345
GET /Observation?patient=12345&code=http://loinc.org|2339-0
POST /DocumentReference

A FHIR Patient resource looks like this (abbreviated):

{
  "resourceType": "Patient",
  "id": "12345",
  "identifier": [
    {
      "system": "http://hospital.org/mrn",
      "value": "MRN-789456"
    }
  ],
  "name": [
    {
      "family": "Smith",
      "given": ["John", "A"]
    }
  ],
  "birthDate": "1980-03-15",
  "gender": "male",
  "address": [
    {
      "line": ["123 Main St"],
      "city": "Tampa",
      "state": "FL",
      "postalCode": "33601"
    }
  ]
}

FHIR resources reference each other by ID, support standard CRUD operations, and are designed to be queried using a standardized search API. The model is far more developer-friendly than HL7 v2 if you are building a new integration and your target system supports it.

SMART on FHIR

SMART on FHIR (Substitutable Medical Applications and Reusable Technologies) is a framework layered on top of FHIR that adds OAuth 2.0-based authorization and a standardized launch context. It enables applications to be launched from within EHRs with the appropriate patient and user context, and to request scoped permissions to read or write FHIR resources.

SMART on FHIR is the mechanism by which third-party applications integrate with modern EHR APIs. If you are building an application that will be accessed from within Epic, Cerner, or another SMART-enabled EHR, SMART on FHIR is not optional — it is the integration model.

Key Differences: A Side-by-Side View

FHIR R4 vs R5

R4 is the current normative standard and is what you will encounter in production EHR APIs. Epic, Cerner, and most payers that offer FHIR APIs support R4.

R5 was released in 2023 and introduces meaningful improvements: a more robust subscription model, improved versioning support, enhanced search capabilities, and refinements to several resource types. However, as of early 2026, R5 is not widely implemented in production EHR systems. Building a new integration against R5 will limit your compatible systems.

The practical guidance: target R4 for any integration you are building now. Monitor R5 adoption, particularly in the subscription and event notification use cases where R5 improvements are most significant.

The 21st Century Cures Act and FHIR Mandates

The 21st Century Cures Act (2016) and the HHS Interoperability and Information Blocking rules (finalized 2020, enforcement began 2022) created a regulatory mandate for FHIR-based data access.

The key requirements:

Certified EHR Technology — EHRs that seek ONC certification (required for Meaningful Use incentives) must support FHIR R4 APIs for patient data access, specifically through SMART on FHIR-enabled apps.

US Core profiles — The regulations mandate support for the US Core Implementation Guide, which defines the minimum data elements and FHIR profiles that must be supported. US Core R4 profiles specify required fields and search parameters for Patient, Condition, AllergyIntolerance, Immunization, MedicationRequest, and other core resources.

Information blocking prohibitions — Health systems, EHR vendors, and health IT developers are prohibited from practices that unreasonably restrict the access, exchange, or use of electronic health information. This creates a legal environment where refusing to provide FHIR API access is increasingly difficult to justify.

The practical implication for software teams: large health systems now have a regulatory obligation to expose FHIR APIs, and Epic and Cerner have both implemented FHIR R4 APIs across their customer base. Accessing data from a modern EHR is often cleaner through FHIR than through legacy HL7 v2 interfaces, and the regulatory trend continues to push in that direction.

When You Will Encounter Each Standard

HL7 v2 environments — Community hospitals and critical access hospitals running older EHR versions, radiology and laboratory information systems, older pharmacy systems, long-term care facilities, legacy data migration projects, and any integration with a hospital's existing interface engine. If the hospital is running any version of Epic before 2018, Cerner before approximately 2020, or MEDITECH for most use cases, expect HL7 v2 to be the primary interface mechanism.

FHIR environments — Epic MyChart APIs, Epic third-party developer program (App Orchard), Cerner HealtheIntent, payer data exchange (the Payer-to-Payer FHIR rule requires payers to support FHIR R4), government programs (CMS Blue Button 2.0 for Medicare data), patient-facing applications accessing data from modern EHR patient portals, and most new health tech integrations being designed after 2021.

Both simultaneously — Large health systems with a mix of modern and legacy infrastructure, organizations aggregating data from multiple facilities, and applications that need both real-time event processing (where HL7 v2 ADT feeds are common) and on-demand data access (where FHIR APIs are preferred).

Implementation Complexity

HL7 v2 Integration Complexity

Building an HL7 v2 integration without an integration engine is painful. The MLLP transport protocol (a TCP-based framing protocol) is not HTTP, which means your existing HTTP client libraries do not work out of the box. Message parsing requires either a specialized library or custom parsing logic.

Libraries worth evaluating:

• Java: HAPI HL7 (the de facto standard, actively maintained)
• Python: hl7apy, python-hl7
• Node.js: node-hl7-client
• .NET: NHapi

The more significant challenge is integration engine interoperability. Most hospitals route HL7 v2 messages through an integration engine (Mirth Connect is open source and common; Rhapsody and Infor Cloverleaf are common in large health systems). You will often need to work with the hospital's IT team or their integration engine vendor to establish the connection, configure message filtering, and handle acknowledgment patterns.

Factor in time for the hospital IT approval process. Even straightforward HL7 v2 integrations routinely take three to six months from initial conversation to live data flow, because health system IT approval processes are cautious by design.

FHIR Implementation Complexity

FHIR is technically more accessible than HL7 v2 — it is REST over HTTPS, using JSON, with a well-documented API. The technical implementation is straightforward compared to MLLP and HL7 v2 parsing.

The complexity in FHIR integrations comes from three places:

Profile compliance — FHIR resources have a base definition and then profiles (US Core, QI-Core, Da Vinci, etc.) that add constraints and required elements. A Patient resource from Epic may differ from a Patient resource from Cerner in which extensions are populated, which identifiers are present, and which search parameters are supported. The FHIR specification permits significant optional variation; actual interoperability requires working within the profiles that both systems support.

OAuth 2.0 and SMART flows — SMART on FHIR adds authorization complexity, particularly around the launch context flow (EHR-launched vs. standalone launch), scope management, and token refresh. For patient-facing applications, the authorization flow involves the patient authenticating with the health system's patient portal, which varies across EHRs.

Epic and Cerner API-specific behaviors — In practice, you are often integrating not with abstract FHIR but with Epic's FHIR API or Cerner's FHIR API. Each has quirks: rate limits, non-standard extensions, specific search parameter support, and their own developer registration and access approval processes. Epic's sandbox environment is accessible through their open.epic.com developer portal; Cerner's through the code.cerner.com portal.

Security Considerations for Both

HL7 v2 Security

HL7 v2 over MLLP has minimal native security. The historical assumption was that HL7 v2 traffic ran over private hospital networks, not the public internet. Modern deployments should use:

• MLLP over TLS (MLLP+) for encrypted transport when messages traverse any network segment you do not fully control
• VPN tunnels for connections between facilities or between a vendor system and a hospital's internal network
• IP allowlisting at the firewall level to restrict which systems can send and receive HL7 v2 messages

Even over private networks, HL7 v2 messages contain PHI in plaintext. Network access controls and encryption in transit are necessary even in internal environments.

FHIR Security

FHIR over HTTPS provides transport encryption. But several additional security considerations apply:

Token scope management — SMART on FHIR scopes define what the application can access. Request only the scopes you need. Broad scopes (patient/*.*) are appropriate in some development scenarios; they are not appropriate in production.

Token storage — Access tokens and refresh tokens must be stored securely. In a web application context, this means server-side storage or secure httpOnly cookies — not localStorage or sessionStorage, which are accessible to JavaScript and vulnerable to XSS.

Audit logging — Access to FHIR APIs that return PHI needs to be logged at the application level, not just at the transport level. Your application needs an audit trail of which patient data was accessed, by whom, and for what purpose — independent of what the EHR logs on its end.

PKCE — The SMART on FHIR 2.0 specification requires PKCE (Proof Key for Code Exchange) for public clients. If you are implementing SMART on FHIR authorization, use PKCE regardless of whether it is strictly required for your client type.

Practical Guidance: Which to Use When

Use HL7 v2 when:

• Your integration target is a community hospital or facility running a legacy EHR
• You need real-time ADT feed processing (admit/discharge/transfer events)
• The hospital IT team has an existing integration engine and prefers to route messages through it
• You are building a device integration (many medical devices and monitoring systems still output HL7 v2)
• The data you need is only available through the legacy interface

Use FHIR when:

• Your integration target is a modern EHR (Epic post-2018, Cerner, athenahealth, modern eClinicalWorks)
• You are building a patient-facing application that accesses data the patient has a right to access
• You need on-demand data access (query by patient, query by date range, search by condition code)
• You are building for payer data exchange under the CMS Interoperability Rule
• You are starting a new integration and have the option to choose

Use both when:

• You are aggregating data from a mixed environment (modern and legacy EHRs)
• You need real-time event notifications (HL7 v2 ADT) plus on-demand data access (FHIR queries)
• You are building a platform that needs to connect to any hospital, regardless of their technology generation

Frequently Asked Questions

Can we translate HL7 v2 messages into FHIR resources?

Yes, and there are published mappings for the most common conversions (ADT to FHIR Encounter/Patient, ORU to FHIR DiagnosticReport/Observation). The HL7 community maintains a ConceptMap and StructureMap library for common v2-to-FHIR translations. Integration engines like Mirth Connect have modules for FHIR transformation. The translations are not perfect — HL7 v2 and FHIR do not have 1:1 field correspondence for all data — but they are workable for most common use cases.

Is FHIR replacing HL7 v2?

Gradually, and not uniformly. FHIR is the direction the industry is moving, accelerated by regulatory mandates. But HL7 v2 will remain in production healthcare systems for many years because replacing integration infrastructure at hospitals is slow and expensive. Any team building healthcare integrations should be comfortable with both.

What is CDA and how does it relate to FHIR?

CDA (Clinical Document Architecture) is an HL7 standard for structured clinical documents — discharge summaries, referral letters, care plans. It uses XML and was the basis for Meaningful Use Stage 2 requirements (via C-CDA, Consolidated CDA). FHIR has largely superseded CDA for new implementations, but C-CDA documents are still widely used for transitions of care (hospital discharge to primary care, for example). Many FHIR integrations include the ability to generate or consume C-CDA documents for document-based workflows even when data APIs are FHIR-based.

If your team is building a healthcare integration and needs clarity on which approach fits your specific environment, or if you are designing a system that needs to handle both HL7 v2 and FHIR at scale, start with an architecture conversation. We work in this space regularly and can give you a direct answer based on your actual target environment.