As a company specialized in software testing, we engage in different software testing projects across different application domains regularly.
In this blog post we will be sharing the experience we gathered in performance testing an Enterprise level healthcare application using JMeter and other open-source tools during early 2013.
The application we were tasked to test was an ICU (Intensive Care Unit) dashboard which helps the doctors to monitor patient’s health status. For example, let’s say a patient is connected to a Heart Rate monitor, the dashboard will get this data from the device and display in the dashboard as a chart in real-time. Likewise, a single patient can be connected to multiple device and all these devices will be pumping data in to the dashboard. The difference of this to a normal application is that all these data is coming in HL7 messages. So our task was to simulate these real devices and measure the performance of the application under an anticipated load.
High Level Application Architecture
The dashboard was developed using Java & MySQL, However, the complete application had a number of layers and connected components. The hardware devices such as Heart Rate monitors were first connected to a component called Rules Engine which would apply some rules to the raw data coming in from the device. Eg: – If the Heart Rate is greater than 100, rules engine defines that the color should be Red.
Then it generates a processed HL7 message and sends it to another open-source component called Mirth Connect via MLLP Protocol. The dashboard application then receives the data and displays in the UI.
Out of all these components, our performance testing scope was limited to the highlighted area in Green and we had to focus on below sections.
- Mirth Connect’s HL7 load handling capability
- Generate a HL7 message load and pump it to Mirth Connect
- Measure how long Mirth takes to process HL7 and improve performance there.
- Application dashboard performance
- User experience when multiple users access the application
- How long it takes to process HL7 message and populate in UI
Health Level 7 refers to a set of international standards for transfer of clinical and administrative data between software applications used by various healthcare providers.
A sample HL7 Message would look like this:
Mirth Connect is a cross-platform HL7 interface engine that enables bi-directional sending of HL7 messages between systems and applications over multiple transports.
When we started this project, we had very limited or zero experience in HL7 and Mirth Connect. But we were able to get a good amount of knowledge by reading articles and tutorials in the internet. However, there were number of technical challenges to overcome and there weren’t any straightforward solutions available at the time.
- Unavailability of components
- JMeter didn’t support HL7 out of the box and no plugins existed which supported HL7
- Existing samplers couldn’t send HL7 over MLLP(Minimal Lower Layer protocol)
- Test Data generation
- Generating a large number of valid HL7 messages for the test was the next challenge
- Extending JMeter
- Generate HL7
- Send HL7
- Extract data form JSON objects
- Measure the processing times
- Limited Timelines
- The testing had to be completed within one month.
Overcoming the Challenges
We went through existing HL7 message generators but couldn’t find anything that fits our exact requirement. So we had to develop a custom library for test data generation. The solution was pretty simple and looked like this.
This way, we could generate any number of HL7 messages at run-time depending on our testing requirement.
Then the next challenge was sending the HL7 messages to designated ports in Mirth Connect. Since JMeter didn’t support this out of the box, we wrote another Java library to send them over MLLP protocol using multiple threads. If you are interested, you can check below sites on how to develop a similar sender.
Then we built both this functionality into a single .Jar file that can be used within JMeter’s BeanShell sampler. This way we could write all the complex lengthy code using java application exposing only the functions to be called inside JMeter.
Finally, this is how a sample BeanShell code looked like.
This would send the specified HL7 message types throughout the given test duration and the random delay. Likewise, we created number of .Jar files to fulfill our requirement and used them inside BeanShell samplers.
JMeter & HL7 Where is it Today?
Now there’s a plugin developed by Avisi B.V. which is a TCPClient for use in JMeter TCP sampler for sending messages over MLLP to a HL7 interface engine. This will make the future HL7 sending requirements easier.