HL7 v2 vs FHIR: Which Standard is Right for Your Integration Project?

What is HL7 v2?

HL7 version 2 (HL7 v2.x) is a messaging standard developed by Health Level Seven International and first published in 1987. It defines a pipe-delimited, text-based message format for exchanging clinical and administrative data between healthcare applications. Versions 2.1 through 2.9 have been released over the decades, with v2.3.1 and v2.5.1 remaining the most widely deployed today.

An HL7 v2 message consists of a series of segments (lines of text separated by carriage returns), each beginning with a three-character identifier like MSH (message header), PID (patient identification), or OBX (observation/result). Within each segment, fields are separated by pipe characters (|), components by carets (^), and sub-components by ampersands (&).

A typical HL7 v2 ADT A01 (patient admission) message looks like this:

MSH|^~\&|EPIC|HOSPITAL|LAB|LIS|20260225093000||ADT^A01|MSG00001|P|2.5.1
EVN|A01|20260225093000
PID|1||MRN123456^^^HOSPITAL^MR||Smith^John^A||19800315|M
PV1|1|I|4N^401^A^HOSPITAL|||ATT123^Jones^Sarah|||MED

HL7 v2 is transmitted over MLLP (Minimal Lower Layer Protocol) — a lightweight TCP/IP wrapper — which provides a reliable, connection-oriented transport for time-sensitive clinical messages. Senders expect synchronous ACK (acknowledgment) messages confirming receipt.

Despite its age, HL7 v2 is not going away. The standard is deeply embedded in healthcare infrastructure: virtually every EHR, laboratory information system (LIS), radiology information system (RIS), pharmacy system, and ADT feed relies on HL7 v2 for real-time clinical messaging.

What is FHIR?

HL7 FHIR (Fast Healthcare Interoperability Resources) is a next-generation interoperability standard published by HL7 International, with FHIR R4 (Release 4) becoming the normative standard in 2019. Unlike HL7 v2, FHIR is built on modern web technologies: RESTful APIs, JSON/XML/RDF data formats, and standard HTTPS transport.

FHIR models healthcare data as resources — discrete, typed objects like Patient, Observation, Medication, Encounter, Practitioner, and DiagnosticReport. Each resource has a defined structure (profile), a set of must-support elements, a unique URL, and can be accessed via standard HTTP verbs (GET, POST, PUT, DELETE).

A FHIR Patient resource in JSON looks like this:

{
  "resourceType": "Patient",
  "id": "patient-123",
  "identifier": [{"system": "urn:hospital:mrn", "value": "MRN123456"}],
  "name": [{"family": "Smith", "given": ["John", "A"]}],
  "birthDate": "1980-03-15",
  "gender": "male"
}

FHIR's modern architecture makes it the foundation of the ONC 21st Century Cures Act Final Rule and the CMS Interoperability and Patient Access Rule, both of which require certified EHR vendors and payers to expose patient data through FHIR R4 APIs. SMART on FHIR extends the standard with OAuth 2.0-based authorization, enabling third-party apps to securely access patient data with patient and clinician consent.

Key Differences: HL7 v2 vs FHIR

Understanding the architectural differences between HL7 v2 and FHIR is essential before choosing a standard or planning a migration.

• Data Format: HL7 v2 uses a custom pipe-delimited text format requiring specialized parsers. FHIR uses JSON or XML — formats natively supported by every modern programming language and framework.
• Transport Protocol: HL7 v2 uses MLLP over TCP/IP, requiring point-to-point socket connections and a persistent integration engine. FHIR uses HTTPS REST APIs, compatible with any HTTP client and web framework.
• Data Model: HL7 v2 is message-centric — data exists only within a message and has no independent identity. FHIR is resource-centric — each resource has a persistent URL and can be retrieved, updated, or referenced independently.
• Standardization: HL7 v2 implementations vary dramatically between vendors — the same message type may look completely different from Epic vs. Cerner vs. Meditech. FHIR, especially with US Core profiles, enforces much tighter conformance.
• Querying: HL7 v2 is push-based — systems send messages when events occur. FHIR supports both push (subscriptions) and pull (queries), enabling richer data access patterns.
• Ecosystem Maturity: HL7 v2 has 35+ years of production deployment. FHIR R4 is production-ready but tooling and expertise are still maturing compared to v2.

When to Use HL7 v2

Despite FHIR's momentum, there are strong reasons to continue using HL7 v2 for many integration scenarios:

