What is C-CDA®?

C-CDA® stands for Consolidated Clinical Document Architecture. It’s the most widely used format for health information exchange in the US today. 

Each patient encounter in the healthcare system can be represented by a single document in the Clinical Document Architecture (CDA®) style. Hundreds of these documents can be generated for an individual when they encounter the healthcare system. C-CDA® is a slightly newer standard that established stricter rules for the structure, encoding, and semantics of clinical documents of CDA® documents to make them more exchangeable. 

C-CDA® has been one of the default export formats for all certified EHRs - that is, US EHRs that comply with the Promoting Interoperability Programs standard - since 2014’s Meaningful Use Stage 2 requirements. 

While C-CDA® is being phased out in favor of the next generation FHIR® standard, its widespread availability makes it a key part of health IT.

What’s Contained Within a C-CDA® Document?

C-CDA® documents are generally represented in XML. They can include structured information like a medication list. They’re also good at capturing unstructured information, like images.

C-CDA® is generally read-only (although the information can be parsed and uploaded elsewhere with some effort). It’s a library of templates, and can encompass information from a single point in time to an aggregation of one’s medical history.

C-CDA® is also known for popularizing the Continuity of Care Document (CCD®). CCD®s are documents that give a snapshot of a patient’s health record in C-CDA® format. 

In reality, many CDA® and C-CDA® documents are limited in scope. There are plenty of documents under CDA® for specific use cases. For instance, a Discharge Summary is limited to information about the release of a patient from care.

While the specification doesn't define the transport mechanism for communication, the mechanisms for the communication of clinical documents are defined in a hierarchy of specifications. At Particle, the networks we communicate with have built upon the framework outlined by IHE International.

In some ways, C-CDA® is a victim of its own success. Older CCD®s can go on for pages and pages, requiring something like Particle’s data transformation platform to convert information from CDA® to FHIR® which can then be searched in a more programmatic way. Even shorter documents benefit from a transformation to FHIR®, a JSON-language standard, which makes it manageable to use the valuable data in C-CDA® records at scale.

There are a bunch of other C-CDA® document types, such as procedure notes, diagnostic imaging reports, and discharge summaries. The majority of the documents that Particle receives (and providers generate) are progress notes, also known as subsequent evaluation notes, with a smattering of summary of episode notes.

What is CDA®?

Since C-CDA® is a consolidation, what is it consolidating? An earlier push towards interoperability started with Clinical Document Architecture (CDA®), a markup standard for electronic clinical documents which was first released in 2000.

Like C-CDA®, CDA® documents are XML-encoded templates that contain information, which allowed for greater flexibility than the rigid standards of its time. CDA® is object-oriented, allowing it to make use of classes, associations, and inheritance.

Different CDA® documents share common elements, or templates. The same Family History template is shared across documents like Consultation Notes, History & Physical, and Continuity of Care Documents. These standardized building blocks of CDA® are what allow it to fulfill most medical record needs. 

In addition, CDA® documents are semantically interoperable, meaning that they use an agreed-upon standardized set of medical terms - a common feature of other data formats today. 

CDA® is supposed to be human readable and machine queryable; however, many documents in the wild do not quite achieve this standard. 

CDA® eventually became known for having many different variations, which made documents in this style difficult to exchange. Different standards bodies had conflicting interpretations of the CDA® format, making it difficult to benefit from would-be improvements. By 2012, multiple CDA® variations - HL7 CDA®, IHE, HITSP and more - were consolidated into C-CDA®.

What Can Be Found In A CCD Document?

Continuity of Care Documents (CCD®s) are used to support handoffs from one clinician to another. They capture what health standards organization HL7® calls a “snapshot in time” - a standardized summary of the relevant clinical data for a specific patient. Although clinician notes can be imprecise, CCD®s are designed to transfer this data from one provider to another without any loss of meaning.

To maximize interoperability, CCD®s are composed of constraints (or templates) that are used in other CDA® documents. A CCD® that meets federal Meaningful Use standards must include fields including:

These fields are not necessarily filled out to completion every time. At Particle, we help our users aggregate CCD®s from different sources to create a more complete patient overview.

Limitations of C-CDA®

Many developers report that C-CDA® is difficult to work with. 

In fact, most EHRs don’t actually store information in the CDA® or C-CDA ®format. These formats were designed to facilitate record exchange, not data storage. EHRs typically convert information into C-CDA® documents once requested, which leads to compatibility issues.

C-CDA documents can be extensive, sometimes over 200 pages long. Programmatically searching within documents is difficult, and must be done on the client side. For example, you can't request only a patient's medications from the EMR server under the C-CDA® paradigm - you have to request all records and then try to parse out the important information yourself. 

Particle’s API solves this problem by converting from C-CDA® to FHIR®, but C-CDA’s lack of support for the needs of modern digital health platforms is making the standard obsolete.

From C-CDA to FHIR, a Next Generation Standard

A newer format, FHIR®, has caught on in response to the limitations of C-CDA®. FHIR® also makes it easier to select and query specific data elements, like a medication list, without downloading an entire health record. Since C-CDA® requires additional steps to connect data with digital health infrastructure, it’s less suitable for modern digital health needs.

For new healthcare data implementations, FHIR® is generally the format of choice. Much like how C-CDA® achieved widespread adoption as a result of federal interoperability policy, FHIR® is required for the next wave of nationwide interoperability programs.

Particle’s API lets healthcare organizations query for patient data that’s pre-parsed and mapped to the right FHIR®-based resources. While our API supports this for both C-CDA® and FHIR® documents, FHIR® is the more usable enterprise format. 

Check out Particle’s related resources for information on FHIR vs. C-CDA®, and the important things about FHIR®, to learn more.

C-CDA®’s Important Legacy

C-CDA® normalized the format of data exports from EHRs. In this way, it paved the way for more advanced interoperability standards. Since all American EHRs are expected to export C-CDA® data, you could say that it’s a successful example of healthcare’s digital transformation towards full interoperability.

C-CDA® clearly has staying power. While it’s being phased out over time, if you’re working in health IT, C-CDA® will remain part of your ABCs!

‍

Reporting was contributed by Sam Hoffman from Particle's developer readme.