Fhir vs. Hl7: A Healthtech Engineering Comparison

HL7 International maintains all three standards—FHIR, HL7 Version 2, and Clinical Document Architecture—so framing it as FHIR vs. HL7 really means comparing siblings within the same family, not rival organizations. Most health tech products end up relying on both: HL7 v2 to handle hospital event streams and FHIR to power modern API-driven workflows.

Correcting the Premise of FHIR vs. HL7

The choice between these standards comes down to what you're actually trying to accomplish. HL7 itself describes Version 2 as the most widely implemented interoperability standard in healthcare, while FHIR brings a resource-based data model and web API patterns that fit newer application architectures (HL7 Version 2 product suite, FHIR specification directory).

Here's how the three standards stack up side by side:

Standard	Primary use	Data unit	Typical transport
HL7 v2	Real-time clinical and administrative messaging	Delimited message segments	MLLP, typically via an interface engine
CDA	Exchange of persistent clinical documents	XML clinical document	Document sharing, often over HTTPS or messaging
FHIR	On-demand application and system interoperability	Resources such as Patient and Observation	RESTful HTTP APIs using JSON or XML

HL7 v2.9 landed in 2019, though many US implementation guides still build on the older HL7 v2.5.1. FHIR locked down normative content in Release 4, also in 2019, and that R4 specification now anchors a broad ecosystem of deployed implementation guides (FHIR R4, v2.9 product brief).

FHIR expands the API surface; HL7 v2 continues to carry hospital event traffic.

What follows is a closer look at how each standard works, where it fits naturally, and how to wire both into a single integration architecture. You'll also find decision criteria tailored to different contexts—apps, analytics, labs, payers, and documents—along with the regulatory pressures driving adoption.

In the US, ONC's certified health IT criterion 170.315(g)(10) establishes a standardized API requirement for patient and population services (ONC criterion). CMS's CMS-0057-F rule goes further, mandating that impacted payers stand up FHIR APIs, with most deadlines hitting January 1, 2027 (CMS Interoperability and Prior Authorization Final Rule). Neither regulation phases HL7 v2 out of hospital operations.

HL7 International's Version 2 product suite defines messages for exchanging clinical and administrative events. The current v2.9 product brief dates to 2019, while many US implementation guides still target v2.5.1. That gap matters. Version selection is an engineering decision, not a minor configuration detail.

An HL7 v2 message is a sequence of segments separated by carriage returns. Fields use pipes, components use carets, repetitions use tildes, and escape characters are declared in MSH-2.

MSH|^~&|LAB|HOSPITAL|EHR|HOSPITAL|202610121030||ORU^R01|12345|P|2.5.1
PID|||123456||DOE^JANE||19800101|F
OBR|1||LAB789|2345-7^Glucose^LN
OBX|1|NM|2345-7^Glucose^LN||105|mg/dL|70-99|H|||F

MSH identifies the message and its sender. PID carries patient identity, OBR identifies the order or observation request, and OBX carries a result. The event code in MSH-9 determines the message's meaning:

• ADT^A01 signals an admission.
• ORU^R01 carries observation results.
• SIU^S12 communicates a scheduled appointment.

Hospitals commonly send these messages through an interface engine using Minimal Lower Layer Protocol, or MLLP. The sending system opens a connection, transmits a framed message, and receives an acknowledgement. A generic ACK confirms technical receipt; an application acknowledgement can indicate whether the receiving system accepted or rejected the content.

Why Every v2 Interface Differs

HL7 v2 provides a shared grammar, but implementation guides decide which fields are required, permitted, or ignored. Optional fields, local code systems, site-specific interpretations, and custom Z segments create meaningful variation between hospitals.

A guide based on v2.5.1 can reduce uncertainty without eliminating it. One laboratory may place a reference range in the expected OBX fields, while another may use a local field or send additional observations. Patient identifiers, facility codes, timestamps, and result status values also require explicit mapping.

HL7 v2 standardizes message structure more reliably than it standardizes local meaning.

This is why production integrations need parsing, validation, routing, acknowledgement handling, replay controls, monitoring, and partner-specific configuration. The v2.9 product brief shows the continuing evolution of the standard, but installed systems rarely move in lockstep.

For engineering teams, v2 remains effective for high-volume, real-time event traffic. It requires a translation layer before those events can serve modern applications, which commonly expose the resulting data through FHIR resources or an internal API.

FHIR organizes clinical data into discrete resources — Patient, Encounter, Observation, DiagnosticReport, and dozens more. Each resource carries a defined structure and a stable identity, which makes it easier for applications to consume exactly what they need without parsing a monolithic message.

The FHIR specification directory tracks published releases and implementation guidance, and most current production systems run on FHIR R4, whose normative content became the baseline for a large wave of interoperability work.

