CDA to FHIR

CDA to FHIR Conversion

Healthcare runs on legacy formats long after the new ones arrive. CDA documents (Continuity of Care, Discharge Summary, Referral) still flow through hospital networks. Converting them to FHIR resources is a well-defined pipeline, with the converted resources landing in Fire Arrow alongside a Provenance record that points back to the source document.

How it works

  1. 1
    Receive the CDA document

    Inbound document arrives over the network (Direct, IHE XCA, or a custom transport).

  2. 2
    Validate and parse

    Document validated against the CDA template; structured sections extracted.

  3. 3
    Map to FHIR resources

    Sections converted to Patient, Practitioner, Encounter, Condition, MedicationStatement, AllergyIntolerance, and DocumentReference.

  4. 4
    Write to Fire Arrow with Provenance

    Resources written through the standard FHIR write API; a Provenance resource links the FHIR resources back to the source CDA document.

Who this is for

Integration teams handling document-based exchange (HISP networks, hospital-to-hospital referrals) that need to surface CDA content in a FHIR-backed application.

Converter component

The converter is a separate service that reads CDA, produces FHIR Bundles, and writes them through Fire Arrow's FHIR API. It runs under a service identity scoped to the resource types it produces.

Open-source converters (such as those maintained by the FHIR community) cover the common CDA templates (CCDA Continuity of Care, Discharge Summary, Referral). Custom templates require additional mapping; the architecture is the same.

Provenance and source documents

Each Bundle written to Fire Arrow includes a Provenance resource referencing the source DocumentReference (which holds the original CDA, optionally with the binary attachment). Reviewers can trace any converted resource back to its source.

Conflicts (the same patient appearing in multiple inbound documents) are resolved at the Patient level through MPI logic, which typically lives in the converter or a separate identity-resolution service.

FAQ

Do I need a separate CDA converter or does Fire Arrow do this directly?

A separate converter handles CDA parsing and mapping. Fire Arrow stores the resulting FHIR resources. Keeping the converter separate means the Fire Arrow runtime stays focused on FHIR; the converter handles the format-specific work.

What about consolidated CDA (C-CDA)?

C-CDA is the most common CDA flavor in US deployments. Standard converters handle C-CDA templates; custom or international templates may require additional mapping.

How do I handle large attachments (PDFs, images) in the source CDA?

Attachments are typically stored separately (object storage) and referenced from a DocumentReference resource in Fire Arrow. The CDA-to-FHIR converter extracts the attachments during parsing.