In the midst of the struggles that we face with interoperability, efforts that support open API use may well hold the keys to the HIT Kingdom.
One of the major reasons that we struggle with interoperability is that software systems are not built in a manner in which they can talk to each other effectively. Developers may list a variety of reasons that this is necessary, or say it isn’t so—but the truth is that if systems could communicate in a safe and effective manner, we wouldn’t be in the interoperability mess we’re in. The good news is that there are some exciting efforts in progress to improve system-to-system communications, like the use of open APIs.
An Application Program Interface (API) is a set of programming instructions and standards for accessing a web-based software application, which allows a software-to-software interface. When a software company releases its API to the public (open API), other software developers can design applications and products that will interact in a compatible manner. This makes it possible for a foundational software program, such as an EHR, to interface with a limitless number of applications that have been developed to specifically communicate with the defined API structure. In this way, one core application isn’t required to do everything, but can be enhanced by a variety of compatible applications which communicate with it.
Though open APIs are used extensively in industries outside of healthcare, their foray into this world is just beginning. The current approach to software architecture, especially in EMRs, is often enterprise-based due to proprietary protectiveness. Kenneth Mandl and Isaac Kohane, both professors at Harvard Medical School, referred to the limitations of this approach in a New England Journal of Medicine article, “Escaping the EHR Trap—the Future of Health IT”. In it, Mandl and Kohane say that the proposition that medicine requires complex and highly specialized IT systems is a myth. “This myth continues to justify soaring IT costs, burdensome physician workloads, and stagnation in innovation—while doctors are becoming increasingly bound to documentation and communication products that are functionally decades behind those they use in their ‘civilian’ life.” They believe that EHR vendors tout the specificity and complexity of need in the healthcare arena as opposed to industrial and consumer products in order to protect prices and market share. “In reality, diverse functionality needn’t reside within single EHR systems, and there’s a clear path toward better, safer, cheaper and nimbler tools for managing health care’s complex tasks…most EHR vendors not only have failed to innovate but don’t even embrace existing modular architectures with interfaces that allow extension of product capability, innovative uses of data, and interoperation with other software.”
The professors say that by controlling all of the data within their systems, EHR vendors thwart medicine’s “decades-long quest for an electronic information infrastructure capable of providing a dynamic and longitudinal view of the health care of individuals and populations.” And that although EHR vendors have proliferated, their products have not helped healthcare professionals or the patients they serve: “…a few companies controlling much of the market remain entrenched in ‘legacy’ approaches, threatening other vendors’ viability. A healthy IT marketplace would favor disruptive innovations…for improving patient engagement, communication, and care coordination.”
Kohane is also the director of the Children’s Hospital Informatics Program, Boston, Mass., and Mandl is the director of the Intelligent Health Laboratory in the same program. Information Week Healthcare followed up with a joint interview with the authors, in which they recommended that EHRs create open APIs – both APIs to export data and those that will run applications to allow external product integration with the EHR. “Health IT vendors should adapt more technologies wherever possible. Clinicians choosing products in order to participate in Medicare and Medicaid EHR Incentive Programs should not be held hostage to EHRs that reduce their efficiency and strangle innovation.”
Edmund Billings, MD, chief medical officer for Medsphere Systems and the developer of the OpenVista electronic health record agrees with an open API approach: “Indeed, the fulcrum of this advanced interoperability is open application programming interfaces (APIs), which enable applications to quickly, easily, and affordably integrate with the core EHR. Think of all those iPhone apps in the iTunes store and then recall that Apple doesn’t even make open systems. Right now open APIs are most frequently associated with the Web and work being done by companies like Facebook, Google, Salesforce and Linkedin, which might seem irrelevant but is anything but. True interoperability in healthcare will result from tightly secured Web-based applications that enable a circle of accountable clinicians to work together with optimal patient health—not a billable test or procedure—as the ultimate goal…As the paradigm shifts, we will follow other industries and move from interfaces to interoperability and real collaborative care. And we’ll recognize that open APIs eliminate the obstacles to interoperability that stifle competition and innovation.”
The open API movement is gaining momentum, as noted recently in a Modern Healthcare article, “API Adoptions Rise as Data Silos Fall”. Author Joseph Conn notes, “Advocates foresee APIs becoming ubiquitous in health IT, opening up data in older proprietary EHRs for Health information exchange and analysis via Web-based tools, particularly applications running on mobile devices such as smartphones and tablet computers.” The sentiment is so strong that JASON scientists recently recommended that APIs be a mandatory part of the federal EHR Incentive program, since they will help create “a migration pathway from legacy EHR systems” to the interoperable healthcare systems of the future. Jeremy Delinsky, the chief technology officer for athenahealth agrees: “Our clients are going to ask for more functionality than we could ever churn out. As a vendor, you have to swallow your pride and say it’s OK, you’re going to lose a bit of control.”
Such momentum is further evidenced by an exciting compatible interfacing initiative recently highlighted in Forbes magazine, the SMART (Substitutable Medical Apps & Reusable Technology) Platform—an open API collaborative effort led by some major names in Health IT, including none other than Drs. Kenneth Mandl and Isaac Kohane, as well as Dr. Joshua Mandel. All three are working on this initiative as part of their roles at Boston Children’s Hospital. SMART’s advisory committee includes Aneesh Chopra, former U.S. Chief Technology Officer; Clayton Christensen, Harvard Business School professor, best-selling author and “#1 Management Thinker in the World”; and Thomas Krohn, Eli Lilly’s director of Clinical Open Innovation, among others.
The goal of this platform is to “revolutionize the way providers and patients use applications to improve access to quality of care. SMART apps are agnostic to the underlying electronic health record (EHR) or other IT platform. Like iPhone or Android apps, SMART apps are substitutable and can be readily added or deleted from EHRs.” Through the use of open and stable APIs, these substitutable apps provide needed flexibility to allow end users to customize their systems. With this effort, Dr. Mandl says “The opportunity is to create an ‘app store’ to extend the capabilities of EHRs”. An EHR provider doesn’t need to expose its underlying proprietary intricacies in order to offer an open API, which can become part of a stable library from which software developers can create new products, make upgrades and implement changes.
SMART’s mission is “to create an ecosystem of substitutable apps that can run on any electronic health record system. To this end, we have been working with the broader Health IT interoperability community to further the development of content standards, including HL7’s Consolidated Clinical Document Architecture (C-CDA) and, most recently, Fast Healthcare Interoperability Resources (FHIR®).”
A newly published open healthcare data standard from HL7, SMART describes FHIR® as “a robust approach to exposing granular data—a well-recognized need for developer-friendly APIs… We recognized in FHIR a new opportunity to align SMART’s vision with an open, fresh standards-based data layer. Like SMART, FHIR provides for RESTful access to clean, granular data. FHIR specifically represents granular clinical concepts as a set of resources that may be addressed individually or in aggregate. The API provides for individual patient and population-wide queries. It enables exchanging health records in highly readable XML and JSON, so it’s highly accessible to a large population of developers. It also brings a large set of data models and vocabularies informed by real-world implementer experience. And FHIR can be implemented incrementally, making it ideal for vendors to adopt in stages.”
FHIR® development is progressing rapidly, as indicated by its January 2014 official designation as a Draft Standard for Trial Use. And SMART is jumping on board by creating their newest platform offering, SMART on FHIR®, an early-stage prototype providing a complete open standards-based technology stack which is mapped to add new capabilities for SMART app developers, and more attractiveness for vendor adoption. As demonstrated at HIMSS14, the Health Services Platform even allows a search across multiple EHR vendors and healthcare providers to find an integrated aggregation of data for a single patient.
Now that’s progress.
In the midst of the struggles that we face with interoperability, efforts that support open API use may well hold the keys to the HIT Kingdom. If this approach makes digital health systems look each other in the eye and communicate in ways that truly make a difference to improving patient care—then we’ll be able to say that solutions are indeed on the horizon.
