Testing

UPHS is currently in midst of upgrading our EMR to a newer version, and as the new guy in town I've been principally working on the testing aspect of the upgrade. Upgrades are an interesting time, as they are essentially an entire implementation project rolled out on a shorter time table and with less impact to the user. For someone just getting to know the system, it's a perfect opportunity to see all of the pieces in action, and more so if one is testing those pieces. Upgrades also promise increased functionality, expanded features, and usually resolution of open issues between the vendor and client.

On the down side, it's necessary to freeze any work on enhancements or maintenance issues unless they are necessary to ensure patient safety. This puts the users in a tough spot, because for the period during which the freeze is maintained (in our case, it takes us through the entire summer) they get asked repeatedly to test base functionality while just having to make the best of an electronic medical record that gets more divorced from their practice and environment with each passing day. It also ends up being a colossal waste of IT resources, as the staff swing from frenzied, over-time work responsibilities to periods of absolute calm. On any given week, you could be at work until 9 PM every night...or you could spend all of your day chatting with co-workers and reading tech manuals for lack of anything better to occupy you.

The feast-or-famine is largely driven by the testing schedule, as there is a great deal of work a couple days before and after a round of testing, but then the rest of the time in between ends up as slack. You can't predict how much time is necessary to fix problems that might crop up following a given set of tests, and the penalty for not allowing enough time is that the schedule gets delayed or moved. The testing only works if you can get the end user to actually work through the scripts though, and rescheduling them at the last minute is a great way to destroy both goodwill and generate even larger slack as the project manager(s) fight to get a 4-8 hour block of time where they can all come in again.

Theoretically you should have some float staff at all times to sit in, but if there's one thing I know about health care, it's that you'll never find a more devout hive of luddites when it comes to information technology. So slack and freezing are inevitable, but you need to limit both. You can mitigate the slack, but there's really not much to do about the freeze since every new change you make adds to testing volume, but during the middle of the process so you have to start at the beginning each time. There's also the go-live date to consider, when suddenly all of these changes start to pile up and require last-minute configuration to make the cut-offs for rolling in whole sale.

What we've done at Penn is just maintain as tight a schedule as possible, and hope that the shorter the duration of the freeze, the easier it will be coming out the other side. Given the frequency with which we upgrade and implement systems, I think we ask a lot of our users, and I can only hope that they stay as engaged and helpful as they have been thus far.