Regression Testing
By Kyle Winden

It’s inevitable: Death, Taxes, and Upgrades.

Your facility had a successful implementation. Unit and integration testing certainly played a large part in this success. This testing enabled the individual teams to find out how their build worked (unit testing), but also how it interacted with other applications (integration testing). The care taken and attention to detail during these phases can make or break any implementation.

Now, months or even years later, you’re stable, you’ve optimized the system and, you can take a deep breath, while you start working on that list of service requests that have been received from the customer. You’ve settled in to the daily routine of maintaining the system. But nothing stays the same for long. Whether you decide to implement new functionality or upgrade to the new and improved version of Epic^®, you will eventually head back to the testing environment. Regression testing, or testing the effects of new functionality on existing functionality, is critical to the success of your change or upgrade.

It is essential that all planned changes from any department be communicated clearly and in a timely manner to all other departments. This will allow other applications to investigate and test what the effects those changes will have on their module. For example, a facility’s lab department decided that an additional department was needed in order to transmit lab results and charges through the interface. They communicated the change to the ambulatory department for the lab resulting message, but neglected to notify the Resolute^® team. The effect was that all incoming charge messages that included the new department ended up in an interface error pool. The new department was not added to the e*gate™ programming and the messages failed in the interface. Not only did the charges need to be corrected and resubmitted individually, but there was a rush to work with the e*gate team to get the department added to the incoming charge message and test those changes. What would have taken a couple of hours took days to correct.

Special Updates (SUs) from Epic should also be regression tested. These can and sometimes will affect programming currently used, as well as the look and feel of the functionality and should be thoroughly vetted.

During what I call the ‘settling in’ phase of post-implementation, it’s easy to forget those wonderfully detailed scripts that were designed during the unit and integrated testing phases. However, it is important to keep these scripts current. Ask yourself, do they truly reflect the facility’s current workflows and/or build? You don’t want to find that codes referenced in a script are obsolete, inactive, or security settings have been changed.

Revision of existing scripts or authoring new scripts to reflect current workflows will be a timesaver when it comes time for the inevitable upgrade of your system. Post-implementation, a committee consisting of a member from each team in your facility’s full suite of applications should meet periodically to review relevancy of the scripts. This can be your first step to a successful upgrade.

In conclusion, even after a successful initial implementation of Epic modules utilized by your facility, there will be upgrades and changes to the current system functions. Regression testing is critical and can prevent or mitigate problems such as:

• WQs filling up
• Risks to patient safety
• Higher A/R or lost revenue
• End user dissatisfaction
• Patient dissatisfaction
• Compliance issues

With careful regression testing you can be assured that your change or upgrade will result in a positive outcome. For more information on regression testing contact us at (610)444.1233 or vcs@getvitalized.com. You can also find more information about VCS’ services and solutions at out website www.getvitalized.com.