Healthcare

Load balancing for enhanced interoperability

Introduction

EHR applications are continuously evolving to improve the efficiency of care. But always-on access to patient data starts with Loadbalancer.org. 

Integrating powerful, clever, easy-to-use, fully-featured application delivery and server load balancing, we are a key piece in the tech toolkit of healthcare providers.

 

Healthcare resources

Check out our library of healthcare resources to see how it works in practice.

Explore

Chapter 1

Chapter One: Interoperability challenges

What interoperability challenges exist in healthcare?

Healthcare interoperability allows applications, databases, and other computer systems to connect, communicate and exchange information with one another readily, even if they are built on different platforms by different vendors.

It is one of the most important pillars of any healthcare IT ecosystem, as care needs to be coordinated across different settings, with access to electronic patient records and test results, anytime, anywhere. In turn, data driven analysis and AI and machine learning are used to back-up clinical decisions and speed up the time to diagnosis. The reduced administration achieved through interoperability therefore improves the patient and clinician experience. But there are significant threats to achieving this. For example, layer-upon-layer of distinct teams exist across healthcare, using different types of data and resources in different ways, to do different things. So it’s not just accessing the data that’s a challenge –  it’s managing, analyzing and ensuring high availability of the data using cross-functional workflows.

Medical imaging interoperability

A critical element in patient care, access to diagnostic images is crucial at all times, especially when demand is unpredictable. Medical imaging provides a non-invasive procedure of taking images with a clinical application, using a variety of imaging modalities to provide a specified diagnostic picture of the body. Various modalities are used, such as CT, MRI, PET, Ultrasound and X-Ray.

To enable access to stored images and associated data, Digital Imaging and Communications in Medicine (DICOM) workstations are used. These connect directly to the DICOM source. Viewer servers are also used which enable client PCs to view DICOM images using a web browser via HTTPS.

The older PACS (Picture Archiving and Communication System) also exists. It has a reputation for being out of date and proprietary, although Loadbalancer.org has seen some great PACS implementations.

For our detailed guide explaining how to load balance medical imaging to solve interoperability issues, refer to the relevant Chapters in the below guide.

Medical imaging guide

Find out how to load balance medical imaging technologies.

back to the top
Chapter 2

Chapter Two: Interoperability standards and implications

What standards exist and what does this mean for interoperability?

The original interoperability HL7 v2 and 3 standards have been overtaken by the more recent HL7 v4 (FHIR). To facilitate a better healthcare environment for patients and providers alike, the purpose of FHIR is to address the need for patient records to be readily available, discoverable, exchangeable and understandable.

In order for these very different messaging standards to work together in harmony, they require a load balancer to ensure they all remain highly available to the end user, and communicate nicely with one another.

HL7 v2 and v3: The original interoperability standards

HL7

Health Level Seven (HL7) is the language used for communication between healthcare IT systems and electronic healthcare records that supports interoperability. It is an American National Standards Institute accredited Standards Developing Organization (SDO) operating in the health-care arena. Since its inception, HL7 has specified standards for a large number of application areas. HL7 standards cover generic application fields such as patient administration, patient care, order entry, results reporting, document and financial management. In addition to that, HL7 addresses the departmental information system communication needs of clinical specialties like laboratory medicine and diagnostic imaging.

There are a number of different HL7 standards to familiarize oneself with, which all need to be integrated if full interoperability of old and new systems is to be achieved.

HL7 v2

This was the first clinical messaging format for data exchange.

HL7 v3

This was developed to address some of the shortcomings of HL7v2. It is a more comprehensive messaging standard for health and medical transactions that includes a standard for electronic documents such as Electronic Health Records.

What is an Electronic Health Record (EHR)?

Simply put, an EHR is the paper chart of a patient presented in a digital format, holding information related to a patient’s medical history including medications, allergies, diagnoses, treatment plans, immunization dates, radiology images, and test results from laboratories. Built to go beyond standard clinical data collected in a provider’s office, EHR systems cover a broader view of patient care, thereby performing a vital role in the health IT infrastructure.

What cross enterprise document sharing interfaces exist?

Cross-Enterprise Document Sharing (IHE XDS) is a standard of systems for cataloging and sharing EHR. It is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility and personal health record systems. This is managed through federated document repositories and a document registry to create a longitudinal record of information about a patient within a given clinical affinity domain. These are distinct entities with separate responsibilities: A Document Repository is responsible for storing documents in a transparent, secure, reliable, and persistent manner and responding to document retrieval requests. A Document Registry is responsible for storing information about those documents so that the documents of interest for the care of a patient may be easily found, selected, and retrieved irrespective of the repository where they are actually stored. Documents are provided by one or more Document Sources. They are then accessed by one or more Document Consumers XDS/XDS-I enables sharing of non-DICOM (i.e. JPEG images, scanned documents, text-based documents) information across disparate healthcare systems.

XDS uses the following EHR standards to facilitate data exchange:

HL7 v4 (FHIR): The new interoperability standard

