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.”
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.”