Healthcare IT Implementations - Begin with the End (User) in Mind

by J Hruby, Director of Marketing

As a project leader assigned to a healthcare IT (HIT) implementation, whether it’s electronic medical records, electronic prescribing, billing, claims processing, or any other HIT initiative, you have big job ahead of you. From requirements gathering, to evaluating options from different vendors, to working with stakeholders to make decisions, to finally negotiating the contracts, the evaluation and pre-purchase phase of any IT project is almost a project in itself.

Project leaders know that they will eventually have to consider training all the people who will need to use the system – physicians, pharmacists, nurses, medical records personnel, administrators, technicians, support personnel, and others —but isn’t this issue of training really something to be considered down the line? After the software is purchased and when implementation is well underway?

The answer should be a resounding “No!”

There is an open window of opportunity during the evaluation and pre-purchase phase where you can have a major impact on the effectiveness of your implementation from your user’s perspective. Unfortunately, this window will be closed as soon as the final purchasing decision is made.

There are two critical things to think about as part of the pre-purchase evaluation and planning process—usability and training requirements. These two considerations will directly impact the most important component in the success of any IT initiative —your user. To take full advantage of the opportunities, you need to begin with the end-user in mind.

Usability evaluations

Would you purchase a car without taking it for a test drive? Probably not.

Yet many organizations invest hundreds of thousands or even millions of dollars in software implementations without effectively test driving it first. Purchasing decisions are made based on cost, compatibility, and features, with no consideration of how well those features work.

The critical reason to consider usability testing now, in the pre-purchase evaluation phase, is simple: The best implementation never has, and never will, fix bad usability. Poor usability causes two problems, both of which impact the effectiveness of your healthcare IT project and cost your organization money.

The first problem bad usability causes is inefficiency. It simply takes more effort and more time to complete tasks using software that has usability problems. Time is money.

The second problem with poor usability is that often usability problems have a nasty habit of becoming “training issues”. What this means is that the users will need to be trained to work around the problems that poor usability and interface design cause. Guess what? This takes more time and costs your organization yet more money.

The risk of not evaluating usability during the pre-purchase evaluation process is that if serious problems are discovered after the contracts are signed, you will have little or no recourse with the vendor. Fixing any problems that are discovered will become a difficult, expensive, and time-consuming process and this will make it even more tempting to put the user’s concerns on the back burner because of time and budget constraints.

However, pushing aside concerns about usability has a way of coming back to haunt software implementation projects. It leaves open the very real possibility of ending up with a disgruntled (or outright angry) user base that resents the software they are now stuck using every day. It also leaves the possibility that software may not deliver on the business goals justified it in the first place. Certainly this is not a pretty picture.

So for these reasons, anyone involved in healthcare IT software purchasing decisions should strongly consider making usability testing part of the pre-purchase evaluation process. There are a couple of things that IT managers and implementation leaders need to be prepared for when discussion usability with a software vendor.

First of all, when you bring up the subject of conducting usability testing, many vendors will say it’s unnecessary because they conduct usability testing internally. Great! Ask to see the test scenarios and the reports. If the vendor really did conduct usability testing, these reports will provide a great starting point to see what they have already found and the improvements they made based on the results.

You can then conduct your own usability tests with your own users to see if your results match the vendor’s assessment and to see what additional improvements need to be made. Or in some cases, testing will reveal that the best course of action is to eliminate that software or vendor from consideration entirely and move on. Yes, it’s an unfortunate fact, but in some cases usability really is so bad that it won’t be worth further consideration, but it’s far better to find that out now and move on.

To some, usability testing can see like overkill and an added burden on top of an already difficult process of evaluating options and the vendors may bristle at the idea of pre-purchase testing. Stick to your guns. If the vendor is serious about winning your business and if they are confident in the effectiveness of their software, they will cooperate.

Almost as an ancillary benefit, usability testing will give your evaluation team key insights into not only the software, but also what it’s like work with the vendor. It’s hard to overstate the value of the information—any information—that is gained before the purchasing decision is made. The more experience you can get with the ins and outs of the software and the vendor, the better off your project will be.

When you have tested your leading software packages, make the purchase contingent on specific usability improvements that are part of the contract. Usually this is not a major hurdle to overcome. Usability improvements generally involve basic changes to the user interface to correct confusing labeling, non-standard application behavior, and other design and workflow issues. But make them part of the contract to make sure everyone knows what needs to be done.

Remember, it may seem like more work, but the time to find out and make these changes is now— before the purchase. You will never have more leverage than you do now. If you discover issues later, fixing them becomes your problem and cost, not the vendor’s. There is a very compelling case for using usability testing to get more value out of your healthcare IT purchasing decision, but the only time this can be done is early in the process, before the decision has been made.

Assessing the training effort

The second to-do in terms of looking out for your end users during the pre-purchase evaluation stage is to plan and budget for your training effort. This can be a tough sell, especially when there seem to be so many more immediate things to address at this stage.

But it’s important to keep the training effort firmly in mind for one overriding reason: This is when the budget and project timelines are being set.

Again, we come back to the same point made earlier with usability testing: The success of any new system implementation is directly linked to the end-user’s ability to use the system to achieve the business goals.

To make sure that resources are specifically allocated to the training effort and the appropriate time is available for developing and executing the training, the time to analyze the scope of the training effort is now—while the project is still in the pre-purchase evaluation and planning phase.

How much will it cost and how long will it take?

As a rule of thumb, training and support materials for package software implementations can cost between 15-25 percent of the total cost of the project.

Surprised by that number? You’re not alone.

