This article will compare how a medical record is structured under the HL7 C-CDA (v3, Consolidated Clinical Document Architecture) and HL7 FHIR (v4, Fast Healthcare Interoperability Resources) standards in detail. To review them individually, see our blogs on C-CDA and FHIR.

To summarize in advance:

Both are formats describe how medical data is transmitted, but are not meant to be the method by which information is persistently stored.
Both were created by the Health Level 7 International: This is a committee that defines electronic medical data standards. HL7 FHIR R4 is meant to be the long-term replacement of HL7 C-CDA R3. HL7 C-CDA is still presently far more common for transmission, but FHIR is heavily used within facilities. Both have significantly improved healthcare interoperability.
FHIR is capable of representing any health data; C-CDA is not. C-CDA is far more narrow in being largely meant for patient summaries only. FHIR is capable of medical device data exchange, scheduling, and billing just to name a few.
There are transmitted differently: C-CDA is meant to be exchanged via file transfer (e.g. SFTP) or via custom network-defined API structure. FHIR is meant to be only transmitted via API payload in a method that has been defined by HL7.
FHIR is fully backwards compatible a FHIR message can wrap a C-CDA for transmission. A C-CDA cannot hold a FHIR message, making it not forward compatible. A C-CDA is also not backwards compatible as it is not capable of ADT messaging. FHIR is capable of ADT messaging on its own, and can wrap ADT messages.
Conversion between the two is difficult partially due to the previous bullet, but also because FHIR is capable of handling so many more data elements, whereas CCDA is structured very differently. Tenasol is capable of product offerings here if interested.

C-CDA (HL7 v3)

C-CDA files are most commonly represented by a:

*.XML or *.JSON file extension when stored as an individual file
*.ZIP file extension when there are multiple files present.

A C-CDA XML looks like the following:

Structure of a CCDA file — Fake data shown in a C-CDA CCD XML file

An XML will typically contain the following sections. Each of the following sections also contains an unstructured section that is used for HTML rendering of the record, and is also sometimes referenced by structured entries as in the case of practitioner notes:

Problems
Medications
Allergies, Adverse Reactions, Alerts
Immunizations
Results
Encounters
Procedures
Social History
Plan of Care
Family History
Advance Directives
Functional Status

Nested C-CDA Data

A CCDA XML may also contain binarized files, which must be extracted and processed separately. Metadata within the XML may contain information about the binarized attached file. There are a limited number of types of files that can be attached in this manner, generally restricted to PDFs, text files, image files, or videos.

Furthermore, a CCDA (and for that matter, a FHIR message as described in the next section) are capable of having data nested in multiple layers. While relatively uncommon, being able to handle these situations is what sets Tenasol apart from the competition in medical record data extraction. Here is a visual example:

nested CCDA data — A file can contain a file, that contains a file, that contains a file.

ZIP C-CDA (HL7 v3)

A C-CDA is compressed to a single ZIP file when multiple files are present. Inside of this zip file contains a folder labeled “Content,“ and optionally a file named “PackageMetadata.json“

The PackageMetadata.json file behaves as an index file, containing information on the patient as well as the underlying contents, what dates of service, and what practitioners are associated with each.
The Content folder contains any number of files (XML or not) that are often associated with different visits, sources, or perhaps different file types agglomerated together. There is no limit on the number of files that may be in the content folder.

While some technologies are capable of processing just the XML files, and fewer are capable of processing some attached files, we at Tenasol believe we are the only technology capable of extracting all information, from all the underlying files, as well as linking the information back to the information in the metadata file.

HL7 FHIR

With the rise in use and heavy standardization of the Application Programming Interface (API), HL7 needed to adapt its model to also communicate in this way with varying amounts of data rather than entire medical records. The Fast Healthcare Interoperability Resource (FHIR) was the answer to this to further modernize the C-CDA format. FHIR files are of the JSON file extension when stored by default, as opposed to XML by default.

FHIR in increasingly being used inside of smaller healthcare ecosystems, but still is an extremely uncommon exchange method between facilities.

It allows for more fractionalization of healthcare data - a device within a hospital can use the FHIR specification to send data to a computer. That computer can send a medical record to another hospital using FHIR. A front desk worker can even send a FHIR message containing patient scheduling information.

FHIR has pre-designed information types called “Resources“ (a full list may be seen here). A group of Resources is called a Bundle Resource, which is the most common resource type:

Structure of an HL7 FHIR JSON including the unstructured areas

A FHIR Bundle, shown above can contain multiple Resources. It may even contain information on multiple patients. Resources can reference each other. Here we show two encounters and a goal that reference other resources.

Similar to C-CDA, FHIR files can contain alternative file types. The DocumentReference Resource type performs this, and can contain any serializable data type, an improvement on the C-CDA carrying capacity. Furthermore, FHIR Resource standards are predefined, and further extensible by choice than what is immediately shown in the documention:

FHIR Resource structure — Partial data structure for a Patient Resource

Because of the massive difference in structure, it is quite difficult to convert a C-CDA to a FHIR representation or vice versa even if both are patient record representations. While tools exist to do this, they will always result in some data loss as result of the conversion.

Converting FHIR to C-CDA and C-CDA to FHIR

See our larger blog on converting medical record filetypes here.

Conclusion

The evolution from C-CDA (HL7 v3) to HL7 FHIR R4 represents a pivotal shift in healthcare information technology, emphasizing the importance of standardization and interoperability. FHIR's adoption signifies a move towards a more connected and efficient healthcare system, enabling seamless data exchange across diverse platforms and stakeholders.

It is important however to know that this shift will still take time, and therefore systems should be compatible with both, making the most of all data where possible. Please reach out to us if you have any questions or comments on this report.

C-CDA vs FHIR HL7 Data Standards