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 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	→ Roughly 80% of CCDA queries are completed in 3 mins →90% are completed in 6 mins →95% completed in 10 mins → a progressively small number of queries with large file count can take up to a maximum of 60 mins	→ Roughly 80% are completed in 5 mins → 90% are complete in 12 mins → 95% are complete in 20 mins → a progressively small number of queries with large file count can take up to a maximum of 60 mins
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	30 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