Standards development work in healthcare is a challenging, often thankless task, and definitely more of a marathon than a sprint. It isn’t often that a proposed standard garners genuine enthusiasm among people working on interoperability issues, but that is what is happening with HL7 Fast Healthcare Interoperability Resources (FHIR).
Proponents of FHIR (pronounced “fire”) are working on a specification that could ease health IT bottlenecks and offer more granular data access. Rob Brull, the product manager for Dallas-based Corepoint Health, which offers a health data interface engine, told me that his company executives are amazed at the activity level around it at HL7 work group meetings. “They haven’t seen anything like it in 10 years, in terms of enthusiasm,” Brull says. “Everyone is talking about FHIR. HL7 struggled with version 3, so this is a big opportunity to create something that will be widely adopted.”
Healthcare has lagged behind other industries in the use of web technologies, Brull adds. “Healthcare has relied on IHE [Integrating the Healthcare Enterprise] protocols and SOAP [Simple Object Access Protocol] for transport, which can be cumbersome. FHIR uses RESTful [Representational State Transfer] web APIs [application programming interfaces]. It is more lightweight.”
The combination of FHIR for content summaries and the REST standard for transport would bring healthcare into alignment with the more modern web services approach used by companies such as Yahoo, Facebook and Google: simple XML and simple transport, notes John Halamka, M.D., CIO of Beth Israel Deaconess Medical Center in Boston and co-chair of the federal Health IT Standards Committee. “Content summaries should use simple XML that any developer, even one without HL7 or healthcare expertise, should be able to create in an afternoon,” he said in a recent e-mail exchange. “FHIR hides the complexity of the HL7 Reference Information Model but enables HL7 to curate standards based on a model its experts understand.”
John Halamka, M.D.
In an interview at the 2013 HIMSS conference, Australian software developer Graham Grieve, who has spearheaded the FHIR project, said that no matter how hard developers have worked on interoperability, the costs have remained too high. “It is really hard to take one piece of information and share it consistently across a lot of contexts,” he said. “With FHIR we are defining a single simple-to-use format that can be used from the back office all the way to personal health records and social web and mobile phones. That is a really compelling picture. We are taking the best bits of HL7 version 2 and the stuff we learned from version 3 and putting it in really modern technology that is making it easy to use.”
VENDOR SUPPORT FOR WIDER ADOPTION
Arien Malec is vice president of data platform solutions for McKesson subsidiary RelayHealth, Atlanta, a founding member and service provider for the CommonWell Health Alliance. He says that FHIR is appealing for several reasons. “We have HL7 version 2 for sending messages from one system to another and CDA [clinical document architecture] is good for documents, but neither of those work well for exposing a service or granular data,” he explains. “If instead of sending a document, I want to expose a medication list to authorized parties, the current systems are not designed to do that and it takes a lot of extra work.”
Malec says a good use case example would be offering mobile app developers access to patient data. “If you are going to do that, using FHIR is going to be cheaper, faster and better than rolling your own.”
Even though FHIR is only a draft standard at this point, CommonWell is already using it in a patient identification and authentication effort involving multiple providers and health IT platforms. “We turned to FHIR and quickly got to 80 percent of what we wanted, and the other 20 percent wasn’t that hard to do,” Malec says. “The disadvantage is that FHIR is still evolving and CommonWell is still evolving. But overall the tradeoff of the flexibility it offers versus it being a moving target was worth it.”
Arien Malec
Another effort that has turned to FHIR is Substitutable Medical Applications, reusable technologies (SMART), a collaboration between Harvard Medical School and the Office of the National Coordinator to create an application program interface (API) for substitutable health apps that run across multiple electronic health records (EHRs). Initially, SMART created its own data model because it couldn’t find one that was developer-friendly, says Joshua Mandel, M.D., the project’s lead architect, “But we were excited to see the FHIR group follow the same principles: developer friendly, open license and extensible,” he says.
To support the FHIR effort and highlight its potential for providing a robust, open health API, the SMART team built a prototype it calls SMART-on-FHIR. “We ripped out our data model for query and changed to one that knows how to talk FHIR,” Mandel says, “and the process went smoothly.”
How quickly could FHIR be more widely adopted? Each EHR vendor will make its own decision, but Mandel believes they will have strong motivation. “Creating an apps platform is a compelling target,” he says. “EHR vendors are getting requests from hospitals for new features, but those take a long time to build into new versions. They would like to build apps platforms. For instance, at Boston Children’s Hospital, we have built apps that work with their Cerner EHR; but once built, these only run in one place. The real trick is to build those in a way that they could be used anywhere someone wants to use them.”
Not everyone is enthusiastic about FHIR. Eliot Muir, CEO of the Toronto interface engine developer Interfaceware, was initially quite positive about the FHIR standard “since at a high level the message is very positive,” but he says that when you look closely the standard is too complex and overly prescriptive. “I think manufacturers and software companies can build better RESTful web service APIs into their products, which will be simpler and more cost-effective that trying to follow the FHIR standard,” Muir says. “My own economic interests are served best in an environment with lots of APIs with useful data, which increases the usefulness of good integration technology. Clunky standards inhibit my business model.”
But Malec, who has worked as coordinator for the Standards and Interoperability Framework for ONC, and still sits on the HIT Standards Committee, is optimistic about FHIR. “In healthcare we have an innovation dilemma because meaningful use has been driving the development roadmaps of EHR vendors. At the HIT Standards Committee we think about ways to break that cycle, and I have a strong belief that FHIR is a promising technology appropriate for innovation. I will be supportive of FHIR as one way out of our innovation dilemma.”
Adopting FHIR will require some up-front work by system vendors, admits Corepoint’s Brull, but once that work is done, “it promises to open up opportunities to work on doing bigger and better things with the data.
