The HL7 Consolidated Clinical Document Architecture (C-CDA) is a library of templates that provide patterns for sharing clinician’s notes in a structured way using the HL7 CDA standard.
This collection of templates was developed by harmonizing years of work by multiple standards development organizations to create CDA implementation guides and templates for common clinical documents. Documents such as the history and physical note, consultation note, progress note and operative note are used to exchange medical records between providers, patients and other stakeholders.
These resources have been the mainstay of clinical documentation and communication between providers for generations, focusing on the narrative component of clinical communication. This narrative is vital to conveying each patient’s unique health story, including the nuances that differentiate one patient’s diagnosis and treatment plan from another patient with a similar presentation.
C-CDA documents are valuable to many stakeholders because they are both human-readable and machine-processesable, meaning they combine narrative information with coded data. Machine processable data is critical for data processing between systems. However, the meaning of the data often depends on its context within the human-readable story that encompasses it.
As new interoperability standards are developed, namely Fast Healthcare Interoperability Resources (FHIR®), should organizations abandon all the time and money spent implementing C-CDA documents into their exchange workflows? How can organizations still leverage the work of C-CDA to implement emerging standards?
One might reasonably assume that CDA and FHIR are competing standards, but actually they are cooperating standards. The two share many similarities. When it comes to supporting a document exchange paradigm, they share the same six core principles:
Both standards support profiling for specific use cases and make use of validation and profile tools. And importantly, they both support human readability as a minimum for interoperability.
On the other hand, FHIR differs from CDA in that it is not restricted to representing just documents. Metadata is generated with the specification, which makes it easier for programmers to validate the format of the information. The standard is tightly coupled to application programming interfaces (APIs) that make use of modern RESTful services. (A RESTful API is an efficient way to use http requests to GET, PUT, POST and DELETE data.) The combination of FHIR and REST create lightweight, maintainable and scalable applications that simplify the work of basic data interactions like GET and POST.
The key to ensuring the optimal exchange of clinical documents across traditional and emerging standards is to map elements between the two standards and provide a standards-based reference for interoperability.
Standardized mapping will allow organizations to preserve their investment to support existing C-CDA documents while integrating use of new FHIR documents. The mappings provide a predictable conversion path between the two standards.
Initial work focused on the easy work of mapping C-CDA document-level templates to profiles on FHIR’s composition resource and the sections contained therein. The most challenging work has involved mapping the discrete data models (i.e., details at the entry, element and attribute level) because value sets used in FHIR are not fully aligned with those in C-CDA, and there are other structural and information- representation differences. However, mapping at this level of detail is important for data integrity. Organizations need to be able to trust that they are able to transform documents between the two standards without losing information. These mapping efforts are important to ensure that the quality of the data is maintained regardless of the standard used.
Work is ongoing to map the two standards using Model-Based Transformation Services to facilitate transformations. As FHIR is more widely adopted, this work will continue to progress and hopefully offer opportunities to educate the community on how to make the most of both of these standards for document exchange purposes.
The views and opinions expressed in this blog or by commenters are those of the author and do not necessarily reflect the official policy or position of HIMSS or its affiliates.
Our Health Story Project helps the health IT community tell a patient’s complete health story with tools and resources that aid in creating comprehensive, shareable electronic records—improving care through collaboration and analysis.