Benefits of load balancing GE HealthCare Edison Datalogue

Load balancing is critical for enterprise healthcare IT systems like GE HealthCare’s Edison Datalogue because it manages the high volume of critical medical imaging and clinical data, offering the following key benefits:

• High Availability (HA): Load balancing ensures that the Edison Datalogue system remains continuously available for clinicians and providers, which is vital in a healthcare setting where downtime can directly impact patient care. By distributing incoming traffic (e.g., DICOM studies, retrieval requests) across multiple servers, the system avoids bottlenecks. If one server fails or becomes unresponsive, the load balancer automatically and seamlessly redirects traffic to the remaining healthy servers (failover). This redundancy means physicians and radiologists retain access to critical patient images and clinical records at all times, supporting timely diagnosis and treatment planning.
• Optimal performance and scalability: Load balancing distributes the workload to prevent any single server from becoming overwhelmed, ensuring a fast and responsive user experience while allowing the system to grow with demand. It intelligently routes requests to the server with the least load or best performance, reducing latency and ensuring rapid access to large medical images and records. As a healthcare organization grows—acquiring more imaging equipment, adding departments, or managing increasing patient volumes—load balancing also allows the organization to easily add new servers to the Datalogue cluster without disrupting services, accommodating the massive and continuous growth of medical data.
• Safer maintenance and upgrades: Load balancing provides a secure and practical mechanism for performing necessary system maintenance, crucial for keeping complex healthcare IT infrastructure compliant and up-to-date. It allows IT teams to isolate a server or a group of servers, take them offline for maintenance (e.g., patching, upgrades, configuration changes) or replacement, and then reintroduce them, all while the remaining servers continue to handle live traffic. This capability significantly reduces the risk of system-wide disruption and minimizes planned downtime, supporting compliance and high service level agreements (SLAs).

About GE HealthCare Edison Datalogue (EDL)

GE HealthCare Datalogue (EDL) is a multi-ology, vendor neutral enterprise archive (VNA) and workflow management solution.

It helps lower costs by providing a consolidated view of medical imaging and clinical IT infrastructure, improve clinical workflow operational efficiency, improve the patient experience, foster more informed decision making, and improve productivity with more streamlined information sharing. 

Why Loadbalancer.org for Edison Datalogue?

This deployment guide isn’t theoretical; it has been field tested and rigorously validated by GE HealthCare experts. This means you can be completely confident that the solution described is robust, reliable, and backed by the real-world operational experience of a global leader in healthcare technology.

Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is also 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 GE HealthCare Edison Datalogue (EDL)

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 GE HealthCare EDL, Layer 4 DR mode and Layer 7 Reverse Proxy are used.

Virtual service (VIP) requirements

To provide load balancing and HA for GE HealthCare Edison Datalogue the following VIPs are required:

Ref.	VIP Name	Mode	Port(s)	Persistence Mode	Health Check
VIP 1	EA_HL7	Layer 4 DR	2575	Source IP	HTTPS (GET)
VIP 2	EA_DICOM_TLS	Layer 4 DR	2762	Source IP	HTTPS (GET)
VIP 3	EA_XDS	Layer 4 DR	443	Source IP	HTTPS (GET)
VIP 4	EA_Console	Layer 4 DR	80	Source IP	HTTPS (GET)
VIP 5	EA_DICOM	Layer 4 DR	104	Source IP	HTTPS (GET)
VIP 6	MM	Layer 4 DR	443	Source IP	HTTPS (GET)
VIP 7	MM_DICOM	Layer 4 DR	104	Source IP	HTTPS (GET)
VIP 8	ATR_WEB	Layer 4 DR	8443	Source IP	HTTPS (GET)
VIP 9	ATR_SYSLOG	Layer 4 DR	2514	Source IP	HTTPS (GET)
VIP 10	REG_XDS	Layer 4 DR	8443	Source IP	HTTPS (GET)
VIP 11	REG_HL7_ADT	Layer 4 DR	3800	Source IP	HTTPS (GET)
VIP 12	MPI_HL7_ADT	Layer 4 DR	3700	Source IP	HTTPS (GET)
VIP 13	MPI_HL7_PIX	Layer 4 DR	3710	Source IP	HTTPS (GET)
VIP 14	MPI_HL7_PDQ	Layer 4 DR	3750	Source IP	HTTPS (GET)
VIP 15	MPI_WEB	Layer 4 DR	8444	Source IP	HTTPS (GET)
VIP 16	ZFP	Layer 7 Reverse Proxy	443	Source IP	HTTPS (GET)

About Layer 4 DR mode load balancing

Layer 4 DR (Direct Routing) mode is a very high performance solution that requires little change to your existing infrastructure. The image below shows an example Layer 4 DR mode network diagram:

DR mode works by changing the destination MAC address of the incoming packet to match the selected Real Server on the fly which is very fast. 

When the packet reaches the Real Server it expects the Real Server to own the Virtual Services IP address (VIP). This means that each Real Server (and the load balanced application) must respond to both the Real Server’s own IP address and the VIP. 

The Real Server should not respond to ARP requests for the VIP. Only the load balancer should do this. Configuring the Real Server in this way is referred to as “Solving the ARP Problem”. For more information please refer to DR Mode Considerations.

On average, DR mode is 8 times quicker than NAT mode for HTTP and much faster for other applications such as Remote Desktop Services, streaming media and FTP. 

The load balancer must have an interface in the same subnet as the Real Servers to ensure layer 2 connectivity which is required for DR mode to operate. 

The VIP can be brought up on the same subnet as the Real Servers or on a different subnet provided that the load balancer has an interface in that subnet. 

Port translation is not possible with DR mode, e.g. VIP:80 → RIP:8080 is not supported. 

DR mode is transparent, i.e. the Real Server will see the source IP address of the client.

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. 

Related Resources