This infographic contrasts how HL7 v2 delivers messages with how FHIR exposes resources through APIs. You'll see differences in data units, transport patterns, and the roles each protocol plays across a health system.

The architectural difference matters most. v2 typically pushes hospital events through interface engines — an ADT admission here, a lab result there. FHIR, on the other hand, lets applications request specific resources over HTTP, pulling data only when they need it.

Resources and Representations

FHIR resources can be exchanged in JSON or XML, and a straightforward lab result might live in a single Observation resource with a patient reference, coded test name, numeric value, unit, status, and effective time.

The RESTful API supports read, search, create, and update operations. This pull-based model suits applications that want selected data on demand rather than a firehose of continuously delivered messages.

Generic resources cover a lot of ground, but profiles are where real-world interoperability takes shape. A profile can lock down required elements, set cardinality rules, constrain value sets, and bind terminology for a specific jurisdiction or workflow. The US Core Implementation Guide is the dominant US example and gives implementers testable expectations for common resources.

FHIR interoperability depends on agreed profiles and terminology, not on resource names alone.

Access and Events

Beyond the core REST API, FHIR supports several distinct integration patterns worth knowing about.

SMART on FHIR handles authorization for applications launched from an EHR or connected to one. Bulk Data handles population-level exports. Subscriptions delivers notifications when specific resources or events change.

Each serves a different workload:

• SMART on FHIR works best for patient-facing and clinician-facing applications that need contextual launch.
• Bulk Data fits analytics, reporting, and population processing.
• Subscriptions fits event-aware applications that need FHIR-based change notifications.

The US certified API criterion ONC 170.315(g)(10) codifies FHIR-based standardized API requirements for patient and population services. R4 and applicable implementation guides shape conformance expectations under this rule (ONC standardized API criterion). Profiles matter here because they make validation and testing far more precise than a bare resource definition ever could.

For product teams, FHIR fits on-demand, app-driven, API-first access. It still demands careful work around identity, terminology, authorization, and version management, but its resource model maps naturally to modern application boundaries.

You can see one practical example of this approach in action with AI-assisted clinical software built around healthcare workflows.

Side-by-side comparison of hl7 v2 and fhir

The table below lays out the most important structural and operational differences between the two standards. It's not meant to declare a winner — each still has strong ground to cover.

Criterion	HL7 v2	FHIR
Data model	Segmented, pipe-delimited messages (e.g., ADT, ORM, ORU)	Discrete JSON or XML resources with defined identities
Transport	Typically TCP/MLLP through interface engines	HTTP/HTTPS, often with RESTful patterns
Format	Text-based, delimiter-separated	JSON or XML, with strong schema support
Interaction pattern	Push-based event streaming	Pull-based API requests, plus subscriptions for events
Security model	Varies by transport layer; often network-level	OAuth 2.0 via SMART on FHIR, with granular scopes
Extensibility	Z-segments and local definitions, which vary widely	Extensions with formal definitions, plus profiles
Developer experience	Parsing-heavy, interface-engine-centric	Modern tooling, test servers, and publicly available specs
Typical use cases	Admission/transfer/discharge, lab orders, results, scheduling	App-driven data access, patient portals, analytics, mobile
Maturity	Deeply embedded since the 1980s; enormous installed base	Rapidly maturing; regulatory tailwinds accelerating adoption
Regulatory drivers	Long-standing billing and operational requirements	ONC API rules, CMS interoperability mandates, international frameworks

In short: v2 remains the backbone of hospital operations messaging, while FHIR is becoming the standard for application-level data access and modern interoperability. Most organizations end up running both for a long time.

Learn how this architecture shapes clinical AI product decisions — see the Clinic AI Assistant.

The practical choice between FHIR and HL7 comes down to the specific workflow, not some universal ranking. HL7 v2 still handles hospital event feeds reliably, while FHIR makes more sense for application access, patient-facing services, and payer APIs.

The underlying technology used in healthcare insights shapes how these standards get implemented and adopted. But the integration decision itself starts with the data flow and the system that owns it.

Decision Table by Integration Use Case

The table below maps common healthtech integration scenarios to the recommended standard, with plain-language reasoning for each.

Use case	Recommended standard	Why
Real-time ADT events	HL7 v2	Hospitals commonly push ADT^A01, discharge, and transfer events through interface engines over MLLP.
Lab results inbound	HL7 v2, then FHIR internally	ORU^R01 feeds remain common; map results into Observation and DiagnosticReport for application use.
Patient-facing apps	FHIR with SMART on FHIR	Apps can request authorized patient resources through web APIs.
Clinician-facing apps inside the EHR	FHIR with SMART on FHIR	EHR launch context and resource access match embedded clinical workflows.
Population analytics	FHIR Bulk Data	Population exports are better suited to asynchronous processing than individual v2 messages.
Payer data exchange	FHIR	CMS interoperability rules make FHIR APIs the relevant US regulatory direction.
Document exchange	CDA or FHIR documents	CDA supports persistent clinical documents; FHIR supports document-oriented resources and bundles.

