Getting Started: How to have a Successful Implementation

This interview is presented as a two-part YouTube presentation -- Due to the length of the discussion (about 18 mins) we're going to give you chance for an iced-soda or comfort break between the discussions. Click Part 1 or Part 2 of the YouTube presentations to listen to our interview. A bit old-fashioned I know but the more traditional of our posters, visitors and lurkers may choose to read the transcription of our interview below. 

(Part 1 of 2)

Robert Gleeman:  This is Robert Gleeman with EMR Update. I'm talking today with Mark Anderson from the AC Group. We're going to talk today about how to have a successful EMR implementation.

Mark, thanks for being with us today.

Mark Anderson:  Thank you for inviting me.

Robert:  Mark, what do you call a successful implementation on EMR? How do you define it? And why is it so important that a person be concerned about this before they buy the EMR?

Mark:  I think the definition really goes back to: What does the doctor really use the EMR for? If the physicians are out there buying EMRs and they're not able to use the product to actually improve their operations, improve clinical outcomes, it's kind of a failure. How long it should really take for a doctor to get this thing installed, get it configured, learn how to use it and really get the successes out of using the product is a major of a lot of the physicians out there. They've heard all the horror stories out there.

Robert:  Why did you want to do this session on implementation so badly; more so than the other ones? Why this one?

Mark:  Well, we did a survey of about 4220 doctors, I believe, the number was in fact, between May and September of 2007. And we asked a simple question: One year after buying your EMR, are you using the EMR to document the patients' visits, look at lab results, and write prescriptions?

The typical things that are in an EMR. So one year after buying EMR, are you using it to see 80% of your patients? We thought the number would be very high, that a lot of doctors were using it. We found out that 73% of the doctors that responded stated that, "No. They were NOT using the EMR for 80% of their patients." Which to us classifies as kind of a failure.

If they're going to spend the money and one year after buying, why aren't they all using it? There must be something wrong relating to either the products or the implementation training and configuration. We all know certain products are installed and working well in practices. We have a lot of good case studies out there.

If it works well in one practice and does not work well in multiple other practices, in this case 73%, there must be something going on that's not necessarily software‑related. But the implementation training and configuration, there may be a problem in that area. And that's what we spent the last three months actually researching. What goes wrong with implementations?

Continued below ...

... continued from above.

Robert:  What is usually the result of your study? What does go wrong?

Mark:  We found that what most of the vendors are doing today is that they're selling you a package and they're providing services. The services include installing the application on your computer and what the vendors call configuration, which traditionally is setting up your physician name, setting up your CPT codes, and your diagnostic codes. We used to call that master file build, but a lot of the vendors are calling that configuration today. And then the vendors are teaching you how to use the product around how they've been trained to show and demonstrate the product.

The product is not being configured around clinical work flows the doctor wants to actually work on. The doctors have to figure those things out as they use the product. These are business‑related questions and work flow questions that the majority of the EMR vendors do not bring up during their installation, configure and training. That's what we have found is the gap out there: it's the business side of running your practice. That's where most of the vendors are not getting involved in helping the practice figure out.

Continued below ...

... continued from above. 

Robert:  What should the vendors be doing differently, and what should the doctors be doing to make sure they don't have an implementation problem?

Mark:  The best way to answer that is to go back and look at some of the success stories out there. We've gone back and talked to a number of practices that are classified in the industry as being very successful. They won the Davies Award or won other awards [indecipherable] state why they're getting some great benefits out of it. We really went down and said, "What made you successful with this EMR?" What we found is that they are spending a lot of time upfront identifying the business issues that they want to address.

An example would be:  What do we do with the old paper chart? Most of the vendors will come back and say, "Well, what do you want to do it? Do you want to scan it in, or do you not want to scan it in?" We've come up with 10 different ways of handling the old paper chart and to figure out what you'd want to do with it.

They looked at the different ways of handling the old paper chart and have looked at the business benefits‑‑the best practices‑‑of the 10 different ways of handling it. They analyzed it, they figured out what's the best way for them. They configure the product that way, and then they train their staff to use the software to match their business work flow and policies. And this case is just one example‑‑What do you do with the old paper charts?

Robert:  It sounds like you're saying that both the vendor and the doctor need to be more applications‑oriented, more solutions‑oriented.

Mark:  Yeah, I think it's getting away from just selling a product, and getting into, "How does this product really work within the business?" It's like going out and buying a car. The salesperson sells you the car, and they may show you how to turn the engine on, but they don't teach you how to drive it.

