Difference between revisions of "Types of Testing for EHR Rollouts"

From Galen Healthcare Solutions - Allscripts TouchWorks EHR Wiki
Jump to navigation Jump to search
Line 4: Line 4:
  
 
An analyst should keep a build verification checklist as the move through building out the design session. The Build Activity Workbook is a good example of a way to track build verification and progress. The master copy should be stored where it can be accessed by analysts and managers working on the project.
 
An analyst should keep a build verification checklist as the move through building out the design session. The Build Activity Workbook is a good example of a way to track build verification and progress. The master copy should be stored where it can be accessed by analysts and managers working on the project.
 +
 +
 +
== Unit Testing ==
 +
 +
Unit testing is simply testing the module or feature the analyst/developer is implementing for defects and bugs. The Unit Testing should be done by someone other than the analyst responsible for the build (for quality assurance reasons) in most organizations. Unless instructed by your lab vendor, the testing of each order code is not necessary, but testing each scenario for the different types of orders is important in a unit test (for example, Additional Order Entries, Hold for Financial Authorization, etc.).  A successful unit test means that each decision point from a design session, or build document is functioning as expected.

Revision as of 20:24, 27 February 2011

Testing your EHR implementation is one of the most important phases of the EHR roll-out. There are different types and theories of testing and the article below attempts to explain the process behind some of them.

Build Verification

An analyst should keep a build verification checklist as the move through building out the design session. The Build Activity Workbook is a good example of a way to track build verification and progress. The master copy should be stored where it can be accessed by analysts and managers working on the project.


Unit Testing

Unit testing is simply testing the module or feature the analyst/developer is implementing for defects and bugs. The Unit Testing should be done by someone other than the analyst responsible for the build (for quality assurance reasons) in most organizations. Unless instructed by your lab vendor, the testing of each order code is not necessary, but testing each scenario for the different types of orders is important in a unit test (for example, Additional Order Entries, Hold for Financial Authorization, etc.). A successful unit test means that each decision point from a design session, or build document is functioning as expected.