Is a New World of Interoperability-Fueled Clinical App Development Around the Corner? | Mark Hagland | Healthcare Blogs Skip to content Skip to navigation

Is a New World of Interoperability-Fueled Clinical App Development Around the Corner?

May 31, 2017
| Reprints
An op-ed in the May 18 New England Journal of Medicine speaks to interoperability-related challenges and opportunities

I read with fascination a “Perspective” column in the May 18 edition of The New England Journal of Medicine, written by Kenneth D. Mandl, M.D., M.P.H., and Isaac S. Kohane, M.D., M.P.H., medical informaticists practicing at Boston Children’s Hospital and at the Department of Biomedical Informatics at Harvard Medical School, respectively.

Entitled “A 21st-Century Health IT System—Creating a Real-World Information Economy,” the op-ed was both broadly comprehensive and also of sufficient granularity and practical depth, on the subject of how federal healthcare officials can compel forward a path forward towards the interoperability of the APIs (application programming interfaces) that collectively offer a way forward on clinical IS interoperability for U.S. (and international) healthcare.

The authors frame their “Perspectives” op-ed by noting that, while the HITECH (Health Information Technology for Economic and Clinical Health) Act of 2009 spurred forward the adoption of EHRs (electronic health records) on the part of hospitals and physicians, “Eight years later, however, the U.S. healthcare system still doesn’t have a usable IT engine that can generate high-quality data, a restriction that may impede progress toward the use of real-world evidence to advance treatment and research. D

Drs. Mandl and Kohane state that they are cheered by the inclusion in the 21st Century Cures Act, passed X, of “a provision that could transform hundreds of existing EHR products certified under the meaningful use program into a coherent platform for innovation and transformation, despite the systems’ nonmodular design and disparate data formats. The new law,” they note, “requires that certified health IT products  have an application programming interface (API) that allows health information to be accessed, exchanged, and used ‘without special effort.’ Such an interface,” they note, “could allow third-party developers to create functionality  that interacts and integrates with other systems in predictable and standardized ways.”

Numerous other commentators have made note of this provision in the 21st-Century Cures Act. Indeed, at a time of disharmony and legislative gridlock in Washington, the passage of 21st-Century Cures—which of course covered a very broad base of areas of endeavor, healthcare IT being only one relatively small slice of its whole—represents a breakthrough that could help transform how healthcare IT evolves forward in the U.S. in the next decade.

But what Drs. Mandl and Kohane have to say is particularly interesting and apropos. “Going forward,” they write, “the API provision in the 21st-Century Cures Act could be leveraged to powerful effect. First of all, if the API is open and standardized across systems, a new form of interoperability will emerge: substitutability. Substitutability would mean that apps could be added to or deleted from an EHR just as they can be on a smartphone—a step that would reflect a shared commitment to the transferability  of healthcare data and knowledge.”

And here’s where the authors get granular. “A uniform open, standardized healthcare API would allow a given app to run on any EHR,” the authors write. “This approach would produce game-changing economies of scale and starkly contrast with current conditions, in which nearly all innovative applications require expensive, time-consuming, custom integrations to connect to EHRs. Physicians and patients would have access to a wide selection of software that could connect to their existing systems. Innovators would have a marketplace where they could compete on quality, price, value, and user experience without mustering the idiosyncrasies of each EHR brand. EHRs would have become commodity components in a large platform that would include other transactional systems and data warehouses running myriad apps, and apps could have access to diverse sources of shared data beyond a single health system’s records.”

What’s more, very importantly, the authors note that, if that level of interoperability were achieved, “Research, regulatory, and public health organizations could both access data obtained at the point of care and deliver services to physicians and patients through substitutable apps that connect to EHRs, as developers create resources for an ‘app store’ for health and research. Substantial progress has been made toward these goals, but they haven’t been achieved on a system-level scale,” they note.

Indeed, these observations speak to a core barrier that the developers of APIs have faced in U.S. healthcare until now—how to overcome the challenge of universality, or as these authors frame it, substitutability.

In fact, this situation reminds me of my readings in history, in particular, the early history of consumer telephone use and the early history of automobile development. Both industries suffered from barriers of particularity. Years ago, I watched a documentary on PBS that described the development of early local phone systems, and was fascinated. The PBS documentary focused on what happened in Kansas City, where consumers rushed to get home telephone service, but were disappointed to discover that they could not in any way be connected with anyone subscribing to a different telephone company’s service; and there were four operating in Kansas City. So that meant that your sister, your neighbor, your doctor, your housepainter, your second-cousin-once-removed, could all be on one of four different, non-connected systems. Naturally, this led to tremendous customer satisfaction—and ultimately resulted in the emergence and consolidation of the Bell Telephone system.