HL7 v2 and FHIR aren’t two formats for the same data — they’re two different integration architectures with two different cost curves, and that distinction is the piece most vendor quotes leave out. HL7 v2 sends pipe-and-caret delimited messages — ADT, ORU, ORM — point-to-point through an interface engine like Mirth Connect, Rhapsody, or Cloverleaf, so every new connection is its own custom build and cost climbs close to linearly with how many systems are involved. FHIR exposes the same underlying clinical data as RESTful, JSON-based resources with standardized SMART on FHIR authorization, which lowers the marginal cost of each additional integration once the API layer and resource mapping already exist — but building that layer is its own real, front-loaded cost, and most EHRs still expose FHIR unevenly next to their legacy HL7 v2 interfaces. In practice, most integration projects need both: an HL7 v2 feed for real-time clinical traffic and a FHIR layer for newer, app-facing use cases. Here’s where that cost and timeline difference actually comes from.

Over 95% of hospitals still run HL7v2 for core system integrations, according to ONC data — so a vendor pitching FHIR as a wholesale replacement is describing where the industry is headed, not where most of your trading partners actually sit today. Our EHR integration guide for founders already covers the plain-English version of HL7 v2 vs. FHIR — what each one is, and why healthcare hasn’t fully switched. This post assumes you’ve already got that context, or already know both acronyms, and goes straight to the part that actually lands in a statement of work: why an HL7 v2 quote and an FHIR quote for what sounds like “the same integration” can come in nothing alike.

HL7 v2 vs. FHIR: The Technical Difference That Drives Cost

It’s tempting to read HL7 v2 vs. FHIR as an old-standard-vs-new-standard story — pipes vs. JSON, legacy vs. modern. That framing is why so much competitor content treats the choice as a format footnote and moves on, and it’s the wrong frame for anyone actually scoping a build. HL7 v2 and FHIR are two different integration architectures, full stop, and each one carries its own cost model. HL7 v2 is a point-to-point, message-based architecture: every connection is its own engineering project, with its own mapping, testing, and go-live cycle, and that structure is exactly what makes cost scale with the number of systems you’re connecting. FHIR is a shared, resource-based API architecture: the expensive part is standing up the API layer and the auth model once, after which additional consumers cost less to add. When two vendors quote wildly different numbers for what looks like “the same integration,” this is almost always the real reason — they’re pricing different architectures, whether or not they’ve said so out loud.

How HL7 v2 Actually Works (and Why It’s Still Everywhere)

Most hl7 integration work in a live hospital environment is still HL7 v2, and understanding why starts with the message format itself.

Message Structure: Segments, Pipes, and the Message Types That Matter

HL7 v2 messages are plain-text strings broken into segments — MSH for the message header, PID for patient identification, OBX for observation results — delimited by pipes (|) and carets (^), a format that looks primitive next to JSON until you remember it was designed in the 1980s to move over serial and dial-up links, not broadband. In practice, three message types account for most of the traffic that matters: ADT (admit, discharge, transfer) for patient movement events, ORU (observation result, unsolicited) for lab and diagnostic results, and ORM/ORDER for orders and referrals. If you’re building against a hospital’s real-time event stream, you’re almost certainly building against one of these three.

Point-to-Point Interface Engines: Why Each Connection Is Its Own Build

HL7 v2 doesn’t have a native concept of a shared API. It moves through an interface engine sitting between the EHR and every downstream system, translating and routing messages point-to-point. Mirth Connect (rebranded NextGen Connect), Rhapsody, and Cloverleaf are the three names that show up in nearly every hospital IT shop, and each does the same basic job: accept a message, transform it to match the receiving system’s expected format, and route it. The catch is that “transform it to match the receiving system’s expected format” is rarely trivial — every EHR and every downstream system implements HL7 v2 with its own local quirks, optional segments, and custom Z-segments, so each new connection needs its own mapping and its own testing and UAT cycle before it goes live. That’s the structural reason cost scales close to linearly per connection: you’re not reusing a shared interface, you’re building a new one every time. It’s also why urgent care operations running on real-time HL7 v2 ADT feeds lean so heavily on point-to-point engines — high-volume walk-in traffic needs the low-latency, message-based model HL7 v2 was built for, not a REST call per event.

