HL7 is the family of healthcare data exchange standards from HL7 International, best known for HL7 Version 2 messaging, while FHIR (Fast Healthcare Interoperability Resources) is HL7’s newest standard, built on modern web technologies like RESTful APIs, JSON, and OAuth. For new healthcare apps, FHIR is usually the right choice, but most hospitals still run HL7 v2 behind the scenes, so many real projects need both.

Here’s a conversation healthcare developers have all the time. A founder says, “We’ll just pull the patient’s data from the hospital’s system.” Then the integration team asks which interface: an HL7 v2 feed, a C-CDA document, or a FHIR API? Suddenly a two-week task looks like a two-month one.

The confusion makes sense. “HL7” and “FHIR” are often treated like rivals, when FHIR is actually an HL7 standard. In this guide, we’ll explain how HL7 v2, CDA, and FHIR differ, show what the data actually looks like, cover the US rules that now require FHIR APIs, and help you decide what your app needs. It’s the same groundwork we lay at the start of every healthcare app development project that touches clinical data.

HL7 vs FHIR at a Glance

What Is HL7?

HL7 refers to Health Level Seven International, the standards organization, and to the family of healthcare data standards it publishes, including HL7 Version 2, HL7 Version 3, the Clinical Document Architecture (CDA), and FHIR.

The name comes from the seventh “application” layer of the OSI networking model, where these standards operate. When people say “HL7” without a version, they usually mean HL7 Version 2.

HL7 Version 2: The Workhorse of Hospital Integration

HL7 v2 is a messaging standard that sends healthcare events, like a patient admission or a new lab result, as pipe-delimited text messages between hospital systems. It’s been around since the late 1980s and is still everywhere. HL7 International describes HL7 Version 2 as the most widely implemented healthcare standard in the world.

Here’s a simplified admission message (ADT^A01) for a fictional patient:

MSH|^~\&|REGADT|GOOD_HEALTH_HOSPITAL|RECEIVER|RECEIVER_FAC|202610011030||ADT^A01|MSG00001|P|2.5.1

PID|1||123456^^^GHH^MR||Doe^Jane||19850214|F|||12 Main St^^Springfield^IL^62701

PV1|1|I|ICU^101^1

Each line is a segment: MSH is the message header, PID holds patient details, and PV1 describes the visit. Fields are separated by pipes, and components by carets. It’s compact and fast, but every hospital tends to use it slightly differently, which is why HL7 v2 interfaces often need custom mapping.

HL7 Version 3 and CDA

HL7 Version 3 was designed to fix v2’s inconsistencies with a formal, XML-based model. It proved complex to implement and never replaced v2 for messaging. Its most successful piece is the Clinical Document Architecture (CDA), and in the US, Consolidated CDA (C-CDA) documents are still widely used for discharge summaries, referrals, and continuity of care records.

What Is FHIR?

FHIR, short for Fast Healthcare Interoperability Resources, is an HL7 standard for exchanging healthcare data through modern web APIs, using small, reusable building blocks called resources that can be read and written with standard HTTP requests.

FHIR (pronounced “fire”) was created to make healthcare data exchange feel like any other modern API. Instead of decoding pipe-delimited messages, developers request JSON over HTTPS. The full specification is published at hl7.org/fhir.

FHIR Resources

Everything in FHIR is a resource: Patient, Practitioner, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, and more than a hundred others. Here’s the same fictional patient as a FHIR resource:

{

  “resourceType”: “Patient”,

  “id”: “123456”,

  “name”: [{ “family”: “Doe”, “given”: [“Jane”] }],

  “gender”: “female”,

  “birthDate”: “1985-02-14”,

  “address”: [{ “line”: [“12 Main St”], “city”: “Springfield”, “state”: “IL”, “postalCode”: “62701” }]

}

FHIR Is RESTful

FHIR uses familiar HTTP methods and URLs. Reading a patient or searching for their heart rate readings looks like this:

GET [base]/Patient/123456

