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.
Meanwhile, back in the 21st century, it was very worthwhile to interview Alistair Erskine, M.D., CMIO of the Danville, Pa.-based Geisinger Health System, as I prepared one of our Top Ten Tech Trends for our March issue this year. The experience that Erskine and his colleagues had recently with developing and then attempting to commercialize an app that was FHIR-compliant—that is to say, compliant with the FHIR (Fast Healthcare Internet Resources) standard—demonstrates both the upside and the downside of the current FHIR-facilitated landscape, he says. Erskine and his colleagues invested time, effort, and funding into the creation of a rheumatology application. “We proved that we could use it on several different platforms,” he reports. “We tried to commercialize it, but got nowhere. There were two key problems. One, the various EHRs [electronic health records] weren’t really ready for a production-based mechanism. There was a lot of work the client had to do on their end to make it work; it wasn’t plug-and-play. Instead,” he says, “it was, build to plug, and do a lot of work to play. And while the app did something useful and helped us to take care of rheumatology arthritis patients, the colors, the buttons, and the feel weren’t harmonious with existing EMRs. So the informaticians and clinicians weren’t comfortable with having to teach end-users to use this.”
Erskine says that Geisinger’s experience with the rheumatology-focused app points to a broad weakness in the current development landscape. “How do you take all these disparate apps and make them work with the natural user interfaces that end-users are used to?” he asks. “Unlike an app on an iPhone, each download of an app using SMART on FHIR requires BA [business associate] agreements, a whole series of architectural reviews with a client, and a whole series of contractual arrangements. So there really was a missing app store where you could say everything in that app store is already vetted, is safe, is free from hacking, is something that I can trust.” And while a small number of the biggest EHR vendors, including Cerner Corporation, McKesson Corporation, and Epic Health Systems, have built platforms on which developers can create FHIR-compliant apps, there is not yet an easy pathway for the development of apps by organizations like Geisinger Health, that will readily be accepted by practicing physicians and other clinicians. Indeed, based on how their experiment turned out, the Geisinger folks made a course correction in their initiative. “We found that the end-user experience tends to be different from EHR to EHR, so we said, let’s let the EHR vendor control the graphical user interface; we can use FHIR to augment the data sitting in the EHR,” Dr. Erskine told me. “So if I use my big data platform to identify patients with kidney disease who should have that marked on their problem list, I can alert my EMR to alert the end-user physician.” It’s not an ideal situation, he concedes. “It would have been nice, if I’m a rheumatologist, to go to this pre-approved app store and download a few apps that would work for me as a clinician. That would have been nice if that had been feasible. So the reluctance of the vendors to have something user-ready and the contractual issues, etc., those are all reasons it hasn’t flourished yet.”
It seems to me that the experience that Dr. Erskine and his colleagues have had at Geisinger speaks to a really, really basic issue here—the “recreating the wheel” problem, if I may. There’s simply got to be a better way to create broad platforms that can lead to the creation of large numbers of interoperable, useful clinical apps, than how it’s been done until now. And honestly, even the very smartest and most innovative clinicians and clinical informaticists simply aren’t going to spend countless hours working on the technical steps around creating innovative APIs.
Indeed, there are very, very many clinical informaticists eager to create truly useful apps, apps that could potentially transform patient care delivery in key areas. For example, last year, I met with Shivdev Rao, M.D., a cardiologist at the vast UPMC health system in Pittsburgh. Dr. Rao enjoyed sharing with me his work collaborating with fellow clinical informaticists on an app that could prove quite useful to fellow practicing cardiologists. As he told me in an interview, “A little app I’m looking at right now on my smartphone, tells me when any one of my patients is in the emergency department, is admitted as an inpatient, or is discharged. Where did this idea come from? Well, historically, what would happen to me is that I’d end up in clinic and see ten patients who’d already been in the hospital, and had had their cardiac meds had been changed without informing me. On the surface, this appears to be a very simple application, but behind the scenes, making it successful requires connecting a lot of dots between our inpatient system, our outpatient system, and our ADT system, pulling demographic data on these patients; and it requires pulling a care team together around these patients. So I now get actionable notifications. I can choose to call the ED, the patient, or any other doctors on the team.”
It was exciting to hear about the development of that app for cardiologists; and it wasn’t surprising to me in any way that UPMC, a pioneering organization in the arena of applied clinical informatics, has been funding app development through its UPMC Enterprises division, which is actively working on apps and solutions that could change patient care, and working to move as many new solutions towards commercialization as possible. Nor is UPMC alone in this; Cleveland Clinic, Mayo Clinic, Intermountain Healthcare, and Geisinger Health System, among other large integrated health systems, are doing the same, funding healthcare IT tech beds, and getting very practical in moving forward to close gaps around useful clinical apps, by engaging physicians and other clinicians within their organizations in developing their own.
And that’s the arena in which we can expect some of the next breakthroughs to take place in this very important sphere. As Drs. Mandl and Kohane put it, “If we make it our goal for a given app to be able to run on any EHR in the U.S. healthcare system, we minimize the risk that the 21st-Century Cures Act will produce only local successes and scores of balkanized, disparate apps.” What’s more, they write, “We also maximize the opportunity for the United States to become a leader in developing new healthcare applications for clinicians and patients with varying needs and ensuring the safe and timely flow of information for patients, care providers, and researchers.”
I have real hope that things will move forward along these different dimensions, since really, they need to. This is a tremendous example of where federal healthcare IT policy, vendor solutions evolution, changes in clinical practice, including the shift towards care management and population health management, and the broader healthcare policy environment, all intersect. Consider how important the app that Dr. Rao and his colleagues at UPMC, could be, for cardiologists who are given more direct accountability for certain specific elements of patient flow and transitions of care. One can easily imagine numerous similar scenarios, U.S. healthcare system-wide.
So let’s hope that what Drs. Mandl and Kohane have envisioned, moves towards practical reality. The U.S. healthcare system—and ultimately, healthcare systems around the world—could benefit immensely from a level of interoperability that turbocharges the development of apps that could work with any EHR—really, we could be on the doorway to a new world.
