FHIR vs. HL7: Key Differences, Use Cases, and When You Need Both

A survey published in the Journal of the American Medical Informatics Association found that only 73% of digital health vendors use standards-based FHIR APIs when integrating with EHR systems. The rest still exchange data through older standards such as HL7 v2 and Clinical Document Architecture (CDA).

Both sides of that statistic matter for your product. US regulation already requires certified EHR systems to support the FHIR API standard, and similar pressure is building in Europe under the European Health Data Space. At the same time, many of the hospitals, labs, and insurers your software needs to talk to still run their daily data exchange over HL7 v2 interfaces built years ago.

So the FHIR vs. HL7 choice comes down to what your software must connect to.

Whether you are adding EHR connectivity to an existing healthtech product or picking the foundation for a new one, this article compares both standards across the parameters that shape healthcare interoperability in practice. We will also show the cases when one product may need both standards working together.

But before that, let’s start from the basics.

HL7 (Health Level Seven) is a family of international standards that define how healthcare software systems exchange clinical and administrative data. Health Level Seven International, a nonprofit standards organization founded in 1987, maintains the standards. The name refers to the seventh layer of the OSI networking model: the application layer, where this exchange actually happens.

In practice, most conversations about HL7 standards concern HL7 Version 2 (v2), the messaging standard first published in 1989. Decades later, it still carries most day-to-day data exchange between hospital systems, and lab equipment and EHR platforms still speak it.

The family also includes HL7 v3, an XML-based redesign from the 2000s that saw limited adoption, and CDA, a document format from the v3 line used for structured clinical documents such as discharge summaries. If your product touches this data in the US, the exchange itself is regulated as well; we cover that side in our overview of healthcare laws and data standards.

An HL7 message is a plain-text structure in which pipe symbols separate fields and each line, called a segment, carries one type of information. A lab result arriving in your system looks like this:

MSH|^~\&|LAB|GENHOSP|EHR|CLINIC|20260910||ORU^R01|MSG00001|P|2.5
PID|1||123456^^^GENHOSP||DOE^JANE||19850312|F
OBX|1|NM|GLU^Glucose||95|mg/dL|70-99|N|||F

Common message types cover patient admissions, discharges, and transfers (ADT), lab results (ORU), and orders (ORM). The HL7 message format is compact, fast to transmit, and proven over decades of production use.

The catch sits in the word “interface.” HL7 v2 connections are point-to-point: each one links two specific systems for a specific data flow. The standard also allows local variations, including custom Z-segments that individual hospitals add for their own needs, so no two implementations are exactly alike.

When an integration quote lists three HL7 interfaces, it means three separately configured, mapped, and tested connections, and a fourth partner will require a fourth. That per-connection effort is the single most important thing to understand about HL7 v2 when you plan an integration budget.

FHIR (Fast Healthcare Interoperability Resources, pronounced “fire”) is a standard that represents clinical data as discrete web resources and exchanges them through REST APIs, most often in JSON. It answers a question many buyers ask early: FHIR and HL7 are related rather than competing brands. Health Level Seven International publishes FHIR too, which is why you will often see it written as HL7 FHIR. What FHIR competes with are the older HL7 standards described above.

The architectural difference is the part that matters for your product. An HL7 v2 integration is a feed: system A pushes a message to system B when an event happens, over a connection built specifically for those two systems. FHIR turns the same data into a web API: any authorized application can request exactly the records it needs, the same way apps everywhere consume APIs. That single change is what makes patient-facing apps, mobile access, and analytics features practical to build.

FHIR R4, published at the end of 2018, is the version US regulators reference for certified EHR APIs; R5 followed in 2023, and R6 is in development.

FHIR models healthcare data as resources: small, standardized building blocks such as Patient, Observation, Appointment, and Medication, with more than 140 resource types defined in R4. The same glucose result from the HL7 example above looks like this as a FHIR resource:

{
"resourceType": "Observation",
"status": "final",
"code": { "text": "Glucose" },
"subject": { "reference": "Patient/123456" },
"valueQuantity": { "value": 95, "unit": "mg/dL" }
}

Readable structure has a hiring consequence. Working with the FHIR API requires the REST and JSON skills most web developers already have, while HL7 v2 work tends to require integration specialists. For a product team, that difference shows up directly in recruitment time and day rates.

