HL7 v2 vs FHIR: Integration Comparison

HL7 v2 and FHIR are both healthcare interoperability standards maintained by Health Level Seven International. They solve the same fundamental problem — moving clinical and administrative data between systems — but they approach it in fundamentally different ways. HL7 v2 is a pipe-delimited messaging protocol designed in the late 1980s. FHIR is a RESTful API framework designed for the modern web. Both are actively used in production healthcare environments, and most organizations need to support both.

Choosing between them is not a matter of which is “better.” It depends on what systems you are connecting, what data you need to move, whether you are building something new or maintaining something existing, and what regulatory requirements apply. This guide provides a thorough comparison to help you make informed decisions for your healthcare integration projects.

HL7 v2: The Workhorse of Healthcare Integration

History and Adoption

HL7 version 2 was first published in 1987. It predates HTTP, JSON, XML, and most technologies that modern developers take for granted. Despite its age, HL7 v2 remains the single most widely deployed healthcare interoperability standard in the world. Virtually every hospital, laboratory, pharmacy system, EHR, radiology information system, and clinical device that supports electronic data exchange supports HL7 v2.

The standard has evolved through multiple sub-versions (2.1 through 2.9), each adding new message types and segments while maintaining backward compatibility. Version 2.3 and 2.5.1 are the most commonly encountered in production environments, though implementations vary widely. The HL7 v2 specification is deliberately loose, allowing significant optionality in how messages are constructed. This flexibility enabled widespread adoption but also means that no two HL7 v2 implementations are identical.

Message Structure

HL7 v2 messages use a pipe-delimited text format with a hierarchical structure of segments, fields, components, and sub-components. Here is a simplified ADT (Admit, Discharge, Transfer) message:

MSH|^~\&|EPIC|HOSPITAL|LAB_SYS|LAB|20260302120000||ADT^A01|MSG001|P|2.5.1
EVN|A01|20260302120000
PID|1||MRN123456^^^HOSP^MR||DOE^JOHN^A||19800115|M|||123 MAIN ST^^ANYTOWN^CA^90210
PV1|1|I|4NORTH^412^A|E|||1234^SMITH^JAMES^A^^^MD|5678^JONES^SARAH^B^^^MD
NK1|1|DOE^JANE|SPO|555-123-4567
IN1|1|BCBS123|BCBS|BLUE CROSS BLUE SHIELD|||||||||||DOE^JOHN^A|SELF

Each line is a segment identified by a three-character code. MSH is the message header (metadata about the message itself). PID is patient identification. PV1 is patient visit information. Fields within a segment are separated by pipes (|), components within a field by carets (^), and sub-components by ampersands (&).

The MSH segment’s ninth field (ADT^A01) identifies this as an ADT message with trigger event A01 (patient admission). There are over 300 defined message types and trigger events in HL7 v2, covering admissions, orders, results, scheduling, billing, master file updates, and more.

Transport Layer

HL7 v2 messages are traditionally sent over TCP connections using the Minimum Lower Layer Protocol (MLLP). MLLP wraps each message in a start block character (0x0B), end block character (0x1C), and carriage return (0x0D). The receiver parses the message and returns an acknowledgment (ACK or NAK) indicating whether the message was accepted.

This is a point-to-point, synchronous protocol. Each connection handles one message at a time. There is no built-in discovery, no API documentation, and no query capability. HL7 v2 is fundamentally a push-based messaging system. If System A needs to tell System B about a patient admission, System A sends an ADT^A01 message to System B’s MLLP listener.

Strengths

• Universal support: Every major healthcare IT system supports HL7 v2. If you need two systems to exchange data today, HL7 v2 is almost certainly supported by both.
• Proven reliability: Decades of production deployment have hardened implementations and established well-understood patterns.
• Event-driven: The trigger event model naturally supports real-time workflows. When a patient is admitted, an ADT message fires immediately.
• Lightweight: Messages are compact text. No XML overhead, no HTTP headers. A typical ADT message is a few kilobytes.

Weaknesses

• No standard query mechanism: You cannot ask an HL7 v2 system “give me all patients with diabetes.” You can only receive messages that the system pushes to you.
• Implementation variability: The specification allows so much optionality that every interface requires custom mapping. The same data element might be in different fields, use different code systems, or be omitted entirely depending on the vendor.
• No built-in security: MLLP has no encryption or authentication. Security is handled at the network layer (VPN, TLS wrappers) rather than the protocol layer.
• Difficult to extend for modern use cases: Mobile apps, web portals, and third-party integrations do not fit the point-to-point messaging model.

FHIR: The Modern API Approach

History and Adoption

