Why does FHIR in Healthcare remind me of the Trouble with Tribbles? (+Blockchain)
On January 26, 2015 John Halamka was quoted in Information Week that the problems of healthcare interoperability would be solved long before 2017 (through FHIR). Halamka specifically stated, “It is entirely possible that long before 2017, when Stage 3 is due, the matter of interoperability will be settled.”
For anyone that doesn’t know about John Halamka, he is described by the same Information Week article as, “ The (FHIR)project’s champion, John Halamka, is one of the best-known figures in health information technology. He’s the CIO of Beth Israel Deaconess Medical Center, a full professor at Harvard Medical School, the chairman of the New England Health Electronic Data Interchange Network (NEHEN), co-chair of the HIT Standards Committee, and a practicing emergency physician. Under his leadership, in 2012 Beth Israel Deaconess was the №1 company in InformationWeek’s innovation ranking.”
After 2 years, FHIR is not anywhere close to being the slayer of the healthcare interoperablity mess as Halamka hoped an predicted. Instead, like the Theranos saga, there are big questions about the interoperability situation in healthcare. FHIR was supposed to be the answer to patient and provider hopes for solving interoperability. Those hopes are delayed and denied.
To date, FHIR has failed to deliver on its promise as an API Interoperability standard and it’s future as a reliable interface solution in healthcare is questionable for the foreseeable future. It is very possible that FHIR has been pushed to the forefront by healthcare vendors in an attempt to shield the industry from interoperability “data blocking” allegations that healthcare vendors faced in 2014–2015.
It appears that FHIR has been hyped to counteract potential congressional action that could have been taken against healthcare electronic medical record vendors such as EPIC and Cerner.
The timing of the healthcare media push that sensationalized the “extraordinary” accomplishments of FHIR and the Argonaut Project mirror the timing of the potential Congressional Action that would have brought sanctions and potential debilitating regulations on EMR vendors that actively are blocking data. The flurry of announcements about the “interoperability savior” embodied in FHIR caused the volume of the “data blocking” talk and potential Congressional action to significantly lowered.
Suddenly on January 12, 2017 it is reported that FHIR and related API’s are failing, “Health IT Vendors, Providers Struggling with API Development.” This should not be a surprise to anyone, since even the FHIR Meetings demonstrated a certain amount of dissonance with the participating vendors. In fact, in Minutes from a HL7 FHIR Meeting in San Antonio, TX on January 21, 2015 it was stated, “ From a read only perspective — here’s our stuff, some of it sucks to bad for you — this could be easily done….”
To be sure, working on interoperability is very hard, in fact 100% interoperability may be 100% impossible given the current state of affairs in healthcare, and the issue is not just the vendors. Doctors, hospitals, and clinical laboratories set up their own test dictionaries, and vocabularies and lexicons and standards such as SNOMED, LOINC, ICD-10, CPT Codes, just don’t get the job done. Furthermore, vendors and healthcare providers could always use the trusty excuse of the lack of any solid patient identifiers as a reason why nothing ever gets accomplished.
There are certainly a handful of FHIR demonstration sites that are trumpeted as examples of success. Duke University and Boston Children’s Hospital has been discussed “over and over” in the healthcare and information technology press. Josh Mandel has received incredible accolades for developing a version of FHIR called SMART on FHIR. For all of the accolades and constant self flagellating, SMART on FHIR hasn’t made it to the mainstream healthcare organizations that don’t spend $100M — $1.2B on EMR systems.
Grahame Grieve is the inventor of FHIR and it appears that he has been thoughtful in understanding that the FHIR hype may have gotten ahead of the ability for vendors and organizations such as HL7 to deliver. FHIR (Fast Healthcare Interoperability Resources) is a new and emerging standard being developed under the auspices of the Health Language 7 (HL7) organization. Pronounced as ‘Fire’, it was initially developed by Graham Grieve, who insisted that FHIR be open sourced. At it’s core, FHIR is intended to be the next generation of healthcare interoperability. It tries to combine the best features of HL7 Version 2 and Version 3, in which Grieve was significantly involved.
Grahame is right, we need clarity of what FHIR can do, and what FHIR can’t do. HL7 purchased the rights to FHIR from Grahame Grieve, and the marketing has been going non-stop in the media since congress was considering sanctions on EMR vendors for data blocking.
FHIR was intended to be developed in an Open Source environment. There are files and servers available for testing around the world. Cerner has a GitHub environment that shows activity and number of people involved in the FHIR effort. Sometimes these are playfully called “sandboxes.” The reality is that this is no cutesy matter, people are dying because they don’t have access to their medical records. The numbers from the Cerner Github “Sandbox” are not indicative of a significant effort from a multi-billion dollar corporation. Maybe Cerner has other development environments and “sandboxes,” that are not open source, but this demonstrates a very small amount of effort to accomplish a very hard job.
Grahame Grieve runs an unsecured FHIR test server for HL7. The server has what appears to be a very low number of transactions. It is entirely possible that all of the testing is done only on secure servers, but, we should certainly expect more than 85 medication related transactions / records, even in an unsecured test environment.
In fact, Grieve lists multiple FHIR servers on his website. The site also connects to Epic and their FHIR implementation guide and takes you through the process of using OpenID and OAuth 2.0 to identify your identify. Epic utilizes a $0 PayPal credit card authorization to verify identity in conjunction with Google or Facebook validation. I decided to check out another one of the Cerner FHIR “sandboxes” and was disappointed.
As stated previously, it is entirely possible that these companies are working diligently on proprietary FHIR servers to create and test APIs and they want to get this done as soon as possible, but the numbers just don’t add up. There are over 5000 hospitals in the US, and FHIR is supposed to be the “next best thing since sliced bread,” yet according to Monster.com, there are only 91 developer job listings for FHIR, and some of those are pretty dated.
It is easy to pick apart efforts like FHIR, Smart on FHIR, HL7, and Argonaut. FHIR, HL7, and the participating vendors should identify areas where they can make a small win that will help patients and providers and increase access to medical data across the country, not just a small number of large medical centers.
Why not create a universal FHIR API that streamlines the process of printing entire patient records to PDF files from every EMR system in the country?
On January 14, 2017, Grahame Grieve sent a tweet regarding blockchain. There is certainly a bit of hype and excitement about blockchain in healthcare. The difference between the the blockchain hype versus the hype surrounding FHIR, is that blockchains technology has been proven by 191,947,148 successful transactions on the bitcoin blockchain as of January 28, 2017.
On January 20, 2017 Grahame Grieve published the FHIR Roadmap. It describes FHIR R4 is expected to be the first ‘normative version’ where the standard becomes stable, and breaking changes are no longer considered. The Final Version of the FHIR Standard is not expected to be Published until October 2018. Furthermore, the document states, “ Longer term, we anticipate following R4 with a roughly 18 month publication cycle, with increasing normative content.” Therefore, FHIR will not be completely finalized based upon the most recent published schedule, until AFTER the next election in the US, in 2020. It is shocking that to date, not a single healthcare information technology publication has reported on the January 20, 2017 FHIR Roadmap and the R4 normative update.
Tribbles of Star Trek Fame were fuzzy, little, and cute. The idea of FHIR started out as cute, but it isn’t getting the job done as advertised in helping patients get their data or making sure that providers can access patient information from disparate sources at the point of care. If it doesn’t work, we will have hundreds of cute little apps running around healthcare just like the Starship Enterprise had a bunch of fluffy little Tribbles, but patients will not have access to their entire medical record.
Hopefully FHIR will recover from it’s current state of affairs and hopefully HL7 will recognize that they now have a duty to represent patient interests in open access to records in addition to their advocacy of healthcare IT vendors. Because, frankly, without the patient there is now need for HL7, FHIR or health IT vendors. Patients and providers will be best served in the future by having honest assessments and expectations of capabilities of FHIR being promoted and published in healthcare (Is anyone comfortable with the can being kicked down the road to 2020 ???). If not, it may be time to dust off the “data blocking” allegations against vendors and get Congress to “regulate the living daylights” out of companies like Epic and Cerner.
Edward Bukstel
@ebukstel
