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, MA, Practice Admin, RN) 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 the not, the test begins with selecting a Patient from the schedule. Starting here is import and will potentially uncover loopholes in the build configuration.
• Role Based Testing - Different steps in the Workflow will required 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 uncover 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 use 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. Resting changes to the build can get overlooked and

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 sure to be clear with Who (RN, Doc, MA, Front Desk) is involved in a Workflow and where the changes 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 know 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
• Assign Testers - who, what, when, where
• Assign the work -
• Report your results
• Do not hesitate to Fail a Workflow