FHIR (Fast Healthcare Interoperability Resources) was first drafted by Grahame Grieve in 2011 and published as a Draft Standard for Trial Use (DSTU) in 2014. FHIR R4, released in 2019, was the first version to include normative (stable, non-breaking) content. This was a watershed moment because it meant organizations could implement FHIR R4 with confidence that the core specification would not change out from under them.

FHIR was designed explicitly to address the shortcomings of HL7 v2 and v3. It borrows concepts from modern web development: REST APIs, JSON and XML data formats, OAuth 2.0 authentication, and a resource-based data model. The goal was to make healthcare interoperability accessible to any developer who can build a web application, not just specialists with decades of healthcare IT experience.

Adoption has been accelerated by regulatory mandates. The ONC Cures Act Final Rule and CMS Interoperability and Patient Access Rule require certified EHR systems to offer FHIR-based patient access APIs. Epic, Cerner (Oracle Health), and athenahealth all expose FHIR R4 APIs. The TEFCA (Trusted Exchange Framework and Common Agreement) framework relies on FHIR for nationwide health information exchange.

Resource Model

FHIR organizes healthcare data into resources. Each resource represents a discrete clinical or administrative concept: Patient, Observation, Condition, MedicationRequest, Encounter, Procedure, and so on. There are approximately 150 defined resource types in FHIR R4.

Here is a Patient resource in JSON:

{
  "resourceType": "Patient",
  "id": "example-patient",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2026-03-02T12:00:00Z"
  },
  "identifier": [
    {
      "system": "http://hospital.example.org/mrn",
      "value": "MRN123456"
    }
  ],
  "name": [
    {
      "family": "Doe",
      "given": ["John", "A"]
    }
  ],
  "gender": "male",
  "birthDate": "1980-01-15",
  "address": [
    {
      "line": ["123 Main St"],
      "city": "Anytown",
      "state": "CA",
      "postalCode": "90210"
    }
  ]
}

Compare this to the PID segment in the HL7 v2 example above. The same data is represented, but the FHIR version is self-describing. You do not need a specification document to understand what birthDate means. The JSON structure is hierarchical, supports arrays natively, and can be validated against a schema.

RESTful API

FHIR defines standard REST operations on resources:

GET    /Patient/example-patient          # Read a specific patient
GET    /Patient?name=Doe&birthdate=1980  # Search for patients
POST   /Patient                          # Create a new patient
PUT    /Patient/example-patient          # Update a patient
DELETE /Patient/example-patient          # Delete a patient

This is standard HTTP. Any programming language with an HTTP client can interact with a FHIR server. The search API supports dozens of standard parameters per resource type, including chained searches across resource references (e.g., find all Observations for patients in a specific organization).

Authentication and Authorization

FHIR uses SMART on FHIR, an OAuth 2.0-based framework specifically designed for healthcare. SMART provides:

• EHR Launch: Applications launch from within the EHR and receive patient/encounter context automatically.
• Standalone Launch: Applications launch independently and use a patient picker to select context.
• Granular scopes: Access is controlled at the resource type and operation level (e.g., patient/Observation.read grants read-only access to Observations for the current patient).
• Backend services: Service-to-service authentication using client credentials with signed JWTs.

Strengths

• Query capability: FHIR’s RESTful search API lets you find data, not just receive it.
• Developer-friendly: JSON, REST, OAuth — technologies that web and mobile developers already know.
• Self-documenting: Resource structures are human-readable. CapabilityStatement resources describe what a server supports.
• Ecosystem: Open-source libraries exist for every major language. HAPI FHIR (Java), Firely SDK (.NET), fhir.js (JavaScript), and many others.
• Regulatory backing: US federal mandates require FHIR support from certified health IT systems.

Weaknesses

• Not universally deployed: While growing rapidly, FHIR is not yet available on every system. Legacy lab instruments, pharmacy systems, and ancillary department systems often only support HL7 v2.
• Complexity of implementation guides: Base FHIR is flexible, but real-world implementations require conformance to profiles (US Core, Da Vinci, CARIN). Navigating the IG ecosystem is a skill in itself.
• Performance overhead: HTTP + JSON is heavier than MLLP + pipe-delimited text. For high-volume real-time interfaces, the overhead is measurable.
• Versioning complexity: With R4, R5, and R6 coexisting, organizations need to manage multi-version support.

Architecture Comparison

The following table summarizes the key architectural differences.

When HL7 v2 Is the Right Choice

HL7 v2 remains the pragmatic choice in several common scenarios.

