Translating CDA to FHIR

Clinical Document Architecture (CDA) is a common HL7 standard, based on XML, which is used for exactly what its name says: to exchange general clinical data. CDAs could include documents like discharge summaries, visit summaries, or other documents with a patient’s history or treatment. 

Generally, there are two ways to retrieve a CDA:

  1. Retrieve the embedded XML document with the DocumentReference resource.
  2. (Recommended) Retrieve discrete data from the XML document by translating CDA to FHIR® with the Composition resource.

Not supported with data on demand

You can retrieve an embedded XML document with data on demand, but we don’t currently support translating CDA to FHIR® with data on demand. Learn more about what’s supported with data on demand.

Supported for clinical networks

You can also retrieve CDA documents using either method from a clinical network like the Carequality Interoperability Framework. Sometimes Carequality may only return embedded files and not support retrieving discrete data; in this case, we return a DocumentReference payload instead of a FHIR® bundle (option #1). If the discrete data is available, we can support retrieving and translating CDAs from the clinical network just like with a direct connection (option #2).

With the Redox FHIR® API, you can retrieve discrete data (option #2) in a consistent, modern way.

Who needs CDA translation

Redox can benefit customers on any side of the CDA data exchange, including: 

  • healthcare organizations establishing a new patient’s history before providing treatment; 
  • health tech vendors consuming patient data for service within their app; 
  • payers wanting data for member engagement to recommend preventative care or more cost-effective services; or
  • payers tracking a patient’s treatments for billing purposes (e.g., services included in a hospital stay). 

How it works

For health tech vendors: Typically, either you or your connection sends CDA documents to a Redox FHIR® endpoint for translation, then we return a FHIR® bundle of resources to your system, or to a cloud for storage (e.g., Google Cloud FHIR® server). However, this isn’t supported with data on demand. 

For healthcare organizations: You can send CDA documents to a Redox FHIR® endpoint for translation and we return a FHIR® bundle of resources to your system. Alternatively, you can retrieve CDA data from a FHIR® cloud vendor first, and then we translate the CDA data to FHIR® afterwards.

Either way, Redox API actions allow you to retrieve clinical data from healthcare organizations or clinical networks. Our FHIR® API returns a bundle of resources (30+ possible) with the normalized data so that you can accomplish your own unique workflow.

Data mapping

We convert CDA sections to a bundle of the best-fitting FHIR® resources. Check out some examples below.

CDA section
FHIR® resource(s)
Allergies
AllergyIntolerance
Assessment
Health conditions
Problems
Reason for visit
Resolved problems
Condition
Discharge medications
Medications
MedicationRequest and/or MedicationStatement
Family history
FamilyHistory
Functional status
Observation and SupplyRequest
Health concerns
Condition
Insurances
Coverage
MedicalEquipment
DeviceRequest
Results
DiagnosticReport
Vital signs
Observation

Ultimately, Redox converts CDA-specific aspects into FHIR® standards while retaining accuracy. See some general examples you may come across in most FHIR® resources: 

General CDA data
FHIR® field or value
Notes
nullFlavor
data-absent-reason extension
There may be sections of a CDA document that use nullFlavor. Refer to these guides for more details: (a) Section 5.1.5 of this CDA companion guide; or (b) Section 3.6 of this CDA implementation guide.
We convert this to a data absent reason in FHIR®. 
Terminology Object IDs (OIDs)
FHIR® terminology
We use the OID from the codeSystem and/or implied valueset of a coded value in CDA and use that to look up the appropriate FHIR® Terminology system. Review FHIR® Terminology.
patientRole
Reference to Patient resource
CDAs must include the patient info, which translates into a FHIR® reference to the related Patient resource. For example, ClinicalDocument.recordTarget.patientRole would translate to AllergyIntolerance.patient.
effectiveTime
Any of these: (a) date; ; (b) dateTime; (c) instant; (d) period; (e) onsetDateTime
Different FHIR® resources have different expressions of time, all depending on the context. So the effectiveTime converts to the most applicable FHIR® time field.
section.entry.id
Relevant FHIR® resource
The CDA section identifier helps us to map the data within that section to the most appropriate FHIR® resource. For example, if the section.code=48765-2 then we map the data to the AllergyIntolerance resource.

FHIR mappings

If you want to get more into the weeds, you can check out HL7's recommended mappings for individual resources. As an example, review the recommended mappings for AllergyIntolerance. We don't always follow every recommendation, but it can at least give you an idea of how FHIR® mapping can work.