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:
- Retrieve the embedded XML document with the DocumentReference resource.
- (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.
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).
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.
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. |