Reduce Legacy System Integration Effort to One-Fifth with Mule ESB
integration medical system with mule esb

Background

A hospital information system needs to be integrated with a wide range of hospital medical equipment, but integration between those applications is a complicated process.

Although there is an international healthcare message exchange standard, HL7, data formats for healthcare equipment are not standardized, adding another layer to its complexity.

HL7 provides an operational and message format guidelines, which are widely accepted in the healthcare industry. It was developed in 1987 as a way to allow hospitals’ medical equipment to communicate. The HL7 became the standard that governs how to exchange data, enabling different types of medical equipment to “talk” to each other, especially when sharing clinical information.

Unfortunately,  HL7 was not designed to be flexible enough to accommodate the changes in other IT standards, hence the complications that arise when it has to be integrated with modern technologies like XML, SOAP, etc.

The Issue

In order to increase the flexibility of our hospital information system, the Ksatria Medical System (KMS), Mitrais decided to extend the integration support not only to the health-specific applications but also to the financial platforms such as KMS-Finance (KMS-FIN).

To tackle these integration challenges and provide enough abstraction so the integration complexities could be simplified, Mitrais adopted the Mule Enterprise Service Bus (ESB), an integration platform that allows developers to easily connect applications together.

The first issue in implementing this approach was to port the existing radiology integration code base from legacy code to Mule ESB, a challenging task, as it involved modernizing a legacy code base into a modern, service-oriented architecture.

The Solution

During the planning and implementation stages, it became clear that adopting Mule ESB reduced a significant amount of effort involved in the legacy code implementation and porting process.

The HL7 message format and non-standard message transport mechanisms cause design and implementation complexities. Without an ESB these complexities would have had to be included in the KMS-HIS’ codebase, decreasing the software’s maintainability

integration ksatria medical system with mule esb

Now that we are using the Mule ESB and porting code base using a service-oriented approach, the project was completed five times faster. Mule ESB and the Mule Health Toolkit decoupled the complexity, thereby reducing the need to modify the KMS-HIS’ codebase and increasing its maintainability and scalability.

The library for constructing HL7 messages and sending them via a non- standard message transport was completely removed. Additionally, Mule’s Anypoint Studio provided an easy to use graphical development environment, requiring a shorter learning curve for our Software Engineers, and reducing implementation time.

Surprisingly, assimilating the Mule ESB into the KMS was a painless process. What had been initially considered a massive undertaking in porting a legacy code base, became a simple one. With a 500% productivity increase provided by the Mule ESB, Mitrais implemented KMS with the hospitals’ equipment faster and more efficiently than before, saving time, effort and cost and reducing future maintenance costs.