Why Application Programming Interfaces Are Key for Healthcare

Application programming interfaces (APIs) are gaining traction in healthcare as developers seek simple, standards-based solutions for their interoperability problems.

Source: Thinkstock

Healthcare organizations seeking to create interoperability between internal apps, EHRs, and other data exchange tools, are increasingly turning to application programming interfaces (APIs) to manage the flow of information between disparate systems.  

As the ongoing transition to value-based care, population health management, and care coordination creates an imperative for actionable insights at the point of care, APIs can ensure the electronic health record data is accessible to the right internal and external users while remaining protected from malware and outside threats.

“We’re moving out of the era of EHR implementation and adoption and into the era of interoperability,” Bob Robke, Vice President of Interoperability at Cerner Corporation told EHRIntelligence.com.

“Now that we’ve automated the health record, the next phase is connecting all of the information in the EHR. We need interoperability and open platforms to accomplish this.”

Healthcare stakeholders have started to invest in APIs to facilitate this vision of open data exchange.  But what are APIs exactly, and what interoperability challenges do they help healthcare organizations overcome?

Solutions for Addressing Health Information Exchange Challenges

Breakdown of Health IT Interoperability Standards, Organizations

What is an application programming interface?

An API is an interface that allows unrelated software programs to communicate with one another. They act as bridges between two applications, allowing data to flow regardless of how each application was originally designed.  

For applications that function by pulling a constant stream of data from one or more sources, an API is especially important to decrease development time, save storage space on endpoint devices, and overcome any differences in the standards or programming languages used to create the data that lives at either end of the bridge.  

For example, third-party travel planning sites like Expedia or Kayak don’t generate data on their own to deliver comparisons of flight prices from ten or twelve different airlines.  

They simply use the API provided by each individual airline to plug into the flight scheduling software for each company and pull information into a single view for the end-user.

“We’re moving out of the era of EHR implementation and adoption and into the era of interoperability.”

Because the API is a standardized gateway to the airline’s schedule and pricing data, Expedia or Kayak doesn’t have to develop a dozen different methodologies tailored to each airline before they can establish communications.  

This eliminates the need for the travel comparison site to duplicate every dataset, create new data, or hold the data itself in order to function.

APIs function similarly in enterprise environments, making building applications and accessing data quicker, more efficient, and less prone to duplication or security errors.

Getting a Handle on APIs and Health IT Interoperability

Open APIs, Use Cases Driving Interoperability at Allscripts

Why APIs are critical for health IT development

Healthcare organizations face challenges accessing and sharing data, especially as healthcare IT infrastructure migrates to the cloud, and digital information becomes an industry standard. Different data sets use different formats, making interoperability between apps challenging.  

“There’s no such thing as one set of data that gives you everything you need in one single format,”  Dr. Nicholas Marko, Chief Data Officer at Geisinger Health told HealthITAnalytics.com.  “There will always be information coming from a number of different places, and there will always be a need to work with systems that handle that.”

Because APIs are the points of communication between systems, they are being developed to simplify interoperability to provide healthcare professionals and users data more efficiently.

HL7 is currently developing the Fast Healthcare Interoperability Resource (FHIR) data standard, which provides a standardized way to aggregate and merge patient health data from separate data sources.

“There’s no such thing as one set of data that gives you everything you need in one single format.” 

FHIR creates a standard to make it easier for healthcare professionals to use and share clinical data by restructuring healthcare data from different sources into a compatible format for easier interoperability.

“Healthcare records are increasingly becoming digitized,” official FHIR documentation states. “As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must also be structured and standardized.”

While FHIR is not yet as widely used in healthcare as it could be, the importance of APIs is a high priority for the ONC, which has included the technology in its most recent EHR certification criteria.

The ONC’s proposed rule for 2015 Edition Certified EHR Technology (CEHRT) outlines three technical outcomes  for APIs that vendor products need to meet:

Security: The API needs to include a means for the establishment of a trusted connection with the application that requests patient data. This would need to include a means for the requesting application to register with the data source, be authorized to request data, and log all interactions between the application and the data source.

