FHIR® (pronounced “fire”) which stands for Fast Health Interoperability Resources, is an interoperability standard for healthcare data developed by HL7® . FHIR has gained a lot of momentum in a very short time because it is simple to understand and is based on modern technologies. Unlike many of the previous standards in the industry, FHIR is very easy implement for most developers even with limited understanding of healthcare domain. There are a lot of articles available that discuss how FHIR can handle healthcare interoperability issues. However, there is very little information (if any) on how FHIR could help with data reporting requirement programs such as MIPS. In this article, I will use a simple scenario to demonstrate how FHIR could really simplify MIPS and other reporting requirements.
HL7® and FHIR® are registered trademarks of Health Level Seven International.
Understanding FHIR With a Quality Measure Example
I will use the MIPS Quality Measure 130 (NQF#0419): "Documentation of Current Medications in the Medical Record" as an example but it can apply to any measure. I chose this measure for a number of reasons.
First, this measure supports all submission methods for MIPS. That helps to connect it to all scenarios for quality data exchange.
Second, the requirements for this measure are easy to understand. This measure requires providers to maintain an accurate and complete medications list for their patients.
Last, but not the least, this is an encounter-based measure that makes calculations a little more complicated.Once you have handled the complicated one, the rest become easy.
Encounter-based measures differ from patient-based measures in the way that encounter-based measures are scored for every encounter during the reporting period and not just unique patients.
Data Elements of Quality Score Calculation
To simplify things, we can say that there are two data elements that will need to be exchanged to calculate the quality score for the MIPS Quality Measure 130:
Encounter details for the encounters during the reporting period
A method to show that documentation of medication was done during a particular encounter. This can be done in one of the two ways:
Add a specific G code (G8427) to a claim. G codes are specific codes for specific measures used to calculate quality score by CMS. There is also a G code available (G8430) to claim an exclusion for this measure.
The second way would be to add a “Procedure Entry” to a CCDA or a QRDA I (explained below). There is a particular code (428191000124101) for the procedure of documenting medications. Most EHRs add this code to the documentation behind the scenes based on some action by the provider.
Don’t get confused by the word “Procedure” here. “Procedure” is used to denote a lot of data in healthcare besides a surgical procedure. In this example, it is simply referring to the act of documentation but it can be extended to any clinical concept.
Current Options for EHR Data Exchange
There are mostly four different ways today in which data for a quality measure can be exchanged by an EHR:
Claims allow coders to automatically or manually populate CMS Form 1500 or 837P with the requisite data. As discussed above, G code are exchanged using claims.
QRDA III provides the aggregated data for a quality measure. In our example, a data exchange through a QRDA III will contain the total number of encounters that a provider had during a reporting period (denominator) and the number of encounters during which the provider completed the requirements for medication documentation (numerator). QRDA III also provides some stratification of those aggregate numbers based on criteria such as gender, race, ethnicity and payers. However, QRDA III provides no information about a specific patient.
QRDA I, in contrast to QRDA III, is a patient level data exchange format. QRDA I contains all the data that is required to calculate a particular quality measure. In the example above, if we need to exchange data via QRDA I, we will need to provide a QRDA I file for every patient that had an encounter during the reporting period. Each of those files will contain data for the encounters for that patient. If medications were documented during an encounter, it will also contain a "procedure" as defined above in that encounter. QRDA I also contains additional patient data that may be required for stratification. So, QRDA I provide a lot more data than a QRDA III. However, a QRDA I contains ONLY the clinical data required for calculating the quality measure for which it was created.
CCDA is the probably the best understood out of all the options. CCDA is a document standard that contains certain data elements about a particular patient at a particular time for a particular purpose (e.g. transfer of care). Unlike a QRDA I, CCDA data elements are not filtered by a particular reporting requirement. However, the data elements that are included in a CCDA could vary depending on the clinical context for which the CCDA was created.
Now, if you look closely, you would notice a common pattern in the four exchange methods. All the methods are based on exchanging a "document" containing health information created for a specific purpose. This really limits the utility and the reliability of the data of these document based standards beyond what they were originally created for. This has been the biggest struggle in achieving true interoperability in healthcare. Even when we solve the issue of exchange of data, the 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 or QRDA I, FHIR works with very granular data referred to as “resources”. A resource in FHIR refers to a single data element. To continue our example above, FHIR considers an encounter and a procedure as resources. 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 completed, a FHIR based EHR will create two new “resources” - an encounter and a procedure in a FHIR repository. Each of these resources will have all the relevant details about themselves. The EHR could also create a Claims resource (with the G code). EHR will also create other resources such as problems, medications but let’s keep the focus on our example. 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”. Both the encounter and procedure resources created above will have a “reference” to the patient resource. The procedure 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 sample available as open source and this makes it really simple to implement FHIR.
“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 encounter resources to calculate the denominator. We can then get a list of procedure resources where a particular procedure code (428191000124101) was used and is referenced by one of the encounters to calculate our numerator. However, the key here is the extensibility of the data that has been collected at a granular level. If a new measure is released by CMS tomorrow that requires providers to check a particular medication or a particular problem in addition to the documentation procedure code, we can still do that with the same data. 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 future.
We just focused on a very simple scenario for a quality measure to illustrate the point. The opportunities on the clinical side for FHIR are endless. That is why there is so much excitement about 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 and QRDA I. You can very easily create these documents on the fly from a FHIR instance by connecting multiple resources through references.
FHIR Can Minimize Workflow Disruption and Make MIPS Reporting Easy
We all have heard stories of providers having to check multiple boxes just to meet the Meaningful Use requirements and then have to check more boxes to meet the Quality reporting requirements. If implemented properly, FHIR can significantly improve the EHR workflow by capturing the right information at the point of care with minimal disruption to the workflow. As part of the 2015 Edition Certification, EHRs will need to support a set of public API standards. Although, it is recommended to use FHIR for those, it is not a requirement. We strongly believe that FHIR is the way to go and hope most EHRs will adopt this standard. MIPS reporting is just a start, the benefits of FHIR will go far.
