Load balancing Oracle Health EHR

Updated on November 25, 2025
Published on July 15, 2024

Benefits of load balancing Oracle Health EHR

Load balancing Oracle Health EHR provides a number of benefits, including:

  • High Availability (HA) and reliability: Load balancing is crucial for eliminating a single point of failure. It ensures that the EHR system remains accessible even if one or more application or database servers fail or need maintenance. By distributing traffic across multiple healthy servers, if one server goes down, the load balancer automatically redirects all incoming requests to the remaining healthy servers. This is vital for a healthcare system where downtime can directly impact patient safety, treatment decisions, and critical administrative tasks.
  • Enhanced performance and response times: By evenly distributing the heavy workload (e.g., clinicians accessing patient charts, running reports, handling concurrent user logins) across all available servers, load balancing prevents any single server from becoming overwhelmed. It maximizes resource utilization and minimizes the response time for users, meaning faster access to patient data, lab results, and decision-support tools. It handles sudden surges in demand (like during peak hours or system-wide events) by scaling resources effectively, maintaining a consistent and fast experience for all users.
  • Scalability and flexibility for growth: As a healthcare organization grows—adding new facilities, more clinicians, or integrating new applications—the demands on the EHR system increase. Load balancing enables the infrastructure to scale seamlessly. You can easily add more application or database servers to the back-end pool without disrupting the system. The load balancer automatically starts sending traffic to the new resources. It also allows IT teams to take servers offline gracefully for routine maintenance, upgrades, or patches (reducing maintenance windows) by first draining existing connections and redirecting new traffic to the remaining active servers.

About Oracle Health EHR

Oracle Health EHR is an open, connected Electonic Healthcare Record (EHR) system that helps surface better information within the patient record so clinicians can make more informed care decisions.

Why Loadbalancer.org for Oracle Health 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 Oracle Health EHR

The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode)

For Oracle Health EHR, we recommend Layer 7 Reverse Proxy.

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 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.

Layer 4 SNAT / Layer 7 Reverse Proxy Network Diagram Loadbalancer

Because Layer 7 Reverse Proxy is a full proxy, any server in the cluster can be on any accessible subnet, 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 two ways:

  1. Either by inserting a header that contains the client’s source IP address, or 
  2. 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.

Layer 7 Reverse Proxy mode can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth0 is normally used for the internal network and eth1 is used for the external network, although this is not mandatory. 

No mode-specific configuration changes to the load balanced Real Servers are required. 

Port translation is possible with Layer 7 Reverse Proxy e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.