Benefits of load balancing Mirth Connect

Load balancing NextGen Healthcare’s Mirth Connect offers a many benefits, including:

• High Availability (HA): Load balancing redirects incoming messages across multiple active Mirth Connect instances. If one Mirth Connect server or node fails (due to hardware, software, or maintenance issues), the load balancer automatically detects the failure and steers all traffic to the remaining healthy instances. This eliminates a single point of failure, ensuring uninterrupted message processing and higher uptime, which is critical in healthcare where data flow is often life-critical.
• Enhanced performance: Load balancing allows you to distribute the processing workload across an entire cluster of Mirth Connect servers. This prevents bottlenecks and ensures no single server is overwhelmed, especially during peak load times or with high-volume interfaces.
• Scalability: As message volume grows, more Mirth Connect instances can be added to the load-balanced pool, scaling capacity horizontally without disrupting service.

About Mirth Connect

Mirth Connect is a cross-platform interface engine used in the healthcare industry that enables the management of information using bi-directional sending of many types of messages.

It became part of NextGen Healthcare following its acquisition in September 20213, but it didn’t change its name to NextGen Connect. The platform is now known as Mirth Connect, and its licensing model was recently changed to a commercial one with the release of version 4.6 in March 2025, while the open-source version remains available but will not be updated.

Mirth Connect enables the management of information using bi-directional sending of many types of messages. Like an interpreter who translates foreign languages into the one you understand, NextGen Connect Integration Engine translates message standards into the one your system understands.

Whenever an alien system sends a message, Mirth Connect’s integration capabilities expedite the following:

• Filtering – Mirth Connect reads message parameters and passes the message to or stops it on its way to the transformation stage
• Transformation – Converts the incoming message standard to another standard (e.g., HL7 to XML)
• Extraction – Pulls and pushes data to and from a database
• Routing – Ensures messages arrive at their assigned destinations

How to load balance Mirth Connect

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 NextGen Healthcare Mirth Connect, Layer 7 Reverse Proxy is recommended. With Layer 7 Reverse Proxy, no network changes are required and SSL termination with re-encryption can be implemented. This mode offers high performance and implementation flexibility, however, as Layer 7 is a reverse proxy, the client source IP address is not visible at the real server. Instead, the IP address of the load balancer is visible at the real server. In order to retain the client source IP address, the load balancer inserts an X-Forwarded-For header into the load-balanced traffic, which the Mirth Connect nodes can log for troubleshooting issues while seeing the true source IP address of connecting clients.

Virtual service (VIP) requirements

To provide load balancing for NextGen Connect nodes one VIP is required:

• VIP 1: NextGen-HTTP(S)

Load balancing deployment concept

When the Mirth Connect nodes are deployed with the load balancer, clients connect to the Virtual Service (VIP) on the load balancer rather than connecting directly to one of the nodes.

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. 

Related Resources