Translating CDA to FHIR

Last updated: Sep 26, 2023
HEALTH TECH VENDOR
PRODUCT OWNER
HCO

Clinical Document Architecture (CDA) is a common HL7 standard, based on XML. It's used for exactly what its name suggests: 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: 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, we don't support CDA translation like this with data on demand.

For healthcare organizations: You send CDA documents to a Redox FHIR® endpoint for translation. 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 into 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 maintaining 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 value set of a coded value in CDA 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 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.