ADT feeds between hospital systems. If your hospital information system sends admit, discharge, and transfer notifications to downstream systems (labs, pharmacy, billing), HL7 v2 ADT messages are the standard mechanism. Every system in the hospital expects them. Replacing ADT with FHIR Encounters would require every downstream system to support FHIR — which most do not.

Lab result reporting (ORU messages). Laboratory information systems (LIS) produce HL7 v2 ORU messages containing test results. These flow to EHRs, reference labs, and public health agencies. The ORU message format is deeply embedded in lab workflows, and the receiving systems expect v2.

Order management (ORM/OML messages). Clinical order entry systems send orders to labs, radiology, and pharmacy using HL7 v2 order messages. The request-response workflow (order sent, result returned) maps cleanly to the v2 trigger event model.

Device integration. Bedside monitors, infusion pumps, ventilators, and other medical devices often communicate using HL7 v2 or proprietary protocols that are translated to HL7 v2 by middleware. FHIR support in medical devices is still emerging.

Connecting two systems that both speak v2. If both the source and destination systems support HL7 v2 and the interface requirements are straightforward (point-to-point, predefined message types), there is no benefit to introducing FHIR as an intermediary.

When FHIR Is the Right Choice

FHIR is the preferred standard when the use case calls for modern API patterns or regulatory compliance.

Patient-facing applications. If you are building a patient portal, mobile health app, or any application that patients interact with directly, FHIR is the only practical choice. The SMART on FHIR framework provides standardized authentication, and EHR vendors expose patient data through FHIR APIs. The 21st Century Cures Act’s information blocking provisions ensure that patient-facing apps can access data through FHIR.

API-first architectures. If you are designing a system where multiple applications need to query clinical data on demand (not just receive pushed messages), FHIR’s REST API model is far superior to HL7 v2’s push-only model.

Regulatory compliance. CMS requires Medicare Advantage plans, Medicaid managed care plans, and QHP issuers to make patient data available through FHIR APIs (Patient Access API). ONC’s Cures Act Final Rule requires certified health IT to support FHIR-based APIs. If your project has a regulatory driver, FHIR is usually required, not optional.

Population health and analytics. FHIR’s Bulk Data Access specification ($export) enables extraction of population-level data for research, quality reporting, and public health surveillance. This is far more efficient than accumulating individual HL7 v2 messages over time.

New development projects. For greenfield projects with no legacy constraints, FHIR provides a more developer-friendly experience, better tooling, and a clearer path forward as the healthcare industry continues to shift toward API-based interoperability.

Third-party application ecosystems. If you want to enable third-party developers to build applications on top of your platform (similar to how Epic’s App Orchard or Oracle Health’s app marketplace works), FHIR provides the standardized API surface for this.

Coexistence: HL7 v2 and FHIR Together

In practice, most healthcare organizations need both standards simultaneously. The installed base of HL7 v2 interfaces is enormous, and replacing them all with FHIR is neither practical nor necessary. The key is to design an integration architecture that bridges both worlds.

Translation in the Integration Engine

Interface engines like Mirth Connect (NextGen Connect) are designed to translate between formats. A common pattern is to receive HL7 v2 messages from legacy systems, transform them to FHIR resources, and POST them to a FHIR server. The reverse is also common: query a FHIR API, transform the results to HL7 v2, and send them to a downstream system that only speaks v2.

Here is a simplified example of a Mirth Connect channel that transforms an ADT^A01 message into a FHIR Patient resource:

// Source: HL7 v2 ADT^A01 message
// Destination: FHIR R4 server

var patient = {
  resourceType: "Patient",
  identifier: [{
    system: "http://hospital.example.org/mrn",
    value: msg['PID']['PID.3']['PID.3.1'].toString()
  }],
  name: [{
    family: msg['PID']['PID.5']['PID.5.1'].toString(),
    given: [msg['PID']['PID.5']['PID.5.2'].toString()]
  }],
  gender: mapGender(msg['PID']['PID.8'].toString()),
  birthDate: formatDate(msg['PID']['PID.7'].toString())
};

// POST to FHIR server
var response = destinationConnector.send(
  "POST",
  "/Patient",
  JSON.stringify(patient),
  {"Content-Type": "application/fhir+json"}
);

FHIR Facade Pattern

A FHIR facade exposes a FHIR-compliant API in front of legacy systems that store data in HL7 v2 format or proprietary databases. When a client sends a FHIR request, the facade translates it into the appropriate query against the legacy system, transforms the results to FHIR resources, and returns them. The client sees a standard FHIR API; the legacy system continues operating as it always has.

This pattern is useful when you need to support SMART on FHIR apps or regulatory FHIR APIs but cannot replace the underlying data store.

