An electronic health record is a very complicated beast. Not only complicated in it’s own right, but doubly complicated due to interfaces with many other products. Installation of new software involves multiple rounds of testing to make sure the software will function as desired. In the early phases, the testing is only as robust as the technicians and analysts doing the testing. With experience, repetitive testing can follow a standard script.
Once the software is installed, testing must occur every time there is a change in software settings or an upgrade to the software program. Though vendors perform a series of tests prior to a release, there is never software without bugs. The vendor can not test how you have deployed their product. Your testing needs to find where the product is no longer functioning as it did previously. You have a certain element of control over the timing of testing when vendors send you new releases to install on your servers. You have no control over timing if your software is hosted by the vendor and updated on their schedule not yours.
Today’s electronic health record is typically a summation of data gathered through multiple interfaces to products provided by a multitude of vendors. Whenever any of the associated programs is updated, additional testing is necessary to ensure the integrity of the entire system.
Testing requirements quickly mount since the complexity of the system increase by the square of the number of elements involved. For example, if the number of connections doubles, the complexity of the system increases by a factor of four. Complexity increases the chance a small change in how a program operates, will have significant downstream effects.
As your EHR becomes more complex, you reach a point where automated testing scripts makes sense.