SMART on FHIR is a companion standard that adds authorization (built on OAuth 2.0) and app-launch rules on top of FHIR APIs. It is the mechanism that lets a third-party application run inside major EHR systems such as Epic and Oracle Health and appear directly in a clinician’s workflow.

For a healthtech product owner, this also opens a sales channel. An app that supports SMART on FHIR can be listed in EHR app galleries, the marketplaces where hospitals and clinicians find and install software that works inside their EHR.

HL7 v2 is a messaging standard: systems push pipe-delimited messages to each other over point-to-point interfaces built for each connection. FHIR, in its turn, is an API standard: applications request data as standardized JSON resources over REST. HL7 v2 dominates existing hospital integrations, while FHIR powers modern patient-facing, mobile, and regulatory-mandated data access.

Here is the difference between HL7 and FHIR at a glance:

The choice between healthcare interoperability standards rarely hinges on a feature list. It depends on how each standard behaves in the places that consume budget: data mapping, infrastructure, hiring, compliance, and maintenance. Neither standard is niche: HL7 International reports that 95% of US healthcare organizations use HL7 v2.x, and FHIR-based access is now the norm among US hospitals, as the regulatory parameter below shows.

Below we weigh both standards across seven such parameters.

The examples earlier in this article show the surface difference: segments and pipes on one side, JSON resources on the other. The bigger difference is variability.

HL7 v2 leaves many fields optional and allows custom Z-segments, so in practice every sender speaks its own dialect, and the knowledge of what field 5 in segment OBX means at a particular hospital lives inside that one interface.

FHIR defines resources strictly, and profiles narrow them further for a market: US Core profiles, for example, specify exactly what a compliant Patient or Observation must contain for US exchange. Mapping work done for one FHIR integration largely carries over to the next.

To sum up, FHIR gives you predictable, reusable data structures; HL7 v2’s flexibility is precisely what turns every new feed into a small analysis project.

An HL7 v2 integration runs as a persistent feed between two systems, typically through an interface engine, message queues, and a site-to-site VPN per partner. That is dedicated infrastructure your team hosts, monitors, and pays for. FHIR travels over HTTPS with OAuth 2.0 authorization through SMART, covered earlier, so it works with the API gateways, monitoring, and cloud services a modern product already uses.

In a nutshell, FHIR fits the architecture your product already has; HL7 v2 brings its own infrastructure that someone must run.

Here the older standard keeps a real advantage. HL7 v2 pushes messages at the moment something happens. For instance, a patient is admitted, and the ADT message is on its way within seconds. Hospitals have run this pattern reliably for decades.

FHIR is request-and-response by default, so an application must ask for data or poll for changes. The FHIR Subscriptions framework addresses event delivery, but vendor support remains uneven.

That said, for event-driven workflows such as admission alerts, HL7 v2 remains the dependable choice today.

The hiring difference from earlier compounds at project level. A FHIR project can start in a public sandbox with synthetic data before a single contract is signed, and the developers who build it are the same profile who build the rest of your product.

Each EHR vendor’s FHIR implementation still differs in authorization scopes, rate limits, and data depth, so plan real effort per integration. On the v2 side, scarce specialists lengthen hiring, and every interface requires coordination with the partner’s integration team; scheduling time with hospital IT is often the longest item on the plan.

To sum up, FHIR projects start faster and staff more easily; neither standard removes per-partner integration effort.

Mature integration engines, such as Mirth Connect and its commercial peers, support HL7 v2 and handle routing, transformation, and monitoring. They’re a settled part of hospital infrastructure.

FHIR’s tooling grew up in the cloud era: open-source servers such as HAPI FHIR, managed services such as Azure Health Data Services, client SDKs, and SMART sandboxes for testing against real EHR behavior.

That said, both ecosystems are production-grade, but FHIR aligns with the cloud stack most product teams already build on.

In the US, the 21st Century Cures Act and ONC certification rules made a FHIR R4 API a requirement for certified EHR systems, which is why every major EHR now exposes one. The effect is measurable: according to an ONC data brief, the share of US hospitals that let patients access their health information through FHIR-configured apps grew from 57% in 2021 to 70% in 2024.

