anx•i•e•ty
/aNG’zi-ite/
Noun

1. A feeling of worry, nervousness, or unease, typically about an imminent event or something with an uncertain outcome.
2. Desire to do something, typically accompanied by unease.

If you have ever worked on a project that has required a significant change to your Allscripts Enterprise EHR™ infrastructure then you certainly know the feeling. You’ve carefully planned your infrastructure, done extensive functional / unit testing and now comes the day of go-live. How will your new infrastructure handle a production load?

This question is far too common, but I have recently worked with a major health system that made significant infrastructure changes and used HP LoadRunner to simulate load given common resource intensive workflows like Note & Results Verification. Here are few lessons learned to share about this experience:

• Value – Licensing around load testing software is expensive and is normally based on the number of users in which you want to simulate load – the more load you want to put on your system the more it costs.
• Risk – Using HP LoadRunner requires a few minor configuration changes to every web servers where load will be tested. This will require a server admin to make changes to the web servers which will then need to be reverted after load testing is completed. Please use caution when scheduling your load testing to ensure that these changes can be reverted and a subsequent smoke test can be executed in a timely manner.
• Define your workflows: Simulation testing is 100% based on capturing and scripting workflows which can be very timely – in some cases it can take days to script out just one workflow in your load simulation software. In this client’s case, we used 4 common workflows including a Nurse Note for Urgent Care Visit, Chart download, Results Verification (POC orders) via worklist, and Charge.
• Technical challenge: Using HP LoadRunner we had to programmatically create/copy both test patients and test users. So if your maximum threshold for testing is 1000 users then you will need to create 1000 test users with unique logins and 1000 test patients.
• What is your organizations baseline? Load testing is based on concurrent users, but Allscripts has a variety of different user roles all which have varying demands on the system. In the aforementioned client’s case, it was decided that a clinician role would be used where common workflows could be utilized. Once you have your role selected you will need to create a tiered approach where you are starting with an average number of system users and slowly ratchet up the simulation testing against your capacity (and even beyond).
• Add a little chaos… Once you have captured your baseline numbers rerun the simulation just short of your capacity using real testers. Click around and measure the impact to your load testing given workflows that aren’t being accounted for in your load simulation. Compare these results with your baseline numbers.