Patient selection: The API would need to include a means for the application to query for an ID or other token of a patient’s record in order to subsequently execute data requests for that record.

Data requests, response scope, and return format: The API would need to support two types of data requests and responses: “by data category” and “all.” In both cases, while the scope required for certification is limited to the data specified in the Common Clinical Data Set, additional data is permitted and encouraged.

The ONC 2015 CEHRT regulations encourage developers to custom design APIs that work for their institution while outlining requirements to ensure security and data integration.

Can FHIR Spark Health Information Exchange, Interoperability?

HHS Releases 2015 CEHRT, Meaningful Use Flexibility Rules

Source: Thinkstock

The question of API security

The ONC 2015 Edition CEHRT specifically calls for organizations to secure their API connections to ensure that unauthorized users do not gain access to the healthcare API.

Organizations are tasked with implementing security measures and protocols to protect their network and data from malicious attacks or leaked information, both of which could have serious implications for patients.

The Health IT Policy and Standards Committee formed the API Task Force to “identify perceived security concerns and real security risks that are barriers to the widespread adoption of open APIs in healthcare.”

A report released earlier this year by the API Task Force, along with the Health IT Policy and Standards Committee, outlines security concerns APIs bring to healthcare.

"There are fears that APIs may open new security vulnerabilities, with apps accessing patient records 'for evil', and without receiving proper patient authorization," stated the report. "There are also fears that APIs could provide a possible 'fire hose' of data, as opposed to the 'one sip at a time' access that a web site or email interface may provide."

Considering how public, consumer-facing APIs function, the concerns raised by the report are valid. There is the risk of users gaining access to too much data instead of just the data they need.

Even if the user is not “evil,” authorized users accessing a wealth of data they do not need is still a security risk and may violate HIPAA privacy regulations.

The report found that when properly secured and managed, the benefits of APIs outweigh the risks. Several organizations testified their properly managed APIs provided better security than legacy or proprietary integration technology.

Well-managed healthcare API exchanges usually include authentication, authorization, encryption, and signatures to ensure secure connections.  

Authentication and authorization are used to reliably determine a user’s identity and what resources they can access, usually through usernames and passwords. Security software certificates and hardware keys may also be used for extra security.

Encryption hides data from unauthorized users and acts as a failsafe in the event the clinical data is stolen. Signatures are also used to validate API requests and ensure the data did not experience interference during transit.

The API Task Force report touches on APIs and HIPAA regulations, particularly focusing on patient-directed API technology. While managed APIs are secure, the risk factor rises when patients are accessing PHI without being familiar with the HIPAA Notice of Privacy Practices for Protected Health Information.

If patients do not understand the value their personal health data has to hackers seeking to steal their identity, they are more likely to carelessly share it with a third party app and expose themselves to privacy breaches.

The Task Force also recognizes the potential risk of patients accessing HIPAA-approved APIs and sharing the information with an app that is not regulated under HIPAA, such as a commercial fitness tracker app.

The API Task Force recommends that the The Office of the National Coordinator for Health Information Technology (ONC) coordinates a program to define the basics of privacy literacy and educate patients to understand basic privacy information needs to make appropriate decisions regarding sharing personal health data with unauthorized apps.

Healthcare Authentication Factors: Breaking Down HIPAA

Health IT Task Force Synthesizes Open API Themes

Using APIs for data integration

The biggest hangup facing data integration in healthcare is the lack of consistency in data formats among disparate organizations,especially when it comes to EHRs.

The Regenstrief Institute is one of several organizations seeking to merge patient health data from separate data sources to create an industry data standard using HL7’s FHIR.

"We can really stitch together information in various sources using FHIR in a way that is user-centered and would be accepted by physicians and patients," Regenstrief Institute investigator Titus Schleyer, MD, PhD, told HealthITInteorperability.com.  

The Regenstrief Institute aims to leverage the FHIR standard and API technology to assemble health information from different EHR systems.

The Institute deployed a use case between between an Epic EHR using the open.epic API and the Indiana Network for Patient Care (INPC) using a previous version of FHIR.