Those are business issues that the vendors need to say, "Here are 100 business issues that you have to decide before we configure your product." And they don't do that. They're only giving you 10 or 15 hours of total training per provider, and that includes the office staff, the nurse, and the doctors. There's not enough time to analyze the practice, do all this analysis, configure the product and then re‑configure how you do training.

What the vendors want to do is put the software in and start training the way the average physician does everything. Well, I haven't met an average physician yet. They all want things done the best way. I'm not saying their way. But what are best practices? We've even asked some of the vendors. Here's an example of a paper chart. What are best practices? What are your successful doctors using your product for, relating to how to handle the old paper charts? And they draw a blank. They don't know.

Another good example is that on the paper chart system, the nurse knows what patient to bring back next based on the way the charts are stacked. When you have an electronic health record system, you're going to know which patient to bring back next. It's typically based on a policy: either appointment time or show‑up time.

If somebody shows up 15 minutes late, do they get seen before the person who shows up on time? Those kinds of things; that's a business decision the practice has to make. Then you have to make sure the product can handle that. If the product only shows you the appointment time and not the check‑in time, then automatically you're going to bring patients back based on appointment time. And a practice may decide, "No, that's not our policy. The software doesn't work that way. We can't use the software for doing it."

So there are a lot of little questions that, if we asked those questions upfront, answered all of those business questions and then matched how the software would work around those, you would have much happier physicians. The implementation would be much stronger if you ask those questions upfront and got good answers to those business questions.

Robert:  What would you say is the most important question that the doctor should ask regarding implementation from the beginning?

Mark:  I think what it gets into is, "Once I sign the contract to buy your product, when does somebody come in to analyze my work flow? And then, will your trainers train us on our‑‑I like to call it‑‑best practices work flow?" Because when a doctor buys a system, they really don't know how their work flow is going to change with the EMR.

A lot of the vendors will tell them, "Oh, just install our product the way we have it, start using it and then you'll figure out best practices later on." We call it clinical and operational transformation. How do you transform the practice to maximize the use of the software? Some vendors do it very good...

(Part 2 of 2)

Robert Gleeman:  It seems one of the main focuses of implementation that I've seen is round about paper and incorporated into the EMR. In other words, paper is the enemy. Let's make a catalog of all the paper forms and lists that you use, and the implementation is done when all the papers absorbed into the system. How does that go wrong and what do you think about that approach?

Mark Anderson:  Well, the problem you run into with all the paper today, you look at‑‑if I could take 12 documents today that that physician is using, I may be able to convert all those 12 documents into two pieces of screen real estate, because a lot of the data's repeated. If I don't go through that analysis and figure out all that, I may not create the right‑‑get workflow around what that practice really wants to do. And once I have this piece of paper, who does the information go to?

For instance, a lab result. When a lab result comes in, what is you policy? The policy is if it's a normal lab, then maybe it goes to the nurse just to review and call the patient. If it's an abnormal lab, maybe it goes to the doctor first. Or it may go to the nurse‑‑to the physician, and then maybe the physician gives it back to the nurse. That's a workflow process. Again, abnormal lab results or a normal lab result, what is the policy and procedure for handling that?

That is never‑‑rarely ever discussed in an implementation. They basically say here's the product. How do you want to do it? If you've never used the software before, you're people may not know the answer to that.

Robert:  So the doctor, when he goes and talks to the reference‑‑the existing user of the software‑‑perhaps instead of saying, "Why do you like the software?" perhaps more, "Why did you like the implementation? How did that go?"

Mark:  Yeah. How did the implementation go? What did you learn? What would you have done differently about the implementation? I've‑‑I was actually at a conference about a month ago and they had, I think it was six different physicians groups talking about how they implemented the system. Of the six, five of them said, oh the first implementation was terrible. We had to redo the whole thing.

So here you got five out of the six saying implementation failed the first time. They went back in, looked at their workflow, looked at different things, and implemented a second time. So all six of these were very successful implementations at the end. But five of them had to redo it.

So again, that was the question. What did we learn? Oh, we would have done a lot more analysis up front. We would have done things differently. And that's what you're trying to learn. What are best practices? And then you learn from some of these groups that failed the first time that got it right the second time. I think there needs to be a good, long conversation just about implementation.

