Understanding C-CDA & FHIR Data Structures
Modern medical records are quite complex. This blog article will delve into how a medical record is structured under specifically the C-CDA (HL7 v3) and FHIR (HL7 v4) structures in detail, how they are meant to be structured, and differences in practice versus reality. In short, FHIR (HL7 v4) is meant to be a more flexible, next generation method of structuring healthcare data for transferring from one place to another to replace HL7 v3.
Storage vs. Transfer
Before we get started, it is worth noting that while the international Health Level Seven (HL7) organization specifies how to transfer healthcare data, it does not specify how it should be stored or rendered. That means that while hospital A may transfer data to hospital B in an HL7-specified manner, it does not mean that both need to store that data or present that data to users in the same way.
XML C-CDA (HL7 v3)
C-CDA stands for Consolidated Clinical Document Architecture. It’s the most dominant structured electronic format at present, though it is not the most recent.
C-CDA files are most commonly represented by a:
*.XML 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:
Fake data shown in a C-CDA 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
An 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.
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 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 Contents 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 XML files, and fewer are capable of processing the 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.
FHIR HL7 R4
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 larger 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:
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:
Partial data structure for a Patient Resource
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.