When it comes to implementing clinical software solutions to help orchestrate workflows in the OR and other hospital departments for better outcomes, it's vital to have a software infrastructure that's nimble, reliable, scalable and easy to deploy. That's why we've created microservices rather than rely solely on monolithic architecture.
The TAGNOS application has many modules that are interlinked and highly coupled. The whole application is built to a single EAR file and deployed to the server.
Though this kind of monolithic architecture is easy to develop, test and deploy, you'll find issues and drawbacks associated with it. For example,
Because of all the above drawbacks of monolithic applications, micro services are becoming more and more popular.
In microservices architecture, the whole application is split into smaller, independent and interconnected services. Each service becomes a small application that can be deployed and managed independently by different teams.
As you might imagine, using microservices architecture has many benefits:
Microservice architecture can be very reliable. If one module has an issue or goes down, other services keep running and the whole application doesn’t go down.
Microservices architecture offers a great deal of flexibility in developing the application as different teams manage the different services.
Each service can be scaled individually and does not require a whole new application instance.
Deployment becomes easier with Microservices. To update one of module, you just need to redeploy that particular service.
Despite the advantages detailed above, there are cons of microservices architecture:
When you're designing microservices architecture, you need to keep the following design criteria in mind:
Circuit breakers matter. It's important to identify the places in microservices and apply logic which will prevent the system from recurrent failure. Failure in one of the microservices should not propagate failure to other microservices.
Health checks are basically endpoints provided by a service to check whether the service is running properly. It helps the user to pinpoint the malfunction inside microservices.
Log messages of all microservices for the application have to be logged at common places. Tools such as ELK stack can be used for this.
A microservice needs to be resilient to failures and to be able to restart often on another machine for higher availability.
To make microservices robust and reliable, each microservice has to have its own set of unit tests and service test suites.
The Journey to microservices involves replacing a custom-built queue mechanism with a queue as a service.
The TAGNOS application had java queues between two modules to transfer data which makes the TAGNOS application highly coupled and dependent on each other. To overcome this dependency between modules, we have replaced the java queues with a message broker. This message broker provides a common platform between two modules to send or receive messages.
As a starting point for implementation, it's important to identify existing functionality in the TAGNOS monolithic system that is fairly loosely coupled with the rest of the application and convert that to microservices.
Next, convert other modules of the TAGNOS application also to microservices one by one, until eventually the monolith is cut out completely. These microservices discover each other using service discovery and talk to each other using rest services. The main idea is to slowly replace functionality in the system with discrete microservices.
We welcome your questions.
Thanks for reading.
TAGNOS is the future of clinical automation software solutions with Artificial Intelligence. TAGNOS is the only platform offering predictive analytics utilizing machine learning and RTLS. This groundbreaking platform leverages historical patient data continuously and adjusts operational intelligence to provide sustainable improvement to both the patient experience and metrics.
TAGNOS provides clinical systems integration, customizable reporting, dashboards, alerts, critical communication with staff and family to improve turnaround times. These solutions support patient flow, workflow orchestration, and asset management.
In the course of 13 months, hospitals see a 12.7% reduction in its overall cycle time - saving an average of 40 minutes from each case and over $1.6M per year - more than 11x the typical investment.