# 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.

[Production-grade access is free with an account.](https://finchnode.com/signup) The $0/month plan includes 100 connected patient-months, 100,000 production API calls per month, one production application, and an unlimited synthetic sandbox.

- Author: [FinchNode Engineering](https://finchnode.com/authors/finchnode-engineering)

- Published: 2026-08-25

- Last reviewed: 2026-08-25

- Canonical URL: https://finchnode.com/blog/fhir-vs-hl7-v2-vs-ccda

- Evidence boundary: Uses published HL7 specifications and implementation guides. Product availability still depends on the participating systems and contracts.

## 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.

## Compare the integration unit, not only the syntax

A workflow-oriented comparison of three healthcare interoperability standards

| 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.

### Primary sources

- [FHIR R4 specification](https://hl7.org/fhir/R4/)
- [C-CDA on FHIR mapping guide](https://hl7.org/fhir/us/ccda/)
- [HL7 standards overview](https://www.hl7.org/implement/standards/)

## Frequently asked questions

### 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.

### 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.