C-CDA vs FHIR is a choice between a whole document and separate pieces of data. A C-CDA file is one XML document with required sections, built for systems that exchange complete records. FHIR stores each problem, medication or result as its own resource. For extracted clinical data, FHIR is usually the easier target unless the receiver requires a document.
C-CDA documents and FHIR resources compared
A C-CDA document is one XML file: a header about the patient, author and encounter, then a body of sections, each with readable narrative and, where the template requires it, coded entries. FHIR breaks the same content into resources such as Condition, MedicationStatement and Observation, each addressable on its own, which can be gathered into a document when needed.
The Consolidated CDA implementation guide describes C-CDA as a library of CDA templates developed by HL7, and says it adheres to the CDA Release 2.0 standard. The current published version on hl7.org is 5.0.0. Templates are the heart of it: a document template says which sections a document must have, a section template says what each section holds, and entry templates define the coded data inside.
The FHIR R4 comparison with CDA sets out the main differences. CDA relies on templates to understand the meaning of instances, while in FHIR meaning is defined by the resource. In CDA, narrative exists for each section, while in FHIR narrative exists for the resources at the root of each section. CDA has its own XML narrative markup loosely based on HTML, and FHIR uses a constrained set of XHTML. CDA linkages can only occur at the level of a section or a couple of entry types, so moving from FHIR to CDA can lose detail.
The comparison for one fictional discharge summary
Take a made-up discharge summary for a made-up patient, Morgan Example, discharged on 2026-09-02 (example). The table compares what each format would require.
| Aspect | C-CDA Discharge Summary | FHIR |
|---|---|---|
| Structure | One XML document: header plus structured body of sections | Separate resources, optionally gathered in a document Bundle led by a Composition |
| Required sections | Allergies, hospital course, discharge diagnosis, plan of treatment, hospital consultations, procedures and results | None in the base resources; only a Composition profile can set them |
| Narrative | Required readable text in each section | Narrative on each resource; a document collates it in order |
| Coded data | Entry templates inside sections | Resources such as Condition, AllergyIntolerance, Observation |
| Validation tools | ONC's SITE C-CDA validators | FHIR validators and US Core profiles; ONC's Inferno for certified APIs |
| Typical receivers | EHRs exchanging transition-of-care documents | EHR FHIR APIs, apps and data services |
The required sections come from the C-CDA 5.0.0 Discharge Summary template definition, which lists them as required and the discharge medications section as recommended. The validation tools are covered in the last section of this post.
C-CDA sections that match extracted clinical fields
Five C-CDA sections line up with fields commonly read from clinical paperwork: problems, medications, allergies and intolerances, vital signs and results. Each section holds human-readable text plus coded entries, so a field read from a page fills an entry and also appears in the section's narrative.
The section names map cleanly onto extracted data:
| Extracted field (example) | C-CDA section | Closest FHIR resource |
|---|---|---|
| Problem list entry "Hypertension" | Problem section | Condition |
| Medication "Lisinopril 10 mg daily" | Medications section | MedicationStatement or MedicationRequest |
| Allergy "Penicillin, rash" | Allergies and intolerances section | AllergyIntolerance |
| Blood pressure 128/82 | Vital signs section | Observation |
| Potassium 4.1 mmol/L | Results section | Observation inside a DiagnosticReport |
All values in the table are examples, not data about any person.
The narrative-plus-entries design has a consequence for extracted data. A C-CDA section is expected to say the same thing twice: once as readable text and once as coded entries. If a field was read from the page but could not be coded, it can still appear in the narrative, but the entry is missing, and a receiving system that imports only entries will not see it.
Empty sections need care too. The C-CDA Results Section template says that if the section's nullFlavor is not present, it shall contain at least one Result Organizer, and that if a required section contains no information, its nullFlavor may be set to NI. A discharge summary with no lab results on the page still needs a results section, marked as having no information.
Turning a free-text note into a clean problem list or medication list is a task of its own, covered in the guide to problem list extraction from charts. For a discharge summary specifically, the fields worth reading are listed in discharge summary extraction.
Which C-CDA document types fit discharge summaries and notes?
C-CDA defines a document type for each common clinical note. A discharge summary maps to the Discharge Summary template, a visit note to the Progress Note template, and a record that pulls together a patient's key facts to the Continuity of Care Document, or CCD. Scanned paperwork that cannot be structured can go in an Unstructured Document.
The C-CDA guide lists the document types: Care Plan, Consultation Note, Continuity of Care Document, Discharge Summary, History and Physical, Operative Note, Procedure Note, Progress Note, Referral Note, Transfer Summary and Unstructured Document. Each is a template with its own section rules.
The section rules differ a lot between types, and that drives the choice:
- Discharge Summary. The template definition requires seven sections and describes the document as one that synopsizes a patient's admission and provides information for the continuation of care after discharge.
- Continuity of Care Document. The CCD template definition requires allergies, medications, problems, results, social history and vital signs sections, and describes the CCD as a core data set of the most relevant administrative, demographic and clinical facts about a patient's care.
- Progress Note. The Progress Note template definition lists sections such as assessment, plan of treatment, problems, results and vital signs, all optional, which makes it the most forgiving target for a partial note.
A discharge summary read from paper should usually become a Discharge Summary document, because that is what the receiving clinician expects to open. But if the page leaves out hospital consultations or procedures, the document still needs those sections, each marked as having no information. A Progress Note does not carry that burden, though calling a discharge summary a progress note misleads the reader.
Schema Care reads discharge summaries into diagnoses, procedures, medications and follow-up instructions, scores each one, and routes uncertain fields to a reviewer. Schema Care offers no API, SDK, webhooks, FHIR output, 835 output or 837 output, and it generates no C-CDA documents; any document or resource would be built by your own code from the reviewed fields.
Can a FHIR Composition replace a C-CDA document?
A FHIR Composition can carry the same content as a C-CDA document: a header, ordered sections and narrative, with coded data held in referenced resources. Whether it can replace one depends on the receiver. A system that only imports C-CDA files will not accept a FHIR document, however complete it is.
The FHIR R4 documents page defines a FHIR document as a Bundle of type document whose first resource is a Composition, which sets the document's identity, context and sections. The bundle holds the Composition and the resources it references. Once assembled, a document is immutable, and the Composition's attester attests to its presented form. The page also says applications should present the narrative in order: the subject's, then the Composition's, then each section's, which gives a reader the same top-to-bottom view a C-CDA viewer would.
HL7 publishes a bridge between the two, though it is narrower than its name suggests. The C-CDA on FHIR implementation guide, version 2.0.0, contains mapping guidance for creating FHIR resources from C-CDA documents, built on US Core 6.1.0. It says earlier versions included FHIR profiles on the Composition resource for each C-CDA document type, that this content has not been updated and is partly outdated, and that those profiles remain only in the older STU 1.1 release. Its next release aims to reintroduce them. Until then, a team that wants a FHIR stand-in for a C-CDA document has no current HL7 Composition profile per document type to validate against, which is one more reason to ask the receiver first.
The CDA comparison page also notes that FHIR can exchange traditional CDA R2 documents through the DocumentReference resource. That gives a third option: build the C-CDA file the receiver wants, and use a FHIR DocumentReference to index and deliver it. Choosing between a Composition and discrete resources for each kind of paperwork is the subject of the guide to which FHIR resources match each medical document type.
In short, a Composition is a full document format on its own terms. It replaces C-CDA only where the receiver accepts it, so the check is to ask the receiver which document format it imports.
When not to build C-CDA from extracted data
Skip C-CDA when the receiver can take discrete data another way, when the source pages are partial, or when you cannot validate the output. A C-CDA document has to meet its template's section and entry rules, and a document built from incomplete paperwork may fail validation or, worse, pass while implying a record is complete.
Validation is the first cost. ONC's conformance test tools page lists the SITE C-CDA and USCDI validators, with base standards that include C-CDA Release 2.1 and its Companion Guide Release 4.1. Those are older than the 5.0.0 guide now current on hl7.org, so find out which version your receiver checks against before you build. The same page lists the Inferno framework for testing certified FHIR APIs against US Core 6.1.0 and FHIR R4.
Partial records are the second cost. A scanned discharge summary may be missing a page, or a section may be illegible. Required sections must still appear, and a section marked as having no information tells the receiver the source had none, which may not be true. In FHIR, you can send only the resources you read and leave the rest out.
Uncertain fields are the third cost. A value the extraction was unsure of should be confirmed by a person before it becomes a coded entry, because a receiver importing entries treats each one as fact. In a C-CDA document, an unconfirmed value is also repeated in the narrative, so a correction later means rebuilding and resending the whole document rather than updating one resource.
Other signals that C-CDA is the wrong target:
- The receiver wants one field type. If a registry only needs problem list entries, send those as discrete data, not a full document.
- No clinician authored it. A clinical document reads as something a clinician wrote. Data assembled by software from a scan should not look like a new note from the care team.
- The data is financial. Claim and payment data have their own X12 formats, and clinical document templates are not built for them. Remittance files are covered in X12 835 parsing, and building claim files in X12 837 generation.
When C-CDA is required, keep the original scan with it, for example as an Unstructured Document or through a DocumentReference, so a reader can check any section against its source page. The document types Schema Care reads include discharge summaries and medical records, but the document assembly described here is outside what it does.