What is our primary use case?
I used Mirth Connect Health Check to ensure that our Mirth Connect is up and running and we do not have any downtime.
We have hosted Mirth Connect on a server, and to ensure Mirth is running, we set up some background services that keep checking for the service. Instead of that, we have an endpoint for this health check, and I use that endpoint by providing the IP address of the server to get the status, such as the version. I was using version 4.4.2. When I hit that endpoint, I get that version, and if I am getting that version, that means our service is up and running successfully, and I do not have to worry about Mirth being down.
It is just for monitoring and to ensure there is no downtime. Mirth Connect Health Check is deployed on a public cloud or private cloud that can be accessed only within the organization. I use Azure as our cloud provider.
How has it helped my organization?
It has helped me save some time, and using this, I made sure that I am very accurate about our downtime, and I do not have to rely on any third-party service or microservices to ensure that Mirth is up and running.
If I want to go manually and log into the server to check that, it takes almost 30 minutes, but with Mirth Connect Health Check, it is just one click away, and I get the response status.
What is most valuable?
Mirth Connect Health Check offers features for managing performance and checking for downtime, and I do not have to manage any credentials for this. I do not have to pass any credentials for this; it just gives me a status of Mirth Connect.
I do not have to hardcode any administrator password for that engine, which keeps a security perspective very good because I am not storing any username and password.
Feature-wise, using this provides downtime prevention, and I can also use it after updating Mirth Connect to validate that the update went through successfully on the new version. I believe this is the main thing.
What needs improvement?
There are some things I have to look for, basically just having the ability to check if Mirth is up and running. I cannot check the data inside Mirth Connect, such as the channels, or whether they have any errors or anything. It is limited to the status of Mirth Connect, so I feel I need to start adding the channel information and the channel statuses also.
If a database crashes but Mirth web service is still running and working, I will get a 200 response or the version. That means our database is not working, but Mirth Connect is up. So that is incorrect information. I do not face this issue too frequently, but still, it should be improved.
For how long have I used the solution?
I have been using Mirth Connect Health Check for the past four years, and I have been using the health check for almost two years.
What do I think about the stability of the solution?
It is perfectly stable; it is 100% stable right now. It is not complicated—just hit an endpoint and I get the response.
What do I think about the scalability of the solution?
I believe it can scale and improve many things. It is just one endpoint for Mirth Connect Health Check, and I do not have to keep track or have problems handling another endpoint. It is pretty good; I have not faced any issues, and I believe it can scale very much.
Which solution did I use previously and why did I switch?
I previously used some microservices that required me to manage that service, consuming extra memory and causing issues, and I had to maintain that service again. With Mirth Connect Health Check, I do not have to maintain anything; it is just an endpoint, and I hit it to get the response based on which I do checks.
What was our ROI?
Definitely, if I am spending 30 minutes checking Mirth Connect health status, I am saving 30 minutes for a server.
What's my experience with pricing, setup cost, and licensing?
I am not sure about pricing and setup cost because that is managed by the management, who decide and give me access.
Which other solutions did I evaluate?
I evaluated the microservices, which was an in-house tool I developed to check Mirth health continuously.
What other advice do I have?
I give Mirth Connect Health Check an 8 out of 10 because it is a must-needed tool that decreased some time monitoring Mirth Connect services.
I chose 8 out of 10 because it is just checking Mirth status and Mirth Connect health; that is it. Nothing else, such as no channel checks or error checks or database connection checks. I believe if those are included, it will definitely be a 10 out of 10.
I feel Mirth Connect Health Check is getting HIPAA compliant, which follows regulation in the US, so I believe it is secure to use, speeding up tasks and ensuring I am compliant.
The output is 100% accurate, and I do not think there is any accuracy problem. But as I said, if the channel is not working or the database connection is not working, I still get the response saying 200, which means the server is fine, and Mirth is working fine.
I would say Mirth Connect Health Check is a perfect tool or service to check on Mirth if I have 100 clients and servers running 100 Mirth Connect instances. Instead of checking manually, it saves a lot of time and is pretty quick.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Microsoft Azure