EHR: How trained users killed productivity

In order to complete today’s lesson you will need one prop, your EHR vendor contract. I will pause for a moment—please let us know when you are ready to proceed.  Ready?

Now, turn to the section with all of the commas and zeroes, that is right, it is probably labeled pricing.  Skim down until you see the line item for training.  Got it?  It is a rather substantial number is it not?  And that number is simply the number your vendor is charging you to train your people.  Your actual training costs are probably double or triple that amount.

Why?  Because there is an opportunity cost for each hour of time one of your employees spends in training to use the EHR.  It is an hour they are not spending doing what they were hired to do.  Now I know some of you are thinking ‘Only Roemer will try to make a big deal out of EHR training.  Goodness knows, he has come down hard on everything else associated with EHR,” and you are probably correct.

Gartner suggests that for an average ERP project firms should budget seventeen percent of the total project cost to training end-users.  Seventeen percent.  I can hear the CFOs gnashing their respective teeth.  Knowing that EHR is at least as disruptive to the organization, and will have more users than ERP, let us agree that a good rule of thumb for training costs for EHR is fifteen percent of the total cost of the EHR project.  When you factor in the opportunity cost of 2X the number starts to get pretty big.

We all can name hospitals whose EHR project cost north of one hundred million dollars.  Who are we trying to kid; we can name hospitals whose cost was way north of that figure.  Looking back at your vendor contract I am willing to bet that nobody budgeted training at or around fifteen percent of the total cost of the project.

Is that a bad thing?  No.  Why?  EHR projects are not failing as a result of hospitals not spending enough on end-user training.  I know that statement flies in the face of conventional IT wisdom, but here is my thinking behind that statement.

Training is designed to get the end-users to use the EHR the way the EHR is intended to be used.  And that is not a good thing.  Whoa big fella.  Don’t believe me?  Just look at your EHR productivity numbers.  Didn’t productivity nose-dive once you required your trained end-users to use the EHR?  Still don’t believe me, ask your physicians and nurses.

Why not train everybody again, wouldn’t that help?  What did Einstein say about the definition of insanity?  Insanity is doing something over and expecting different results.  If the hospital already spent fifteen million dollars to train the end-users on the EHR, and the result was a twenty percent drop in productivity, might it not be time to say enough already?

EHR adage 101: When you are in a hole stop digging.

The EHR project summary for many hospitals reads a little like this:

  • EHR cost               $100,000,000
  • Training cost          $15,000,000
  • Opportunity cost $15,000,000
  • Productivity loss 20%
  • Cost of productivity loss—priceless

Face it; you spent millions of dollars to be worse off than you already were.

Today I spoke with the CFO of a hospital that owned one of those hundred million dollar EHRs.  His question to me was whether or not he should hire the EHR vendor or a large, expensive system integrator to help him recapture the productivity loss.  I told him no.  Why?  All the EHR vendor will do is to retrain your people, and you have already proven that training your people to use the EHR brought about the productivity loss.  After all, it wasn’t untrained users who did it.  Why not hire a systems integrator for tens of millions to reimplement the system?  Because I bet you put the system in correctly in the first place.

If training is not the reason productivity is low and a poor implementation is not the reason, what is?  Productivity is low because the hundred million dollar EHR never included a single dollar of resource to design it around how your physicians and nurses function.  Your expensive EHR was built to answer the question of what needs to be done; it was not designed to deal with the issue of how something is to be done.  At best, the only input the hospital had, if it had even this much, was a list of functional requirements that was handed over to a bunch of coders.  I am willing to bet in most cases even this did not happen because all of the EHR code was already written.  The EHR is not productive because it was never designed for your organization.

It is never too late to incorporate design into a business system, but remember, neither IT nor the EHR vendors are designers, and you have already seen their results.

2 thoughts on “EHR: How trained users killed productivity

  1. I’m not from the healthcare sector but all of this sound familiar.. Large prehistoric vendors treating it like an engineering project and charging extortionately for it.

    It’s not in their interest to design a proper useful product. If they did that then the cycle of training and reinvestment that you describe would no longer be necessary, and they would be out of pocket.

    The notion that something as (in interaction terms) simple as a health record should need training is quite frankly laughable. It sounds like the engineering complexity is throwing up design problems, and rather than solve them themselves they are just foisting them onto their customers.

    B2B is starting to catch up with web, but obviously public sector will always lag behind. What’s really needed is a good ux focused digital agency to take a stab at it. Once the first proper, cheap, usable system has been built the old approach will become obsolete. See for an example of this kind of thing in progress.


  2. Pingback: EHRs and the Healthcare Productivity Paradox « – Business Intelligence, PR 2.0, New Media

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s