Connecting the Disparate: Middleware’s Role in Solving Healthcare’s EHR Interoperability Problems

By Donald M. Voltz, MD

According to data published on HealthIT.gov, 173 health IT vendors are supplying certified electronic health record (EHR) products to more than 4,500 hospitals. Despite wide penetration of EHRs in hospitals, clinics, and physician offices, a lack of access to patient information between systems continues to plague the US healthcare system.

Most physicians feel they have a duty to provide the best care that addresses patients’ health needs with the least possible risk of adverse events. Physicians can look at the EHR implementation history from a similar perspective. EHRs should offer the ability to collect, store, and allow for timely, accurate, and appropriate access to patient health information from any and all healthcare providers who require the information to meet the needs of their patients. Medicine is a data-intensive field involved in risk assessment and reduction and/or mitigation of risks during the course of treatment. At the same time the medical field must be cognizant of the limited resources available and the costs incurred by patients, employers, and the entire health system.

No matter what area of healthcare or what role one plays in the care of patients, all have a stake in the art and science of medicine as well as the economic implications of physicians’ decisions. The same requirements and limitations placed on healthcare providers from the care delivery side are impacting all providers on the technology side with the requirements put in place for EHR use.

In the past, the vast majority of healthcare providers were not tech savvy. Many have worked very hard to overcome their discomfort with computer charting and other technical requirements that are now omnipresent in medicine. Access to patient information, not only that which is individually collected, but all of the information collected across a care continuum, not only adds value and accuracy to the decisions made in the management of a patient, but also impacts the cost of care to the patient and system.

Healthcare stakeholders have learned a great deal about technology from other industries that has direct implications for their industry. Competitive advantage does not come directly from the implementation of technology, but instead from the information that is enabled by the technology. EHRs alone will not solve the needs of patients or providers. But they do have the potential to greatly impact the way care is delivered, and help to realize the value contained in patients’ health data, both for the acute illness as well as the chronic medical conditions that can span a lifetime. The question of how to best realize the value contained in the rapidly expanding database is still open for debate.

The most promising value from health data comes from connecting the pieces. Now software called middleware is beginning to help connect those pieces and finally make disparate EHRs interoperable. It is not a day too soon. Enabling real-time access to patient data by the providers who are making decisions in the office, in the emergency department, on the wards, or in the operating room is no longer a luxury, but a requirement for patient safety, quality, and cost effective care.

To do this requires one of two approaches: collect every piece of patient health data in a single or tightly coupled set of databases, or develop an interface to the various EHRs. The decision cannot be taken lightly given the inherent risks as well as the unforeseen consequences that can occur as healthcare providers scale data.

Cost and risk are two of the major determinants of how we solve the data access problem for healthcare. A third issue, often downplayed, is the ability to respond to new technology. In the era of Big Data, one is easily fooled about the integrity, providence, and accuracy of data that are moved from one system to another. Knowing where a piece of information originated can make all the difference in catching and addressing an issue before a negative outcome or missed diagnosis is made.

Solving the healthcare interoperability challenge by establishing large data warehouses where all patient data eventually is stored leads to duplication of data. This is a cumbersome, risk-prone solution where issues are often not realized until they are questioned at the point of care, where accuracy and trust in the data source is a requirement.

Middleware More than Simple System Glue

Middleware, software that serves to connect previously disconnected systems, has shown value in many data-intensive sectors outside of healthcare. Middleware goes beyond the simple “gluing” together of two disconnected systems. It often serves to synergize and produce more than the sum of the two systems together.

Expanding the functionality of EHRs is an attractive thought for many in healthcare. However, EHR technology takes time to advance. There is no question that establishing and maintaining a robust, secure, and fault-tolerant back end database is an absolute requirement for EHR systems. However, the need to focus on the back end solution slows the ability to add additional features that are required by patients, providers, administrators, and leaders in healthcare.

Healthcare 2.0 vendors have demonstrated that middleware-based EHRs go far beyond the limitations present in non-interoperable EHRs. Adding additional functionality to patient data has been accomplished with a seamless connection to disparate EHR systems. An additional benefit of this technology is that frontline providers no longer need to worry about accessing many different systems to manually utilize data for patient care.

Those with open application programming interfaces (APIs) have the ability to develop health IT solutions once and then deploy them to various EHRs at a fraction of the cost and with much less risk than doing the same development directly on top of the EHR code base.

API’s Role in Connecting EHRs

An application program interface (API) is an interface that enables programmers to work with apps in a standardized way much like a key interacts with a lock to open a door. The API allows programmers to extend an application developed by someone else without having to get into the code of the initial application, which could also risk corrupting the code. As a key component of middleware’s service-oriented architecture (SOA), APIs are a software-to-software interface allowing two pieces of software to communicate.

For example, if you have a software application requiring users to sign in and authenticate themselves, you could utilize an API developed by Google to do this. When a user logs in to your program, it contacts the Google Server to authenticate the information entered by the user. When Google returns a successful authentication of the user, your application can then allow access.

