Load balancing NextGen Connect (Mirth)
NextGen Connect, formerly known as Mirth Connect, is a cross-platform interface engine used in the healthcare industry.
It 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 a ‘foreign’ system sends you a message, NextGen Connect Integration Engine’s integration capabilities expedite the following:
- Filtering – NextGen Connect Integration Engine 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” data from and “push” data to a database
- Routing – Ensures messages arrive at their assigned destinations
Offering performance without limitations, the best-value hardware load balancer on the market supports any environment. Licensed for unlimited throughput, bandwidth and features, upgrading is seamless if your requirements change down the line.
When the NextGen 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.
We recommend using Layer 7 as 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 NextGen Connect nodes can log for troubleshooting issues while seeing the true source IP address of connecting clients.
The load balancer can be deployed as a single unit, although we recommend a clustered pair for resilience and high availability. Details on configuring a clustered pair can be found on page 18 of our deployment guide, below.