A Serious Proposal For Healthcare IT Interoperability
The healthcare industry should give serious consideration to a ubiquitous, public, open approach to health information exchange based entirely on web standards.
I believe that Fast Healthcare Interoperability Resources (FHIR), promoted by appropriate and strong government action, can provide the basis for making interoperability a practical and affordable reality. This opinion will come as no surprise to anyone who has been following my posts.
Recently, I discussed how the long-simmering debate about how to achieve interoperability was significantly intensified in April with the release of JASON's report "A Robust Health Data Infrastructure." In parallel with the report's release, Office of the National Coordinator (ONC) for Health IT director Karen DeSalvo said, "This report is consistent with our intent to support nationwide interoperability." She promised swift action when she said that the ONC and the Centers for Medicare and Medicaid Services (CMS) "have already begun to work on many of the recommendations cited in the report."
Clearly, DeSalvo meant what she said. Only five months later, on Oct. 15, the 18-member JASON Task Force (JTF) she convened issued its final report and said that it
… strongly agrees with JASON's call for an orchestrated interoperability architecture based on open APIs as the foundational approach for nationwide health information exchange. The JTF also agrees with JASON's observation that current interoperability approaches -- based on complex, health-care unique, document-oriented standards, and business frameworks -- are functionally limited and need to be supplemented and perhaps eventually replaced with more powerful, API-based models. The JTF thus also agrees with JASON's recommendation that MU Stage 3 be used as a pivot point to begin the transition to an API-based interoperability paradigm.
Before proceeding, let's step back and consider just how remarkable and significant all of this is. Before the Direct email-based exchange was introduced a few years ago, healthcare operated almost entirely in its own proprietary standards environment. In retrospect, Direct was the first step in moving to the same web standards and technologies used by virtually all other industries.
Now, here we are with a serious proposal for a ubiquitous, public, open approach to health information exchange based entirely on web standards for transport and leveraging the massive investments made by industries that are far ahead of us on data exchange. The API model essentially means that health information can be requested and retrieved using the same technologies you already use to find the right gift for someone's birthday on a retail website. Healthcare didn't have to invent it, and we can use web resources virtually for free, because we're sharing them with everyone else.
None of this should be interpreted as ignoring the very real, very healthcare-specific requirements for assuring privacy, security, and trust when protected data is exchanged. Nor can it ignore other health industry-specific challenges such as accurately identifying patients across (and possibly even within) provider organizations. JASON and the JTF clearly recognized both of these and other challenges and proposed approaches to them.
The JTF then goes on to list what it sees as JASON limitations, including:
It "does not accurately characterize the very real progress that has been made in interoperability, especially in the last 2 years."
It "does not accurately portray the broad range of functionality of [current] systems, or the innovation occurring on those platforms."
It "does not examine policy, legal, governance, and business barriers to health information exchange."
It "assumes a high degree of centralized orchestration," yet "the report does not describe the source, structure, and process for achieving such orchestration."
Progress has been made, as I discussed in a prior post. However, it would be wrong to suggest that we don't still have a very long way to go. Moreover, I doubt we'll get there anytime soon without a better strategy, and I am thrilled to see it coming into focus.
Of great importance, in addition to agreeing with JASON's recommendation that "Meaningful Use Stage 3 include certification and incentives for inclusion of a Public API in Certified EHR Technology (CEHRT)," the JTF formally recommended FHIR as the technology (interestingly, something JASON did not do). Since it is a draft standard, it called for "ONC [to] mobilize an accelerated standards development process to ready an initial specification of FHIR for certification to support MU Stage 3".
The JTF apparently (and, I think, appropriately) views this as minimum set of requirements and not a ceiling. "We do not anticipate that this specification would preclude the use of other existing standards to meet MU requirements."
I hope the ONC and the CMS don't end up bowing to pressure and viewing FHIR-based public APIs as optional -- a concern raised by the JTF:
The simple goal is to make such a FHIR specification available to vendors and providers along with other existing functional specifications so as to offer a viable opening to those who would invest in new standards, while at the same time not penalizing those who are already investing in capabilities based on existing standards.
The JTF also recognized that vendors and their healthcare organization clients must be brought to the interoperability table. Appropriately, the JTF members included representatives from more
Mark Braunstein is a professor in the College of Computing at Georgia Institute of Technology, where he teaches a graduate seminar and the first MOOC devoted to health informatics. He is the author of Contemporary Health Informatics (AHIMA Press, 2014) as well as Health ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Cybersecurity Strategies for the Digital EraAt its core, digital business relies on strong security practices. In addition, leveraging security intelligence and integrating security with operations and developer teams can help organizations push the boundaries of innovation.