CMS is on Fast Healthcare Interoperability Resources (FHIR)

Open Data Image

By Mayank Thanawala, SVP R&D

Change in healthcare requires a perfect storm of policy, technology, and critical mass of support. It happens slowly, and because healthcare systems are so monolithic, every change is an enormous one, and any new change is often blocked by the long-lasting repercussions of the last change. 

For example, everyone has known for decades that bundled payments make far more sense than the still-prevalent fee-for-service payment model for episodic care – I explained this to my Uber driver in about 30 seconds yesterday – but only now are we seeing momentum in that direction as the Centers for Medicare & Medicaid Services (CMS) has begun to put policies with outcome-based incentives in place.  This has finally created a critical mass of demand in hospitals and healthcare systems for good solutions to collect and manage outcomes data, and the health technology industry has responded by creating those solutions. It’s taken 25 years, but with the right elements in place, we’re seeing things change.

For interoperability in health technology, the perfect storm is finally brewing. CMS is taking bold and extremely forward-thinking steps to move us from policies that measure use of technology to ones that measure outcomes. The healthcare market is bursting at the seams with best-in-class point solutions as startups are able to create compelling apps for everything imaginable.  And the technology that will tie it all together is the Argonaut Project’s FHIR specification, as it hopes to displace the long-in-the-tooth incumbent of health system communication, HL7.

The central problem with HL7 is that essentially, every system uses HL7 differently, which means third parties have to write specific parsers for each system. If a system tries to add a component, it could break third party parsers, so CIOs are motivated to buy into monolithic systems so that they can be assured that it all works together. And the purchasing decisions, costs, and implementation timelines for  huge, multi-faceted monolithic systems are necessarily much greater in magnitude than they are for small, focused point solutions. 

These point solutions are often the ones that can actually be considered treatments for a particular condition or disease state. I’ve heard a lot lately about doctors wanting to prescribe apps. But how can a doctor prescribe an app if she has to clear it with her CIO first?  CIOs don’t control a doctor’s access to other treatments; why should an app be any different?  Mainly because the data flow back to the doctor is not a lab test as it is for traditional treatments; it’s data from the app, and with HL7, data only plays well when it’s within the monolithic system. And building and maintaining a separate HL7 interface for each of a bevy of apps is a massive and unsustainable investment.

FHIR has a few important advantages over previous attempts to unseat HL7 (version 2 is what is in use just about everywhere) as the lingua franca of health technology, such as HL7 version 3.  While v3 may have solved some of the aesthetic issues of v2 (depending on how one feels about XML), it created more confusion by introducing different but similar standards and difficult-to-comprehend transport mechanisms (e.g. Direct), and it didn’t solve the real problems of access, inconsistency in usage, and inextensibility.

While it’s early for FHIR, it shows promise of using modern API design techniques to solve these core problems.  Because it uses JSON or XML, it is extensible – objects have optional references to other objects, and if a type is added, it should not break the logic at the receiving end. It uses web technology as a transport mechanism instead of relying on HL7 interface engines, so access management becomes a matter of granting or revoking authorization tokens. FHIR could mean the end of making monolithic decisions, give CIOs the ability to work with doctors to implement the best solution for every problem, and give doctors the ability to use the solutions that drive the best outcomes for their patients.

Maybe most important, Argonaut and FHIR have support from some impressive industry leaders, including big EHR vendors, forward-thinking healthcare systems, and companies that have historically focused on connecting systems.  Between this level of health industry support and the push from smaller health tech companies with excellent point solutions to increase interoperability, FHIR has a critical mass of support. 

By prioritizing interoperability and outcomes, CMS is making sure that we’ll have the right policies.  The technology is on the right track, with FHIR leading the charge.  Everyone in the healthcare industry is moving toward an interoperable world.  The charges have been set, and it won’t be long before we see an explosion in healthcare interoperability.  FHIR in the hole!

Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Email this to someone

Leave a Reply