Aaron Berdofe, MHI – Health Informatics

Back in September, I posted some of the hurdles that organizations experience when implementing an ambulatory EMR.  The top three that I had dealt with at the time were:

• Treating the implementation as an entire organization project instead of a solely Information Systems/Technology project.
• Physician acceptance and leadership
• Reviewing existing physician practice group procedures and policies and homogenizing those before the implementation begins.

In other words, most implementations fail before the code gets delivered.  We all know that once the code is delivered, it may or may not work and you may or may not be assigned a specialist from the vendor who knows how the software is supposed to work whether it does or not.  Suffice it to say, it’s best to have your ducks in a row before you deal with everyone else’s problems.

However, with the “Meaningful Use” movement many people outside the IT department are taking notice and some physicians are feeling less reluctant because there might be some money on the table for them.  My last implementation was done without a physician champion.  There were just a bunch of willing physicians.  Sensing a change in the wind, I posted the following query to the MEDITECH-L to get some outside input:

I’m curious to know from those who have implemented or are in the process of implementing the LSS MPM suite fully or another EMR attached to MEDITECH, what were the top hurdles that were overcome or still need to be tackled?

Here are the top 3 things I’ve noticed with clients I’ve helped implement or advise lately that slow down or halt an implementation:

1.)  Fighting with the vendor about functionality or not being able to find out how a piece of functionality works.

2.)  Lack of personnel that understand how the system works.

3.)  Lack of inter-departmental communication (i.e. between implementation team and LAB/RAD while setting up ordering through AOM).

The responses were from a mix of consultants and “real people” that are actually employed by healthcare organizations (Consultants are generally figments of your imagination).  Posted below are the unedited responses that didn’t reiterate my three points and my comments on them if I felt they were necessary.  Thanks to all those that responded!

• I would clarify #2, lack of Meditech personnel that understand how the system works. For 6.0, they are very short on staff who know anything…and those that do, get hired away by consulting firms.
• Communication to physician offices AND their staff.
• Communication to off site clinics.
• Communication to IT staff of the project, and what their role will be during all the stages.
• Failure to plan for adequate resources and training
• Failure to plan for ongoing maintenance of users from the physician offices
• Failure to peform a system wide hardware evaluation, i.e. are the physician offices even able to use what they have, if not, who’s going to pay to replace it? Some folks can get zealous about hardware, especially regarding the wired/wireless debate.  I’ve seen it work both ways, but the rest of the world is becoming increasingly mobile.
• First the MPM suite works best with full implementation.  When you use only “part” of it things seem to go wrong.  For example, they want lab/rad results in the messaging but the orders are entered outside of PWM (i.e. via Lab, Rad, or OE). Extremely important point for LSS customers!
• Second, it is best to identify who are going to be the primary users of the system (receptionists, medical assistants, RNs, providers) and try to make it as user friendly as possible for those users.  In a clinic setting there is often the mistake of trying to please all of the doctors (who are 20% of the users) at the expense of your medical assistants (who are 60% of the users).  Basically, pre-implementation planning is HUGE.
• Third, the more customization you have the more maintenance you have.  The more maintenance you have the more staff you need to support the system.
• Yes we have struggled with support from LSS but it seems to be more related to when we want to “customize” or only use partial functionality.  The staff at LSS are just not familiar with all the nuances and tend to let things sit when they don’t understand what is going on.  We have had good luck with scheduling conference calls where they dial into the system to see what we see.
• Some of the obstacles still exist and some we have been able to circumvent.  Of course, now we are going to 6.0 so who knows what that will bring. As alluded to here, don’t think an upgrade will ever solve problems.
• You missed the most important: providers with “I don’t want to” and “You
  can’t make me” attitude. The rest pale into insignificance. Unless there’s a
  physician who is leading the charge, keep resume up to date. They’re still out there, but see my point above.
• Lack of EHR roadmap and timeline for clinic and hospital – this
  continually leads to re-work etc etc. I would also add that even if there is a roadmap, it shouldn’t be changed constantly by execs or management.  Things will come up.  Stick to the plan.  Give your project manager the power to say no.
• Clinic Managers who do not understand what it takes (their involvement)
  to transition a site from electronic to paper. If a dashboard of live or semi-live information that is relevant to the clinic managers is the end goal, they’ll see how the project benefits them.  Otherwise, they just think of it as a new burden that their staff will complain about.
• No internal coordination or Administrative support for decision making.