C-CDA vs. FHIR

Particle supports two major health data formats: FHIR and C-CDA. At the most basic level, C-CDA is an older health data format that many developers report is hard to work with, and FHIR is a newer health data standard that many developers find much easier to work with.

HL7

HL7 is a multinational nonprofit organization that defines interoperability and messaging standards for the healthcare industry. They are responsible for both the C-CDA and FHIR standards, as well as other healthcare standards.

C-CDA

C-CDA stands for Consolidated Clinical Document Architecture. It's built on top of the Clinical Document Architecture (CDA) standard, where each patient encounter with the healthcare system could be represented by a single document. Hundreds of these documents might be generated for an individual in their course of navigating the healthcare system. (We say "could be" because most EMRs store data in a non-document-based way and only output documents when requested.) CDA is an older standard with many variations; documents in this style may be hard to exchange. CDA is supposed to be human-readable and machine queryable; however, many documents in the wild do not quite achieve this standard.

C-CDA is a slightly newer standard that established stricter rules for the structure, encoding, and semantics of CDA documents to make them more exchangeable. Continuity of Care Documents (CCDs) are documents that give a snapshot of all of a patient’s health records in Consolidated Clinical Document Architecture (C-CDA) format.

CDA and C-CDA documents definitely have some limitations. They can be extensive and lengthy, sometimes over 200 pages long. Interoperability between different EMRs is still not perfect, therefore sharing these documents across healthcare systems can be difficult. Programmatically searching within CDA and C-CDA style 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.

There are many different types of CDA documents (like procedure notes, diagnostic imaging reports, discharge summaries, etc.), but the majority of the documents we receive are subsequent evaluation notes, with a smattering of summarization of episode notes.

C-CDA documents are generally represented in XML and use the SOAP API paradigm.

FHIR

FHIR stands for Fast Healthcare Interoperability Resources. It's the newest HL7 standard for exchanging healthcare information electronically. This standard is meant to address the limitations of C-CDA. The standard covers not only the data format that should be exchanged between EMR servers but also details of how FHIR servers themselves should be structured. Developers generally find working with FHIR to be significantly easier than working with C-CDA, and FHIR is definitely (both through momentum and law) the health data standard of the future.

FHIR is resource-based, meaning that the individual components of FHIR (called resources) are meant to be exchanged. The components of a resource include: (1) A common way to define and represent the resource itself, (2) A common set of metadata, and (3) A human-readable part. Resource types include medications, immunizations, encounters, etc. (There are lots of other resources — if you'd really like, you can check them out here.)

FHIR enables server-side querying. That is, you can request to only have certain parts of a patient's medical record sent to you (i.e. medications only, encounters only, etc.). Particle requests all parts of a patient's FHIR record and puts them in our FHIR store, which enables users of the data to request only the specific parts they need.

FHIR data generally comes in JSON format (although it could be represented in XML), and uses the REST API paradigm.

How does Particle handle these data types?

Particle generally receives only C-CDA documents when we make queries. For queries requesting C-CDA, we directly pass on the documents that we receive. For queries requesting FHIR, we use a ✨magic process✨ to convert all of a patient's C-CDA records to FHIR, then add the data to our FHIR store where it can be queried with FHIR operations.

C-CDA vs. FHIR Summary

C-CDA (Consolidated Clinical Document Architecture)

FHIR (Fast Healthcare Interoperability Resources)

Exchanges Full Clinical Records

Yes

Yes

Easy Extraction of Specific Data Points

No — specialized parsing needed to extract individual data points

Yes — easy to search and separate every aspect of patient encounters

Time to Return Data from Initial Query

2–3 minutes.
A long tail of 10 minutes

10 minutes.
A long tail of 20 minutes

Best For Organizations That

→ Need data quickly
→ Prefer to receive all individual data files
→ Already have a CDA-compatible system

→ Can query for data before it’s needed
→ Know which specific data elements (like medications) they need
→ Previously worked with healthcare data (especially JSON-based FHIR)

Tech Specs

C-CDA

FHIR

Human-Readable Output

Yes

Yes

Data Formats

XML (primarily); PDFs + PNGs also occur

JSON

API Paradigm

Downloadable via REST

Follows REST FHIR R4 Spec

Particle Stores Data For

2 days

30 days

Developer Ease of Use

Easy to implement, but harder to parse

More intensive to implement, but easier to parse

Future Compatibility

Being phased out — Particle can transform into FHIR format

Largely codified as new standard

Good To Know

C-CDA

FHIR

Meets Meaningful Use
and Patient Access Standards

Yes

Yes

Date Required in Health IT

2014

2022

Health API and EHR Support

Universal

Sometimes

Regulatory Basis

HITECH Act / Meaningful Use Rule

Cures Act / Anti-Information Blocking Rule / TEFCA

Supported by Particle’s API

Yes

Yes


What’s Next
Did this page help you?