Hi, I’m Darrell Woelk, Chief Technology Officer for Green Room Technologies. We’re a firm that specializes in business viability for health tech companies through market and technology readiness. Recent U.S. government regulations require healthcare organizations and insurance companies to make patient data available through a FHIR API.
Having been involved with fire standards since 2014, my role at Green Room is to help our clients understand how to leverage FHIR and other standards for both data exchange and creating new business opportunities. I’m going to use this diagram to talk about some of the problems caused by a lack of healthcare data interoperability in the past and then how FHIR is helping to solve those problems today.
I used examples of three healthcare organizations in the diagram: a hospital where I recently had surgery, a clinic on the left where my dermatologist practices and finally health information exchange at the bottom. The top of the diagram we have me on the left and my doctor on the right.
The EHR vendors in this example — Cerner and Epic — have each provided a web portal where my doctor and I can access my patient records but as shown by the gray lines here my data was only available through the software portal provided by that specific EHR vendor. My doctor or I could view my data on the screen but only software provided by that specific vendor could analyze my data.
And similar problems existed with the insurance industry. My medical claims were only available to me through software provided by the insurance company.
At the bottom of the diagram then there’s a need to transfer patient data from healthcare organizations to another or to insurance companies. This would be done in the past by FAX , proprietary data formats, or by digital messages or digitized documents that conform to earlier HL7 standards. Health information exchanges were created to improve the sharing of data but it was very complex.
So the problem at the top you can see in the red circles is that both myself and my doctor have at least four different portals that I have to interact with to see my data. And then I cannot have third-party software to act on that data once I have viewed it.
So how does FHIR solve these problems? First the government regulations require that my doctor and I have access to my patient data in the FHIR format and rather than requiring me to use the portal software from the EHR vendors I can give permission to a third-party app to access my data. That third-party app just refers to the fact that the app was not developed and marketed by Cerner or Epic in this example but created separately by a separate organization. These third-party apps then comply with things like SMART on FHIR or CDS Hooks protocols that allow me to authenticate who I am, authorize the third party app to work on my behalf — similar to what you do when you use Facebook to log into a third-party app.
For example, my doctor and I can view my lab results in an app in my iPhone where my data can a copy of my data can reside. And the government regulations also require that third party apps have access to my claims data from my health insurance provider. And government regulations will also require that FIHR in the future be used to exchange data among health care providers and health care payers.
So you can see that FHIR will have a big impact on interoperability.
So how do we get these standards I’m talking about? We start out with industry standard organizations at the bottom here. HL7 is the standards organization that created the base FHIR standards. Each of these organizations is creating base standards in a certain area of healthcare. We then have FHIR Accelerator projects that create FIHR implementation guides for specific use cases.
For example, the Da Vinci project started a couple of years ago to create implementation guides for exchanging data between health care providers and healthcare payers such as insurance companies. We also have a FHIR at Scale Task Force. This task force is investigating the scalability of FHIR deployment. As you can see by the diagrams if we begin to have me having access to my FHIR data across the country and having analytics come software accessing my data can be very complex and requires scalability.
By the time the U.S. government agencies get around to actually defining the regulations, hundreds of healthcare organizations standards organizations vendors have created, designed, implemented, and tested the FHIR based solutions. The two government organizations you need to know about ONC – the Office of the National Coordinator – which coordinates exchange of healthcare data is more of a technology organization. CMS administers Medicare Medicaid CHIP and insurance marketplaces. So CMS is putting pressure on the EHR vendors and the insurance companies to make the data available to the patients.
Back up a minute and talk about the scope of FHIR. The FHIR standard itself is very broad. It covers three dimensions. The y-axis is the content such as structured clinical data, text in the form of clinical notes, and a broad variety of types of data. The x-axis has the FHIR API functions. The z-axis are the use cases such as provider to provider and provider to payer etc.
What’s the scope of the ONC and CMS rules as they exist today?
A very small subset of FHIR capability is covered as I show in the little red cube at the bottom the left of this. Very specifically current EHR’s certification requirements only cover the content in the USCDI. Only reading of a subset of healthcare data is covered at this point and then the use cases are fairly restricted.
Let’s talk a minute about the architecture of FHIR applications. EHR vendors have built a FHIR facade on top of their existing systems so they map the data in their unique databases into the FHIR data model and then they make it accessible to applications over a rest API which follows the industry standards for rest APIs.
I can write a JavaScript app that uses the FHIR rest API to access the FHIR data in Epic or Cerner. SMART on FHIR is a set of protocols that allow me to authenticate and authorize a third-party app to act on my behalf as I mentioned previously.
CDS Hooks is for clinical decision support so I can register a module FHIR application to execute at some specific point in a workflow in the healthcare organization, for example when a provider is doing a prescription to check for interactions with other drugs. Finally, a FHIR bulk access API.
There is a SMART on FHIR app gallery where you can write your SMART on FHIR app and register it in that gallery so that people can use it and try it out in a sandbox FHIR database. Each of the vendors below also have their own app galleries where I can list my app. Once I have completed the app I can get it certified then with Epic or Cerner or some of the other EHR vendors.
Most of the common programming languages are covered with a FHIR library so you can write your applications in many different languages. The lower left hand corner of the diagram are public test FHIR servers. There are 29 reference servers out there that are accessible to the various applications for testing. Many of those public FHIR servers have been turned into commercial FHIR servers by companies like Health Samurai, 1upHealth, and Smile CDR.
Also the big tech companies – Google, Microsoft and IBM have implemented FHIR databases servers that are now available. Then finally the health insurance companies have I put a facade of FHIR API on top of their systems.
Let’s say a few words about the FHIR accelerator projects. There are six primary ones and they’re being added every so often. This is our original diagram. The Argonaut project was the first FHIR accelerator project started four or five years ago, and it focuses on HER patient data. The EHR vendors got together and decided along with the government, what are the most important data to be from their databases to make available to me and my doctor. SMART on FHIR CDS is part of that standard. The Argonaut Project then defines the implementation guides for that.
The CARIN alliance Project focuses on getting payer claims data to me as a consumer. The lower right- hand corner of the Da Vinci Project focuses on exchanging data between payors, insurance companies, and EHRs.
Then there are three other projects. The Gravity project that focuses on social determinants of health. The Codex project on cancer data and the Vulcan project on clinical research and clinical trials data. You can see each of these FHIR accelerator projects then are working on implementation guides which eventually may become government regulations.
I’m excited about what’s happening with this FHIR ecosystem. If you’re in the healthcare industry, Green Room can help you understand the impact of this evolving ecosystem on the future viability of your business. We specialize in technology readiness, market readiness, and funding readiness to help you make sure you’ve got the right product in the right market and funded properly.
Contact me today and if you’re interested and let’s talk about how Green Room can help you FHIR up your business.
