APIs in Healthcare

What providers should know

Introduction

New demand for population health, precision medicine, mobile applications, and home health applications has highlighted the need for rapid and standardized digital integration. Modern API technology—which gives applications a simple and fast access into other applications—contains the potential to transform patient care.

Providers are now requiring more of their EHR technology, which are frequently coined “antiquated billing systems.” These EHR systems are now expected to deliver more to providers. APIs have the potential to unlock data through interoperability to open a myriad of possibilities for patient care.

Despite the promise of APIs, providers have concerns and unique challenges that need to be addressed before the API economy can deliver its fruit. This whitepaper details how providers can leverage API integration to reap the benefits of an open API in a hybrid integration environment.

What is an API?

An API, or application programming interface, is a set of standards that enable communication between multiple sources, most typically software applications. APIs actually pre-date personal computing.

Almost every internet user has used an open API— whether they’ve seen Google Maps on a website, or utilized apps like Waze or Mint. Closed and private APIs alike are useful for integrating data within a company, to business partners, or consumers.

Open APIs differ from closed APIs in exactly the way the name suggests—they are open and available for anyone to leverage. Open APIs provide a specified software with a standardized, public interface so anyone can receive and send data with the proper security authentication. When EHRs have an open API, countless third-party applications and downstream systems can input and/or leverage existing data within the system’s database. Both open and private APIs are valuable in healthcare and widely used in other industries.

Although the healthcare data standards needed to implement APIs are still maturing, APIs are based on web service data exchange standards. The HL7 organization, which is responsible for developing data standards in healthcare, is close to releasing the industry’s specialized standard in HL7 FHIR, which is ideally suited for API data exchange. To learn more about the technical details of HL7 FHIR, download “FHIR: shaping the future of health data exchange.

 

API benefits for providers

With the promise of rapid, lightweight, standardized integration, there is no end to the possibilities an API can enable—think population health databases with real-time data and analytics; granting patients’ access to their medical records; and medical research opportunities that arise from new access to key data.

As discussed in greater detail in the Harvard Business Review paper, “The Untapped Potential of Health Care APIs,” provider usage can be broken down into two categories:

  1. Open API for patient data sharing
  2. APIs for traditional provider integration strategy

Open API for sharing patient data

Patient and provider access to data via an API allows the aggregation of medical history for use via applications chosen by the patient or the provider. While the specific use cases are many, the need for EHRs to provide access to data via an open API has been mandated by the ONC’s Meaningful Use program (See the next page for details on the proposed rule). API capability is currently being developed by EHR vendors, however, it will be the responsibility of the provider to route the data and provide patient access (via portal or their chosen application) to their health data in the Common Clinical Data Set.

To facilitate a patient-facing open API, hospitals need to gather data from many applications into one intelligent stream. Sustainable systems depend on an interoperable layer that serves as the health data platform to interoperate between applications. While much attention has been placed on the EHR system, the integration layer serves as the catalyst for all health data activities and allows IT departments to break free from EHR “data silos” and gain full control of their patients’ health data.

Once a health data framework is established through the integration layer, powered by integration engine software, the IT team has access to a myriad of system performance information about the enormous amount of data transmitted between systems and applications every day. This technology offers many advantages for large organizations that employ a hybrid technology model of both enterprise-level and cloud-based IT applications.

A healthcare-specific integration engine is essential to providing an enterprise hybrid integration environment, not only to facilitate a patient-facing open APIs, but also to meet requirements of fast and simple integration with any application or business need.

APIs for provider integration

Currently, healthcare data is commonly exchanged using HL7 v2 messages via TCP/IP connections. Adherence to the HL7 standard varies between vendors, creating challenges to create data interoperability between applications. APIs offer the ability to supplement the current methods of exchanging data by offering a cheaper, lighter, and easier format of interoperability. Ideally, providers could create a robust API to connect internal systems and gain the flexibility to facilitate external data-sharing requests by simply sharing their approved API standard.

