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.

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

Who needs to translate CDA to FHIR®

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.

Which CDA sections can Redox translate

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

CDA section
FHIR® resource(s)
Health conditions
Reason for visit
Resolved problems
Discharge medications
MedicationRequest and/or MedicationStatement
Family history
Functional status
Observation and SupplyRequest
Health concerns
Vital signs

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
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.
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.
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.
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.