"We can really stitch together information in various sources using FHIR in a way that is user-centered."

Although this use-case was not a full implementation, the Regenstrief Institute was able to give INPC proof of concept that their data could be integrated.

The Argonaut Project is another organization with close ties to FHIR. The group is working to develop a FHIR-based API and Core Data Services to expand the sharing of electronic health information.

The goal of the Argonaut Project is to “enable interested vendors and providers to develop and implement a focused but complete FHIR API specification, and accompanying security implementation.”

Argonaut members encourage prepared entities to move more quickly towards data standardization and API adoption than current regulatory processes require in order to lead the industry by example.

“I’ve seen a lot more progress when groups of provider organizations and technology developers get together and say, ‘We're going to go at the quickest pace we can, regardless of whether the whole market travels at the same speed,’” Arien Malec, Vice President of Data Platform and Acquisition Tools at RelayHealth told HealthITAnalytics.com.  

“Clearly, I'm proud of my work in the CommonWell Health Alliance and in being part of the Argonaut Project, which I think are both good representations of that attitude that says, ‘We're going to get together and drive interoperability independently of the certification program.’”

"We're going to go at the quickest pace we can, regardless of whether the whole market travels at the same speed."

The Argonaut Project aims to introduce specifications for a new architectural pattern and style for healthcare organizations to access data and services, and more flexible and open methods for authorized access to health information.

While these projects have yet to be fully realized, the potential for APIs in health data integration for secure and efficient access is promising.

Will FHIR, APIs Help or Hinder Health Information Exchanges?

Addressing HIPAA as an Obstacle to Health Data Exchange

Looking towards the future of APIs in healthcare

Support for APIs in healthcare is growing as government organizations encourage the use of APIs in health IT infrastructure.

The Centers for Medicare & Medicaid Services (CMS) recently called for the use of APIs to help providers meet requirements for electronic patient access to health information by giving consumers tools to easily interact with their personal health data.

ONC also recognized the importance of FHIR and APIs by hosting a pair of industry challenges and a funding opportunity to address several  interoperability issues in healthcare including: helping patients access their data, improving the provider user experience of EHRs and other health IT tools, and coordinating the development of app-based solutions across the industry.

The support CMS and the ONC have for FHIR and APIs speaks to the future of the technology and its potential impact on healthcare interoperability.

“The FHIR standard is still quite new,” said DR. David McCallie, Jr., Senior Vice President of Informatics at Cerner.  “It’s not even a formal standard yet – it’s still in draft status."

"And vendors who are implementing it are feeling their way forward to make sure they understand it, and to discover if there are any gaps or bugs, or if the specification is not actually specific enough.”

As API development continues, the importance of creating a standard for healthcare application communication is a priority for vendors and organizations.

“As an industry, we have to come together to solve the problem of access to our own healthcare information,” said Cerner Corporation President Zane Burke.  

“Patients deserve access to their data no matter where they are in the country, and no matter where their record primarily resides.  They should have the ability to provide consent to have a clinician be able to pull those records whether they’re on a Cerner system or a competitor’s solution.  Ultimately, that’s what we need to deliver.”

As interoperability efforts such as The Argonaut Project and The Regenstrief Institute continue to develop a data standard that can be implemented universally, across healthcare organizations, APIs will be able to easily request and retrieve data from multiple EHR solutions across multiple healthcare organizations and arrange them in a clear usable format.

"Patients deserve access to their data no matter where they are in the country, and no matter where their record primarily resides."

As API development continues, healthcare organizations can prepare their IT infrastructure by implementing app development and cloud solutions where necessary and improving wireless network speed and capacity to support faster and more efficient data exchange between applications and sources.

Organizations looking to embrace better interoperability - and have the IT infrastructure to support it - may benefit from bringing more developers onto their IT staff to develop APIs for standardized data to increase organization operations and prepare for a future of shared data.


Sign up for our free newsletter covering the latest IT technology for Hospitals:

Our privacy policy

no, thanks

Continue to site...