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). CCDs 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 CCDs 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 (CCDs) 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, CCDs are designed to transfer this data from one provider to another without any loss of meaning.

To maximize interoperability, CCDs 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 CCDs 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.