APIs – the Magic Bullet for Healthcare Interoperability?
Ease and Simplicity Key Benefits Behind Adopting API Use
A U.S. government task force comprised of an independent group of scientists, JASON, was recently tasked with analyzing healthcare interoperability progress. In its report, A Robust Health Data Infrastructure, the use of standardized data-level APIs (Application Programming Interface) across the healthcare industry was a key recommendation. As a healthcare interface engine company, we have seen the value of and embraced the use of APIs. In fact, supporting APIs is part of our architecture. We think it’s a great recommendation.
An API specifies a software component in terms of its operations, inputs and outputs and underlying types. Its main purpose is to define a set of functionalities that are independent of their respective implementation, allowing both definition and implementation to vary without compromising each other.
APIs are commonly used to expedite programming graphical user interface components. However, practically speaking they operate as a common ‘gateway’ into the exposed features and functionality of a product (for example, a plug-in API). In our software, an API allows for the creation of additional components, like custom listeners, transports, processors, etc. These additional components provide the functionality to read in virtually unlimited types of data, move the data, and process it. With our Java API you can extend the integration to do almost anything that you want. If that is some specialized transport, listener, transform, or processor, you don’t have to rely on what is packaged with the product. You can create your own, custom component, made to suit your specific requirements. Thus, our APIs provide the user with a full range of desired flexibility.
While APIs work well for enabling healthcare interoperability, APIs are also extremely useful for facilitating data sharing between diverse systems and applications. Not only for accessing data, for example, from an EHR system, but also as an effective means for adding data to a system or EHR, or for bi-directional data exchange. The beauty and simplicity of using an API is that data models behind APIs are irrelevant. Data from applications or systems just need to be sent to the API in the format which the applications or systems can accept. Then API server can then parse and send the information to the EMR data store, or to some intermediary data store.
APIs can also enable analytics. They can be used to easily perform quality checks on the data going through the APIs. We’ve made use of a RESTful API in one of our applications for this purpose. The RESTful API can give the status of any route or interface running through our integration engine. It also allows for the deployment of new routes, the modification of existing routes, and turning on/off routes and interfaces. It provides an operational window into our engine, one that our engine exposes as a web interface. But being an API, it is also something that clients can connect to with their own systems for automated deployment, system monitoring, and a number of other operations. In short, our a RESTful API provides users with a great deal of flexibility, and standardization, all central to interoperability.
The task force behind the JASON report understood very well that APIs create an easy means of interoperability with EHRs and other healthcare systems, something the industry desperately needs. It’s an approach that we at PilotFish support wholeheartedly and encourage others to support, as well.