Benefits of load balancing Epic Electronic Healthcare Records (EHR)
The main benefits of load balancing Epic EHR are High Availability, performance, and scalability, which are critical for continuous and quality patient care:
- High Availability (HA): By distributing traffic across multiple servers, if one server fails, the load balancer automatically redirects users to other healthy servers, preventing system outages and ensuring continuous, uninterrupted access to critical patient data for clinicians and caregivers. Servers can also be taken offline for scheduled maintenance or upgrades without disrupting service to end-users, as the load balancer routes traffic away from them.
- Optimized performance: The load balancer distributes incoming requests evenly (or based on intelligent algorithms) across the server pool, preventing any single server from being overwhelmed by traffic spikes. This ensures consistent speed and responsiveness for users accessing applications like Epic Hyperspace and MyChart. Advanced load balancers can also offload the processor-intensive task of encrypting and decrypting secure (HTTPS/SSL) traffic from the application servers, dramatically increasing the performance of the Epic applications.
- Scalability: Load balancing allows the Epic system to easily accommodate a high volume of concurrent users and data access, which is essential for large healthcare organizations and during peak usage times. As a healthcare organization grows or user demand increases, new servers can be easily added to the cluster, and the load balancer immediately begins sending traffic to them. This ensures the infrastructure can scale effortlessly without compromising performance.
About Epic EHR
The Epic EHR (Electronic Health Records) software suite brings together essential tools for clinicians and patients in the healthcare space, including Epic Hyperspace and Epic MyChart:
- Epic Hyperspace is a clinician-facing platform. It’s a front-end client used to access most parts of the Epic software suite, including patient charts, prescribing, and even print services.
- Epic MyChart is a patient-facing web portal. It gives patients the ability to view their medical records and test results, manage their appointments and prescriptions, and more.
Why Loadbalancer.org for Epic EHR?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Epic EHR
The load balancer can be deployed in four fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Epic EHR, Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for Epic EHR, the following VIPs are required:
- Hyperspace
- Hyperspace redirect (to force inbound HTTP traffic to use HTTPS)
Optionally, additional VIPs may be required as follows:
- MyChart
- MyChart redirect (to force inbound HTTP traffic to use HTTPS)
The following table shows the ports that are load balanced:
| Port | Protocols | Use |
|---|---|---|
| 80 | TCP/HTTP | Redirect to HTTPS (not strictly load balanced) |
| 443 | TCP/HTTPS | Web Services |
Load balancing deployment concept
The load balancer can be deployed as a single unit, although we recommend a clustered pair for resilience and high availability. The deployment concept is as follows:
Load balancing topology
Layer 7 Reverse Proxy can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth1 is typically used for client side connections and eth0 is used for Real Server connections, although this is not mandatory since any interface can be used for any purpose.
For more on one and two-arm topology see Topologies & Load Balancing Methods.
About Layer 7 Reverse Proxy load balancing
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods. Layer 7 is typically chosen when either enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.
The image below shows an example Layer 7 Reverse Proxy network diagram:
Because Layer 7 Reverse Proxy is a full proxy, Real Servers in the cluster can be on any accessible network including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default, i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address).
This can be configured per Layer 7 VIP. If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in 2 ways. Either by inserting a header that contains the client’s source IP address, or by modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client. For more information on these methods, please refer to Transparency at Layer 7 in the Enterprise Admin Manual.
