At the HIMSS16 conference in Las Vegas, healthcare technology and data standards leaders were bullish on the promise of solutions such as FHIR and public API approaches enabling SMART applications, but cautioned that they alone won't solve the industry's interoperability problems.
In front of a standing-room crowd at the Sands Expo Convention Center in Las Vegas as part of the Interoperability and Health Information Exchange pre-conference symposia at HIMSS16, Richard Ellmore, senior vice president, corporate development and strategy at Allscripts, Micky Tripathi, Ph.D, president and CEO of the Massachusetts eHealth Collaborative, and other FHIR architects and experts gave a presentation on where healthcare stands on the application of open standard web service technologies that enable data exchange and care coordination.
Indeed, SMART (Substitutable Medical Applications & Reusable Technologies) on FHIR (Fast Healthcare Interoperability Resources) implements an open architecture to support interchangeable developer-friendly APIs (application program interfaces) that can be “plugged in” to any compliant EHR or health data container. Part of the allure is that the effort can get away from document-centric approaches and expose discrete data elements as service. Ellmore noted that the benefits of APIs check all the boxes including satisfaction, treatment, electronic secure data, patient engagement, and population health management. "APIs are an important tool for interoperability and a learning health system. It's how the future will work in a very significant way," Ellmore said.
When discussing why the need for FHIR, Tripathi cited the need for greater innovation in healthcare. While interoperability is growing rapidly, there are structural impediments that inhibit both the scale and scope of the growth, he said. "These standards are unique to healthcare, and they are too complex. We hear often from people in Silicon Valley that they will take months to understand, let alone implement. When you compare this to open APIs like you see with Uber, Twitter, and Facebook that you can get up and running in days, there is a big difference," Tripathi attested.
He added that standards have too much optionality. The scope of the data is either too broad (in the form of consolidated clinical document architectures, or CCDAs) or too narrow (in the form of labs or medications only). "A lot of the time, when you get the [document], it has no usability. That is due to a lack of standardization and too much optionality in the standard itself. And that's a policy/business issue, not a technology one. The current standards not able to support a rich set of use cases, and that's where FHIR comes in," Tripathi said.
Indeed, Tripathi said that FHIR breaks through many of the structural barriers of legacy standards. It is consistent with the principles you see in Uber, Twitter and Facebook. It allows users to create detailed profiles that can plug into FHIR resources. It allows data-level and document-level queries. "Sometimes you want an entire document about what's going on with the patient, and sometimes you just want the allergies. The flexibility of the standard opens up a wider variety of use cares, and importantly, to a broader set of users than just provider-to-provider. You see this in many other cases of the Internet," he said.
But as a standard, FHIR alone will not solve the many problems of interoperability, Tripathi continued. Interoperability is not just about standards; it's about policy alignment, standards alignment at multiple levels (format, semantic), and about business and workflow alignment, he said. "People might think that this is the magic bullet to fixing interoperability, but that's not the case." Nonetheless, Tripathi said there are a lot of reasons to think that moving to the next generation of standards will open up possibilities that didn't exist before. "By lowering the barriers to participation by a broader set of users inside and outside of healthcare, FHIR holds the prospect of having a strong democratizing affect on interoperability, Tripathi said. He added that broader and deeper demand released by the standard may catalyze policy and workflow development needed to support new and innovative use cases.
Tripathi said that FHIR is a nascent standard, and because it is still in the beginning, it will take long term to reach the market, especially if it proceeds through the same processes as past standards. It's broad-based, covers a lot of use cases, and is necessarily comprehensive, so it takes a while, he said. This, in addition to industry pressure, is why the Argonaut Project—an initiative launched by Health Level Seven International (HL7) to accelerate the development and adoption of FHIR—came about. Several things are needed to accelerate a standard, including: the need to focus on maturing those parts of the standard that will cover most day-to-day use cases; the need to have focused technical input and project management discipline; the need to have testing and implementation feedback from real users; and the need to have easily accessible implementation guides focused in high priority use cases. As such, the Argonaut Project addresses all of these areas, Tripathi said.
Providing a "where and when" update for FHIR, Tripathi noted that on the apps side, initiatives such as CommonWell, the Precision Medicine Initiative, among many others, are already showing interest and experimenting with the standard. On the FHIR server side, there have been similar interests and experiments from major vendors such as Allscripts, Epic, Cerner, athenahealth, Surescripts McKesson and others.