Fast Healthcare Interoperability Resource (FHIR – pronounced ‘fire’), is a standard for seamless healthcare data exchange and application programming interface (API) for exchanging EHR, published by HL7 (Health Level Seven International).

Currently in its fourth iteration, FHIR is a standard describing data formats and elements (known as ‘resources’) and an application programming interface (API) for exchanging electronic health records. Built off of previous HL7 clinical and admin data standards — v2, v3, and clinical document architecture (CDA), it can be used as a stand-alone data exchange standard or in conjunction with existing standards.

FHIR offers the promise for achieving smooth healthcare interoperability leading to patient-centered, data-driven care. By taking a modern, internet-based approach to connecting different discrete elements, it is paving a way for EHR systems to talk to each other, and healthcare apps to communicate with EHRs using a format that is widely understood and used in the web-application industry (RESTful web services). Moreover, it may also provide the first reliable gateway for patient-generated health information from millions of fitness trackers, smartwatches and blood pressure monitors to merge with clinical data in doctors’ offices, hospitals, and medical labs. By aggregating health records from various health institutions alongside patient-generated data, FHIR is likely to present a more holistic view of a user’s health condition.

FHIR has been designed with the complexity of healthcare data in mind. The need for a framework like this arose due to the inconsistency of EHR systems at various medical sites such as hospitals, surgeries, care units, and doctors’ clinics. One of the key challenges in the healthcare industry right now is to achieve coordinated care because of the lack of interoperability between electronic healthcare systems. FHIR enables interoperability between EHRs and related healthcare applications such as mobile apps and cloud communications, allowing clinicians to have the best information available at the point of care when making diagnosis and treatment decisions.

FHIR facilitates the same independence and ease of use by allowing developers to build standardized browser applications that let patients and healthcare providers access data from any EHR, helping them manage prescriptions, monitor test results, refer to health records and do a lot more. This results in meaningful care coordination, better decision-making, and advanced data analytics.

FHIR caveats

FHIR has arrived as the hottest new standard hitting the healthcare industry with an aim to make it easier for everyone to view and share medical information. An estimated 85% of hospitals in the US have the FHIR API available for most major EHR systems today, allowing patients access to data, such as medications and laboratory results. But it is yet to be used for providers to exchange information because, until recently, there was limited advocacy by health care providers to create the necessary demand for FHIR’s adoption – according to Micky Tripathi, the President & Chief Executive Officer of the Massachusetts eHealth Collaborative (MAeHC) and chairperson of the advisory council of HL7.

In fact, health records giant Epic Systems opposed the policy proposed by the US Department of Health and Human Services (HHS) that would allow patients easy access to their medical data. However, according to HHS’ final interoperability rules announced at the beginning of March 2020, it confirmed that patients will now have more electronic access to, and control of, their personal health information at no cost. As per these rules, both public and private entities must share health information between patients and other parties while keeping that information private and secure. The rules are focused on preventing information blocking, facilitating patient access to health data stored in EHR and moving healthcare systems towards greater interoperability as part of the current administration’s MyHealthEData Initiative. HHS considers these rules as the most extensive healthcare data sharing policies implemented by the federal government so far.

Clearly, HL7 FHIR has caught on faster than any other interoperability standards since it was first unveiled. With the accumulated wisdom of many experts, it is opening the doors to innovation by addressing many of the problems associated with traditional health IT such as domain complexity, data modeling, storage and custom integrations with older systems. But it’s important to bear in mind that FHIR was built only to do big things for data exchange and not meant to address technical considerations. As such, it does not tackle infrastructure and technological concerns such as system architecture, system-to-system integration, security, and analytics. Besides, it’s not a security protocol, nor does it define any security-related functionality. Nevertheless, FHIR is a powerful tool in the hands of healthcare innovators.

For more detailed information on FHIR check out the following white paper:

White paper

Find out how load balancers facilitate interoperability within the healthcare IT ecosystem.

The variety of standards and need for load balancing

A summary of the benefits and limitations of each HL7 standard described above can be found below.

Interface Benefits Limitations
HL7 v2
  • The most widely used healthcare standard.
  • Supports most common healthcare interfaces globally.
  • Provides a ‘non-standard standard’.
  • Reduces implementation costs.
  • Generally backward compatible.
  • An implied data model i.e. an absence of formal methodologies with data modeling, creating inconsistencies and difficulties in readability.
HL7 v3
  • Includes electronic documents (CDA/CCDA), as well as messages.
  • Therefore incorporates abstract data models.
  • Complex
  • Not backwards compatible with HL7v2 which means adoption has been slow.
HL7 v4 (FHIR)
  • Builds on previous v2 and v3 data format standards from HL7.
  • Completely open source.
  • Define security mandates and transmission protocols which lower the risk of errors
  • Have real-time ability to share and access data.
  • Many of the v3 models are quite abstract, which makes mapping them to FHIR tricky.
  • Mapping all of CDA to FHIR is impossible given the abstract nature of the v3 model, although mapping Consolidated-CDA (CCDA) templates to FHIR is possible.

Ensuring these different messaging standards communicate nicely with each other is no minor challenge. Load balancers sit across all of these disparate workflows, allowing them to work together properly, and remain highly available to the end user.

