Section 4.18 Implement

Section 4 Implement—Testing Plan - 1

Testing Plan

This tool describes the types of tests typically performed on electronic health records (EHR), health information exchange (HIE), and other health information technology (HIT).

Time needed: 40 - 80 hours (process is repeated multiple times)
Suggested prior tools: Section 2.2 Project Management, Section 4.8 System Build

Introduction

Although vendor products vary in the complexity of testing needed, every system must be tested to ensure that:

·  Data tables and files have been loaded properly

·  Data collected are processed and stored correctly

·  Interfaces work

·  Customizations are correct

·  Work flow is appropriate for the organization's processes

·  Clinical decision support rules fire correctly

·  Reports are generated accurately and completely

Proper system testing is sometimes not performed because implementation has already taken a long (or longer than expected) time and people simply want to get on with using the system. As a result, the new users—who are struggling to learn the system and manage the change it brings about—are also left with the burden of being test subjects. It is unfair to put users this position because they may not be aware that a function is not operating as intended, or they may be reluctant to report issues for fear of being seen as resistant to change.

The tests performed on EHR, HIE, and other HIT should be conducted in a test environment, or separate section of the database that is not in production use. Security testing should also be performed. Use this tool to identify who within the organization will be responsible for performing the tests and tracking dates that test results were accepted. Although the vendor should be involved in performing these tests, someone from your organization should be an active participant. In many cases, an IT staff member and a clinician are involved, depending on the application. Many organizations require a clinician representative to sign off on all clinical information system applications prior to go-live. If a test is performed and results are not accepted the first time, issues should be posted in issues management tracking and resolved before acceptance occurs.

How to Use

  1. Review the types of tests and their purposes.
  2. Review with the vendor the tests to be performed. Determine if any changes are needed. Modify your testing plan accordingly.
  3. Record the date, who is responsible, and whether testing results are acceptable.

Test / Components / Timing / Responsibility / Accepted /
Unit and Functional Testing / Each major function performs as specified in user manual.
Design changes/customizations are present and work as requested. (Document all changes for future reference, see Section 4.X Change Control.)
Screens appear as expected, including content and placement of all fields, codes, drop down menus, and messages (see Screen Design portion of Section 4.x System Build).
No spelling errors or color changes. Icons are readable.
Appropriate representation of content can be printed if necessary for legal purposes.
Entries that have been corrected and their corrections are both displayed accurately.
Field edits (e.g., valid values, optionality, defaults) function as expected.
Clinical decision support provides appropriate reminders and alerts. Use CDS Scripts to test various scenarios.
System Testing / Workflows send and/or receive data properly between systems (e.g., between EHR and pharmacy; PMS messages and EHR; EHR charge capture and billing system). Use scripts to test various scenarios (see Section 2.X Workflow and Process Redesign for EHR and HIE).
Interfaces between applications move data correctly and completely. Test both sending and receiving when interfaces are bi-directional.
Connectivity with external organizations is accurate and complete as authorized (e.g., continuity of care record to referrals, personal health records for residents, portal access to/from hospital/clinic, disease management to/from health plan).
System access is appropriate per assigned privileges. Test attempts to gain access when not authorized.
Data are processed accurately, in graphs, tables, claims, resident summaries, reports, etc.
Data correctly populate registries, reporting warehouses, etc.
Integrated Testing (simulates live environment) / Ensure all system components that share data or depend on other components work together properly.
Ensure that workflows reflect actual new processes and workflows (see Section 2.X7 Workflow and Process Redesign for EHR and HIE)
Ensure that usage is defined in and follows policies and procedures (see Section 4.X EHR and HIE Policies and Procedures Checklist. Reinforce training as applicable (see Section 4.1X Training Plan).
Ensure that help desk, support personnel, and other aids function properly.
Ensure that EHR works with all forms of human-computer interface devices and modalities being used (e.g., tablets and PDAs as well as workstations; voice recognition and speech commands as applicable).
Attempt to break the system by testing mission critical and high risk functions, such as situations requiring exception logic (e.g., overrides to clinical decision support; handoffs from one department to another; and where there may be a series of events over a period of time (e.g., assessments performed and designated intervals).
HIE Testing / Measure response times for key Pull transactions and assure they are within acceptable limits, which may be defined in the contract.
Determine that all Push transactions are received, they are linked to the appropriate records, and that exceptions are provided in a separate, manageable report.
Determine that consent management enables or disables the ability to retrieve information.
Test several common patient names and different levels of additional patient matching data to evaluate the accuracy of patient identification.
Acceptance Testing
This is not a specific test but indicates achievement of specific milestones. Milestones may represent time for payment. / All modules have been implemented and successfully tested as planned.
All outstanding issues have been resolved to organization’s satisfaction.
User adoption rates reflect goals.
User satisfaction rates reflect goals.
Resident satisfaction rates reflect goals.
Return on investment is demonstrated (see Section 2.1X Business Case: Total Cost of Ownership and Return on Investment Analysis for EHR and HIE).

Copyright © 2014, Margret\A Consulting, LLC. Used with permission of author

Copyright © 2014 Updated 03-19-2014

Section 4 Implement—Testing Plan - 4