The CMS Interoperability and Prior Authorization rule extends the same approach to payers, with compliance dates in 2026 and 2027. In the EU, the European Health Data Space regulation phases in mandatory health-data sharing, with FHIR positioned as the leading standard for implementing it.

None of these rules requires anyone to switch off HL7 v2. They regulate access to data, and they consistently choose FHIR as the mechanism.

HL7 v2 costs scale with the number of connections. Each interface is built, tested, and maintained separately, and a change on the partner’s side means indefinite rework on yours.

FHIR shifts spending forward: you invest once in the API layer, authorization, and profiles, and each additional consumer costs comparatively little. The honest caveat: if the organizations you exchange data with only expose v2 feeds, adopting FHIR does not remove that cost; it adds a translation layer, which is the subject of the “when you need both” section below.

In short, economics favor FHIR when you expect many consumers and future integrations. Yet, a handful of stable hospital feeds may never justify replacing v2.

“HL7” names a family, so the comparison gets sharper one standard at a time. When a partner, vendor, or job description says HL7, it almost always means one of the standards below, and what that means for your product differs in each case.

The head-to-head above covered how differently the two work. The version-level question is about replacement, and the honest answer to what is replacing HL7 is: it depends on which layer you look at.

Hospitals depend on thousands of working v2 interfaces, and nothing in the industry suggests those are going away this decade. FHIR is instead taking over the edges of the system, the places where products, patient apps, and third parties connect, while v2 keeps running between the systems inside hospital walls. HL7 International maintains an official V2-to-FHIR mapping guide precisely because the two are expected to run side by side.

For planning purposes: expect HL7 v2 whenever your product connects deep into hospital operations, such as lab feeds and admission events, and expect FHIR at the front door, where EHRs expose API access.

HL7 v3 was the organization’s early-2000s attempt to fix v2’s inconsistency with a strict XML model. The stringency made implementations slow and expensive, adoption stayed limited, and v3 is rarely a serious candidate for a new product today. If you encounter it at all, it will be inside specific national health programs rather than in commercial EHR integration.

CDA is the part of the v3 line that succeeded, because it standardizes something clinicians genuinely exchange: structured documents such as discharge summaries and care records. Its US variant, C-CDA, remains a required format in many health information exchange and quality-reporting flows. FHIR has its own document capabilities, but CDA is still what many partners actually send.

If your roadmap includes ingesting care summaries or connecting to health information exchanges, you should plan budget for CDA handling even in a FHIR-first product.

In short, which HL7 standard you meet depends on the door your product enters through.

Choose HL7 v2 when your product’s value depends on data that hospitals, labs, and clinics already publish as v2 feeds. In those situations, the standard is set by the partner, and fighting it costs more than adopting it.

This is the most common case for teams adding integrations to an existing product. The lab whose results you need, or the hospital whose patient roster you serve, offers exactly one thing: a v2 feed managed by its integration team.

The pattern holds across the market: the same ONC survey of health information exchange organizations found that more than 80% routinely or sometimes exchange HL7 v2 messages, while only about one-fifth do so through FHIR APIs. Ask partners early what they expose; their answer settles more than any comparison table does.

Care coordination, bed management, and patient-flow features depend on knowing about an admission the moment it happens. As the real-time parameter showed, ADT feeds deliver exactly that with decades of production history, and 90% of health information exchange organizations in the ONC survey routinely receive data as v2 ADT messages. If missing an event by hours breaks your value proposition, v2 is the proven route.

Hospital IT teams standardize on their integration engine and its established message flows. When a statement of work names v2 message types, the format is a commercial term of the deal. Delivering inside the partner’s infrastructure beats trying to modernize it from outside.

If your product already runs stable v2 connections, replacing them for architectural neatness rarely survives a cost review. As the total-cost parameter showed, a stable feed is cheap to keep. Add FHIR where new requirements appear, and leave working interfaces alone.

Choose FHIR when you control the architecture and the data consumers are modern applications: your own, your users’, or a regulator’s. For new development, it is the default choice, and the burden of proof sits with any alternative.

If you are starting now, build FHIR-first. You get standardized resources, web-standard security, staffing from the mainstream developer pool, and alignment with where regulation is pushing the whole market. Every parameter that favors v2 concerns other people’s existing systems, which a new product does not have yet.

