FHIR vs HL7: 5 Interface Scenarios and the Standard to Use

For new APIs, patient-access requirements, and third-party app integration, choose FHIR. For real-time, in-hospital event feeds like ADT and lab result streams, HL7 v2 still does the job better. Almost every health system will run both for years, since HL7 itself expects the standards to coexist rather than one fully replacing the other, and federal patient-access mandates are pushing FHIR adoption faster than internal IT roadmaps can absorb it.

TL;DR:

• HL7 v2 remains the standard for high-volume, real-time hospital event feeds like ADT and lab results, which are typically stable and costly to replace.
• FHIR is best suited for patient-facing applications, third-party app integration, and workflows requiring OAuth2 security and flexible querying capabilities.
• Transitioning to FHIR involves profiling, terminology management, and careful interface prioritization based on regulatory and clinical needs.
• Using transformation engines or a single internal model can help migrate interfaces gradually without disrupting existing stable HL7 v2 feeds.
• Most health systems will run both standards simultaneously for several years, focusing migration efforts on high-value, regulation-driven use cases first.

Table of Contents

• What HL7 (v2, v3/CDA) and FHIR Actually Mean in Practice
• Why FHIR Exists: What HL7 v2 and v3 Got Wrong First
• HL7 vs FHIR: The Technical Comparison That Matters for RFPs
• Where Each Standard Actually Wins
• How to Migrate Without Breaking What Already Works
• What Your Team Needs Before FHIR Goes to Production
• How MedScrub Supports FHIR-Ready, Privacy-First Workflows
• What Realistic FHIR Adoption Looks Like From Here
• MedScrub: A Practical Path to FHIR-Friendly Workflows
• Sources
• FAQ

What HL7 (v2, v3/CDA) and FHIR Actually Mean in Practice

“HL7” is not one thing. It is a family of standards published by Health Level Seven International, and the version number changes almost everything about how a system talks to another system.

HL7 v2 is a message standard built for point-to-point event notification. When a patient gets admitted, a lab result posts, or an order gets placed, the source system fires off a pipe-delimited text message like ADT (admit/discharge/transfer), ORU (observation result), or ORM (order message). These messages travel over MLLP, a lightweight TCP protocol, usually through a dedicated interface engine sitting between the EHR and every downstream system. There is no formal schema enforcement out of the box, which is exactly why two hospitals running the “same” ADT feed often need custom mapping work to talk to each other.

HL7 v3 and CDA took a different approach: XML-based, model-driven, and document-centric. The Clinical Document Architecture (CDA), and its constrained cousin C-CDA, structure a full clinical document (a discharge summary, a care plan) as a single machine-readable file with a human-readable rendering built in. C-CDA remains genuinely useful for care transitions between systems that need a complete, legally attestable document rather than a stream of discrete data points, and it is still active in production care-transition workflows today.

FHIR (Fast Healthcare Interoperability Resources) breaks clinical data into small, reusable units called resources, roughly 150 of them covering things like Patient, Observation, Condition, and MedicationRequest. Systems exchange these resources over standard REST calls, using JSON or XML, the same way most modern web and mobile apps already talk to their backends. Authorization runs through SMART on FHIR, an OAuth2-based pattern that lets a third-party app request scoped access to a patient’s record without ever seeing the underlying credentials. Because raw FHIR is intentionally generic, real deployments constrain it with “profiles,” most commonly US Core, to guarantee that two systems claiming FHIR compliance actually return comparable data.

Why FHIR Exists: What HL7 v2 and v3 Got Wrong First

FHIR did not appear from nowhere. It is the direct product of two earlier standards teaching the industry, sometimes painfully, what actually works at scale.

HL7 v2 won on ubiquity. It launched in the late 1980s, asked little of implementers, and spread into nearly every hospital on earth. That flexibility became its long-term liability. Because the standard barely enforced structure, every vendor and every hospital IT team built its own dialect. A “standard” ADT message from one EHR often needs a translation layer before another system can read it correctly, and that customization tax has never gone away.