In an EHR using middleware, medical application developers can interact with EHR data in a standardized manner. This SOA software architecture allows different EHR systems to connect, creating interoperability. A middleware API connecting various EHR systems allows developers to build customized applications that interact with EHRs without needing to rewrite code for each individual EHR system. The applications are endless—from an iPhone and iPad dashboard screen view of patient data to alert escalation apps ensuring data is sent to the right place at the right time.

HL7 vs. Middleware

Health Level Seven (HL7) also addresses interoperability through its standards work, but some feel middleware has distinct advantages. HL7 is a standard protocol to decode message interactions. Middleware uses an open API as a programmable interface to applications. While HL7 can wrap and compile data, each medical facility receiving that data would still have to create its own interface with the data from the sender in order to communicate. This defeats the purpose of the seamless interoperability provided by middleware.

HL7 is an interface defined through specific end points; Hospital A to Hospital B, not EHR vendor 1 to EHR vendor 2. Hospitals C and D, even with the same EHRs, could still not communicate with Hospitals A and B. To achieve middleware style interoperability, HL7 developers would have to build a customized solution for each healthcare facility rather than one overall commercial solution.

To overcome this obstacle, developers wrapped HL7 with JavaScript Open Notation (JSON), an open format that uses human-readable text to transmit data between a server and web application. However, this is seen by many as yet another cumbersome step. A middleware open API does not tie developers to specific hospitals or EHRs.

Potential Downsides to Middleware’s Use in EHRs

Employing a middleware architecture has been shown to reduce risk as well as cost of development, but it is not without critics. Opponents of middleware raise concerns about having to learn the middleware development platform before seeing the benefits of the platform.

With respect to EHRs, non-vendor development is not possible or scalable. Although vendors with high market penetration have introduced API’s and development platforms for their systems, development requires new strategies, code, and resources for each system.

This alone limits widespread implementation of solutions that sit on top of EHR systems or access health data stored in their databases.

Middleware Allows User Interface Standardization Across EHR Systems

Well designed middleware architecture allows a user interface development to be easily standardized across EHR systems to provide visual consistency for healthcare providers, something that has been demonstrated to aid in safety and efficiency. And the good news is it is an easy “plug and play” type of IT application.

Service Oriented Architecture is known for its “plug-and-play” approach on existing legacy software solutions. Its approach is to extract features and functionalities from the legacy software solutions and extend them to more focused, fast cycle solutions. Many popular cloud-hosting services can extend such SOA applications in a “pluggable” approach to the IT operational environment for quick and easy installations. It also solves specific needs at a fraction of the cost required for development for each EHR platform and should be embedded with the healthcare applications. Its pricing is based on its embedding application. Middleware can offer significant value-added capabilities to EHR systems in medical error reduction at a fraction of the overall EHR system cost. While prices vary, a cost example from one Healthcare 2.0 middleware vendor is about two to four percent of the entire application.

Increasingly, organizations in all sectors are realizing that software, platforms, and architecture offer services that significantly decrease business costs. No longer does a company have to do all of the development themselves, but instead is able to rely on off the shelf applications to solve its problems while allowing for middleware to connect the various systems where data resides.

Middleware brings an application-agnostic approach to connect EHRs to one another while allowing for specific development to enhance the significant investment by hospitals, health systems, and physicians. The approach also allows for scaling, something that centralized or federated health information exchanges (HIEs) will continue to have issue with in solving and dealing with data access.

Middleware has Potential to End Interoperability Issues

The healthcare industry is still early in the overall lifecycle of its EHRs. Although implementation has been widespread through government incentives, healthcare stakeholders are still struggling to find efficient and effective ways to utilize these systems. The search for high quality and effective patient care continues, along with the need to develop solutions to meet the needs of patients so they become engaged with their data and their care.

These issues will require the creative and innovative connection of data to bring meaning and insight into that data. Middleware allows for the spreading standard of “software as a service” (SaaS) as the mindset for EHR platforms. The benefits are great while preserving value on the infrastructure already in existence. As consumers have seen in the retail and financial industries, middleware has transformed technology to bring about uses of data to solve problems. Credit card point of sale terminals can be connected across global retail chains and banks just as EHRs can be connected across the healthcare continuum, on any mobile platform. While middleware is very new to the healthcare sector, there is hope by proponents that its use will make healthcare the next new frontier to end its lack of interoperability.

Donald M. Voltz (donald.voltz@gmail.com) is medical director of the main operating room in the department of anesthesiology at Aultman Hospital, and assistant professor of anesthesiology at Case Western Reserve University and Northeast Ohio Medical University. Board-certified in anesthesiology and clinical informatics, Dr. Voltz is a researcher, medical educator, and entrepreneur. Thanh Tran, CEO of Zoeticx, also contributed to this article.