ICE on FHIR: Top 5 reasons why FHIR will never take off (or Top 5 reasons why we don’t learn from history)by Chintan Patel, PhD
For starters, FHIR is a new “standard” under development by the healthcare IT industry to build RESTful APIs for healthcare data. The big promise that simple REST APIs will make it easy for third-party developers to create useful “apps” for patients and doctors across different EHRs (atleast with those that adopt this standard). You will hear about FHIR in almost every health IT conference or keynote these days. This is not the first time the health IT industry has identified a new blockbuster drug for all its interoperability woes – in recent past, we have seen similar levels of excitement on HIEs (“top 3 buzzword”, 2012), C-CDAs (“next step in interoperability”, 2014), BlueButton(“is the future”, 2014) Direct (“kill the fax in healthcare”, 2011) and so on. Below is a graphic showing the growing interest in FHIR.
“But this time it is different!”… I hear you. And I agree that FHIR is definitely a positive step in right direction. In this post, I want to outline some of the lessons learned from history of doing standards and software and how we as a community keep ignoring those repeatedly. So here we go.
Lesson # 1. Specification v/s Implementation
a). Specification developing bodies such as IETF, W3C or HL7
b). The actual implementors of these standards such as OS companies (Microsoft, Apple), Browsers (IE, Firefox, Chrome), or EHR vendors (Epic, Allscripts, Cerner etc).
The specification generating bodies usually create a neat, all-inclusive, world-saving, shiny looking specification after countless hours of discussion/workshops/meetings with consultants, developers and members of their respective communities (mostly these are individuals/lobbyists from the implementor companies). Usually there may be a reference implementation, but when the rubber hits the road and the implementors start integrating the specification into their products or services – things start to fall apart quickly. The implementors with monopolistic positions in industry usually put a foot down and go in their respective directions (e.g. implementation review of IE6 in 2002). Such differences in implementation usually leads to pain among developers and that’s where libraries like jQuery emerge to ease their pain. In our industry, in 2014, one JAMIA study conducted on 91 different C-CDA implementations found “615 observations of errors and data expression variation across represented technologies”.
One area where I see implementors working cooperatively and winning big is Finance. You can go to any corner of the world and use an ATM to fetch money from your bank in another part of the world. There are hundreds of different standards in between that make this possible. I know everyone brings finance into such conversations and one guy responds “you don’t understand healthcare – its hundred times more complex”. The reasons are not technical but all tied to special interests, money flow, monopolies, and regulation – people are not willing to think beyond running their small private company in the Wisconsin.
Lesson # 2. Vendor specific App Stores
The mobile platform cluster#$@# is unveiling in front of our eyes and yet we keep running after the “app store” concept. Let me break it down for you. You have a favorite iPhone app (e.g. Dr Chronos mobile EHR) that is part of your daily work. Now your wife presents you a new shiny Galaxy S7 since she knows that you are so much into mobile “gadgets”. You like this new shiny gadget, but the Dr. Chronos EHR app is not provided on Android yet. What do you do?… There are literally thousands of such device specific apps that are “exclusive” on one platform and as different platforms emerge, the burden falls on to the developer to spend equal amount of resources to show presence on their device. Imagine, if you had to make separate websites for OSX, Windows, Linux users? OK fine, you will argue that we will all be using the “same” FHIR standard, so develop once and deploy everywhere…. Good luck with that! First of all, FHIR does not say any thing about app store/access (more on this later). And as we saw in History Lesson # 1, each vendor app store will have its own idiosyncrasies and the burden will fall on to the developer to ensure that their app is setup, maintained, and runs on each EHR’s app store to serve the maximum customer base.
Lesson # 3. Open Interoperability Cartels
Wouldn’t it be nice, if we as a community come together and create a nice open, vendor neutral consortium that will ensure every vendor is kept honest and everyone benefits? Well, there are quite a few of these in our industry without really pointing fingers. Usually you pay 50K, 200K or more to become a member – only then you have access to their “development sandboxes”, “have their EMR, EHR, or App certified” to be <ORG> compliant, and are able to distribute their applications in the <ORG> AppStore. Why do we let such horse s*** happen in our community? They call themselves OPEN, standards compliant and usually they are found running or sponsoring all the connect-a-thons in big HIT conferences. All you have to do is cough up 100K/year as a token of support. So right there you killed of all the enthusiasm among the ramen-fed 24 year-olds in silicon valley coding away in their garages desperately wanting to fix healthcare or cure cancer. There are hundreds of small/medium size businesses, like us who cannot afford to be part of such exclusive big boys club or to make meaningful contributions to the industry. This has to be stopped STAT.
Lesson # 4. Fun days of Meaningful Use implementation
I would say that from 2011-2015, when the majority of EHR vendors went through the first wave of MU certification, was a golden period of health IT or a dark period depending on whom you ask. The developers, product managers, and the QA team in EHR companies were neck deep in trying to understand and implement all the requirements related to MU certification. At the same time, the sales team and business leaders were having a ball seeing 100% or more growth in their sales. The opportunity cost of having your product managers worry about regulation implementation is potentially huge. You, the product manager at an EHR co, keep having all the innovative ideas in the shower to making EHRs suck less, but can never get those into priority list as the team is bogged down to meet the next set of regulations. Its almost as if your product’s JIRA backlog is driven by government regulation. The inclusion of FHIR in the next wave can potentially keep EHR vendors busy for a significant period of time.
Lesson # 5. App Developer Cannibalization
If Twitter Inc had a chance to change one thing in its history, I bet it would be to keep the platform fully open for its developers. Around 2010 or so, Twitter started closing off its developer API fire hoses and started block apps that were competing with Twitters official app. This led to an exodus of developers doing innovative things with it (we ourselves built an app that would let you find clinical trials by tweeting to it). Today with new (old) CEO, Twitter is trying to woo the developers back to its platform as they now only realized the real value that developers were bringing to the platform. Using the FHIR APIs, one could develop a much beautiful EHR experience or subset of it – the real question is, would EHR vendors be open to allowing such innovation on their platform? Or will they see it as a cannibalization of their business and actively stop such apps? Given the history of a “closed world” attitude of the vendors, I highly doubt if EHR vendors would be open to let developers go crazy with innovation. So after all this effort and work, all we will get is a cute little app that could read my prescriptions and send me alerts. “Thank you very much.”
Okay so enough of these history lessons. What can we do now to change the inevitable? I have one thought that I will present and I would certainly like to hear yours in the comments below.
The Big Idea to Make FHIR Successful and Live Happily Ever After
Standardize the Access and Distribution of FHIR apps.
The biggest flaw in the current scheme of things is the loophole where EHR vendors get to decide who gets on to their platform and how users discover these apps. The vendors are for-profit, self-managed businesses, so they will obviously do things that is in their best business interest. They will select apps and provide access to people or companies that make the most sense for their business. The challenge is that everyone is thinking myopically as Twitter Inc did in history Lesson # 5. It took 5 years for Twitter to realize its mistake. Having data fluidity will lead to prosperity for everyone just has how we saw the finance industry did in Lesson # 1. Let me explain. By outsourcing the innovation to developers, you, the EHR co is benefiting from increased usage of your product and a more likelihood that users stick with your EHR. You let more innovative minds into the industry, a.k.a people who will build the next Googles and Microsofts in the healthcare IT industry.
The real heart of this proposal is who controls the access and distribution? would it be another “open cartel” or the government?
Blockchain Architecture for FHIR Access and Distribution
I propose a blockchain architecture that enables distributed, verifiable, and vendor neutral way to host and manage applications. The blockchain will let verifiable registration of developer apps, the app keys stored in the blockchain and the EHRs would verify developer apps through the same blockchain. This is still a work in-progress – I plan to release more detail architecture specs on how this would actually work. Stay tuned!
As disclaimer, I am by no means an “expert” commenting on the future of such a big undertaking by thousands of my fellow industry men (& women!), who have each put hundreds of thousands of hours to bring this to fruition. I’m just another HIT guy trying to make a difference. Would love to hear what you think in the comments below!