As APIs become more popular, potential workflows could replace VPNs and allow applications to have access to data as it becomes available. This new strategy will empower value-based care initiatives such as precision medicine, population health, and predictive analytics.

What you need to know about APIs in Meaningful Use Stage 3

Currently for Meaningful Use Stage 3, providers will have to certify an open, patient-facing, read-only API with a deployed certified electronic health record technology (CEHRT). The ONC has made it clear that supporting the patient API is the provider’s responsibility.

The API requirement is currently paired with the View Download Transmit (VDT) threshold requirements, and can either compliment or replace the patient portal given the existing engagement thresholds are still met (5% patient access in 2017, 10% in 2018).

For the specific data types, review the ONC’s 2015 Health IT Certification Criteria PDF. The deadlines and exact requirements for hospitals to certify are still up in the air, but a few hospitals are currently paving the way to support such an API.

APIs are relevant for Objectives 5, Patient Electronic Access, 6, Coordination of Care through Patient Engagement. Meaningful Use Stage 3 is optional in 2017, but required in 2018, and the ONC has published many documents on the API rule for patient access.

Although current API engagement requirements only apply to provider-to-patient interoperability, it is a clear goal of the ONC to promote provider-to-provider and public health data sharing on a similar level, and it will not be surprising to see more like-minded API initiatives in the future.

Decoding API Meaningful Use Stage 3 requirements:

  • APIs must allow patient access to data categories found in CCDs (electronic summary of care document) using the application of their choice.
  • Information must be returned meaningfully, using required data standards in computable format.
  • APIs must be open and transparent, and publish access instructions, documentation, and terms of use online and on the ONC website.
  • The ONC has not yet set standards and security measures, but have indicated they intend to require FHIR and OATH2.
  • Requirements for APIs are mostly read access. The HIPAA Privacy rule requires proof of signature. The ONC’s future goal is to encourage bi-directional interoperability.

The new API strategy

The cost of incorrect and inoperable data is immeasurable. Whether the mistake is an unreconciled billing account or a missed penicillin patient allergy, caregivers need timely and accurate data. As API technology gains popularity, more vendors will accept common API connectivity.

A current challenge for CIOs is to provide the right data to the right location at the right time, whether needed by insurance companies, caregivers, or patients. An open API allows CIOs to focus on developing and maintaining internal interoperability. Once internal data interoperability is achieved, optimizing external exchange is possible.

The graphic below illustrates the innovation open APIs provide. The burden of integration is placed on downstream stakeholders. For example, if a hospital has documented API standards, connecting with external entities can be as simple as establishing a basic business agreement. Downstream stakeholders can easily maintain their interface with ease and will no longer be bound by traditional interfacing methods.

Hospital Integration Workflow with Open API

Why is healthcare different?

Considering the success in integration of smart phone apps, digital prescribing, and personal finance, it’s easy to ask, “Why is healthcare so different?”

Perhaps Roy Fielding best answered that question in “Architectural Styles and the Design of Network based Software Architectures,” when he stated that “all architectural decisions need to be dependent upon the requirements of the given system.”

It is overly optimistic to suggest that APIs leveraging SOAP or RESTful web services will be applicable to all health data-exchange scenarios. Healthcare providers have to consider the context and workflow of caregivers who use existing health data-producing technologies. Ignoring this vital— and time consuming—step has consequences that risk not only adoption and acceptance of the end user, but also the health of the patients.

APIs have the long-term potential to positively disrupt healthcare interoperability, though there are some challenges providers face in the interim. While some of the challenges health IT vendors have with API technology exist for good reason, many of those same obstacles have been successfully resolved in other industries. Healthcare provides unique challenges that increase the sensitivity of the API argument, and groups like the ONC’s API Task Force have been set up to address those concerns.

Below are a few challenges providers face with API integration.

Data security