The right standard depends on who is sending, who is receiving, and what the data needs to do once it arrives. A single product may use multiple standards at different boundaries.

Why the answer can change within one product

A lab feed illustrates this well. An inbound ORU^R001 might be the only interface a hospital offers, so accepting v2 becomes a practical necessity. The product can then transform that result into a FHIR Observation, preserve the source message for audit purposes, and expose a stable internal representation to downstream services.

Choose the protocol at each boundary, then keep the meaning consistent inside the product.

Hypothetical remote monitoring example

Consider a remote patient monitoring company integrating with several hospitals. Its first requirement is admission and discharge notification, so each hospital sends ADT messages through its interface engine. The company receives those messages over the agreed transport, validates acknowledgements, matches the patient, and records admission status.

Its second requirement is a clinician-facing view inside the EHR. That workflow uses a SMART on FHIR app, launched in context and reading resources like Patient, Encounter, and Observation from the EHR's FHIR API. The app never needs to parse the hospital's v2 feed directly.

Both pipelines should feed into one internal data model:

1. The v2 adapter converts admission and discharge events into normalized encounter state.
2. The FHIR adapter converts API responses into the same patient, encounter, and observation entities.
3. Identity and terminology services reconcile identifiers and codes across both sources.
4. Product services consume the canonical model rather than protocol-specific payloads.

This approach preserves the hospital's operational interface while giving the product an API-oriented clinical surface. It also prevents separate business logic from creeping in around each standard. Detailed API behavior belongs in a dedicated EHR integration API reference, while the standard choice stays tied to the actual use case at each integration point.

Nearly every production healthtech environment ends up running HL7 v2 and FHIR side by side. HL7 v2 messages typically land at an interface engine where adapters handle validation, routing, acknowledgements, and transformations on hospital traffic. FHIR steps in downstream to serve resources and APIs to applications, partners, analytics, and clinician workflows.

The real design principle is straightforward: keep protocol-specific logic at the boundary. Both the v2 and FHIR pipelines should feed one canonical internal model covering patients, encounters, observations, orders, and documents.

Map Messages Into Canonical Data

A v2 adapter parses segments like PID, PV1, OBR, and OBX, along with trigger events such as ADT^A01 and ORU^R01. The output should map to FHIR resources where it makes sense, but downstream services should consume normalized entities rather than depend on either wire format directly.

Terminology mapping lives at that same boundary. A lab code might arrive as a local identifier that needs to resolve to LOINC. Clinical concepts often map to SNOMED CT, while medications route through RxNorm. Skip controlled terminology and two feeds describing the same result end up speaking different languages.

Identity matching demands the same rigor. Medical record numbers, assigning authorities, facility identifiers, and FHIR references all need to resolve against a single patient identity. And provenance has to stick around for audits and corrections.

Translate syntax at the edge, preserve meaning in the core, and keep source provenance available.

A practical architecture splits these responsibilities cleanly:

• Interface engine: Receives MLLP traffic, handles routing and acknowledgements, and applies partner-specific rules.
• Transformation services: Convert v2 messages into canonical entities or FHIR resources.
• Terminology service: Maps local codes to agreed-upon systems and tracks mapping status.
• Identity service: Links identifiers while flagging uncertain matches for manual review.
• Internal data model: Supplies consistent data to product, analytics, and workflow services.

Teams building an API layer need to nail down resource behavior, authentication, and data ownership early. For more implementation context, see Ekipa's EHR integration API reference, its EHR software development guide, and its healthcare software modernization guidance.

A Remote Monitoring Scenario

Imagine a remote monitoring company receiving HL7 v2 ADT messages for hospital admissions and discharges. Each hospital's interface engine pushes the feed, and the company validates and acknowledges before mapping encounter status into its internal model.

The clinician-facing view runs as a SMART on FHIR application embedded in the EHR. It pulls Patient, Encounter, and Observation resources through the EHR's FHIR API while both data sources feed the same patient and encounter records.

For teams tackling older integrations, Vision on modernizing legacy tools covers useful ground. And for hands-on support, Ekipa's implementation support team can help with the practical details.

The engineering takeaway? The integration layer is part of the product, not a side project.

HL7 International publishes HL7 Version 2, CDA, and FHIR, so the real decision in the FHIR vs. HL7 conversation is which standard a given integration actually requires. ONC criterion 170.315(g)(10) mandates that certified health IT expose standardized APIs for patient and population services, while CMS-0057-F compels impacted payers to implement FHIR APIs—with most deadlines landing by January 1, 2027 (ONC, CMS).