It might not surprise project managers who have tracked training as part of project budgets before, but many organizations think they can deal with training as an afterthought and they underestimate the time and money it will take.

This leaves these organizations and the implementation project managers trapped in a Catch-22. Users will be the ones who ultimately determine whether a system meets the business goals that justified its implementation. If the users aren’t trained, what are the chances of the business goals being achieved?

Remember that old bumper sticker—“If you think education is expensive, consider the cost of ignorance”? The same principle applies here. The unfortunate result of a poorly planned and skimpy training effort will be at the very least a slower return on investment. In today’s economic environment that factor alone is bad enough. But in healthcare IT, economic factors are not the only worry. Poor healthcare IT training can also impact the quality of patient care and patient or staff safety. Training simply can’t be left to chance when it comes to healthcare IT implementations.

Determining the scope of the training effort

Just as in every other facet of healthcare IT, there is no quick back-of-the-cocktail-napkin way to accurately determine the scope and cost of a training effort. There are, however, a few questions that you can ask to get a feeling for the relative size of the effort.

Consider these:

• How many users will need to be trained by the go-live date? Don’t forget to include system administrators, help desk personnel, and other support personnel that will need to use the system, even on an occasional basis.

• How many new users will need to be trained every month because of turnover and new hires? As long as the software is in active use, there will most likely be some need for ongoing training.

• How big of a change does this system represent for the average user? Is this a minor add-on to their job, or will it completely change the way they do virtually every task during their working day? The bigger the change, the larger the scale of the training effort.

• How long will it take to train each user in every major user group to a minimal level of proficiency? Try envisioning the training, will it be an hour long, a day long, or even a week long? Be honest in your estimation and error on the side of pessimism. Remember, unlike the IT project team, in most cases the users will have no prior exposure to the system before the training starts.

• In the past, how have the other successful healthcare IT implementations in your organization trained their users? Instructor-led classroom training, eLearning, individual one-on-one training or by other methods? The method by which the training is delivered has a major impact on the training development timeline as well as how long it will take to actually conduct the training. In some cases, the training has to be finalized weeks or even months before the actual go-live date.

• Are accurate metrics available to show you how long it took and how much was spent on similar training efforts in the past? If so, what was the cost and time spent per user to develop this training? Was it adequate?

• Are there resources available that can make this training effort their full-time job? How many and do they have the right skill set? While many healthcare organizations have an internal training staff, in many cases this staff needs to satisfy regulatory and ongoing training needs. Don’t assume that “the training group will take care of it.”

• What are the consequences of a user error that comes from insufficient training? Lost money? Lost productivity? Potential injury or loss of life? All of the above? The more severe the potential consequence, the more diligent the training effort must be.

• What are the expectations for ROI and cost savings? What is the expected timeframe for this ROI? Again, if organization expects a rapid return on investment, training must be a priority.

Answering these questions isn’t a substitute for a proper needs assessment, but it will show you what you’re up against. If it’s difficult to answer many of these questions, it’s a sign that the sooner you do a training needs assessment, the better off your project will be.

The myth of free training

It’s very likely that sometime in the pre-purchase evaluation and planning process, IT managers will hear some version of this phrase: “If you purchase our software/system, we’ll include free training . . .”

If this sounds like a great (and cheap!) solution to your healthcare IT implementation’s training needs, let’s begin by stating that this is one gift horse you should look in the mouth. Yes, there are vendors out there who will provide some level of “free” training as part of the purchase of their system. But there’s a catch. There’s always a catch.

First, any training that is included with the software is likely to be limited in scope and constrained in other ways. While this “free” training may be suitable and useful for some users, in some roles, it likely won’t provide adequate training for your entire user base. There will also likely be limits on how much of this “free” training you’re entitled to.

Secondly, you need to closely examine the specifics of this free training. On what system will this free training be delivered? Will the training system be exactly the same version of your system? Will the training include the customizations you made to the software? Will it reflect your specific business process, policies, or care delivery processes at your organization? Or will it be generic training on a vanilla version of the software?

In fairness to software and IT vendors in general, training included with any software or hardware purchase is not without value. At least for some users in some roles.

However, most users will need specific training that teaches them how to use your specific implementation of the software as well teaching as your organization’s methods and requirements for using the system. That level of business-specific training is seldom, if ever, provided as part of a vendor’s free training program.

The bottom line as it relates to training is simple: The training effort is going to take more than just whatever is left over in the budget after everything else is done. Training is no different than any other aspect of IT, the more thought that is put into planning and executing the effort, the better the results will be.

Start by thinking about the finish line

Looking out for the needs of your users starting in the pre-purchase and evaluation stage of any healthcare IT implementation has many benefits. The most important thing IT managers should keep in mind is that this stage of the project represents a key window of opportunity that will not remain open once the contract is signed.

Making usability testing a part of your evaluation program and assessing the scope and resources your training effort will require are not just feel-good items. They are linked to very real business concerns—namely efficiency and the speed and size of the return on investment.

But beyond the hard business reasons, there’s also some enlightened self-interest at stake for IT managers and project leaders. Ultimately, the success or failure of an implementation is determined not by the technical achievements, but by the way the technology improves (or hinders) the jobs of those that use it. A vocal group of unhappy users will drown out technological triumph every time.

There is also no way to make up for the opportunities that were not capitalized on during this phase. The earlier you start planning for the needs of the user, the greater the likelihood that your healthcare IT implementation will be a success. The temptation is to focus getting the system purchased, programmed, installed, and otherwise working, but the real success of the system will depend on the users and how quickly they achieve the business results and care-delivery gains that justified the system in the first place.