There is No Magic Solution When It Comes to Implementing New Electronic Health Record Technology

Healthcare is facing big changes.

As evidenced by the media, there seem to be no boundaries on the extent to which this can be discussed. Putting much of it aside, I would like to offer a few thoughts on the adoption of electronic health/medical records, as the advancement of new technology in healthcare appears to be a major platform of the Obama administration’s plan.

My first observation is that despite the Obama administration’s “Change/Hope” platform, with regards to EHRs, there is no disagreement with the previous administration’s view: EHRs will streamline care, reduce waste and therefore costs, and reduce errors, thereby improving outcomes for patients. So, this is terrific, because we actually have some agreement about the problems/answers of healthcare. To the “civilian,” that sounds pretty fantastic‑‑“streamline care, reduce waste and therefore costs, and reduce errors, thereby improving outcomes for patients.” For those of us working in healthcare, we realize that it is not so simple.

A typical IT implementation rollout

What actually happens is more complicated, and the real benefits of a new EHR system are often debatable. We spend millions of dollars on the software and the training. Timelines for training and “go-live” dates are constantly set back. This takes away from other initiatives that have been designed to improve care. Productivity drops dramatically. Overtime increases. At some places I have worked, seasoned clinicians decide that the new system is just the signal they needed to retire. Ironing out the kinks of the new system takes years, and when that happens, we’re operating roughly at the same levels that we were before we began this endeavor. During the course of that time, we have often been forced to adopt other technologies that don’t “speak” to the new system, and we come to live with these shortcomings because we have to. After all of that, there is sure to be a new system “update” that will come along in the not-so-distant future.

Now, that is a pretty chilling assessment, but if you have been around for a while, I would bet much of that resonates with you. Why is it like that? I always ask my clients who are not satisfied with their current IT systems, “What is different now as you prepare to take on this new system? What have you learned that will keep you from being in this same position two years from now?” I get all sorts of answers to this interrogation. Many people cite an insufficient investment in either training or post go-live support. Occasionally, I hear that staff are “stuck in the stone age” that is, not willing to learn a new system. One answer that particularly interests me is, “We involved the clinicians in the design of the system, but when it was finished, they weren’t happy with it.” The most common answer I hear is about the failure of the technology: “It just wasn’t designed well.” We blame the technology. A colleague of mine was discussing this with Greg Daines, founder of Knowligent, an IT consulting and services firm based in Boston, MA, and Daines said something interesting. “No IT adoption has failed because of a lack of capability of the technology.” To some of you, that probably sounds crazy. What if that is true? We need to step back and take a look at how we generally go about implementing a new IT system at a healthcare organization.

First, please forgive me for being overly simplistic in my description here. Traditionally, an IT implementation happens in three phases: system build, training, and “go live” and post “go live” support.

System build

The major providers of large-scale IT solutions have years of experience in helping design and customize systems to meet their client’s needs. Starting with a basic platform, teams are deployed to understand how different teams and departments will need the system “tweaked” to suit them. During this phase, frontline staff members have the opportunity to provide input into the design of the system.

Training

A few people from each department are assigned to become “super-users.” While everyone will get a good deal of offsite classroom training, super-users will get extra training so that they can be a resource to regular “end-users” after the system is up and running. Training consists of walking through a user manual and learning the various functions of the system as appropriate. Most often, staff will have paid time allotted to practice using the system in a computer lab on-site, where there will often be super-users and members of the implementation team present to help navigate through problems.

Go-live and post-go-live support

A great deal of effort is put into understanding the order in which different departments should be up and running. Some departments can operate independently, and some cannot. That’s pretty complicated stuff. Once each department “goes live,” we invest an enormous amount of resources in order to have help available to the end users while they actually use the new system and take care of patients. This is when, as I said above, productivity drops dramatically, and the “hidden” costs of the new system begin to be realized. I’ve even worked with a few clients who can attribute terrible patient outcomes to the post go-live confusion. It’s pretty scary stuff.

So, what is going on here? If, as Greg Daines states, “it’s not about the capability of the technology,” then what is it? Are many staff members really stuck in the past and unwilling to learn something new? I witnessed an encounter during an IT training session that I really loved. At the beginning of the session, the teacher from the implementation team said to a group of seasoned nurses, “Now,

