CDA FHIR mapping

Question

I am trying to add support for sidecar applications in EHR platforms. I am taking a pure implementer's approach to build an intermediate representation (such as an XML) for mapping CDA<--->FHIR. I am using the smart-on-fhir as the reference implementation for this. The CDA I am trying to use is the Australian extension - ereferral (www.digitalhealth.gov.au/implementation-resources/clinical-documents/EP-0936-2012/NEHTA-0967-2012).

Is it possible to create such an intermediate representation using the smart-on-fhir (or any other FHIR) reference implementation? Has anyone else tried this?

While searching for actual implementations I came across these repos:

• github.com/jmandel/sample_ccdas
• github.com/amida-tech/fhir2ccda
• github.com/amida-tech/cda-fhir

The FHIR group has some hand crafted examples. Are there any equivalent CDA examples for these FHIR resources?

I have read couple of web articles and white paper documents regarding the challenges between the transforms, such as:

• David Hay's blog says "FHIR document is that it is like an object graph, rooted in the composition resource", so is their an equivalent representation for CDA?
• Rene Spronk's article about whether HL7 v3 is a message or a document. What are the implications for an implementer who has to handle and validate representations across both CDA and FHIR
• Lantana Group position paper - "If or when FHIR can accommodate the full CDA use case, the future holds the promise of seamless integration and information sharing between clinical documents and APIs". Does this mean that CDA<--->FHIR transform is not possible at this stage of the FHIR standard?

Apologies for cross posting it in both SO and FHIR community forums: http://community.fhir.org/t/cda-fhir-mapping-implementations/211/1

Answer 1

CDA to FHIR is fairly straightforward and it looks like you've already found some repositories that do that.

FHIR to CDA is also fairly straightforward - assuming all you care about is something that is valid. You may need to adjust those libraries for use in the AU/NZ locales.

That said - Keith Boone has some blog posts about some of the challenges in mapping between the two, as there will always be quirks.

The biggest hurdle you will have is loss of fidelity. A CDA (at least a C-CDA here in the states) comes with so much HL7v3 cruft that by turning it into FHIR, you're instantly not going to be able to re-create the original C-CDA from FHIR. The CCD template has evolved so much that you find documents that contain C32 elements, C-CDA 1.1 templateIds, and maybe someday C-CDA 2.1 templateIds. So while you can reasonably make a valid C-CDA out a FHIR bundle, you will have to pick a specific implementation and version to target.

My startup https://www.redoxengine.com has a JSON version of CDA that yo can see on the docs page. It's designed for simplicity, but can be mapped back and forth to FHIR resources.