• Real-time clinical messaging: ADT, ORM, ORU, and SIU messages between hospital systems are overwhelmingly HL7 v2-based. Changing this infrastructure is expensive and high-risk.
• Legacy system connectivity: Many LIS, RIS, pharmacy, and ancillary systems only support HL7 v2. If your EHR or ancillary system does not offer a FHIR interface, HL7 v2 is your only option.
• High-volume, low-latency messaging: MLLP connections have lower overhead than HTTPS for high-frequency message streams. Large hospitals processing millions of ADT events per month often prefer HL7 v2 for performance reasons.
• Existing integration engine investments: If your organization has already built and validated HL7 v2 interfaces in Mirth Connect, Rhapsody, or another engine, maintaining those interfaces is often more cost-effective than re-building in FHIR.

For more on building and maintaining HL7 v2 integrations, see our complete HL7 integration guide and our HL7 integration overview.

When to Use FHIR

FHIR is the right choice — and often the required choice — for a growing set of integration scenarios:

• Patient access and portal applications: The ONC Final Rule requires EHRs to expose patient data via FHIR R4 APIs. Patient-facing mobile apps and portals must use FHIR.
• Payer-provider data exchange: CMS rules require payers to expose member data via FHIR APIs. Provider directories, formularies, and prior authorization workflows are moving to FHIR.
• Third-party application integration:Epic's App Orchard, Cerner's Code Program, and other vendor marketplaces require FHIR-based integrations. SMART on FHIR enables secure, consent-based app access.
• New greenfield applications: If you are building a new clinical application, analytics platform, or care coordination tool, building on FHIR from day one avoids legacy technical debt.
• Cloud-native and microservices architectures:FHIR's REST API model integrates naturally with cloud platforms (Azure Health Data Services, AWS HealthLake, Google Cloud Healthcare API) and microservices-based architectures.
• Regulatory compliance: ONC certification, CMS reporting, and many state HIE requirements now mandate FHIR R4. Non-compliance risks program exclusion and significant fines.

Learn how to build FHIR APIs from scratch in our FHIR API Development Guide.

Migration Strategy: Moving from HL7 v2 to FHIR

Most healthcare organizations will not replace HL7 v2 wholesale — instead, they will run both standards in parallel and progressively migrate use cases to FHIR as systems and business needs evolve. Here is a practical migration framework:

1. Inventory your current integrations: Document every HL7 v2 interface — the message type, sending system, receiving system, transformation logic, and volume. This becomes your migration backlog.
2. Identify FHIR-first candidates: Patient access, third-party app integrations, new system onboarding, and regulatory reporting are natural FHIR candidates. High-volume internal ADT feeds are not.
3. Deploy a FHIR server: Stand up a FHIR R4 server (HAPI FHIR, Azure Health Data Services, or AWS HealthLake) to serve as the central FHIR repository for your organization.
4. Bridge HL7 v2 to FHIR: Use your integration engine (Mirth Connect, Azure API for FHIR, or a custom pipeline) to translate inbound HL7 v2 messages into FHIR resources stored in your FHIR server. This gives you FHIR access to v2 data without re-implementing source systems.
5. Validate FHIR resources against US Core profiles: Ensure transformed resources conform to US Core 4.0 or 6.1 profiles using a validator like the HL7 FHIR Validator or Touchstone.
6. Migrate new integrations to FHIR-native: As source systems gain FHIR support, retire the HL7 v2 bridge interface and connect directly via FHIR APIs.

A hybrid HL7 v2 / FHIR architecture is the reality for most health systems for the foreseeable future. See our healthcare software development services for expert migration support.

Which Standard Should You Choose?

Here is our practical recommendation based on hundreds of healthcare integration engagements:

• Maintaining existing hospital infrastructure? Keep HL7 v2. It works, it is tested, and the cost of migration outweighs the benefit for core clinical messaging.
• Building patient-facing applications or meeting ONC/CMS requirements? Use FHIR R4. It is mandated and the ecosystem is ready.
• Integrating with Epic, Cerner, or other major EHRs for third-party app access? Use FHIR with SMART on FHIR authorization.
• Building a new internal system that will need to communicate with your EHR? Check whether your EHR vendor supports FHIR-based subscriptions or write-back APIs — if so, build FHIR-native. If not, HL7 v2 may still be required.
• Working with payers, HIEs, or government programs? FHIR is increasingly required. Confirm specific requirements before choosing.

The best integration strategy is almost always a pragmatic hybrid: preserve working HL7 v2 infrastructure, adopt FHIR for new integrations and compliance requirements, and build a FHIR-based data layer that makes v2 data accessible through modern APIs.

Ready to plan your HL7/FHIR strategy? Contact our team for a free technical consultation. Our engineers have deep expertise in both standards and can help you design the right architecture for your organization.