C-CDA vs FHIR Documents: Which to Keep When Migrating EHR Data?

C-CDA vs FHIR Documents: Which to Keep When Migrating EHR Data?

When a US practice migrates EHR systems, the clinical-document question shows up faster than most teams expect. Years of C-CDA documents sit in the old system. The new system speaks FHIR fluently and wants FHIR Document Bundles. The migration team has to decide what to keep, what to convert, and what to leave as an archive nobody opens but everyone is legally obliged to retain. The answer is rarely the clean rewrite that the migration kickoff slides imply.

This comparison walks through the C-CDA versus FHIR document decision for US practices in the middle of an EHR migration. The cornerstone context lives in FHIR terminology servers vs EHR vocabularies for Da Vinci workflows, and the operational form-builder companion piece is in cloud-hosted vs self-hosted FHIR form builders for US specialty practices. The wider series sits at more on healthcare data exchange.

What Each Format Actually Is

A C-CDA document is a self-contained XML payload with structured sections (allergies, medications, problems, results, vital signs, encounters) and a human-readable narrative for each. It is a snapshot, signed, and immutable by convention. The format is well understood by US EHRs and underpins most of the document traffic on existing HIE infrastructure.

A FHIR Document Bundle is a FHIR-native version of the same idea. The Bundle has a Composition resource at the top, structured FHIR resources for each section's data, and the human-readable narrative attached where the spec asks for it. The data is queryable, the references are followable, and the resources can be re-used outside the document context.

The two are not equivalent. They overlap, and the overlap is where the migration decisions actually happen.

The Argument for Keeping C-CDA

C-CDA documents are legally meaningful objects with a clean chain of custody. They were signed at a point in time, they are immutable, and they survive system migrations without needing reinterpretation. For US practices subject to long retention requirements, keeping the original C-CDA archive is the safe legal posture.

C-CDA is also the format most external HIE traffic still flows in. Even after the practice migrates to a FHIR-first EHR, the documents arriving from referring providers, hospitals, and labs are mostly going to keep arriving as C-CDA for the foreseeable future. Throwing away the C-CDA handling on the new platform is a choice that will look short-sighted within two years.

The Argument for Converting to FHIR Documents

FHIR Document Bundles are queryable in a way that C-CDA documents fundamentally are not. A clinical-quality measure that needs to scan five years of allergies across the patient population can do that against FHIR resources at scale. The same query against a C-CDA archive requires re-parsing every document on every run.

Modern integration engines like Interbox use hash-based diffing that chooses PUT vs PATCH vs skip on each write, which makes the conversion from a stream of incoming C-CDA documents into a normalized FHIR store much cheaper to keep current. The conversion is no longer a one-time migration cost; it becomes part of the steady-state document-ingestion pipeline.

The Hybrid Path Most US Practices Actually Take

Most practices end up keeping both. The C-CDA archive stays intact as the legal record. A FHIR projection of the same content sits next to it as the queryable, queryable-at-scale operational copy. Every new C-CDA arriving from external sources is both archived and converted; every FHIR document the practice produces internally can be exported to C-CDA on demand for HIE traffic.

The hybrid path costs more in storage and in pipeline engineering. It is also the only path that holds up against both the legal retention requirements and the operational analytics demands US practices face in 2026.

How to Pick for a Specific Migration

If the practice has the engineering capacity to keep both, keep both. If not, keep the C-CDA archive and run conversion on-demand against the subset of documents that operational queries actually need. Throwing away the C-CDA archive in favor of a one-time conversion is the choice that looks clean on a migration plan and produces multi-year regret in the field.

Sources

  • HL7 Confluence - CDA R2.1 migration discussion (forward/backward compatibility for archives)