One of the most exciting developments in health IT in the last few years has been HL7's FHIR (pronounced "fire") standard. In a time when most providers are finally using electronic health records, many still lament the challenges associated with interoperability, and FHIR stands out as a potential way of unlocking more efficient sharing of healthcare data.
So what is FHIR exactly? The FHIR specification describes a way of sharing healthcare data. For example, if I wanted to share some basic patient information, FHIR says to structure the data like this:
That's it. Granted all I told you is that the patient's name is Eric Gunther and his identifier is #12345, but one of the important parts of FHIR is that you only have to request and send as much data as you have and/or need. Compare this to some of today's standards such as C-CDA, which have particularly rigid requirements resulting in very large files that are hard to deal with when you only want a small amount of data.
The FHIR standard doesn't just tell you how to format the data, it also specifies how you share the data. FHIR says to share the data using a REST API, which is just a fancy way of saying you should share the data just like we share web pages. You access a FHIR "resource" through a URL, just like you get a web page. Again, using our example from above, you could send a request to https://AzaraFHIRAPI.com/Patient/12345 (not a real link) and you would get back the data we showed above.
The big idea is that we make healthcare data easier to express and access using web technologies that most software developers have become very comfortable with over the past decade.
So what could Azara use FHIR for? A lot, actually, but we're just in the beginning stages of exploring these ideas. One option would be for us to extract data using an EHR's FHIR API (application programming interface), as opposed to building our more traditional, proprietary, connector. The biggest challenge for us in this scenario is data volume; we don't request data one patient at a time, we do bulk pulls because we need data on all patients to satisfy our primarily focus of population health reporting. While FHIR works great for a single-patient-focused application, a population health system like DRVS would need access to FHIR resource "bundles", which are not as widely implemented as accessing data for a single patient. In addition, in order to gather the rich data set Azara requires, EHR’s would need to make a substantial amount of their data accessible via their FHIR API, much more so than most current FHIR API implementations.
Azara could also make the data we have collected available through a FHIR API. Health centers, health plans, HIEs, and other 3rd parties could potentially access the data directly through a FHIR API, as opposed to working with Azara to develop a data extract. This is not something Azara currently offers, but it is something we will be looking at as FHIR becomes widely adopted throughout our customer base. This use case also depends heavily on the ability of FHIR to support the extraction and transfer of bulk data.
Azara could use FHIR for our own internal data interfaces - we've already begun having discussions about using FHIR to handle our terminology services.
CMS has also been investigating using FHIR as the basis for their eCQM clinical quality measurement infrastructure (https://ecqi.healthit.gov/sites/default/files/FHIR-101-Cooking-with-CQL-508.pdf). Several EHR vendors have been working to align with the SMART on FHIR standards (http://docs.smarthealthit.org/). The ONC has established FHIR as the standard for interoperability and has defined a set of Core Data for Interoperability (USCDI - https://www.healthit.gov/isa/us-core-data-interoperability-uscdi).
Clearly, there is a lot of hype around FHIR and momentum continues to grow. We at Azara have not yet used FHIR in a production setting, but we are keeping a close eye on its growth and maturation and are keen to get involved soon. That said, it's important to remember that FHIR is not a panacea for interoperability! FHIR itself is just a standard. We still face the same challenges associated with the adoption of any “industry standard” healthcare technology: non-standardized coding, interpretation and terminologies, unique point of care workflows within the same system, free-text documentation, and other foundational data and workflow variability that remain the same with or without FHIR. Like the standards’ authors, our hope at Azara is that FHIR will allow us to focus on those problems, while easing the technical burden of building the interfaces.