Health data is valuable currency for enhancing patient care within health settings. To support easy information transfer, standards organizations like Health Level Seven (HL7) have dedicated considerable effort towards a common standard for communicating health information. HL7 is responsible for developing and maintaining some of healthcare’s most valuable data standards, with the Consolidated Clinical Document Architecture (C-CDA) — the most widely used standard for healthcare data exchange — and Fast Healthcare Interoperability Resources (FHIR), being notable innovations.
In a 2018 report, the C-CDA was recognized for supporting the exchange of 500 million documents annually. FHIR follows closely behind in widespread usage: in 2019, 84% of hospitals and 61% of clinicians adopted API technology enabled with FHIR.
With no questions as to popularity, in this guide we’ll be focusing on how C-CDA and FHIR compare and contrast to promote interoperability and enhanced care.
While the C-CDA is often referenced as a data exchange standard, this isn’t entirely correct. The Consolidated Clinical Data Architecture is more of a framework of templates and specifications for the Clinical Document Architecture (CDA). It became necessary to build on top of the CDA because while this standard further revolutionized healthcare interoperability resources, it also made exchanging documents a complex, and often inefficient process.
For a little background on the CDA — developers will remember that this standard permits every patient encounter from test results, vital signs, and progress notes — to be represented by a single document. Now while that made for detailed record keeping, it also built up an extensive amount of data for every patient on record.
Also, while CDA operates on standardized, and agreed to medical terms, what could have been an easy exchange of these documents turns complex due to its many variations. Before the introduction of the C-CDA, CDA documents were available in different versions like the HL7 CDA, IHE, HITSP. These data formats were consolidated into the C-CDA for easier data exchange.
Through the C-CDA, or more accurately — the Continuity of Care Documents (CCDs) which gave a snapshot into a patient’s record in C-CDA format — interoperability became easier for healthcare players. The Consolidated CDA implementation guides provide best practices and guidance for creating clinical documents, and also specify data elements to be included in each section of the clinical document.
C-CDA are widely represented in XML, and are suitable for capturing unstructured information like images.
Without picking favorites, FHIR has been carefully designed to be a faster, cheaper, and above all more modern upgrade to the C-CDA.
For starters, FHIR is a darling of developers. This standard is based on resources — building blocks of health information that contain standardized and exchangeable data elements. FHIR resources are simple and encourage human readability. This granular representation shortens the learning curve, making data extraction and manipulation easier. FHIR also adopts modern web standards like JSON and a RESTful API approach.
Since its release in 2014, FHIR profiles have gone through two stages of advancements. In 2019, a normative version of this standard — HL7 FHIR R4, ensured backward compatibility so continuous data exchange can take place between newer and older forms of this standard. In 2020, the Department of Health and Human Services, Centers for Medicare and Medicaid Services (CMS), and the Office of the National Coordinator published two rules mandating the use of FHIR APIs for healthcare data exchange.
The good thing about FHIR and CCDA is that they’re playing for the same team: healthcare interoperability. To reach this goal, both players have adopted a few similar tactics. For instance, both the FHIR and C-CDA assist with the Cures Act Anti-Information Blocking compliance to prevent common restrictions to the free flow of electronic health information. These healthcare data standards also support structured and unstructured input.
Likewise, just as FHIR is an open-source project, the C-CDA also has its specifications, standards, and related resources available for public use. Despite these similarities, however, contrasts between both HL7 standards make all the difference in how they simplify access to patient data.
As mentioned, FHIR makes use of modern, open web technologies like JSON plus RDF data formats, compared to the C-CDA’s XML-based languages, these lightweight approaches, plus easy-to-use technologies simplify FHIR implementation for developers. FHIR takes the best advancements from previous HL7 standards like HL7 V2, HL7 V3, and CDA to remodel the exchange between information systems. Because this standard adopts granular data elements, healthcare providers can access information on a specific part of healthcare like medication and past observations.
Compared to C-CDA, which employs a document-centric approach, simply querying an electronic health record for a patient’s allergies might require sifting through hundreds of patient data.
FHIR reflects modern times and needs. This standard permits real-time data exchange and access via mobile apps, telehealth, and other use cases. The C-CDA is more suitable for bulk data transfers, like continuity of care documents and clinical summaries.
Specific exchange needs, existing systems, regulatory requirements, and long-term goals are just some of the factors to bear in mind when configuring health information systems.
However, as the world shifts to modern, web-based approaches, the chosen structure should be future-proof, and sure to improve patient engagement.
Metriport's API supports FHIR specifications, plus C-CDA and PDF formats. Learn more about how we're enhancing clinical accuracy and improving patient care outcomes.
Get the latest updates and blog posts from the Metriport team.
