Time Capsule: Before You Buy, Look at the Impact on User Productivity

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in April 2006.

Before You Buy, Look at The Impact on User Productivity
By Mr. HIStalk

A story often repeated: a big organization executes a high-profile rollout of a clinical system, but caregivers say it takes longer to use. They deliver an ultimatum — either you accept a reduction in productivity or you ditch the system.

The latest subject is the Department of Defense, whose new $1.2 billion AHLTA system (which is actually the renamed old system, CHCS II) is claimed by users to be so slow that they have to reduce their patient schedules by one-third. Patients are being diverted to emergency departments and routine checkups aren’t being done.

Maybe this is telling us that we don’t look hard enough at a system’s impact on user productivity. I don’t recall ever having heard of a health care organization that measured how long it takes to write an order, document care, or write a prescription, comparing times before a system install and after. I’ve never heard of someone choosing a particular system because it’s faster for the caregiver, or in many cases, even giving the caregivers a peek at it before the decision to buy is made.

I’ve also not heard of an organization budgeting additional staff to offset reduced productivity with automation. The reason is there’s not supposed to be any slowdown. Everybody knows that computers improve productivity, right?

If that was the case, all those PCs that hospitals have deployed would have caused huge staff reductions. I haven’t heard of that either. Sales prospects are easily impressed with unrealistic projected staff reductions that never seem to materialize.

It gets worse when users are hard-to-find licensed staff, such as nurses or pharmacists. A system that takes up more of their time, no matter what benefits it provides to someone else, may create a staffing dilemma that directly impacts patient care.

This is a customer problem, not a vendor problem. If customers demanded productivity gains for their users, vendors would respond (or lose business). This goes back to a generally casual regard for usability testing — never a priority in the mainframe days and not improved very much since in health care.

Local configuration options make it hard to evaluate an off-the-shelf vendor system upfront to determine workflow impact. You could ask the vendor’s customers, though. Arrange to time how long it takes to chart a med as given, to create a progress note, or to enter an order set as a physician. Then, compare that with the time required by your current process.

You don’t need the vendor’s help to do this. You might want a management engineer to look over your shoulder for consistency in measurement. Otherwise, all it takes is for hospitals to talk to each other, which they’re usually pretty good about doing.

I don’t know about you, but I’d rather not be in the hot seat to answer this question from clinicians — do you want us to take care of patients or to use your system?