Load balancing Meditech RESTful API
About Meditech
Meditech is a leading global provider of Electronic Healthcare Records (EHR) and interoperability solutions. The RESTful API Infrastructure allows MEDITECH and third party vendor software to securely access the MEDITECH EHR through APIs. Interoperability Services (or IOPS) — which is a component of the RESTful API Infrastructure and installed on the same machine(s) — adds a set of APIs to meet Meaningful Use Stage 3 (MU3) and Imaging Appropriate Use Criteria (AUC) requirements.
Note: RESTful API is independent from any other web products or interoperability interfaces MEDITECH offers and requires dedicated hardware.
Key benefits of load balancing
In an industry where uptime saves lives, our extensive experience means we can design unbreakable solutions to enterprise imaging’s unique challenges. Load balancing provides a solution that is:
- high-performing
- highly available
- scalable
Loadbalancer.org specializes in providing application delivery controllers (ADC) and load balancing solutions to the Health IT and other industry sectors where zero downtime is essential.
How to load balance Meditech
Meditech RESTful API can be load balanced in two different ways, as shown in the diagrams that follow:
- Recommended deployment: Uses two virtual services to load balance the Meditech API servers which then make a connection to the Cache servers and any other Meditech related server, such as Platform Service, File Library, Monitor Service on the backend.
- Minimum deployment: Uses two virtual services to load balance the Meditech API servers which have both the API and Cache services installed on the same server. The server then makes a connection to the other Meditech related servers, such as Platform Service, File Library, Monitor Service on the backend.
Scenario 1 – Recommended Deployment Using SSL Offloading

In this deployment, two virtual services are used in addition to a TLS/SSL termination. The virtual services use layer 7 SNAT mode. An SSL certificate is uploaded and associated to the Virtual Service. Data is encrypted from the client to the load balancer, but is unencrypted from the load balancer to the backend servers as shown above.
Scenario 2 – Recommended Deployment Using SSL Bridging

In this deployment, two virtual services are used in addition to a TLS/SSL termination. The virtual services use layer 7 SNAT mode with re-encrypt to backend enabled. An SSL certificate is uploaded and associated to the Virtual Service. Data is encrypted from the client to the load balancer and is also encrypted from the load balancer to the backend servers as shown above.