Interoperability: There is FHIR® at the End of the Tunnel
Over the last decade, billions of American tax payer dollars have been spent to achieve “interoperability” in healthcare. Has it worked? The answer depends on who you ask but everyone agrees that still we have a long way to go. In this article, I will discuss how FHIR® might be a definite answer to this billion-dollar question.
Let’s start with defining the "WHY". Why do we care about interoperability?
There are three main goals we are trying to achieve:
Care Coordination
Patient Engagement
Reporting and Research
We have discussed a lot about Care Coordination and Patient Engagement in many of our other blogs. However, Reporting and Research usually don’t get the attention they deserve. The thing is - You can’t improve what you can’t measure, and you can’t measure what you can’t report. In this blog, I would discuss how interoperability can help us create better reporting
HL7® and FHIR® are registered trademarks of Health Level Seven International.
So, why would anyone not want interoperability?
To understand this, we need to discuss the “controllers” of interoperability. Most of the time, this blame has been put on the EHR vendors. However, based on the emphasis on Information Blocking in a recent NPRM for 21st Century Cures Act by ONC, it is obvious that there has been evidence of blocking interoperability at the provider level too.
It begs the question: why would a provider or an EHR vendor not want to help achieve the three above-mentioned goals? In any other industry the answer would be so easy - “The cost doesn’t justify the ROI”. But healthcare is not just any other industry. The ROIs and the costs are not that straightforward. That being said, the basic principles still apply. Meaningful Use and all its descendants are just attempts by CMS to fuel interoperability by reducing the costs for providers. Has that solved the problem? I don't think so. Solving it would require better understanding of the costs. That brings us to the next logical question. What are the costs?
On the provider side, we are going to ignore the Information Blocking Act and assume that every provider does want to achieve interoperability at the right cost. The cost for the provider comes from the time and effort required to complete the interoperability related tasks. The steps for meeting true interoperability in most EHRs are not streamlined with the provider’s regular workflow. The time spent on accomplishing interoperability related tasks is time taken away from the patients. Providers are made to choose between seeing more patients or completing the "requirements", putting them in a very difficult position.
On the EHR vendor side, the cost is a little more clear. It is the cost to keep building features to meet every provider’s requirements. Healthcare IT industry still relies on standards and technologies that are decades old. There are very few “Health IT experts” who understand these standards. The learning curve is pretty steep. That obviously increases the software development cost in healthcare as compared to any other industry. The ever changing regulatory requirements make the matters worse. Vendors have to constantly juggle between building new features and supporting new requirements, while keeping cost under control.
So, how does FHIR® break this cycle?
As I had discussed in a previous article, FHIR efficiently leverages the standards commonly used in other industries and applies it to healthcare. Any developer from any industry can review the FHIR specifications and get started on building healthcare apps. How does that help?
For starters, FHIR has reduced the entry barrier for developing healthcare technology solutions by encouraging more developers to join healthcare IT. FHIR allows reuse of many open source solutions available from other industries to accelerate development of healthcare solutions. This is one of the main reasons why FHIR based solutions have spread like fire in the last couple of years.
In other words, FHIR® has democratized healthcare technology development and by doing so, has drastically reduced the cost of building innovative solutions.
More importantly, FHIR is causing a paradigm shift in healthcare IT industry. EHRs are now being viewed as a platform, and not a complete solution. This frees up EHR vendors to focus on their core features rather than trying to meet every single user requirement. This is not a 10 year vision of what might happen. This is already happening, thanks to the amazing team at SMART®. SMART stands for Substitutable Medical Apps, Reusable Technology. SMART® on FHIR® is an open standards-based technology that utilizes the same concept as our mobile phones. It allows independent developers to develop solutions that can work with any EHR without requiring any custom integration. This tectonic shift in approach has lead to creation of an entirely new ecosystem of healthcare app developers. In this new ecosystem, Providers will have the option to choose an app for that one single feature that their EHR vendor just couldn’t move up the priority list because there were not enough customers who wanted it. EHR vendors will now be able to say “There’s an app for that”.
The key difference between SMART on FHIR and all the previous attempts at interoperability is that SMART on FHIR provides a self-sustaining revenue model. Interoperability is not a goal. It is an inherent requirement to meet the needs of this new ecosystem. The provider is not using an app to meet interoperability requirements. He is using it (by choice) to meet his specific requirements. Interoperability is a side effect in this new ecosystem.
It is important to note that the app developers don’t have to be limited to meeting the three goals of interoperability. The scope of apps extends far beyond. Take a look at Juxly which is an amazing example of this new potential. Darena’s MyMipsScore and BlueButtonPRO apps are developed with FHIR standard that allows providers using any EHR to meet and exceed MIPS and CPC+ requirements.
Sounds too good to be true? Is there a catch? Not unless you considered controlling patient data as your only advantage. If it is any consolation, that data was not yours to begin with. The spread of FHIR fueled by the new regulatory requirements that require Health IT vendors to support FHIR is going to burn all your excuses any way.