GET [base]/Observation?patient=123456&code=http://loinc.org|8867-4

That RESTful design is a big reason FHIR is easier for web and mobile developers to adopt. If you want a refresher on what makes an API RESTful, our guide on REST vs RESTful APIs covers the principles FHIR builds on.

FHIR Versions: R4, R4B, and R5

FHIR R4, released in 2019, is the version most systems use in production today, and it’s the version required by key US regulations. R4B was a small update in 2022, and R5 was published in 2023 with new features. Further versions are in development, but for most healthcare apps in 2026, R4 with US Core profiles is the practical target.

HL7 vs FHIR: The Key Differences

When developers compare FHIR vs HL7 v2, these seven differences matter most.

1. Architecture

HL7 v2 pushes event messages from one system to another, usually through an interface engine. FHIR exposes data as resources through APIs that apps can query when they need it, while still supporting messaging, documents, and subscriptions.

2. Data Format

HL7 v2 uses compact pipe-delimited text. FHIR uses JSON or XML, which every modern programming language can parse easily.

3. Granularity

HL7 v2 messages bundle many data points around an event. CDA packages whole documents. FHIR breaks data into small resources, so an app can request just a patient’s medications or one lab result.

4. Standardization and Variability

HL7 v2 allows lots of optional fields and local customization, so no two interfaces are quite the same. FHIR uses profiles and implementation guides, like US Core, to define exactly how resources should look for a given use.

5. Security

HL7 v2 typically relies on secure networks, VPNs, and interface engines. FHIR apps use SMART on FHIR, which builds on OAuth 2.0 and OpenID Connect so patients and clinicians can authorize apps securely.

6. Developer Experience and Tooling

FHIR offers open-source servers, client libraries, test servers, and validators. HL7 v2 usually requires specialist integration engines and analysts who know each hospital’s quirks.

7. Adoption

HL7 v2 still moves most data inside hospitals. FHIR is now the standard for patient-facing apps, EHR app ecosystems, payer APIs, and regulatory compliance in the US.

Is FHIR Replacing HL7 v2?

Not completely, and not soon. FHIR is becoming the standard for new APIs and app integrations, but HL7 v2 will keep running inside hospitals for years because it’s deeply embedded in existing systems and works well for internal event messaging.

In practice, most health systems run both. An HL7 v2 feed might carry lab results between internal systems, while the same data is exposed through a FHIR API for patient apps and partners. Many integration platforms now translate HL7 v2 messages into FHIR resources automatically.

Why FHIR Matters So Much in the US Right Now

Regulation has pushed FHIR from “nice to have” to “required” across much of US healthcare.

• 21st Century Cures Act and ONC certification. Under the ONC Cures Act Final Rule, certified EHR technology must offer standardized FHIR APIs, using FHIR R4, US Core, and SMART on FHIR, so patients and authorized apps can access data. The same rule set addresses information blocking.
• CMS interoperability rules for payers. CMS requires many health plans, including Medicare Advantage, Medicaid, CHIP, and Affordable Care Act exchange plans, to offer FHIR-based Patient Access APIs. Its newer Interoperability and Prior Authorization rule adds further FHIR APIs, with most requirements starting in January 2027.
• TEFCA. The national Trusted Exchange Framework and Common Agreement is growing support for FHIR-based exchange alongside document-based exchange.

For app builders, this means more health data is accessible through standard APIs than ever before, though each EHR vendor still has its own registration process, scopes, and review steps.

SMART on FHIR: How Apps Plug Into EHRs

SMART on FHIR is an open standard that lets third-party apps launch inside or alongside EHRs and access FHIR data securely using OAuth 2.0 authorization.

The SMART App Launch specification supports a few common patterns:

• Patient-facing apps where patients log in with their health system account and grant access to their data.
• Clinician-facing apps that launch inside the EHR with the current patient’s context already loaded.
• Backend services that connect system to system without a user, for tasks like population health.