How FHIR Actually Works (and What’s Different)

fhir integration starts from a completely different premise: instead of a stream of discrete messages, the EHR’s data is modeled as a set of standardized resources — Patient, Observation, Encounter, MedicationRequest — that an outside application requests over a normal RESTful API call, formatted as JSON (or, less commonly now, XML).

Resources and REST: A Different Structural Model, Not Just a Different Format

That’s a structural difference, not a cosmetic one. HL7 v2 pushes a message when an event happens; FHIR gets pulled on request, the way any modern web API works, which is exactly why FHIR fits app-facing use cases — a patient portal, a mobile app, a third-party clinical tool — better than a message queue ever would. Cardiology practices pulling device and results data increasingly build against FHIR resources for this reason: structured, on-demand pulls fit how a cardiology app actually needs to consume device and lab data, layered alongside whatever HL7 v2 feed is already running for real-time clinical events.

SMART on FHIR and US Core: Why “FHIR-Compliant” Doesn’t Mean “Identical API”

Every FHIR-based EHR uses SMART on FHIR for authorization — an OAuth 2.0 profile purpose-built for healthcare that governs how an app requests and receives a token scoped to a specific patient and a specific set of permissions. That part is genuinely standardized. Adoption is real and growing, too: two in three hospitals reported using a FHIR API to enable patient access in 2022, a 12-point jump from the year before, according to ONC. What isn’t standardized in practice is resource support — implementation guides like US Core define the baseline data elements a certified EHR has to expose, but “FHIR-compliant” only guarantees that baseline, and most EHR vendors implement extensions, custom profiles, and partial resource coverage well outside it. Two systems can both be technically FHIR-compliant and still require meaningfully different integration work, which is the same trap “HL7-compliant” used to be, just with a newer coat of paint.

Where the Actual Cost Difference Comes From

HL7 v2 Cost Drivers: Licensing and Per-Connection Build

The interface engine itself is a real line item before build work even starts. NextGen Connect (the free, open-source edition of what used to be Mirth Connect) has no license fee, but the commercially supported tier and its plug-ins run five figures to low six figures a year, and Cloverleaf and Rhapsody are priced on enterprise, per-interface licensing models that get expensive fast at scale. On top of licensing, a single HL7 v2 interface build typically runs $10,000 to $30,000 or more depending on complexity, and point-to-point connections often carry their own port fees on top of that — each interface needs its own export and import ports, and those can run up to $5,000 per port, adding up to roughly $20,000 in port fees alone on a single four-port interface. Multiply that by the number of trading partners in a real hospital environment and it’s obvious why cost scales close to linearly with connection count.

FHIR Cost Drivers: Front-Loaded Setup, Lower Marginal Cost

FHIR’s cost curve runs the other direction. Before a single resource gets consumed, someone has to stand up the API layer, implement SMART on FHIR auth, map internal data models to FHIR resources, and get through whatever sandbox and certification steps the source EHR requires — real, often underestimated upfront work. Regulation is a big reason that investment got made industry-wide in the first place: the CMS Interoperability and Patient Access Final Rule (CMS-9115-F), effective January 1, 2021 and enforced starting July 1, 2021, required Medicare Advantage, Medicaid, CHIP, and federal exchange plans to expose patient data through a standardized, FHIR-based Patient Access API — a mandate that pushed EHR and payer systems to build FHIR infrastructure years earlier than they otherwise might have. Once that layer exists, though, each additional consumer really is cheaper to add than another HL7 v2 point-to-point build. You’re granting API access and scope, not standing up a new interface from scratch.

The Maintenance Line Item Both Sides Underquote

