Benefits of load balancing Greenway Health PrimeSuite

Load balancing an Electronic Health Record (EHR) and Practice Management system like Greenway Health PrimeSuite provides the following benefits:

• Maximized High Availability (HA): In a healthcare setting, downtime is not just an inconvenience—it can compromise patient care. Load balancing ensures the PrimeSuite application is continuously accessible. Load balancers perform continuous health checks on all PrimeSuite application servers. If one server fails due to a hardware or network issue, the load balancer automatically detects the failure and instantly redirects all traffic to the remaining healthy servers. By having multiple redundant servers and a resilient load balancing mechanism (often deployed as an active-standby pair), the entire EHR system avoids a single point of failure, ensuring physicians, nurses, and staff maintain uninterrupted access to critical patient records, scheduling, and billing data.
• Stable, optimal performance: Greenway PrimeSuite handles thousands of transactions daily, from checking in patients and charting clinical notes to running complex billing reports. Load balancing ensures the system remains fast and responsive even during peak usage hours. The load balancer uses algorithms (like Least Connection or Round Robin) to distribute incoming user connections and requests evenly across all available PrimeSuite servers. This prevents any single server from becoming overloaded or a performance bottleneck. By keeping the load balanced, each server can process its smaller share of requests more quickly, leading to faster screen loads and reduced latency for users, which is essential for maintaining high staff productivity and a smooth patient flow.
• Enhanced scalability and flexibility: Load balancing makes the PrimeSuite infrastructure elastic and future-proof, allowing the practice or hospital to grow without service disruption. When the organization expands (e.g., adding a new clinic location or acquiring a large practice), new application servers can be easily added to the server pool. The load balancer immediately includes them in the distribution, allowing the system to seamlessly handle the increased user volume and data load. Load balancers allow IT staff to take a server offline for scheduled maintenance, patching, or upgrades (e.g., to a new PrimeSuite version) without impacting user access, as all traffic is temporarily routed to the remaining active servers. This significantly reduces risk and allows for updates during business hours.

About Greenway Health PrimeSuite

Greenway Health PrimeSuite is a clinically driven electronic health record (EHR) and practice management (PM) system that can be customized to align with the specific documenting, billing, and reporting needs of hospitals and private practices. 

Why Loadbalancer.org for Greenway Health PrimeSuite?

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 Greenway Health PrimeSuite

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 Greenway PrimeSuite, we recommend a Layer 7 Reverse Proxy deployment.

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.

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.

Related Resources