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:
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.
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.
Redox can benefit customers on any side of the CDA data exchange, including:
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.
We convert CDA sections to a bundle of the best-fitting FHIR® resources. Check out some examples below.
Reason for visit
MedicationRequest and/or MedicationStatement
Observation and SupplyRequest
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
There may be sections of a CDA document that use
We convert this to a data absent reason in FHIR®.
Terminology Object IDs (OIDs)
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,
Any of these: (a)
Different FHIR® resources have different expressions of time, all depending on the context. So the
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
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.