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.
Ultimately, Redox converts CDA-specific aspects into FHIR® standards while retaining accuracy. See some examples below:
nulloption in CDA. There may be sections of a CDA document that are populated with
null. We convert this to a data absent reason in FHIR®.