back to the top
Chapter 3

Chapter Three: The role of load balancing in interoperability

How can load balancing facilitate healthcare interoperability?

Implementing a load balancing solution can help solve communication issues between cumbersome interfaces, data scalability problems and issues related to accessing and connecting data that resides in numerous, often disconnected health data systems located within one setup or spanning across multiple geographical locations.

Load balancing can ensure high availability by preventing healthcare systems from falling apart whenever there is heavy traffic or data overload, helping clinicians with continuous data access. And additionally reducing workflow interruptions and employee inconveniences caused due to system failures.

As more modalities and newer scanning technologies like 3D mammography are being introduced in hospitals, the storage demand has increased significantly. A load balancer can enable additional storage to be added and seamlessly integrated into a hospital’s storage system to match their massive storage requirements and handle the increasing workload. Most hospitals also face data migration challenges while replacing legacy systems with modern databases. Implementing a load balancer can help in extracting, standardizing, transferring and making data usable for augmenting various digital technologies like AI, analytics, machine learning, etc. Healthcare organizations also face multiple issues around security requirements for accessing certain data. In such cases, a load balancer is able to encrypt the transfer of data from one location to another, allowing users to access that data via a secure connection.

Refer to Chapter Four below for an example use case.

back to the top
Chapter 4

Chapter Four: Example - Load balancing for seamless interoperability

How can load balancing be used to achieve seamless interoperability?

Step one: Determine your load balancing needs to deliver interoperability

Healthcare interoperability enables computer systems to connect, communicate, and exchange information with one another readily, even if they are on different platforms, used by different vendors. But that means the various software, networks, databases and applications need to exchange data and present that back to the user in a way that can be understood.

A large proportion of work that load balancers do is taking data from a modality (e.g. a CT or MRI image generated by a scanner), making a decision about where that image needs to be stored, and using a particular standard of communication with a health records system so it can be integrated. Because all this information traverses the load balancer, it is able to make intelligent decisions about where that data needs to go.

Step two: Configure your load balancer to achieve interoperability

You may wish to see an example of how Loadbalancer.org helped this healthcare integration engine optimize their interoperability capability.

The case study below outlines how load balancing NextGen Connect enables the management of information using bi-directional sending of many types of messages and HL7 formats.

Deployment guide

Find out how to load balance NextGen Connect.

back to the top
Chapter 5

Chapter Five: The role of load balancing in EHR

How can load balancing optimize EHR?

EHR systems help coordinate care among multiple healthcare providers, giving them access to a patient’s most recent health data. As more and more healthcare providers around the world are now moving away from paper-based health records to EHRs to make real-time, patient-centered information available instantly and securely to authorized users, more patients are now receiving better-coordinated, higher quality care.

HITECH compliance

In the US, although the transition was not overnight, the use of EHR has become much more widespread since the passage of the HITECH Act signed into law in February 2009, with adoption rates increasing three to nine-fold depending on the practice setting.

The Act requires the adoption and ‘meaningful use’ of electronic health records (EHR) technology by US-based healthcare providers. ‘Meaningful use’ means that healthcare providers need to demonstrate their commitment to using EHR in a way that can be measured in both quantity and quality.

Data protection and GDPR

In the UK, the Data Protection Act (DPA) and GDPR mean that patient records must similarly be safeguarded.

It is therefore imperative that patient records remain stable and secure to avoid data loss, and ensure high availability.

Using load balancing to protect EHR

Deploying a load balancer makes critical EHR applications stable and highly available – ultimately improving the quality of patient care.

Implementing a load balancing solution in front of an EHR system:

  • Ensures reliable access to critical systems for physicians and caregivers
  • Helps increase the IT staff’s efficiency
  • Can introduce a complementary layer of security
  • Supports health centers in provision of an ‘always available’ application environment.

By dynamically interrogating key server elements such as the number of concurrent connections and CPU/memory utilization, intelligent load balancing algorithms mean that load balancers distribute and direct users to the best performing, accessible servers, thus avoiding server bottlenecks and application failure. This ensures EHR applications are available and always running at optimum performance, ensuring instant access to data for clinicians and patients.

In the event of a server failure, application inaccessibility, or scheduled maintenance, a load balancer can take that server offline, while automatically rerouting users to other healthy and functioning servers. By managing the traffic to EHR systems, a load balancer helps avoid system outages and downtime – essential for every healthcare setup delivering 24/7 patient care. Moreover, installing advanced load balancers provide SSL acceleration, thereby dramatically increasing the performance of EHR applications, while decreasing the time and costs involved, and further enhancing the overall user experience.

back to the top
Chapter 6

Chapter Six: Example - Load balancing for EHR optimization

How can load balancing optimize EHR?

To find out how Loadbalancer.org helped a US government healthcare institution achieve interoperability across its multi-site IT infrastructure, while also getting the most from its critical Electronic Healthcare Records solution, take a look at this Meditech deployment guide.

Want to find out more?

Download our online demo or start a free trial.

back to the top