The future of interoperabilityWeb APIs & HL7 FHIR
As healthcare continues to integrate internally and adopt mobile devices and cloud-based applications, the need for using web APIs for data exchange is growing.
The demand for population health, precision medicine, mobile applications, telemedicine, and home health applications has highlighted the need for rapid and standardized digital integration. Modern, web API (application programmer interface) technology—which gives applications simple and fast access into other applications’ data—has the potential to transform patient care.
Web APIs are methods of secure communication between electronic devices over the internet that make it easier to communicate health data between applications, regardless of the operating system or software in use.
Providers have been demanding more of this type of access from their EHR vendors, who, in turn, are eager to prove that they are committed to their customers’ goals of improving patient care through internal and external data interoperability. EHR systems are now required to deliver more to providers in terms of API connectivity and the ability to improve caregiver and patient workflow.
Web APIs have the potential to open myriad possibilities for patient care. This whitepaper details how providers can leverage API integration to reap the benefits of APIs alongside HL7 FHIR, the standard that is being employed as the data standard of choice for APIs by all major EHR vendors.
How did we get here? A brief history of health data exchange
Today’s health IT environment is very fragmented. It’s not unusual for large health systems to have 100s of applications from different vendors installed, including EHR, lab, radiology, and billing systems. Each of these applications tend to favor flexibility for their specific function or department over interoperability with external applications.
Data is exchanged between these separate systems using HL7 v2. (See Figure 1.) Traditional data exchange typically follows the following pattern:
- A caregiver types data into the EHR
- The vendor allows that data to leave the EHR in an HL7 v2 or CDA document
- The data is sent over an interface to the receiving application
- The receiving application parses the data and imports it into their database.
HL7 v2 progressed with the goal of connecting different applications via point-to-point interfaces. Today, most providers place an integration engine, such as Corepoint Integration Engine, in the middle of all the interfaces to allow for central monitoring, alerting, flow control, data mapping, logging, and more, to orchestrate data flow between these applications. (See Figure 2.)
The ultimate goal of the government’s Meaningful Use program, which financially encouraged all providers to adopt EHR technology and engage in the act of exchanging health data with external organizations, is to create a national, connected health information exchange network. (See Figure 3.) Ideally, participating providers using certified EHRs would be able to send and receive health data from this connected national health information network.
What has transpired, however, is that many providers have bypassed the federated HIE model and instead focus on their current needs. As organizations merge and incorporate new facilities, much more data is being exchanged between affiliated provider locations rather than with regional HIEs. Healthcare organizations are finding that it is more beneficial to focus on their own interoperability architecture. As interoperability capabilities and demands for data have grown over time, the need for additional methods of data exchange has grown.
Enter the API method of health data exchange.
An API is a set of standards that enable communication between multiple sources such as EHRs, mobile applications, devices, etc. APIs provide a standardized, public interface so any authorized application can receive and/or send data with the proper security authentication. When EHRs have an API, authorized third-party applications and downstream systems can input and/or leverage existing data within the system’s database.
APIs are based on web service data exchange standards. HL7 International has developed HL7 FHIR, which is ideally suited for API data exchange. With 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.
API usage can be broken down into two categories:
- APIs for traditional provider integration strategy
- Open API for patient data sharing
APIs for provider integration
APIs offer the ability to supplement the current methods of HL7 v2 exchange by offering a cheaper, lighter, and easier format of interoperability powered by RESTful web services. Providers can create a robust API and gain the flexibility to facilitate external data-sharing requests by simply sharing their approved API standard.
As API use grows, potential workflows could replace VPNs and allow applications to have access to data as it becomes available. This new approach can provide real-time data for value-based care initiatives such as precision medicine, patient-facing mobile apps, population health, and predictive analytics.
Open API for sharing patient data
Access to data via an API allows the aggregation of medical history for use by applications chosen by the patient or the provider. While current use cases are unlimited, the latest versions of EHRs provide access to data via an open API. EHR applications allow patients to directly request their health data via portal or their chosen application.
To provide a patient’s complete medical record via API, providers must consolidate data and return it via API. While much attention previously was placed on the EHR application, the integration layer, powered by an integration engine, must serve as the catalyst for all health data activities and allow IT departments to gain full control of their patients’ health data. (See Figure 4.)
How APIs work
Vendor-specific APIs allow other technologies to look inside their databases. These APIs control the amount of openness it provides other applications. Some only allow the ability to read data with the API. Others allow the ability to read, write, and delete to the database using a specified set of standards.
APIs allow interaction with the data within the secured database, but it alone is not an industry-wide interoperability solution. That’s where HL7 FHIR becomes applicable. APIs using FHIR allow applications to access health data at the source of truth in a standardized way. This type of access introduces new ways to interact with patient data that offer truly exciting opportunities. FHIR provides the standard that will allow API integration to scale from proprietary internal applications outside the four walls to include other applications and providers that adhere to the standard’s specifications.
HL7 v2 is a well-established standard that works well within institutions to connect enterprise applications. Its design is limiting to modern devices and apps that are trying to leverage available patient data. Privacy and security are also difficult to implement.
The FHIR standard presents an API designed with a more lightweight method of data exchange. The standard, which is being employed as the data standard by choice by all major EHR vendors for their open APIs, will designate a guide for data semantics that will break down many of the prior barriers to API interoperability.
Smaller mobile applications are typically not able to handle v2 messages and its requirement to be on the network with a persistent connection. They may only need or utilize one or two HL7 segments. API data exchange using FHIR allows lightweight applications to only request the data elements, packaged in resources, that is needed for the product’s function.
Because EHR APIs across the industry will utilize the same FHIR standard, smaller applications will only have to worry about defining their data structure correctly one time – as opposed to HL7 v2, which allows for optionality in the way the data is presented by each EHR.
Security is also easier with FHIR because it utilizes RESTful web services, which is available in Corepoint Integration Engine. Web services has readily defined security protocols (HTTPS) along with commonly used authentication techniques such as Oauth 2.0. Being able to leverage widely used security standards makes implementation much easier than was capable with v2 integration.
The powerful combination of the FHIR API with web services means that the future of healthcare technology could resemble integration that is familiar outside of healthcare, such as in social media newsfeeds.
What’s the difference between an API and a web service?
A FHIR API defines the layer on top of an EHR that allows other applications to interact with its data. This layer defines a set of data elements that outside applications must use to send or retrieve data via the API. Those elements and standards will be defined by the FHIR standard.
A web service is a type of data transport protocol that provides a standard way for systems to securely move data across a network. The web service methods allowed by specific applications are defined by the API and differ in how they are used by various healthcare applications.
APIs offer mobile applications greater opportunity for real-time interoperability. These might include methods to post, update and retrieve more complex clinical data. An EHR’s FHIR API, for example, details what data it will accept from outside applications and also what data in its database is available for external access by the mobile application.
The Web Service functionality in Corepoint Integration Engine makes it easy for customers to exchange data by complying with the FHIR API standard or a private API. Corepoint Integration Engine Web Services allows both RESTful and SOAP-based transactions.
Currently in healthcare, a majority of web APIs are primarily used to transmit data to various government agencies to fulfill basic public health reporting requirements. These interfaces function similar to traditional FTP or TCP/IP interfaces, but are transmitted securely over the internet. The APIs for these interfaces commonly only use the post method and are very simple in data definition.
Using FHIR and web APIs
Because it is a new standard, healthcare organizations are just now beginning to test the waters with FHIR APIs within the four walls of their organization. Many applications currently use FHIR to exchange data through an integration platform such as Corepoint Integration Engine, which can also simultaneously orchestrate HL7 v2 interfaces.
The most interesting aspect of FHIR APIs is not the data exchange mechanisms behind the scenes, but the new opportunities it presents to improve patient care. Developers and applications will have access to the patient’s most current health record as a single source of truth, which is not possible in a HL7 v2 transaction. This new ability broadens horizons for patient-provider communication, care coordination, and workflow improvement.
For years, providers and developers have asked for access to data that is trapped inside EHR vendors’ databases. External providers, technology vendors, payers, health research organizations, and other trusted entities will soon have access to discrete data at the source of truth within the EHR.
Push vs pull models of exchange
APIs allow applications to pull the data it needs from the current source of truth when it is needed. Traditional v2 interfaces continually push patient data each time it is updated within an application.
An application with approval to connect to the EHR’s API can ask about the status of particular pieces of information about a given patient, such as order status, room number, current blood pressure, location, etc. This piecemeal, real-time approach is not possible with v2.
Providers can get creative with APIs to find non-healthcare uses of the data to improve operations, such as alerting housekeeping that a room is available for cleaning.
For more detail, a typical workflow for admitting a patient may require the following technical steps:
- Look for the patient ID in the master patient index
- Search for an empty bed of a particular type
- Look for the physician and his/her location in the provider directory
- Search for and confirm insurance coverage
- Choose demographics information (gender, religion, ambulatory status, etc.)
Traditional v2 interface transactions take several steps to find the needed information. Traditional interfaces push these data transactions from the database – an HL7 ADT interface is constantly transmitting information each time a particular patient’s information is updated.
This process can be greatly streamlined if the application has direct access to all the needed information via API. Having access to the patient’s single source of truth allows the application to easily query the database for the particular items it needs, and only when it is needed. Additionally, an API transaction does not require the application to store any data it does not need, which has been a longstanding barrier to integration for smaller mobile applications.
SMART Health IT
SMART Health IT is an exciting initiative that is run out of Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department for Biomedical Informatics.
Formerly called SMART on FHIR, the program is an open, standards-based technology platform that enables innovators to create apps that seamlessly and securely run across the healthcare system. Using an EHR or data warehouse that supports the SMART spefications, patients, doctors, and healthcare practitioners can draw on this library of apps to improve clinical care, research, and public health.
The SMART platform is composed of open standards, open source tools for developers building apps, and a publicly accessible app gallery. SMART innovations will very likely influence how the entire industry exchanges data using FHIR APIs.
Apple uses SMART to connect the iPhone’s Health app to hospitals and doctors’ offices. The good news for patients, doctors, and innovators is that Apple chose a standardized, open connection over a proprietary, closed one. This approach lets any other app, whether running on the web, iPhone, or Android, use that very same interface to connect.
Another example of a SMART innovation is specialized charting. This concept allows the organization to create a chart customized for a specific patient. This chart, which is created in the cloud, is populated with data from various application databases. The chart is displayed to caregivers directly in their EHR so they can better inform a patient about their specific diagnosis.
A specific use case of specialized charting is a cardiac test. The cardiologist wants to provide the patient with a personalized chart that shows their cardiac risk in a graphical, more understandable format. That same chart cannot be created directly from the cardiologist’s EHR, but the EHR contains the needed lab results. Those results are fed to a web application, using FHIR APIs, that produce a printable PDF chart that can be delivered to the patient.
Learn more about the SMART initiative at SmartHealthIT.org.
Future outlook: A hybrid approach to data exchange
Over the past five years, many healthcare IT departments have shifted away from a best-of-breed approach of software selection toward the single suite offerings from the industry’s leading EHR vendors. The suite approach is appealing to providers because it can be easy to manage and offers modules that have greater access to patient data because they run on the same database as the parent EHR.
As FHIR API connectivity becomes widespread, EHR databases will become much more transparent. External provider- and patient-facing applications will have the ability to import and export data more easily without the need for providers to directly access the EHR database. This change will likely create a fundamental shift away from dependence on EHR functionality.
According to the HIMSS Analytics Cloud Survey, 83% of heatlhcare providers use some sort of cloud service or application within their IT architecture. However, 85% of EHRs are on-premise applications, which means traditional v2 interfaces will be in use for many years to come.
The juxtaposition of on-premise EHRs and cloud use – combined with the groundbreaking FHIR API approach to data exchange – requires an extremely flexible, platform approach to managing health data. Modern health 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) to ensure that each application and caregiver has the right patient data, with the right insights, at the right time.
Providers will need to share traditional HL7 v2 messages over TCP/IP and route it into an FHIR API, which offers 100s of potential opportunities to improve workflow and patient care. A modern interoperability platform like Corepoint Integration Engine provides the needed flexibility and industry expertise to support traditional interfaces in conjunction with FHIR APIs.
Leading providers already 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 application databases. More importantly, the future FHIR API economy means that CIOs can reap the benefits of choosing the right technology for the job.
As shown in Figure 5, a data framework powered by Corepoint Integration Engine can contain many different workflows and uses. Healthcare systems need to handle complex data workflows that blend modern web APIs with proven v2 interfaces. Adding to the mix the vast array of additional applications a healthcare provider may have, the build starts to get complicated. Corepoint Integration Engine provides the versatility providers need in a more connected and open health data ecosystem.
Corepoint Health is committed to playing a leading role in delivering interoperability confidence for healthcare providers, including product support for API integration across healthcare applications. Corepoint Health has focused its API capabilities in Corepoint Integration Engine on robust FHIR API support, while also supporting generic APIs through Action List operators and web service connections.
Beyond FHIR, Corepoint Integration Engine provides tooling to define and configure interfaces to published APIs from a third party vendor. For example, Corepoint Health and its customers have configured API integration with Microsoft Dynamics, Curaspan, Care360, Vocera, Surescripts, Salesforce, Kareo, AdvancedMD, Athena IODocs, Secure Exchange Solutions, Zotec, and more.
This new mix of data across web API sources is managed seamlessly with traditional sources through the monitoring, alerting, and debugging capabilities of Corepoint Integration Engine.
Answers from Dave Shaver, Corepoint Health CTO and co-chair of the HL7 FHIR governance committee.
Will FHIR ensure better consistency?
How do we get more consistent in our approach to interoperability? I think as we learned in the days of HL7 v2, we can extend HL7 v2 through the use of Z segments that allow us to send virtually any data that we want. We learned that if there’s no standard way to profile a Z segment, they truly become proprietary.
That’s an important parallel to draw to what we do with proprietary APIs. A proprietary API is almost always synchronous with the database. They may not allow true interoperability, but they do allow the application to talk to the data and its source of truth. These APIs present the same challenges as Z segments in v2.
In developing HL7 FHIR, we followed the 80% rule: if we believe that 80% of the vendors would likely support or need this segment, we try to standardize that portion of the data model to provide for interoperability with other systems. If it doesn’t meet the 80% threshold, we push it off to an extension, which is similar to a Z segment in v2.
FHIR allows developers and providers to extend the data profile through extensions, but there is a formal framework that allows those extensions to be profiled and shared. For example: If there’s a particular state requirement or a particular cancer reporting infrastructure issue, rather than having to create Z segments, FHIR can build a standard profile and publish it online so all parties can see what those extensions look like.
How should providers evaluate an integration engine’s readiness for FHIR APIs?
There are many reasons to upgrade your platform if you’re still writing code to build interfaces. There are other options that allow interfaces to be created more simply and more succinctly. You might look at uplifting your technology over time, rather than rip and replace. You can look to add or augment your engine with a Corepoint product or some other product that is more efficient at building interfaces, particularly using FHIR.
All healthcare providers should carefully evaluate the vendors they depend on. In the context of an integration engine, evaluate what level of participation the vendor has in industry organizations, such as HL7 and IHE International. Are they helping to build and fine-tune standards such as FHIR? Do they hold committee membership?
This type of evaluation goes beyond simply checking a box that says “they support FHIR.” Vendors that actively participate in standards development stay two steps ahead of other vendors. Here at Corepoint, for example, playing a leadership role in the industry helps our development team get a head start on product features that will be perfected and tested long before they become needed throughout the industry.
What is the status of FHIR? Who is currently using the standard?
For several years, many individuals and vendors have been testing and using the early versions of FHIR. In fact, one of the very first steps in the maturation of a standard is to test and successfully exchange data between at least three independently developed systems.
Many people rightfully ask, “When is FHIR going to be done?” The answer is that the normative edition of FHIR, Release 4, will likely be published in late 2018. Release 4 will still contain components that are normative and others that are still in their trial use state, meaning they haven’t moved far enough along in the maturity model to be considered final.
Everyone would like to hear that there are many providers using FHIR in production in their hospitals, but those stories are limited at this point in time. However, all major health IT vendors are currently participating in the creation of APIs using FHIR.
Users can’t take advantage of FHIR until it’s available for use in the applications – and only when those new versions of the software are actually installed at the hospital. Without a doubt, the industry is moving faster to implement FHIR than all previous standards.