HL7 v3 and CDA tried to fix the ambiguity problem with rigor: a formal Reference Information Model, strict XML schemas, and precise semantic definitions. It largely worked, on paper. In practice, the tooling was heavy, the learning curve was steep, and building a compliant v3 interface took specialized expertise most IT shops didn’t have on staff. Adoption stalled outside of a few document-heavy use cases like C-CDA.

Combined with REST and JSON, technologies web developers already knew, a structured scoping review of the three standards concludes FHIR gives the industry a scalable, genuinely implementable foundation that v2’s inconsistency and v3’s complexity never quite delivered. It wasn’t a rejection of what came before so much as a synthesis of what actually worked.

HL7 vs FHIR: The Technical Comparison That Matters for RFPs

The differences that show up in a vendor conversation are rarely philosophical. They’re about wire format, auth, and what breaks under load. Here’s how the two standards stack up across the dimensions that actually drive architecture decisions.

Architecture and paradigm. HL7 v2 assumes a direct, often permanent pipe between two known systems. FHIR assumes a client that may not know the server in advance, which is exactly what patient-access apps and third-party integrations need.

Wire format and transport. MLLP is fast and low-overhead once it’s running, but it is brittle. A malformed segment can silently corrupt downstream processing, and there’s no standard retry semantics baked in. FHIR rides on ordinary HTTPS, so retries, status codes, and idempotent request patterns (using conditional headers or client-supplied identifiers) are things engineers already know how to handle.

Query capabilities. This is where FHIR pulls ahead decisively. Native search parameters mean a client can ask “give me all Observations for this patient since March 1” in a single call. HL7 v2 has no equivalent; querying typically means building a custom QRY/RSP exchange or, more commonly, just not supporting ad hoc query at all.

Security and auth. HL7 v2 was designed for a world of trusted internal networks, so it has essentially no built-in authorization model. FHIR was designed after the API economy existed, and SMART on FHIR bakes OAuth2 scopes directly into the specification, which is why every payer and provider patient-access API mandated under current federal rules runs on FHIR rather than v2.

Tooling and developer ergonomics. Interface engines like Mirth Connect or Rhapsody remain the backbone of most HL7 v2 shops, and experienced HL7 integration engineers are a genuinely scarce skill. FHIR benefits from the much larger pool of developers who already know REST and JSON, which shortens onboarding time on new integration projects.

Migration difficulty. Ripping out a functioning v2 ADT feed that touches a dozen downstream systems is an operational risk, not a technical one. Building a new FHIR-based patient app from scratch is comparatively low risk but requires more upfront design discipline around profiling and terminology.

None of this makes FHIR strictly “better.” HL7 v2 still moves the majority of real-time hospital messaging in most health systems, and nothing about FHIR’s search capability changes the fact that a stable, high-throughput ADT pipeline running for fifteen years without incident is not a good candidate for a rewrite just because a newer standard exists.

Where Each Standard Actually Wins

Mapping standards to real workflows removes most of the guesswork. Here’s the decision logic in order of how often it comes up:

1. HL7 v2 for real-time hospital events. ADT feeds, lab result delivery (ORU), and order/result pipelines (ORM) are high-frequency, low-latency, and already stable. Ripping these out for FHIR resources gains little and risks breaking downstream systems that have depended on the exact same message shape for a decade.
2. FHIR for patient-facing access. Any app where a patient logs in and pulls their own records, medication list, or lab history should be built on FHIR. It’s the only standard with native OAuth2 scoping suited to a patient authorizing a third-party app to see their own data.
3. FHIR for payer-provider data exchange. Prior authorization requests, coverage checks, and claims-adjacent data sharing increasingly run through FHIR APIs, driven directly by CMS interoperability rules rather than internal preference.
4. FHIR for SMART on FHIR embedded apps. Clinical decision support tools, risk calculators, and specialty workflow apps that need to launch inside an EHR session (Epic, Oracle Health, and others all support this pattern) require FHIR, because that’s the only standard with a defined app-launch framework.
5. A hybrid approach for everything in between. Many interfaces don’t fall cleanly into either camp. A registry submission, a public health reporting feed, or a legacy lab interface might make more sense staying on v2 for now, even if a FHIR equivalent theoretically exists, simply because the existing pipe works and nobody is asking for the query flexibility FHIR offers.

