Interoperability: There is FHIR® at the End of the Tunnel
Over the last decade, billions of American taxpayer dollars have been spent to achieve “interoperability” in healthcare. Has it worked? The answer depends on who you ask but everyone agrees, we still 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 in-depth Care Coordination and Patient Engagement in our past blogs. However, Reporting and Research usually don’t get the attention they deserve. The thing is - You can’t report what you can’t measure, and you can’t improve what you can’t report. As I have discussed in an earlier blog, interoperability can simplify regulatory reporting and create research opportunities.
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 EHRs. However, based on the emphasis on Information Blocking by the 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 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 were attempts by CMS to fuel interoperability by reducing the cost for providers. Has that solved the problem? I think answering that would require a 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 wants 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 the 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 side, the elements that make up the cost are clearer. It is the cost to keep building features to meet every provider’s requirements. The Healthcare IT industry still relies on standards and technologies that are decades old. There are very few “Health IT experts” who understand these standards and the learning curve is steep. This obviously increases the software development cost in healthcare as compared to any other industry. The ever-changing regulatory requirements make matters worse. EHRs have to constantly juggle between building new features and supporting new requirements while keeping costs under control.
So, how does FHIR® break this cycle?
As I had discussed in a previous blog, FHIR efficiently leverages the standards commonly used in other industries and applies them 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 the reuse of many open source solutions available from other industries to accelerate the 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 the healthcare IT industry. EHRs are now being viewed as a platform, and not a complete solution. This frees up EHR 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. Thanks to the amazing team at SMART®, this is already happening. 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 led to the 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 their priority list because there wasn’t enough demand for it. Now we can all 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. Providers are not using an app to meet interoperability requirements. They are using it (by choice) to meet their specific requirements. Interoperability is a positive side effect of this new ecosystem. Our MeldRx™ Ecosystem was built with the same intent. It allows EHRs to meet the ”Certify and Provide” Cures Act requirements, while enabling providers to prevent Information Blocking, and gives patients the power to securely store and share their healthcare data in FHIR format.
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 anyway.
RELATED BLOGS