Neither side is maintenance-free, and this is where most estimates quietly go wrong. HL7 v2 interfaces break silently — an upstream system adds an optional segment or changes a field length without warning, and the interface either drops data or fails outright, with ongoing monitoring and error resolution typically running $3,000 to $15,000 per interface, per year. FHIR APIs version and, in theory, deprecate more predictably than a hand-built HL7 interface, but “in theory” is doing real work in that sentence — vendor implementation gaps, US Core version bumps, and inconsistent resource support still cause breakage in practice. A 2025 healthcare IT survey found interoperability issues were the leading cause of delayed implementations, cited by 56% of teams — and that’s the same complexity, on either protocol, that turns into an unbudgeted maintenance line a year after go-live.

Timeline Implications: HL7 v2 vs. FHIR Projects

What Typically Extends an HL7 v2 Build

The interface engine setup itself takes time, but the real schedule risk is per-partner testing — every new trading partner needs its own UAT cycle, and hospital IT teams run change-control windows that don’t bend for a vendor’s launch date. A build that looks done in code can still sit for weeks waiting on the client’s own change-control calendar.

What Typically Extends a FHIR Build

FHIR projects lose time differently: getting sandbox and certification access from the source EHR vendor, registering and getting a SMART app reviewed before it can request production data, and discovering partway through that a given EHR’s FHIR implementation doesn’t actually cover the resource you need, forcing a custom extension that wasn’t in the original scope.

Why Hybrid Is the Realistic Answer for Most Projects

Most mid-complexity integration projects end up needing both, not a clean either/or. Epic’s Interconnect and App Orchard interfaces are a concrete example of this in the wild — Epic exposes both an HL7 v2 surface and a FHIR-based developer program on the same platform, precisely because real-time clinical event traffic and app-facing data access are different jobs that call for different architectures. An HL7 v2 feed handles the real-time ADT and orders traffic a hospital already depends on; a FHIR facade sits alongside it for the newer, app-facing consumers that need on-demand, structured access. Planning for one and bolting on the other later almost always costs more than scoping both from the start.

How to Decide: HL7 v2, FHIR, or Both

The decision isn’t really HL7 v2 vs. FHIR in the abstract — it’s a handful of concrete questions about your specific project, and most of them can be answered before a vendor ever writes a proposal.

  • How many trading partners does this integration actually need to reach, and does that number grow over time? A handful of point-to-point HL7 v2 connections is manageable; a growing list of consumers is exactly when FHIR’s lower marginal cost starts to pay for itself.
  • Does the data need to power a patient-facing or third-party app? That favors FHIR — it’s the architecture built for exactly that use case, and it’s what CMS’s own interoperability mandates were written around.
  • Is this high-volume, real-time clinical event traffic — admissions, orders, results? That favors HL7 v2, or a hybrid with an HL7 v2 feed underneath a FHIR layer.
  • What does the source EHR actually support well, not just claim to support? “FHIR-compliant” and “fully implements the resources you need” are two different statements, and the gap between them is where most healthcare data integration projects lose their timeline.

Answer those honestly before you’re comparing vendor quotes, and the quotes themselves start to make a lot more sense.

Why the Protocol Choice Isn’t the Real Risk

Here’s the differentiation point worth sitting with: picking HL7 v2 vs. FHIR is rarely what actually blows up an integration budget. The bigger risk is hiring a team that’s only ever built one of the two and defaults to whatever they know regardless of what the project needs — or a team that quotes a flat rate without asking which architecture is even in scope. A team that’s actually shipped both knows when a hybrid is the honest answer and when it isn’t, which is the whole premise behind our EHR integration services. For projects where legacy HL7 v2 traffic and a modern FHIR-facing app both need to exist on the same system, that usually means building a custom integration layer — purpose-built middleware that bridges the two instead of forcing one protocol to do a job it wasn’t designed for.

Get Your Integration Scoped Around the Right Protocol

If you’re past the “what’s the difference” stage and into “what does this actually cost us,” the conversation worth having is about your specific trading partners, your data’s end use, and what your source EHR really supports — not a flat quote for “HL7 vs. FHIR integration.” Talk to our team about where your project actually sits on that decision. And if you’re earlier in the process and want the less-technical version first, our EHR integration guide for founders is the better starting point.