I think there are a lot of great products out there. In our database we have 386 EMR vendors that we know about. Every one of those vendors has, probably, at least one or two very successful implementations. All the products work. You've got to make sure the product meets your requirements, but it's not just functionality. It's about how well that product is going to work three months, six months, or a year after buying it. I don't care how great the product is, if it doesn't work for the practice, in this case‑‑if you never learned how to drive the car, you're going to have accidents‑‑people are going to fail.

Robert:  What can we say to vendors to make this better?

Mark:  Well, I think most of the vendors I've talked to agree that more work needs to be done around that. They're comments are the physicians won't pay for it. They just want to find the right product at the right price. They won't pay for that extra time it takes to make the product work for the practice.

I think that's not true. I think doctors pay for value. And if doctors realize that they have, statistically, a 73 percent chance of failure, that they'll spend a little bit more money so they don't have that failure. They'll reduce that risk of failure by implementing it the right way.

Now certain doctors are just going to‑‑they're going to want to go after best price and the cheapest price. Certain ones won't have failures, but the 73 percent‑‑call it non‑success rate. We call it failure rate. One year after buying the system the doctor still can't really use it effectively. Why buy it? Why spend the money doing that if you're not going to be successful?

Robert:  Do you see any difference in how the manufacturer conducts implementation as opposed to a VAR?

Mark:  If they are a local VAR, I see that they spend a lot more time with the practice because they're local there. They can drive over, talk to the doctor. They work through the processes a little bit more then the traditional national‑based vendor who's just really selling the product, spending a couple hours, and then leaving. Maybe 20 hours, 40 hours, whatever it takes.

I think it's all about the follow‑up. Who comes into the practice two days after installation, after go live, to see how things are going? Local VARs can do that. They can come back in multiple times. But if you're buying a product where the vendors going to come in, install and train and then maybe they're just one day during go live, what happens two weeks later? Or when an employee quits and you have to hire a new employee? How does that person get retrained on your new policies and procedures?

I think a local VAR, potentially, can provide a lot better support. But again, that's where you have to ask the right questions. How many hours do you spend looking at workflow and workflow optimization? And 30 days after, 60 days after, 90 days after is somebody coming back in to analyze my practice to make sure I'm optimizing the use of the software with my business processes. That shows success‑‑is when somebody's reviewing it ongoing to fine‑tune the process of using the product.

I think the difficulty is you're talking to a salesperson. Most sales people understand how to sale the product. They don't have as strong a knowledge, traditionally, on the implementation process. So you may have to ask the sales people to talk to their implementation team. And to find out, again, will the configuration and the training be customized the way I want to run my practice? In other words, will the training be built around the way we do things?

Robert:  That's excellent advice, to talk with the implementation team as well as the sales team.

Mark:  There's a way of determining how much customization you really want out there to the product. It really‑‑it's not customizing the software product; it's customizing how you use it.

Robert:  How often do you think a doctor needs to refresh the implementation and get some new knowledge in the office?

Mark:  I think it really depends on how often the software is updated. But I think there needs to be more communication between the new user of a software product and‑‑I don't want to call older users of the software‑‑but experienced users, online chats between multiple doctors, practices that are using the same product. Ongoing communication between practices, maybe in different regions, that uses the same product.

Robert:  Any parting words for the doctors out there?

Mark:  I think the bottom line is we have found‑‑and people's always reminded us of this‑‑the functionality's not the only part. It's functionality. The company has to survive. The usability has to be there. But I think now, implementation, which again is installation, configuration, training and follow‑up, needs to be one of the highest points to be successful.

You can buy a great product. It's going to sit on your computer if‑‑ but if no one ever uses it; it's never successful to that organization. So you may buy the right product, but implementation will either make it work for you, or will break you if it's not done effectively for that individual practice.

Robert:  Mark Anderson, AC Group, thank you very much for being with us today.

For more information about the subjects discussed here you can contact Mark Anderson at the details listed below.
See our other Getting Started resources here.

Mark R. Anderson CPHIMS, FHIMSS
CEO and Healthcare IT Futurist 
AC Group, Inc.
118 Lyndsey Drive
Montgomery, TX  77316
(c) 281-413-5572
(f)  832-550-2338
email: mra@acgroup.org
web: www.acgroup.org

Robert Gleeman
Medical Journalist and Sponsorship Agent
Email: robert@emrupdate.com
Tel: 1-650-968-6359
Skype: robertgleeman
EMR progress is a matter of fact.
EMR Update supports your right to know.