Patient portals, mobile apps, and personal health tools run on FHIR because that is how certified EHRs expose records and how SMART on FHIR admits applications into the clinical ecosystem. Patients are moving the same way: ONC’s 2024 survey of individuals found that 57% of those who accessed their records did it through an app, up from 38% in 2020. The hospital adoption figures in the regulatory parameter show the supply side is ready, and your product plugs into it.

When compliance drives the work, the standard is chosen for you. The Cures Act EHR APIs, the CMS prior-authorization requirements, and the European Health Data Space all point to FHIR, as covered earlier. Building the mandated capability on the mandated standard is the shortest path through certification.

Analytics and AI features are only as good as the consistency of the data behind them, a challenge we examined in our article on adopting AI in healthcare. The scale of the problem is documented: Deloitte research places data-related issues among the top three challenges for companies implementing AI, with 28% of life sciences and healthcare respondents naming data collection a significant obstacle. FHIR gives models and pipelines predictable, profiled structures to work with, which shortens the path from raw records to a working feature.

The two previous sections read like a fork in the road. For most products past their first integration, they describe the same road at different points. A typical healthtech product a few years into its life runs a FHIR API for its own applications, its users, and its regulators, fed in part by HL7 v2 streams arriving from hospitals and labs.

The ONC numbers above explain why: the partners supply v2, the consumers expect FHIR. The practical question shifts from which standard to how the two meet inside your architecture.

Most HL7 integration and FHIR integration projects converge on one of these patterns:

• FHIR facade. Incoming v2 messages hit a translation service that maps them into FHIR resources, and everything you build afterward sees only FHIR. The HL7 complexity stays contained in one component, and each new feature reuses the same clean API.
• Integration engine in the middle. An engine of the kind described in the tooling parameter receives, transforms, and routes both formats, and handles queuing, retries, and monitoring. This suits products with many hospital connections, where per-feed reliability is the hard part.
• Native support for both. The product speaks v2 where a partner requires it and FHIR everywhere else, with no central translation layer. Least infrastructure, but format knowledge spreads through the codebase, so it fits products with a small, stable set of connections.

Sequencing differs by starting point. If you run an existing product, keep the v2 connections that work and introduce the bridge with your first FHIR-facing feature, so every later feature inherits it. If you are building new, put a FHIR-first core in place and treat v2 as an adapter at the edge, budgeted from your first hospital deal onward.

Wherever you start, expect the HL7 data integration effort to concentrate in the same places: mapping each partner’s v2 dialect, test cycles with each partner’s integration team, and the security review of every new PHI flow. The translation code itself is rarely the expensive part.

Our team meets this coexistence in real projects. We built a healthcare practice management platform for a telehealth solution provider, where the product’s value depended on connecting cleanly to surrounding healthcare and payment systems, and we migrated an EHR platform serving around 30 clinics to a HIPAA-compliant private cloud without disrupting the integrations running on it. Healthcare systems earn their keep at the connections, and that is where we focus the engineering effort.

Choosing between standards is analysis; making either work inside a secure, compliant product is delivery. As a dedicated team and solution provider, we take healthtech companies through both.

Leobit provides healthcare software development services and can build solutions that support HL7, FHIR, and DICOM, connected through the middleware and APIs your integration map requires. That work runs on security practices backed by ISO 27001:2022 and ISO 9001:2015 certifications and full HIPAA and GDPR compliance.

If you are weighing an integration roadmap, the practical first step is a discovery phase: we audit the systems your product must connect to and the standards each one exposes, then propose the architecture and an estimate before you commit to a build.

FHIR and HL7 v2 are both production reality, and the comparison ends differently depending on where you stand. HL7 v2 excels where hospital infrastructure already speaks it: event feeds, lab results, and long-lived partner interfaces. FHIR excels everywhere something new is being built: patient access, mobile apps, analytics, and every API a regulator now mandates. Most products that live long enough run both, connected by a bridge you should choose deliberately.

Picking the standard is only part of the problem. The results depend on the team that maps the feeds, builds the API layer, and keeps PHI secure along the way. If that team is what you are missing, we are ready to help.