For large data sets, Bulk FHIR (FHIR Bulk Data Access) lets authorized systems export data for many patients at once, which is useful for analytics and quality reporting.

When to Use HL7 v2, CDA, or FHIR

How to Build a FHIR-Enabled Healthcare App

Step 1: Map Your Data Needs

List exactly which data your app needs, such as demographics, medications, labs, or appointments, and which FHIR resources and US Core profiles cover them.

Step 2: Identify Your Data Sources

Find out what each partner supports: FHIR R4 APIs, HL7 v2 feeds, C-CDA documents, or a mix. EHR vendors and payers publish developer programs with their own registration rules.

Step 3: Choose Your Architecture

Decide whether to connect directly to each EHR, use an integration engine, or build on a managed FHIR service. Teams also commonly use open-source servers like HAPI FHIR or cloud services such as Azure Health Data Services, Google Cloud Healthcare API, and AWS HealthLake.

Step 4: Implement SMART on FHIR Authorization

Register your app with each EHR or payer, implement the OAuth 2.0 flows, and request only the scopes your app truly needs.

Step 5: Handle Legacy HL7 v2 Data

If partners send HL7 v2 or C-CDA, map that data to FHIR resources so the rest of your app works with one consistent model.

Step 6: Secure and Validate Everything

Validate resources against FHIR profiles, encrypt data in transit and at rest, log every access, and follow HIPAA requirements for protected health information.

Step 7: Test With Sandboxes, Then Go Live Gradually

Use vendor sandboxes and public test servers, complete each vendor’s app review, then launch with one partner before scaling to more.

Common HL7 and FHIR Integration Challenges

• Vendor variation. Two EHRs can both “support FHIR R4” and still differ in which resources, search parameters, and extensions they offer.
• Incomplete data. Not every data element you want is available through standard APIs yet.
• Terminology mapping. Codes like LOINC, SNOMED CT, RxNorm, and ICD-10 must be mapped and normalized across sources.
• Duplicate patients. Matching the same person across systems needs careful identity logic.
• Rate limits and performance. Some APIs limit requests, so caching and Bulk FHIR matter at scale.
• App registration timelines. Vendor review and approval can take weeks, so start early.

Strong engineering practices help with all of these. Reliable API and backend development keeps mappings, retries, and validation consistent across every integration.

Security and Compliance for HL7 and FHIR Apps

Healthcare integrations handle protected health information, so security can’t be an afterthought. Encrypt data everywhere, use short-lived tokens, log every request, and follow the principle of least privilege when requesting scopes.

Session handling deserves special attention in patient apps, which are often used on shared family devices. Our guide to web app session management covers safe sign-in, timeouts, and logout.

Hosting matters too. Running FHIR servers and integration engines on HIPAA-eligible infrastructure with a signed business associate agreement is standard practice, and our Cloud App Development team designs that infrastructure with compliance built in.

Monitoring and automated deployments keep integrations healthy after launch. Our DevOps and cloud solutions team sets up alerting for failed messages, API errors, and expiring credentials.

For a deeper look at how compliance shapes cloud architecture, read our guide on cloud application development for regulated industries.

How FHIR Affects Your Budget

Integration is often one of the biggest line items in a healthcare app budget, because each data source adds registration, mapping, testing, and maintenance work. In our breakdown of telemedicine app development cost, EHR integration alone can add $15,000 to $40,000 or more per system, depending on the vendor and data needed.

Conclusion

HL7 vs FHIR isn’t really a battle between rivals. HL7 v2 still runs the inner plumbing of most hospitals, CDA documents still carry clinical summaries, and FHIR is the modern API layer that makes healthcare data usable by apps. For new healthcare products in 2026, start with FHIR R4, US Core, and SMART on FHIR, and plan to translate HL7 v2 or C-CDA when your partners need it.

Building a healthcare app that needs EHR or payer integration? Book a free consultation with The Apps Developers, and we’ll help you map your data needs, choose the right standards, and plan a secure integration path.