I know it’s scary for some of you to learn how to use a computer…” One nurse said, “Don’t give me that, we’ve all been using computers for years. I use computers more than my daughter and she’s a high school principal!” So, I don’t buy the idea that nurses aren’t willing to use technology. Is it a failure to dedicate enough resources? Remember, this is what many of my clients “blame” their “bad” systems on. It’s my observation that once underway, large organizations hemorrhage time and money in an attempt to make the transition successful. If it’s not the technology, and it’s not your staff or your financial commitment, then what is going on here?

A few years ago, we got a call from a former client who was anxious about the new EHR their hospital (Hospital B) was about to adopt. The hospital was part of a larger health system and, luckily, not the first hospital in the health system to “go-live.” The first hospital’s (Hospital A) rollout was, by all accounts, not a success. My previous description of a typical rollout was based on quotes and observations from Hospital A’s initial IT rollout. Fortunately for our client, Hospital B, they had the sense to try something different rather than just trudge along a predictable (and dangerous) path.

First, let’s look at outcomes, taken from a working paper written by staff at Hospital B.

Time taken to return to preimplementation staff productivity:

Hospital A: 12 months

Hospital B: 9 weeks

“Incidents” in first seven days as a ratio of daily census:

Hospital A: 6.5

Hospital B: 3.5

To summarize, it took more than five times longer to return to previous (note: not an improvement) productivity levels with almost twice as many verbalized safety concerns at the hospital that used the traditional approach to IT implementation.

Now, what did Hospital B do differently? There are three keys to understanding how their approach was different: context, problem solving, and timing.

Context

Traditionally, we teach people to how to use a new technology by walking them through an exploration of all the functionality of the new technology. Hospital A did this in a classroom setting, which is pretty standard procedure. At Hospital B, a wise super-user took note of a nurse who stated, “This all sounds great, but I have absolutely no idea how to admit a patient, and I’m going to need to do be able to do that.” The super-user helped make a case for teaching people to use the new system in the context of how they take care of patients, rather than the context of what the system was capable of. This was a profound discovery. Immediately, super-users began observing staff in all departments in order to learn what tasks different people do so that they could practice those tasks with the new system. Staff became energized, rather than intimidated, when learning how their work would change. Also, by learning the system by practicing doing their work, staff actually had some sense of how things needed to be customized. Remember the nurse who wanted to know how to admit a patient? I was there when she learned how to do that. After her third pass through, she said, “This actually works better than the way we’re doing it now!” I was excited to hear that. (Though, as a side note, how low have our expectations become about the ways that healthcare will change?)

Problem solving

To be fair, I should mention that Hospital B had a platform for process improvement/problem solving that was fairly robust before we explored a new way to integrate the new EHR. Staff at Hospital B had learned to see problems in their work as an opportunity, rather than a reason to throw their hands in the air. That capability was critical to the success of the implementation. Also, this capability made it very clear who each staff member would turn to for help. The shared language and openness around system shortcomings allowed the staff and implementation team to swiftly address every problem they encountered and quickly move on to the next. Staff at Hospital B were taught the necessary skills needed to speed up the process of ironing out the kinks in their system,

as evidenced by the return to preimplementation productivity. At Hospital A, and almost every place I visit, when staff members discover a problem with a new technology, the most common reaction is (approximately) “Why would we even change to this system? It makes no sense.” The difference in the perception of problems at the two hospitals had a huge impact on the rollout. When Hospital B went “live” with the system, they had already identified and addressed 1,030 problems. Hospital A had addressed about 130.

Timing

Did you catch that I said “already” when I mentioned the problems addressed at each hospital? That’s a key here. Both sites were 400+ bed hospitals. Large-scale IT implementations are incredibly complex. Hospital A had just as many problems with the implementation as Hospital B, and they did eventually sort those problems out, but they did it after go-live, not before. Sorting these problems out is a lot more complicated when you have real patients who need things. It also lends itself to workarounds, which greatly reduce staff productivity. Remember the number of post go live incidents I mentioned above? Hospital B avoided real incidents by simulating them before go-live.

Implementing IT systems in hospitals is very complicated. The cost of implementing these systems is much higher than we expect and often dangerous for patients. The extent to which this is true often offsets the benefits of the new system. If you want different outcomes, you are going to have to take a different approach:

• Redesign the teaching program so that the emphasis is how staff members take care of patients, rather than how the technology works. (This is difficult, I know.)

• Have a systematic methodology for addressing problems, and engage your staff in the process. They understand their own work much better than do you or I do.

• Allow staff to encounter as many problems as possible before the system goes live, not after.

Now you have my “magic solution.” Good luck.