The mistake most teams make is treating this as an ideological choice rather than a per-interface one. Integration practitioners are consistent on this point: the useful skill isn’t picking a winner between HL7 and FHIR, it’s correctly matching each individual interface to the standard that fits its actual traffic pattern and consumer.

How to Migrate Without Breaking What Already Works

A realistic migration plan starts with an inventory, not a mandate. List every active interface, then score each one on three axes: regulatory exposure (does a federal rule require FHIR here?), clinical value of the data moving through it, and how stable the current feed actually is. Interfaces that are both regulated and unstable move to the front of the queue. Interfaces that are stable and unregulated, like an internal ADT feed nobody has touched in years, stay exactly where they are.

For the interfaces you do migrate, you generally have three technical patterns to choose from:

• Interface engine transforms: Keep the HL7 v2 message as the source of truth and use your existing engine (Mirth, Rhapsody) to transform it into a FHIR resource on the way out, so downstream FHIR consumers see clean resources without touching the source system.
• A canonical internal model: Rather than writing bespoke v2 to FHIR mappings for every single consumer, map everything into one internal canonical representation first, then generate FHIR or v2 output from that single model. This avoids the maintenance nightmare of N separate point-to-point translations as your interface count grows.
• Bulk export for batch use cases: For population-level or reporting workflows that don’t need real-time delivery, FHIR’s Bulk Data Access ($export) pattern handles large volumes without the overhead of a live event stream.

Whichever pattern you pick, the operational controls matter more than the mapping logic; see how Technology & EHR Integrations support migration and coexistence strategies in real healthcare environments. Build in idempotency so a retried message doesn’t create a duplicate encounter. Use durable queues so a downed consumer doesn’t silently drop messages. Log enough to replay a specific transaction when a data discrepancy shows up three weeks later, because it will.

Pro Tip: Don’t migrate an interface just because FHIR “can” handle it. Migrate the interfaces where the query flexibility, OAuth2 scoping, or regulatory requirement actually changes what you can build. Everything else can wait.

On timelines, executive-level guidance suggests treating FHIR R4 as the baseline for all new development while explicitly planning for HL7 v2 to keep running stable, high-volume interfaces in parallel, often for several more years. That’s not a failure to modernize. It’s a realistic reading of what “done” looks like in a health system with hundreds of live interfaces.

What Your Team Needs Before FHIR Goes to Production

Standing up a FHIR endpoint is the easy part. Making it interoperable with someone else’s FHIR endpoint is where teams underestimate the work.

Profiling is not optional. Base FHIR is intentionally loose, which means two systems can both be “FHIR compliant” and still return incompatible data. US Core profiles constrain which fields are required, which value sets apply, and how resources relate to each other, and skipping this step is the single most common reason a FHIR integration works in testing and fails against a real partner system.

Terminology bindings need active management. A Condition resource is only useful if its code comes from a shared vocabulary. Most US Core profiles bind to SNOMED CT for clinical findings and LOINC for lab observations, and someone on your team needs to own keeping those value sets current as they get updated.

Validation tooling differs by standard. For FHIR, the official FHIR Validator checks resources against profiles and value sets before they ever reach production. For CDA, Schematron and XSD validation catch structural errors in the XML. For HL7 v2, dedicated conformance testers check message segments against your interface specification, since v2 has no native schema to validate against.

Operational tooling stays largely the same shape. You still need an interface engine or API gateway sitting in front of either standard, an auth server if you’re doing SMART on FHIR, and real observability so a failed transaction gets flagged before a clinician notices missing data. Developer-facing platforms that expose de-identified FHIR access can shorten this build-out considerably for teams that don’t want to stand up the full validation and auth stack themselves.

