Healthcare industry leaders have been talking about FHIR for years. But with the finalization of the CMS and ONC rules, as well as the COVID-19 pandemic, how should healthcare stakeholders be thinking about FHIR now?
In this brief video interview, Austin Dobson, Product Manager, weighs in on FHIR. This interview was conducted with Mark Hagland, Editor in Chief of Healthcare Innovation. Watch the 15-minute video, or read the transcript below.
Mark Hagland:
Much has been said about FHIR. Can you tell us what your definition of FHIR is, and how it fits into the broader landscape of interoperability, especially right now?
Austin Dobson:
That’s a great question. It’s helpful to add that baseline level of context for folks, because FHIR has been thrown around both the healthcare and healthcare interoperability landscape for quite a while now, and sometimes people define it as different things.
FHIR is defined as the Fast Healthcare Interoperability Resources, which is a set of data standards, and the philosophy behind those data standards is basically to build a base set of resources that either by themselves or when combined with other data standards, satisfy the majority of common use cases around healthcare data transactions.
Typically, you have to choose a set of data to transmit and generate a message that contains only that data.
MH:
How should the various stakeholders around the healthcare table be thinking about FHIR in the current context?
AD:
As we talk to our payer, provider, and public health customers, they’re all asking us about FHIR. They’re asking us, “We know we should be adopting FHIR data standards in our organization, but we don’t quite see how yet.”
And one of the big changes recently is the ONC and CMS released a joint rule calling out healthcare interoperability and preventing of information blocking. The rule is designed to first, allow patients access and control of their healthcare data, second, tear down some of those walled gardens and data silos that larger healthcare organizations have accumulated over 20, 30 years of gathering healthcare data, and start empowering the consumer to have ownership over their data.
Providers, payers, and health IT vendors will all have to allow patient access and control of their data, and this must happen via FHIR®r4 standards.
Previously, many of the CMS and ONC rules have indicated you need to execute X transaction. We don’t care the standard in which this transaction is executed in, we don’t care the time it takes for you to execute this said transaction, just do it.
And with these new rules, the ONC and CMS are mandating a standard. As many of these complex organizations are looking to fulfill the goal of allowing a patient’s access, if we can get a uniform manner to allow access, we’re hopeful that it could scale across the entire industry.
MH:
One of the things that perhaps some people don’t fully appreciate is there is complexity, because there are different flavors of FHIR, and as rigorous in certain ways as it is, it’s still a broad standard. Can you just speak to the fact that there are levels of complexity in how one interoperates with FHIR?
AD:
This is one of the things that’s routinely glossed over when people talk about FHIR. People think it’s a one-size-fits-all, plug and play system. There are different versions of these standards: an R3 standard with different resources, and an R4 standard, which is the most up-to-date FHIR standard, with a separate set of resources.
The R4 standard is now normative. It’s backwards compatible, which is going to be a big driver in adoption. Because previously, if you go through all of this effort building an R2 or an R3 FHIR profile — then the HL7 organization releases a new set of FHIR standards, you’re now out of date for much of this FHIR data exchange.
What’s great about R4 is that anyone implementing R4 knows that they will have this baseline set of resources that they will always be able to interoperate on. And as it expands, their standard will still be functional.
MH:
What do hospitals, health systems, and health plans need to have in place in order to use FHIR APIs effectively?
AD:
One of the first things I would point to is the need for translation services between legacy systems, within the four walls of the hospital. Your radiology system, your lab system — all of these ancillary systems within a hospital need to be able to communicate to FHIR, so if you get a new lab result, it breaks the interoperability model if you can’t connect that HL7 V2 message to a FHIR resource. So having the tools for message translation, to interoperate with a FHIR infrastructure and a FHIR server is important.
In more detail, the ability to build FHIR JSON and XML payloads, and send them securely via the REST API, those RESTful communications are a separate set of technical infrastructure that hospitals, that provider organizations, that vendors need to stand up in order to send and receive this data effectively.
Also integration engines can play a critical role in that translation service. Because if you buy a FHIR server off the shelf, you don’t have the ability to make those translations from whatever data standard your systems are on right now, to that FHIR R4 standard, to send out to whatever organizations are requiring that data.
MH:
Nearly all hospital-based organizations in the U.S. have an EHR at this point. You need an electronic health record. However, I think a point of confusion has to do with the fact that so ABC hospital has an EHR, they can’t simply plug in APIs into their existing architecture. How do you frame what the situation is around integrating APIs right now?
AD:
Many of the biggest players in the EMR space are providing a EMR-based FHIR API endpoint for that communication out. That is a great first step that’s going to solve a fairly narrow set of the FHIR use cases for that organization. That out-of-the-box set up is taking care of, I’d say 15 to 20% of FHIR use cases.
To backtrack to the last question, you may have this FHIR API endpoint via Epic, Cerner, Athena, ECW, whatever your EMR is. But that doesn’t allow you to do the transformation from those legacy ancillary systems in the hospital to send it out via FHIR.
If systems that are connecting to your hospital can’t connect via FHIR yet, which as I stated earlier, most organizations are not implementing FHIR standards yet, so they’re still operating in a largely V2, XML, JSON environment. So you need to be able to ingest those messages, convert them to FHIR, to store them and have them work within your FHIR ecosystem. So you still do need that transformation of those legacy and ancillary systems.
Lab systems within the organization need to be able to communicate via HL7. One of the things that people often miss about FHIR, is when I last had interactions with the HL7 organization that builds these FHIR standards, they’re not looking to build resources for 100% of all of the use cases that a hospital will ever experience, because HL7 messages, this push message, is really optimized in many organizations.
They’ve built process around it. They’ve built the infrastructure around it. They have the ability to convert those HL7 messages to FHIR, and that’s much easier than developing a new set of standards around these HL7 messages.
For organizations that retooling the entire kind of messaging infrastructure is infeasible, they need that transformation capability within the hospital.
The EHR traditionally looks at their data as a source of truth, which it absolutely is. But in order to get information into and out of that source of truth, you need transformation in most of the cases.
MH:
What should CIOs, CMIOs, CTOs all the top healthcare IT leaders in hospital-based organizations be doing right now to prepare for the next couple of years?
AD:
Where I would start if I had a C in front of my title, is I’d get familiar with the ONC and CMS rules. I would understand how the implementation timelines of the different federal mandates affect my organization, and understand what technical infrastructure I have at my organization to fulfill it, and understand where there are holes.
Allowing for that patient access is not as easy as going off the shelf and saying, “Hey, this one product provides easy patient access, easy FHIR HL7 transformations.” It’s understanding that technical infrastructure and looking to for future-proof your organization, to both be compliant with some of these large federal mandates, and also unlock some of the business potential that optimizing data transformation, and creating truly interoperable systems offer.
I would try to understand how the healthcare landscape is going to evolve because of these ONC and CMS rules, and make sure I have the infrastructure in place to navigate this industry change successfully.
And one thing I will call out as it relates to the CMS rules, is they’ve made a lot of comments about the app economy that they’re thinking will come out of unlocking this patient data. So if I’m a EMR, if I’m a payer, if I’m a provider organization, I’m going to be thinking critically about — where is the value I’m adding in this supply chain?
Because if the patient now has control over their healthcare data, if I, an empowered consumer can say, “I want to use this third party ancillary application to track my heart arrhythmia, or track my diabetes A1C levels,” it starts to chip away that total ownership that one vendor may have over patients managing their own healthcare and managing their healthcare data.
So I would also be thinking critically about the value my organization offers throughout the life cycle of care delivery.
MH:
Take us forward about two years, and help us understand what you think the policy, regulatory, and operational landscape will be about two years from now.
AD:
The ONC and CMS interoperability and data blocking rules are going to play a big role in this. Not to overstate how important these are, these two departments within HHS have released simultaneous and complementary rules, with complementary implementation timelines to solve this problem of data blocking, and a lack of an interoperable health care system.
We will see a need for better security within healthcare organizations, more consistent data standards, more consistent process around the movement of data inside and outside of organizations.
Also, some of the positives to come out of the COVID-19 crisis as it relates to healthcare IT and infrastructure is the adoption of telemedicine.
The federal government right now is looking at permanently waiving some of the temporarily waived licensure restrictions around who can provide telemedicine visits, and also looking at continuing in perpetuity the reimbursement levels for telemedicine visits, as these were the biggest barriers for telemedicine adoption over the past five years.
With the adoption of greater synchronous and asynchronous, digital communication with your provider, healthcare standards are going to be a really critical part that underpin all of those communications.
You’re not going to be able to fax in your immunization history, your lab history, your radiology history to a telemedicine provider for them to deliver high quality care. We’re going to have to have an interoperable system, in order for all of these changes to come out of COVID-19 across the healthcare landscape, to be fully fulfilled.
MH:
That’s such a great answer and it gives us such insight. I really appreciate it.
For more on this topic, see:
- Blog | FHIR: 3 Real-World Scenarios
- HL7 FHIR Resource Library
- FHIR vs. HL7: We explain the key differences
