Digital disruption comes in waves. Other industries have profited from modern API integration, driven by the boost of internet technologies such as cloud applications and mobile phones. Consumer technology runs on modern APIs, considering apps like facebook, Waze, and Mint. Healthcare has some catching up to do.
More providers are realizing the potential impact modern APIs have on bottom lines, both in patient care and in profit. In a 2014 HIMSS Analytics Survey, 83% of healthcare providers reported using cloud services. HL7’s decision to develop FHIR, along with Meaningful Use Stage 3 API requirements, have solidified the hype and marked API and cloud integration almost essential to understand as a provider.
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.”
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:
- Open API for patient data sharing
- APIs for traditional provider integration strategy
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. 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.
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 valuebased care initiatives such as precision medicine, population health, and predictive analytics.
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-toprovider and public health data sharing on a similar level, and it will not be surprising to see more likeminded API initiatives in the future.
A modern, 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 modern requirements of fast and simple integration with any application or business need.
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.
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 modern 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 modern 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 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.
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.
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.
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.
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 modern 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. 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 modern 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.
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.