Data in healthcare flows in many directions and providers are responsible for the security of their patient data. While providers typically send data to the state, to pharmacies, and across the continuum of care, patients also need data exchanged between many unaffiliated systems and applications. An open API gives patient data a window to the World Wide Web, so appropriate security standards need to be defined, continuously improved, and checked for compliance.

Data complexity

In many other industries, a single source of data exists, and is typically exchanged/transmitted in small, encrypted chunks. In healthcare, the latest version of elements that exist within a patient’s health record may exist in several different databases. In order for a complete picture of a patient’s health and to improve care delivery, the patient needs her/his longitudinal (most recent and complete) health record. A patient’s health data is dispersed due to the siloed nature of health care delivery—each specialist a patient sees will save and store the information and data that corresponds with the nature of the care provided. Combine that over a patient’s lifetime, with multiple specialists located in multiple hospitals or clinics, and you can get a glimpse of healthcare’s complexity.

Data authority and trust

In the medical field, discerning data authority is a convoluted task. For example, one patient may have 2 different medical records, one declaring “no allergy to penicillin”, while the other reads “severely allergic to penicillin”. How do physicians decide which data source to deem authoritative? Discerning between data sources is not the only issue. Patient identification errors happen frequently and no fool-proof solution exists on the market today. However, these problems are not new to APIs. Over time, as competitive gains of on-demand data are realized, data authority and trust issues will lessen with increased collaboration between clinical and technical staff.

Hybrid integration environment

Greater than 85% of EHR implementations are on-premise applications. On-premise applications aren’t going away anytime soon

That being said, 82.7% of healthcare providers reported using cloud services of some sort according to the 2014 HIMSS Analytics Cloud Survey. Today’s healthcare IT departments need a central command—or an “eye in the sky”—to help guide the flow of data between applications and systems, regardless of database location, and to ensure that each caregiver and colleague has the right patient data, with the right insights, at the right time.

Healthcare providers will need to share V2 TCP/IP data and route it into an API, thereby creating hundreds of potential use cases. With a modern integration engine, capable of providing interoperability in both utilizing an integration engine capable of supporting both traditional and hybrid environments, this task becomes simple.

Hybrid Integration Environment: Bi-Directional Interoperability

Leading organizations recognize the value in establishing an interoperable health data foundation layer that allows a proactive approach to vendor selection. This approach ensures interoperability between systems, and provides actionable insights to data and access to EHR databases. As healthcare is set to adopt data exchange standards in HL7 FHIR, the future API economy means that CIOs can reap the benefits of choosing the right technology for the job.

As shown in the graphic above, a hospital strategic data framework, powered by an integration engine, contains many different applications and uses.

A legacy EHR might only allow HL7 V2 via TCP/ IP, while a population health system only exchanges SOAP web services messages. Adding to the mix the vast array of additional applications a healthcare provider may have, the build starts to get complicated.

A modern integration engine can accept and send data in any format or protocol, allowing the user to quickly parse and configure the feeds. For example, one can combine data from HL7 V2 streams with FHIR streams, and open up a REST API enabling cost-effective capability to connect any downstream application.

Where do we go from here?

In the not too distant future, seamless bi-directional health data interoperability will be powered by public APIs with impenetrable security and trust.

Until then, there are significant challenges, both practical and political, to overcome. But for those who can navigate APIs in healthcare, there is no shortage of competitive advantages ready to be earned.

For CIOs and Directors, maintaining a comprehensive hybrid integration framework and API strategy is essential as healthcare standards continue to advance. For Managers, Engineers, and Analysts, understanding the potential of APIs and their underlying principles will empower smarter decisions and influence strategic direction.

API adoption may be slow, but it is growing rapidly. More hospitals, clinics, and radiology practices are starting to build and test their own open APIs, and many have already implemented cloud applications that send data through web services. The emerging FHIR data standard appears to be the catalyst for the early adopters, and the hype will continue to grow as more use cases are fine tuned and receive attention.

 Print Friendly