C-CDA — Consolidated Clinical Document Architecture — packages a patient's clinical story as a single structured XML document: problems, medications, allergies, results, immunizations, and encounters bundled together. It is the format used to exchange clinical summaries between electronic health record (EHR) systems, especially at transitions of care such as a referral or discharge, and the ability to produce and consume it is a requirement in US health-IT certification programs.
C-CDA predates FHIR, and it survives precisely because the established document-exchange networks — Carequality, eHealth Exchange, and Direct secure messaging — all speak it fluently. So even as new integrations reach for FHIR APIs, a telemedicine product that needs a patient's history from another organization will often receive it as a C-CDA document rather than as discrete API resources.
The engineering reality is that parsing C-CDA is notoriously uneven across sources. The standard allows considerable variation, and different EHRs populate sections and codes differently, so a parser that works perfectly against one vendor's output can choke on another's. The practical guidance is to treat inbound documents as semi-structured: extract what you can reliably, validate the clinically important fields (allergies and active medications above all) rather than trusting them blindly, and surface the original document to a clinician when machine extraction is uncertain. The common mistake is building a strict parser to the spec and assuming real-world documents will conform — they often will not, and a missed allergy is a patient-safety failure, not a formatting bug.