Event-Driven Bridges

For real-time workflows, you can combine HL7 v2 trigger events with FHIR Subscriptions. When an HL7 v2 ADT message arrives at your integration engine, it can create or update a FHIR Encounter resource on a FHIR server. FHIR Subscriptions or event handlers on that server then notify downstream FHIR-native applications. This gives you the real-time event characteristics of HL7 v2 with the query and API capabilities of FHIR.

Migration Strategies: v2 to FHIR

For organizations planning to gradually transition from HL7 v2 to FHIR, a phased approach is recommended.

Phase 1: Establish FHIR as the Read Layer

Deploy a FHIR server and populate it from HL7 v2 feeds. Continue using v2 for all write operations and real-time messaging. New applications and analytics workloads read from the FHIR server. This adds FHIR capability without disrupting existing v2 interfaces.

Phase 2: New Interfaces Default to FHIR

When building new integrations, use FHIR if the connecting system supports it. Only fall back to HL7 v2 when the other system does not offer a FHIR API. Over time, the proportion of FHIR interfaces grows.

Phase 3: Replace High-Value v2 Interfaces

Identify the HL7 v2 interfaces that are most expensive to maintain (complex mappings, frequent break/fix, high volume) and replace them with FHIR-based equivalents. ADT interfaces connected to modern EHRs are often good candidates because Epic and Oracle Health both support FHIR-based notifications.

Phase 4: Maintain v2 for Legacy Systems Only

Eventually, HL7 v2 interfaces remain only for systems that genuinely cannot support FHIR — older lab instruments, legacy pharmacy dispensing systems, and similar. These interfaces are maintained but not expanded.

The Future of Healthcare Interoperability

FHIR adoption is accelerating. FHIR R5 was published in 2023, and R6 is currently in ballot with expected publication in late 2026. Each version adds capabilities that reduce the need for HL7 v2. R5’s improved Subscriptions framework, for example, provides a standardized real-time notification mechanism that competes directly with HL7 v2’s trigger event model.

TEFCA (Trusted Exchange Framework and Common Agreement) is building a nationwide health information exchange network based on FHIR. As TEFCA reaches production scale, organizations that support FHIR will be able to exchange data with any other TEFCA participant without bilateral interface agreements.

CMS continues to expand FHIR mandates. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires payers to implement additional FHIR APIs for prior authorization, provider directory, and payer-to-payer data exchange.

However, HL7 v2 will not disappear. The installed base is too large, and many systems that rely on v2 will operate for decades. The realistic trajectory is that FHIR becomes the default for new projects and external APIs while HL7 v2 continues operating for internal, legacy, and device-level integrations. Organizations need competency in both.

Choosing the Right Standard for Your Project

If you are starting a new integration project, ask these questions:

1. Do both systems support FHIR? If yes, use FHIR. It is simpler to implement, easier to maintain, and future-proof.
2. Is there a regulatory requirement? If the project involves patient access APIs, payer interoperability, or TEFCA participation, FHIR is likely required.
3. Do you need query capability? If the consuming system needs to search for and retrieve specific data on demand, FHIR’s REST API is the answer. HL7 v2 cannot do this.
4. Are both systems legacy? If both the source and destination only support HL7 v2, use v2. Introducing FHIR as an intermediary adds complexity without benefit.
5. Is real-time event notification the primary need? Both standards support this. HL7 v2 has a simpler model for basic event notification. FHIR Subscriptions are more powerful but more complex to implement.

For most organizations, the answer is not “HL7 v2 or FHIR” but “HL7 v2 and FHIR.” The integration engine is the bridge between these worlds, and a well-designed integration architecture supports both standards simultaneously.

Next Steps

Whether you are maintaining existing HL7 v2 interfaces, building new FHIR integrations, or designing a migration strategy from v2 to FHIR, having the right expertise matters. Healthcare interoperability is a specialized field where protocol knowledge, clinical domain understanding, and integration engineering skills all intersect.

• HL7 Integration Services — We build, maintain, and optimize HL7 v2 interfaces for hospitals, labs, imaging centers, and health IT vendors.
• FHIR API Integration — From SMART on FHIR app development to bulk data pipelines, our team delivers production FHIR implementations.
• Healthcare Interoperability Consulting — Need a strategy for coexistence and migration? We help organizations design integration architectures that bridge HL7 v2 and FHIR.
• HL7 Workbench — Our online HL7 parser and message analysis tool for development and testing.
• FHIR R4 vs R5 vs R6 — If you are choosing FHIR, understand which version to target.
• HL7 Message Types Explained — A deeper dive into HL7 v2 message types for integration developers.