Is FHIR replacing HL7 v2?
FHIR is preferred for many modern API use cases, but HL7 v2 remains deeply used for provider event workflows. The standards often coexist.
Patient-authorized EHR integration
FHIR vs HL7 v2 vs C-CDA: a developer’s guide.
These standards overlap, but they solve different integration problems. The right choice begins with the workflow and access relationship—not whichever acronym is newest.
Updated: 2026-08-25 · 10 min read
The bottom line
FHIR is resource-oriented and commonly accessed through modern APIs; HL7 v2 is an event-message standard deeply embedded in provider operations; C-CDA packages a clinical document with narrative and structured entries. Many real integrations use more than one.
Key takeaways
- FHIR is usually the best starting point for patient-authorized app access when supported.
- HL7 v2 remains important for event-driven provider workflows such as admissions, orders, and results.
- C-CDA is useful when the exchanged unit is a clinical document or summary rather than a resource query.
Evidence boundary: Uses published HL7 specifications and implementation guides. Product availability still depends on the participating systems and contracts.
Author: FinchNode Engineering
Compare the integration unit, not only the syntax
| Standard | Primary exchange unit | Common fit | Operational reality |
|---|---|---|---|
| FHIR | Resource and Bundle through REST or other exchanges | Patient access, app integration, modern data services | Profiles, scopes, searches, and server behavior still vary |
| HL7 v2 | Delimited event message | ADT, orders, results, and provider interfaces | Requires interface agreements, routing, acknowledgements, and local mapping |
| C-CDA | Clinical document with narrative and structured entries | Summaries, transitions of care, document exchange | Parsing and section-level normalization are substantial tasks |
Choose by workflow
- Use patient-facing FHIR when an individual authorizes an app to read supported resources.
- Use contracted FHIR or HL7 v2 when a provider needs operational events or write-back inside clinical workflows.
- Use C-CDA when document fidelity and a human-readable clinical narrative are part of the exchange.
- Expect translation when an application needs one normalized model across resource, message, and document sources.
Why the standards coexist
A hospital may expose patient-access data through FHIR, send admission events through HL7 v2, and exchange a transition-of-care summary as C-CDA. Replacing every mature interface is rarely the immediate goal. A platform should identify the source model, preserve provenance, and use the standard that fits the permitted workflow.
More FinchNode interoperability guides
- What we learned building patient-authorized FHIR connections across EHRs.
- SMART on FHIR OAuth with PKCE in React and Node.js.
- Fetch patient data with a FHIR API: Patient, labs, conditions, and medications.
- Epic and MyChart FHIR integration for patient-facing applications.
- Oracle Health FHIR integration: discovery, authorization, and tenant routing.
- How to normalize FHIR data across EHRs without losing the source.
Frequently asked questions
What is the difference between FHIR and C-CDA?
FHIR commonly exchanges granular resources and Bundles, while C-CDA exchanges a clinical document containing narrative and structured sections.
Which standard is best for patient-authorized access?
FHIR with SMART authorization is usually the appropriate modern starting point when the source supports the needed patient-facing resources and scopes.
Can one normalized API combine all three?
A platform can normalize selected concepts from multiple standards, but it must retain source provenance and cannot guarantee identical coverage or semantics.