Implementing an EMR? Five mistakes you should avoid
From the December ACP Observer, copyright © 2003 by the American College of Physicians.
By Jerome H. Carter, FACP
You've done a lot of comparison shopping, kicked the tires of several electronic medical record (EMR) systems and even signed for one on the dotted line. Are your EMR worries now over?
Hardly. While everyone knows at least one software implementation horror story, the number of implementation-gone-wrong tales just keeps growing.
Failed implementations are not limited to health care. In fact, major studies of information technology initiatives discussed in the April 2001 issue of Communications of the ACM revealed that as many as half of all software projects ended in failure across all industries. According to a 1997 study published in the April 1997 International Journal of Technology Assessment in Health Care, information systems projects in health care had an equally dismal track record.
What dooms an implementation to failure? Size can be a major factor, with smaller generally being better. In my experience, groups of more than three physicians often wind up with more implementation problems, possibly because they have more decision-makers to appease, more to consider when planning and less flexibility to respond to unanticipated events.
But having a small practice is no guarantee of success. Studies conducted by the business consulting firm KPMG in 1989 and 1995 identified five key reasons why information technology launches fail, regardless of company size. They are vague or shifting project objectives; bad planning or estimation; poor project management; insufficient senior staff; and poor performance by a software or hardware supplier.
Here is a look at each of these pitfalls—and some advice on how physicians can avoid them.
1. Vague objectives. To say you need to know ahead of time what you are trying to achieve seems like obvious advice. But goals and objectives have a way of changing when everyone is excited about getting a new computer system.
One common mistake is to alter the scope of an initial project after implementation has already begun. Here's a typical scenario: A small practice decides to add an EMR to its practice management system, and it wants to be able to download lab results from the main hospital to its EMR system.
The group presents its plan to the hospital administrator, who is receptive and mentions the idea to other practices. The hospital then decides to advance its own information technology strategy and save money by linking all local practices with a different EMR. The practice that initially wanted to add its own EMR is now part of a larger project—under the direction of the hospital.
Changing the scope of a project after-the-fact—to add sites not originally included or to expand a system's functions—is guaranteed to sabotage your implementation.
Vague or open-ended objectives are another problem. This is usually the result of what I call a "technology rush." Dazzled by an EMR demonstration, key decision-makers decide that they must have one of their own. The problem, of course, is that they start to identify project objectives after the software has already been selected.
The cure is to spell out objectives ahead of time. Make an exhaustive list of problems or issues that you want to solve with a new system, ranking those issues by importance, as well as a detailed "wish list" of features or functions you want the system to have.
For a three-physician group, this kind of document should require at least a month's worth of meetings and revisions, and it may run as long as 30 pages. Once system software is installed, be sure to establish a process to see if all those objectives have been met.
And what should you do if you find your hospital pre-empting your EMR implementation? Stop everything and rethink the entire project from the ground up. This can easily take an entire year to do properly.
2. Bad planning. There are several classic symptoms that an implementation has been poorly planned, or that the money, time and resources to pull off a successful launch have been (usually) underestimated.
Critical implementation dates keep being missed, for instance, or the cost of installing equipment mushrooms beyond what was originally budgeted. Key interfaces are not ready when the system goes live, or staff productivity doesn't bounce back because of insufficient training. Or the system is only partially implemented, forcing you to use both paper and electronic records.
Successful implementation requires a great deal of planning. A partial list of concerns that must be carefully mapped out ahead of time include: wiring layout, equipment purchases, maximum load response times, back-up strategies, staff training, data migration, data security and disaster recovery, and workflow alterations.
A good place to start would be simple project management software that details every step you need to take, who is responsible (vendor or practice), and how much that particular item or phase should cost. Regular meetings with both vendors and staff to review the plan are critical.
3. Poor project management. Even with focused objectives and a comprehensive project plan, many groups make a potentially fatal mistake: They leave the management of the plan up to their information technology committee. Even worse, they may turn project management over to the vendor, one of the partners' relatives or the staff person who has the most time on his or her hands.
Project management is an underrated skill and is not an activity that can be handled by a committee. Good project management requires a clear line of authority, a sound grasp of project objectives and sensitivity to resource consumption.
A well-managed project has a clear time line with well-defined milestones tied to specific budget outlays. It should also identify a central go-to person when things go wrong.
The best hope for completing a project on budget and on time rests with the skill of the person managing the project. In a small practice, the office manager armed with a spreadsheet and a penchant for details may be adequate. In larger practices and for implementations that cover more than one site, a project manager who spends half or more of his or her full-time job may be required.
When picking a project manager, select someone who is detail-oriented with good people skills and a great sense of humor. That person is going to need it.
4. Insufficient senior staff. This is likely to be a concern in very large practices. You know your project lacks the involvement of senior staff when a project manager is convinced that some aspect of the project needs a major overhaul—a different vendor or better equipment—but can't even get a meeting with upper management, let alone serious consideration.
Having senior staff on a project serves two purposes: First, they may have overseen other technology projects, so know ahead of time what can go wrong.
Even more importantly, their access to upper management ensures quick decisions. When identifying senior staff for implementation, look for people with strong administrative skills, sound technical knowledge and sufficient clout. They need to either be one of the "big guys" or have direct access to the chief information or executive officer.
5. Poor supplier performance. Even the best planned and managed projects can be plagued by a quirky wireless network, flaky server, unreliable Web site or computer-to-computer interface problems.
Vendors often make promises that they cannot keep or are blatantly false. The most egregious example of this is unfinished software. Vendors, eager to get a product to market, scrimp on testing or leave out functions or features that they list anyway in their glossy brochure.
Unwitting clients buy the software and then, under the guise of customization, pay for finishing the product. Or you discover that your practice is the beta-tester for what was purchased as a finished product.
The key to avoiding supplier problems is good background research and detailed evaluations of vendors and their products. Review the vendor (as you would any company in which you're investing a good deal of money) to assess its market share, years in business and customer satisfaction.
Get a working copy of software to evaluate its performance with your data and in your practice. Find current customers who have similar needs and practices, and ask detailed questions about the product's bugs, features, update frequency and maintenance. Finally, assign some risk to the vendor in case the implementation is delayed or derailed because of problems with the product.
Avoiding these mistakes will lead to a successful implementation, something that is not a chance occurrence. Instead, it is the result of quality products selected according to detailed plans, with clear objectives carried out by capable managers.
Jerome H. Carter, FACP, is director of informatics at the 1917 Research Clinic in the division of infectious diseases at the University of Alabama at Birmingham. He is the former Chair of ACP's Medical Informatics Subcommittee and edited "Electronic Medical Records: A Guide for Clinicians and Administrators," published by the College in 2001.
Internist Archives Quick Links
Superior MOC Solutions from ACP
Meet your requirements with our approved activities. See details.
Making the Most of Your ICD-10 Transition
To help you and your practice make a smooth and successful transition to ICD-10 coding, ACP and ICD-10 content developers have created multiple resources available at discounted rates for ACP members.