Enterprise EHR Test Strategy

Overview

The Application Project Team is most often responsible for ensuring the application is properly setup and configured in a way that supports the application's end users. With some structure and planning, this team should be able to quickly and thoroughly validate the system.

General Preparation and Planning

• Plan and schedule the testing cycle - Be as specific as possible when planning the the upcoming validation cycle. Everyone involved with the effort should know what they are responsible for, how to access the environment, how to log issues, etc. Be mindful of everyone's time and be assured everyone has the tools they need to be successful.
• Testers - The Application Project Team will likely be responsible for the bulk of the time spent testing, however, every effort should be made to include folks outside of that team. Trained Superusers as well as Clinical Users (Providers, MAs, Practice Admins, RNs, etc) should also be encouraged to help with this effort.
• Test Patients - A broad spectrum of Test Patients should be used when testing. When validating workflows scripts, more often than not, the test begins with selecting a patient from the schedule. Starting here is important and will potentially uncover loopholes in the build configuration.
• Role Based Testing - Different steps in the Workflow will require different User Roles of profiles. Each Workflow should reference who is executing steps at any given time and also highlight when the workflow changes hands.
• Issue Tracking - Some level of process must be used when reporting and tracking problems uncovered during testing. The process should reflect the size and scope of the effort and above all must be understood by the team.
• End of day recap - Keeping everyone on the same page throughout the duration of the test cycle is important. End of Day meetings are a good way to provide continuity and communication. Specific issues can be discussed, but the time is often best used to review roadblocks to getting the work done. If there are competing projects or issues preventing individuals from completing their assigned tasks, the Test Lead should reassign the work or help clear the roadblocks.
• Retesting Workflows - Any failed workflow should minimally be retested by the individual who uncovered or helped to resolve the issue.

Clinical Workflow Documentation

• Document - Above all, document your Organization's Workflow. A simple Excel document serves this purpose well and can be used to track progress (PASS and FAIL) through a Test Cycle.
• Make the Certified your own - Use the Allscripts Certified Workflows as a jumping off point for your own documentation. These are well traveled pathways through the software and should provide the least resistance for your user community.
• Level of Detail - Documenting test steps at the 'click' level is not necessary. The team that creates, and is ultimately responsible for test and validation, needs to be comfortable with the level of detail in the documented workflows. Enough detail and context should be provided such that most users with product experience can pick up a script and execute. Focus on clarity and application "triggers", e.g. charges dropping to an Encounter, Tasks falling onto a Task View or Worklist, Requisitions printing. Also, be clear with who (RN, Doc, MA, Front Desk, etc) is involved in a Workflow and where the transition from one use to another is made.
• Peer & Clinical Review - Before testing begins (and certainly prior to Go Live), Workflows should be reviewed with peers on the Application team and with end-users at the clinic who would be using the workflow to complete their work. Do not assume what was captured and documented in a design session is the absolute final product. Trust, but verify.
• Change Control - Change are inevitable. Document the Team's Change Control Policy and be sure everyone on the team knows how to request a change. Changes could be as simple as an update to a workflow, but should also consider application (build configuration) changes.
• Build a living document - The final product should be a living document that evolves with the Organization's use of the application. A well built and well maintained set of workflows can be used in a variety of ways from testing a point release or hot fix to developing new avenues for end user training.

Test Cycle

• Assign a Test Lead - For consistency, a single Test Lead should be assigned for each Test Cycle. The Test Lead will coordinate who is responsible for testing which workflows and ensure coverage and communication throughout the cycle.
• Assign Testers - who, what, when, where - Everyone involved with the testing effort should have a clear understanding of what is expected of them and how long they have to complete their assigned tasks.
• Assign the work - Individuals (or teams) should be assigned and responsible for the completion of a workflow.
• Report your results - Results (Pass or Fail) should be sent to the Test Lead. If a workflow script fails, a concise description of the issue should be provided.
• Do not hesitate to Fail a Workflow - People sometimes second guess their instincts and assume they are doing something incorrectly. If a tester thinks there is a problem with the behavior of the system (or the workflow), it should be reported as a failure. At the very least, the workflow document should be updated with steps that are more clearly written.