That regulatory pressure reshapes the API surface; it doesn't rip out the hospital's operational plumbing. HL7 v2 still hauls ADT, orders, results, and scheduling traffic through interface engines every minute of every day. In practice, most health-tech products end up supporting both standards rather than choosing one.

The Regulatory Direction

ONC's criterion centers on standardized API access to patient and population data via certified health IT. FHIR R4 and its implementation guides form the technical backbone for much of this ecosystem—covering everything from third-party app integrations to population-health workflows (FHIR R4).

CMS-0057-F targets specific payer categories and sets interoperability and prior-authorization requirements built on FHIR APIs. The rule's major payer deadlines stretch through January 1, 2027, though the exact date depends on the provision and the organization in question.

FHIR expands regulated access to health data; it does not replace the interfaces that keep hospitals running.

Why HL7 v2 Stays

Hospitals still rely on v2 messages for real-time operational events. When a patient is admitted, a lab result comes back, or an order fires, that message typically flows from an EHR or registration system through an interface engine over MLLP. These aren't legacy artifacts—they're load-bearing infrastructure.

Neither ONC's certified API criterion nor CMS-0057-F tells hospitals to abandon those feeds. The practical architecture ends up with two distinct boundaries:

• FHIR surface: patient-facing apps, clinician apps, payer exchange, and population-level access.
• v2 backbone: admissions, transfers, orders, results, and scheduling events.

Engineering teams are better served normalizing both streams into a single internal data model and pushing protocol-specific logic to the edge—rather than pretending one standard can cover every scenario. For products that may fall under regulated software classification, Software as a Medical Device engineering deserves attention alongside the integration design itself.

Does FHIR Replace HL7 v2?

Not even close. FHIR is one standard within the HL7 family, while HL7 v2 still handles the heavy lifting across most hospitals — admissions, orders, results, scheduling, you name it. Walk into any health system and you'll find v2 humming along in production.

Most products don't force a choice between the two. They support both, typically running an integration layer that translates incoming v2 events into a unified internal model, then exposing the data that matters through FHIR APIs. It's a pragmatic setup that acknowledges reality: v2 isn't going away, and FHIR fills different gaps.

• HL7 v2 product suite
• FHIR specification directory

What Does ONC Actually Require?

The ONC's criterion 170.315(g)(10) mandates that certified health IT expose standardized APIs for patient and population services. The technical backbone here is FHIR-based API access, paired with implementation guides like US Core.

This is worth parsing carefully: the regulation targets the API surface of certified systems. It doesn't dictate how every internal hospital interface or engine-to-engine communication works. Your ADT feeds between departments? Still fair game for v2. The patient-facing data access layer? That's where FHIR and the ONC requirements come into play.

• ONC standardized API criterion
• US Core

When to Use SMART on FHIR vs. Bulk Data

Different jobs, different tools. The distinction comes down to who's on the other end and what they're trying to accomplish.

SMART on FHIR fits interactive use cases — a patient portal pulling records, a clinician app launching from within an EHR, anything that needs OAuth-scoped authorization tied to a real user session.

Bulk Data is built for the backend: population health analytics, asynchronous exports, feeding data warehouses. It's optimized for scale, not interactivity.

Neither replaces the other. Most serious deployments end up using both, depending on the workflow.

• FHIR R4 specification

Handling HL7 v2 Trigger Events

Think of every trigger event as a contract with an external system. When an ADT^A01, ORU^R01, or SIU^S12 arrives through your interface engine, it's not just a message — it's a commitment. Something happened somewhere, and your system needs to respond reliably.

The playbook is straightforward:

• Validate and acknowledge the message immediately
• Extract patient, encounter, order, or result data and map it to your canonical model
• Preserve the original message and the partner-specific mapping logic

That last point matters more than teams realize. When something breaks at 2 a.m., having the raw v2 message and the exact mapping that transformed it is the difference between a quick diagnosis and hours of finger-pointing with the sending facility.

Building an Internal Model That Actually Works

Design your canonical data model around clinical concepts, not wire formats. This is the architectural decision that pays dividends every time a new integration lands on your desk.

A practical model covers:

• Patient identity and demographics
• Encounters and visits
• Observations and vital signs
• Diagnostic reports and results
• Orders and referrals
• Clinical documents
• Terminology mappings and code sets
• Provenance and source identifiers

Once this model is solid, both v2 adapters and FHIR clients feed into the same structures. Your product services stop caring whether the data arrived via a segment pipe or a REST call — they just work with clean, protocol-agnostic entities.

---

Ekipa AI can help plan and build healthcare integrations through Ekipa.ai.