Particle supports two primary health data formats: FHIR and C-CDA. C-CDA is an older standard that many developers find challenging to work with due to its complexity and limitations. FHIR, by contrast, is a modern health data standard widely regarded as more intuitive and developer-friendly.

Below is a deeper give into these data formats and their underlying organization, HL7.

HL7

HL7 (Health Level Seven International) is a global non-profit organization that defines standards for healthcare data exchange and interoperability. They developed both the C-CDA and FHIR standards, among others (HL7 v2, HL7 v3).

C-CDA

C-CDA stands for Consolidated Clinical Document Architecture that builds on the older CDA (Clinical Document Architecture) standard, designed to represent healthcare data as structured documents. Each patient encounter with the healthcare system can generate a CDA document, leading to potentially hundreds of them over a patient's lifetime navigating the healthcare system. Note that there is a 'potential' to generate hundreds of these documents because most EMRs store data in a non-document-based way and only output documents when request. With the newer C-CDA standard, HL7 established stricter rules for the structure, encoding and semantics of CDA documents to make them more easily exchangeable. The Continuity of Care Documents (CCDs) are documents that give a snapshot of a patient's health record in a C-CDA format.

Key Characteristics of C-CDA:

Human Readable and Machine Queryable: Although intended for dual usability, real-world implementations often fail to achieve this.
Interoperability Challenges: Sharing C-CDA documents between EMRs can be problematic due to inconsistent implementations and document complexity.
Extensive and Lengthy: Documents can span hundreds of pages, making them cumbersome to work with.
Data Parsing: Developers must handle document parsing client-side, as C-CDA lacks granular query support. For example, retrieving only a patient's medication from the EMR record is not possible; you must fetch the entire document and parse it to obtain medication data.

Common Use Cases:

Continuity of Care Documents (CCDs): Summarize a patient's health record in C-CDA format.
Document Types: Include procedure notes, diagnostic imaging reports, discharge summaries, and more. However, most C-CDA documents Particle receives are evaluation or episode summaries.

Technical Details:

Format: Represented in XML.
API Paradigm: SOAP based. Downloadable from Particle via REST.

FHIR

FHIR stands for Fast Healthcare Interoperability Resources. It is the modern standard from HL7, designed to address the limitations of older standards like C-CDA. It provides a streamlined, developer-friendly framework for exchanging healthcare data electronically. 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.

Key Advantages of FHIR:

Resource Based Structure:
- Data is divided into discrete, reusable components called resources (e.g. Medications, Immunizations, Encounters). For a full list of FHIR resources, click here.
- Each resource includes: 1) A standard definition and structure, 2) A set of metadata, and 3) A human-readable component.
Server-Side Querying: Developers can request specific data (e.g. only medications or encounters) without fetching the entire patient record. This is a significant improvement over C-CDA.
Future-Proof: FHIR is the industry standard, driven by both adoption and regulation.

Technical Details:

Format: Typically JSON, though could be represented in XML.
API Paradigm: REST based.

How does Particle handle these data formats?

Particle receives C-CDA documents when querying the networks for a patient's data. Please note that Particle receives other document formats (e.g. PDFs, PNGs, JPEGs) but does not conduct any data transformation of this data currently.

For customers requesting data in C-CDA format, Particle directly passes on the retrieved documents.

For customers requesting data in FHIR format, Particle converts the patient's C-CDA records to FHIR, and then stores them in Particle's FHIR store where they may be queried for via FHIR operations.

By supporting both the C-CDA and FHIR data formats, Particle bridges the gap between legacy and modern interoperability standards.

C-CDA vs. FHIR Summary

	C-CDA	FHIR
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 completed in 12 mins → 95% are completed 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 (e.g., medications) they need → Previously worked with healthcare data (especially JSON based FHIR)

Technical Specifications

	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