Healthcare organizations seem to struggle with creating and maintaining integration test scripts. This whitepaper will outline the steps necessary to create great integration test scripts for your organization.
Integration testing is a systematic way to ensure that a group of applications work together to produce desired outcomes when the end users execute their workflows as understood.
In healthcare this means that integration test scripts written to be used for integration testing must cover everything from the time a patient first interfaces with the healthcare organization through to the time the claim is paid – a single set of test scripts to incorporate all clinical care and revenue cycle workflows.
A second set of test scripts should incorporate all enterprise resources planning (ERP) workflows. This whitepaper will only deal with those test scripts associated with clinical care and revenue cycle.
If created appropriately, and maintained, integration test scripts are a great corporate asset. If not, they are nothing more than a project artifact that gathers dust once the project is complete.
To be a valuable corporate asset the set of integration test scripts need to cover all major workflows and need to be kept up to date as those workflows evolve and change. This is especially true in healthcare where workflows are extremely dynamic, changing frequently as software is updated, laws change and science advances.
Healthcare organizations can not afford to write new integration test scripts each time they upgrade or add a new application into the existing mix.
Create Great Integration Test Scripts in 6 Easy Steps
The following steps are required to create the kind of integration test scripts that will serve your organization through time:
1. Determine Which Patient Care Scenarios to Incorporate
Typically, the best way to determine which patient care scenarios to include in an integration test script is to ask the Health Information Management (HIM) department to provide the list of the highest volume discharge diagnoses and the highest revenue discharge diagnoses. By utilizing a combination of these two groups of episodes of care you will ensure that you cover the most important workflows in the fewest number of test scripts.
2. Flesh Out the Story of Each Patient Care Scenario
Once you know which patient care scenarios your test scripts are going to be built around, it is best to convene the subject matter experts (SMEs) for the departments that will participate in each scenario, along with the informaticists, business analysts and application analysts to get all of the necessary details for what should be in the story.
This should include the patient demographics, which providers should be involved, what order sets will be ordered, and add-on orders, what the results should be, how the patient should present, how the patient should be discharged, whether there should be follow-up, and so on.
3. Ensure All Major Workflows Are Incorporated
Do you have a list of all major workflows for each department in your organization? If you do not, you should have. This should include all departments, not just clinical, but also revenue cycle. Once you have the stories outlined for each patient care scenario you should pull out your list of workflows and start checking them off.
Each one should be included in one or more of the patient care scenarios. If there are ones that are not included the next step is to determine whether you can easily incorporate them into one of the existing scenarios. If not, you may need to add another scenario. It is always better to incorporate into an existing scenario if possible – fewer scenarios mean less resources to run the scripts and maintain the scripts over time.
4. Add the Details of Each Integration Test Script
Now that you have your stories finalized and know that you have all the workflows covered, you need to go back to each scenario and start filling in the details. For these test scripts to be a real corporate asset they need to be documented click-by-click and call out all of the expected outcomes so that even someone that has not been trained on the applications being used is able to execute the test script.
This is what allows SMEs to participate in integration and really confirm their acceptance of the system prior to go-live. Without the proper details being included as part of the scripts you can not ensure that the same exact steps will be executed each time the scripts are run, nor that you will have the desired outcomes.
5. Complete a "Dry Run" with the Integration Test Scripts
Each integration test script will contain hundreds, if not thousands, of steps. The first time that your organization runs through the test scripts with the SMEs is very important. If the scripts are riddled with mistakes it will be a bad experience for the SMEs.
If however they can run through the scripts and get a good idea of the workflows represented by the scripts, it will help to build buy-in to the new workflows and create the appropriate connection between the workflows and integration testing.
For this reason, it is important to have the informaticists, business analysts and application analysts that have configured the applications run through the integration test scripts prior to the first round of integration testing to ensure that as many errors as possible are removed from the scripts. This run through of the scripts is referred to as the “dry run”.
6. Make Updates and Corrections to the Integration Test Scripts
Each time the integration test scripts are run a mechanism needs to be in place to allow testers to identify issues with the integration test scripts themselves, as well as issues found with the system configuration as a result of the test cycle. Once identified, the issues in the test scripts need to be corrected prior to the next time the scripts are run. This is especially true if SMEs are running the test scripts. If they identify the same issues time and time again, they will lose confidence in the integration test scripts.
Ensure Your Scripts Remain a Corporate Asset
Too many healthcare organizations put their integration test scripts on the shelf after go-live and do not bring them back out until the next major upgrade or new system implementation. This usually results in a scramble to update the scripts that can often delay the project timeline.
A better strategy is to institutionalize the idea that as workflows change, the integration test scripts that test out those workflow changes also get updated. This is best done when ownership of the integration test scripts, and the patient care scenarios they represent are owned by the SMEs and the informaticists and business analysts who support them.
This allows the integration test scripts to be updated to include not only workflow changes that are rolled out intentionally with software updates but also those that the SMEs make themselves when they become comfortable with the applications they are utilizing.
To do this you need a mechanism that allows for integration test scripts that incorporate all the current state workflows, as well as integration test scripts that incorporate future state workflows for new systems or upgrades. That way if the date of your go-live is pushed out significantly you will not need to go back and undo all of the changes that have already been made to your integration test scripts.
Great integration test scripts that accurately reflect the workflows that are being used, or will be used, by the end users ensure smoother go-lives for all system and workflows changes being implemented by your healthcare organization.
Talk to Our Experts
You don't have to try to figure this out on your own. Get the help you need to ensure better outcomes and be confident in your testing approach.