Transitioning from CDA to FHIR
CDA documents became a core part of the national exchange framework in the US over a decade ago. However successful, CDA as a clinical document standard cannot fit every possible data element within the document paradigm. CDA is bound to the HL7 V3 development methodology, which is complicated and difficult to implement.
FHIR, HL7’s latest standard, supports the document paradigm without document restrictions. FHIR includes a RESTful API out of the box, as well as alternate syntaxes (i.e., XML and JSON). The industry will need transition strategies for those invested heavily in CDA while new implementers move directly to FHIR.
A Use Case for HIEs
Let’s say you are part of an HIE with a heterogenous environment where participants invested heavily in CDA-based infrastructures over the past decade. These participants will want to preserve that investment and maximize value. Other participants new to the HIE or HIT exchange will likely see FHIR as a cheaper/faster way to exchange clinical data.
With a well-tested transition/transformation infrastructure, the HIE can satisfy the needs of both types of participants. Each participant can use the standard/syntax of their choice; and bi-directional transforms are the bridge between them.
If the HIE maintains the transition infrastructure, those with a CDA investment can create and receive CDA documents for existing use cases and choose between CDA and FHIR for new use cases. Where CDA content is converted to FHIR, new implementers will have large amounts of new and historical data to consume without an investment in outdated HL7 V3-based technologies. They can use the transformation infrastructure to convert FHIR to CDA in compliance with existing regulations.
Of course, the success of the transition plan depends on consensus over the set of data and transforms. A logical starting point for coded data is US-Core for Data Interoperability (USCDI). The data classes in USCDI have CDA and FHIR implementations based on the Common Clinical Dataset as well as Clinical Notes and Provenance.
The C-CDA on FHIR specification uses the document paradigm across both CDA and FHIR for consistency. C-CDA on FHIR is a US-Realm specification that addresses the C-CDA use case with FHIR as the document syntax (i.e., XML or JSON). C-CDA on FHIR addresses the ongoing need to exchange clinical documents without the HL7 Version 3 methodology. Simple issues (e.g., simple datatypes, off the shelf XML tools) became road-blocks for many implementers, who burned budget implementing CDA basics before hitting major challenges such as terminology mapping. FHIR makes simple problems simple again, so implementers can focus on the truly hard problems in HIT.
C-CDA on FHIR simplifies clinical document implementation by using FHIR as the core syntax and reusing USCDI as the data layer to reduce user burden. USCDI does not yet cover all coded data for C-CDA. Recent updates cover the 80% most essential for clinical document exchanges. Implementers with specific needs should submit comments to the US Core team (via HL7 gForge, select US Core as the specification when submitting a new tracker item) to prioritize data elements.
FHIR makes simple problems simple again, so implementers can focus on the truly hard problems in HIT.
In Production Today
One proven strategy creates dual CDA/FHIR implementation guides based on C-CDA and C-CDA on FHIR, paired with transforms between the two IG syntaxes. The ONC High Impact Pilot (ONC-HIP) grant for creating Pharmacist Care Plan documents is an example.
This project created three key tools for the public domain:
- CDA (Clinical Document Architecture) and FHIR® (Fast Health Interoperable Resources) implementation guides (IGs) for PhCPs
- Library of bi-directional transformations written in XSLT that converts between PhCP FHIR and PhCP CDA
- In-person training and materials about PhCP FHIR and PhCP CDA for implementers at ONC
To our knowledge, this was the first dual CDA/FHIR IG project that demonstrates a viable pathway for CDA/FHIR integration and transition planning.
The initial plan was to train to Pharmacy Management System vendors on both IGs and instruct them to submit data to Community Care of North Carolina (CCNC) for processing. CCNC assumed those using FHIR would use the FHIR to CDA transform and submit CDA data. By the time the pilot ended, the team had trained 22 vendors. In the process, CCNC reversed course and decided to receive data in FHIR, because most vendors had no prior investment in CDA.
During implementation, the CDA to FHIR transform converted CDA data to FHIR. Vendors with existing CDA implementations used the CDA-based IG. Vendors without existing standards support used the FHIR IG due to the shallow learning curve and modern technologies.
The project started production over a year ago. The National Community Pharmacists Association (NCPA) is updating the CDA and FHIR IGs for FHIR Release 4, which HL7 will release as a Standard for Trial Use (STU) in mid-2019. In the meantime, various HL7 workgroups have created other dual CDA/FHIR IGs, including electronic case reporting and healthcare-associated infection reporting.
The PhCP project limited the CDA to FHIR transforms to CDA templates and FHIR profiles in the care plan document type; however, it covers a substantial portion of Consolidated CDA. Many implementers have used the open source transforms to cover individual use cases.
The PhCP open source transforms are far from the only option for transforming CDA content into FHIR. In recent years, many participants in the FHIR Documents track at the FHIR Connectathon demonstrated C-CDA to FHIR transformation using a variety of products and techniques. For implementers, the issue is identifying reliable mappings rather than converting the data.
HL7 launched the C-CDA to FHIR mapping project in May 2018 to create HL7-sanctioned mappings between C-CDA and FHIR. These mappings will use FHIR Mapping Language. The project will refine the mapping language and its tooling as well as the CDA Logical Model for FHIR. HL7 scheduled project completion of initial work by September 2019.
HL7 must update US Core and C-CDA on FHIR from FHIR R3 to support FHIR R4. C-CDA on FHIR and many other FHIR IGs rely on US Core. C-CDA on FHIR will also need profiles beyond US Core for high priority C-CDA templates not covered by the USCDA data classes.
The Road Ahead
The industry will need to deal with both CDA and FHIR for the near future. In the short term, dual CDA/FHIR IGs with well defined mappings are a good approach. In the future, when the C-CDA to FHIR mapping project is complete, HL7 will launch a sanctioned approach to improve consistency and broaden support for FHIR Mapping Language. The transition from CDA to FHIR will not be easy or short; however, the right tools and strategies will make it viable for most implementers.