In the previous blog, I had discussed how updating CCDAs is the easiest way to share USCDI data and avoid the $1,000,000 penalty under Information Blocking regulation that is going to take effect in six months (April 5th, 2021). The easiest way may be the quickest way, but is not always the best way to accomplish a goal. The Cures Act ultimately requires you to make the same data available through a FHIR® API. In this blog, we will drill a little deeper on how making this data available through a FHIR® API is a better long-term strategy than simply sharing an updated CCDA.

A CCDA is a structured data document standard that contains certain data elements about a particular patient, at a particular time, for a particular purpose (e.g. transition of care). The data elements included in a CCDA could vary depending on the clinical context for which the CCDA was created. This variation limits the utility and the reliability of the data shared via these document-based standards beyond what they were originally created for. This has always been the biggest struggle in achieving true interoperability in healthcare. Even when we solve the issue of data exchange, the long-term usability of data is always limited by some constraints.

The FHIR® Approach – Resources Connected by Reference

FHIR takes a completely different approach to interoperability. In contrast to the document-level data of CCDA , FHIR works with very granular data referred to as “resources”. A resource in FHIR refers to a single data element. A simple way to understand a resource is to think of them as nouns in healthcare data - Patient, Medication, Encounter, Procedure etc. You can check the list of FHIR resources to gain a better understanding.

When an encounter is documented in an EHR, a FHIR based EHR will create multiple new “resources”. This could include the encounter, one or more conditions (problems), medications, procedures and others based on the encounter. Each of these resources will have all the relevant details about themselves. If this was a new patient, it will also create a new patient resource. All the resources are stored independently in the FHIR repository. FHIR provides a very powerful way to link these resources together through a concept called “reference”. All resources created above will have a “reference” to the patient resource. Additionally, the medication, procedure and the problems will also have a “reference” to the encounter. Although it might sound complicated, this architecture is very common in other industries. There are lots of samples related to this architecture available as open-source, making it very simple to implement FHIR within your EHR.

“The decoupling of data exchange from context is the most important differentiating factor of FHIR.”

Using the FHIR repository, we can now very easily get a list of resources by a particular resource-type or by the patient, based on the requirements. The key here is the extensibility of the data that has been collected at a granular level. We discussed this in detail using quality reporting as an example in a previous blog to show how this can simplify adding new quality measures with minimal effort. The decoupling of data exchange from context is the most important differentiating factor of FHIR. By not predetermining the purpose for exchange, we prepare the data for anything that we might need in the future.

The opportunities for FHIR on the clinical side are endless. That is why there is so much excitement around FHIR. It is important to note that with FHIR you don’t have to give up any of the benefits of the documents-based approaches of CCDA. You can still very easily create these documents on the fly from a FHIR instance by connecting multiple resources through references.

CCDA to FHIR® Crosswalk

We all have heard stories of providers having to check multiple boxes just to meet the Meaningful Use requirements. Those quick fixes never worked well as the number of check-boxes kept increasing to meet the next set of reporting requirements. As we discussed in the previous blog, you can similarly meet the Information Blocking requirements by just updating the CCDA. However, making this data available through a FHIR API can help you meet the requirements for now AND prepare you for future. Both these options are not mutually exclusive. We recognize that this long journey must begin with the first step. To help with this transition, we have started an Open Source Project to help vendors satisfy the required modification to enable your providers to avoid being considered as Information Blockers. This intent for this project is to allow for the migration from CCDA to FHIR® resources well ahead of the deadline and serve as your Information Blocking insurance policy.