C-CDA

C-CDA, explained: the standard everyone exchanges but few can use

C-CDA is how clinical documents move between systems. It was built for exchange, not computation, and that gap is where most projects stall.

Curiflow·June 22, 2026·5 min read

C-CDA, short for Consolidated Clinical Document Architecture, is the format most US health systems use to send a summary of a visit to another system. If you have ever seen a "Continuity of Care Document" move between two hospitals, that was C-CDA.

It is everywhere because it was mandated: certified electronic health records must be able to produce and consume it. That makes it the closest thing healthcare has to a universal document. The catch is what the format was designed to do.

The core issue

C-CDA was built for exchange, so one system can show a document to a human, not for computation, where software reads specific facts. The structured, coded entries inside are largely optional, and the human-readable narrative is what most systems actually fill in reliably.

How a C-CDA is built

A C-CDA is an XML document built on the older HL7 CDA R2 standard. It has a header (patient, author, encounter metadata) and a body split into sections, Problems, Medications, Results, Allergies, Encounters, and more. Each section is identified by a templateId and carries two layers side by side: a human-readable narrative block, and machine-readable coded entries.

Example: one Problems section, two layers

The narrative is what a clinician sees. The entry underneath is what software is supposed to read, if it is present and correct.

<section>
  <templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>
  <title>PROBLEMS</title>
  <!-- narrative: what a human reads -->
  <text>Type 2 diabetes mellitus</text>
  <!-- entry: what software reads -->
  <entry>
    <observation>
      <value code="44054006"
             codeSystem="2.16.840.1.113883.6.96"
             displayName="Type 2 diabetes mellitus"/>
    </observation>
  </entry>
</section>

That codeSystem OID is SNOMED CT, and 44054006 is its concept for type 2 diabetes. Note what is missing: no ICD-10 code, no mention of the chronic kidney disease that would change the billing code, and no link to the encounter it belongs to. A downstream system that needs E11.22 has to derive it.

Why a valid C-CDA can still be unusable

Three things break in practice:

Entries are optional. Many real documents carry a rich narrative and a nearly empty entry layer, so the coded data you need is simply not there.
Narrative and entries drift. The text lists a medication the entries never mention, or an entry says "active" while the note says "resolved." You have to decide which to trust, per field.
Vendors template differently. The same Problems section is nested three different ways across three EHRs, so a parser tuned to one breaks on the next.

A C-CDA tells you a visit happened. It rarely tells you, in computable form, exactly what was decided.

A second example: a medication that does not reconcile

Say the narrative reads "metformin 1000 mg BID, lisinopril discontinued," but the coded Medications entries list only metformin, with no dose and no mention of the stopped lisinopril. Three facts a downstream workflow needs, the dose, the frequency, and the discontinuation, live only in the prose. Pull the entries alone and you ship an incomplete, slightly wrong medication list.

What Curiflow does with it

Curiflow treats a C-CDA the same way it treats a fax or a scan: as a document to be understood, not just parsed. It reads both the narrative and the coded entries, reconciles conflicts between them, resolves each value to the standard code the downstream job needs (ICD-10, SNOMED, RxNorm, LOINC), and ties every field back to the exact span it came from. What you get back is a typed, cited record, not another document to reconcile by hand.

Convert anything to FHIR.

NHance turns eFaxes, PDFs, CCDA, and CSVs into clean, structured, FHIR-ready data in under 3 minutes, not 3 months. HIPAA and SOC 2 compliant.

Try for free →Request a demo