How MedScrub Supports FHIR-Ready, Privacy-First Workflows

MedScrub connects to EHR systems and does its data handling on-device rather than sending patient information to a cloud server for processing. That distinction matters for any team weighing FHIR access against PHI exposure risk: MedScrub performs anonymization locally, then offers developers reversibly de-identified FHIR access for building integrations without raw PHI ever leaving the clinical environment.

Two examples show the pattern in practice. The eSpiral case study documents an AI-in-the-chart workflow where PHI never touches the cloud, with the assistant working directly against synced chart data. The Monarch Health deployment runs nightly chart preparation and open care-plan tracking, automating exactly the kind of documentation review that otherwise falls to clinicians at the end of a shift.

For teams that need FHIR-based access to patient data but want to minimize how much identifiable information ever crosses a network boundary, this on-device-first architecture is a workable middle path between building custom de-identification pipelines and accepting full PHI exposure just to get API access working.

What Realistic FHIR Adoption Looks Like From Here

Most health systems will spend the next several years running FHIR and HL7 v2 side by side, and that’s not a transitional failure state, it’s the normal operating condition for the industry right now. The organizations that get frustrated are the ones treating FHIR migration as an all-or-nothing initiative instead of an interface-by-interface decision.

The practical next step is boring but effective: run a full interface inventory, tag each one by regulatory exposure and clinical value, and pilot FHIR on whichever interface scores highest on both. Don’t touch the stable v2 feeds that aren’t causing anyone pain. Momentum on the right pilot builds more organizational buy-in than a mandate ever will.

— Clint

MedScrub: A Practical Path to FHIR-Friendly Workflows

If your team is weighing how to expose FHIR data without building a de-identification pipeline from the ground up, Medscrub offers on-device PHI handling that never sends raw patient data to a cloud server, paired directly with EMR syncing.

For clinicians, that means automated chart prep, lab trend summaries, and follow-up tracking without adding another system to log into. For developers, it means reversibly de-identified FHIR access through an API built for exactly this kind of integration work to simplify integration efforts. Clinical teams evaluating fit can review real deployment patterns in the MedScrub case studies, or clinicians ready to see it against their own patient load can start with the clinician-facing product overview and request a walkthrough of how it handles their EHR.

Sources

For the primary specifications and implementation guidance behind this comparison, start with HL7’s official FHIR core pages, the HL7 comparison of FHIR against other HL7 standards, and Ecqi. For deeper technical context, the PMC scoping review comparing HL7 v2, v3/CDA, and FHIR and the executive migration framework from FirstLine Software are both worth a full read.

• A structured scoping review comparing HL7 v2, v3/CDA and FHIR
• FHIR: The relationship between FHIR and other HL7 standards
• FHIR R4 vs Legacy HL7 - Executive framework
• EHR Integration: HL7 vs FHIR vs Vendor APIs

FAQ

What Is Replacing HL7?

Nothing is fully replacing HL7 v2 in the near term. FHIR is the standard gaining ground for new APIs and patient-facing access, but HL7 itself expects both to coexist since v2 still handles most real-time hospital event traffic.

What Does FHIR Stand For?

FHIR stands for Fast Healthcare Interoperability Resources, a standard published by HL7 that structures clinical data as small, reusable resources exchanged over REST APIs.

What Are the Disadvantages of FHIR?

FHIR requires upfront investment in profiling (like US Core) and terminology bindings to avoid inconsistent data across systems, and it demands OAuth2/SMART on FHIR infrastructure that many legacy IT teams don’t already have in place. It also doesn’t natively replace the high-throughput, low-latency event streaming that HL7 v2 already handles well.

Is HL7 Still Relevant?

Yes. HL7 v2 continues to carry the majority of real-time clinical messaging in many hospitals, including ADT and lab result feeds, and replacing those stable pipelines offers little benefit relative to the coordination risk involved.

Recommended

• For Developers
• eSpiral Case Study
• Monarch Health Case Study