The hard work is done. You’ve made the decision, signed a software contract with a vendor and are taking the plunge into the world of electronic medical records (EMRs). Now you just have to install the system and start doing all those wonderful things the salesperson told you about, right? Maybe not. In fact, there remain the rather large tasks of installing the EMR and completely changing how your practice operates on a day-to-day basis. Though numerous EMR software products with varying features and costs are available, many of the implementation tasks are common to all of them in any practice setting – single-physician, multispecialty and residency practices alike. This article outlines the major issues that were involved in implementing an EMR system in a small family practice residency clinic at the University of Wisconsin Department of Family Medicine (UWDFM).

The EMR

After three years of evaluating EMRs and developing funding sources for implementation at one of our family practice residency clinics, we chose EMR software that would allow us to meet our goal of having a completely paperless medical record. In October 1999, we decided to install Practice Partner Patient Records at the Belleville Family Medical Clinic, which has 11 exam rooms, six part-time faculty physicians, six resident physicians, three visiting consultants and 13 full- and part-time office staff, and provides about 11,000 patient visits per year. After a four-month university bid process and two months of negotiation with the vendor, the contract was signed. [For information about this and other EMR software and about how to select an EMR system for your practice, see “Electronic Medical Records: The FPM Vendor Survey,” January 2001, page 45, and the AAFP Web resource “How to Select a Computer System for a Family Physician’s Office,”www.aafp.org/x3700.xml.]

The implementation team

One of the keys to a successful EMR implementation is creating a project team to manage the process. Our team included a designated project manager and representatives from the information services department at UWDFM and the practice’s clinical and office staff. Since the project manager needs substantial protected time for the job, we hired a project manager at half time to track and coordinate the pre-implementation issues, decisions and tasks. The technical members of our team included UWDFM’s chief of information services, an applications support specialist and an applications trainer. The staff members of our team included the clinic office manager, a “physician champion” (a practicing physician with a strong desire for project success) and a second physician experienced in EMR implementation.

Early in the planning process, members of the project team visited two practices that had recently implemented the software we’d be using. Leaders and high-level users at the sites talked about their experience, shared documents and answered questions. The team also discussed the implementation process with the vendor’s staff. These discussions gave us a good starting point for developing our own implementation plan. Before we began using the EMR in daily operations (“went live”) six months later, the project team met weekly and used e-mail to develop and refine the implementation plan, discuss issues and update progress.

The implementation plan

The plan the team developed involved several simultaneous implementation tasks, including work-flow analysis and redesign, facility modification, hardware installation, software configuration, developing a backup system, entering old data, dealing with paper and training. Another key to a successful EMR implementation is having a clear definition of what you want the EMR to accomplish and making decisions throughout the process that support that goal. With our goal of becoming paperless in mind and with the general philosophy of “plan for the worst, hope for the best,” here’s how we handled each of the implementation tasks:

Work-flow analysis and redesign. One of our most important jobs was to analyze every function of every job to understand how tasks were accomplished with the old system. The project team spent considerable time analyzing existing work processes, looking for opportunities for improved efficiency, designing new work flows that could be accomplished with the tools available in the EMR and developing a transition plan. At monthly meetings during the implementation process, office and medical staff discussed and made plans for necessary changes in work flow that would make the best use of the EMR system. For example, we decided to replace paper phone messages with electronic ones, and we incorporated resident supervision documentation (a task formerly done on paper) into the electronic progress note.

Facility modification. To avoid the expense of major renovations, most practices will have to fit the EMR system into the existing space and floor plans, as we did. With our work-flow redesign complete, we had a good understanding of what the patient and staff flow would be with the EMR system functioning in our existing space. This was essential for planning where to put the new EMR equipment. To fully retire the paper records, we had to have computers in every location in the office where staff would need to look up or enter data into the record, and we had to have printers everywhere staff members would be handing printed materials to patients. Once we decided where to put all the hardware, we installed additional electrical and network wiring where necessary. In each exam room, we installed a workstation with a pull-out tray for the keyboard, a pull-out writing surface and a desk drawer for forms. The exam-room workstations were designed with the following goals in mind:

• Create a triangle between physician, monitor and patient to facilitate eye contact and allow the physician to sit close enough to touch the patient.

• Assure ergonomically appropriate keyboard height, mouse position and monitor-viewing height.

• Avoid the clutter caused by racks of paper forms on the walls.

• Have a readily available writing surface.

Hardware selection and installation. The choice of hardware for the network and servers is mainly driven by the vendor’s requirements and recommendations. Considering how fast this kind of hardware changes, we made sure we had the vendor’s latest recommendations before purchasing anything. There is considerable debate among EMR users about one hardware choice: whether to use hardwired desktop computers or mobile notebook or tablet devices at the workstations. We chose hardwired desktop computers to avoid the problems associated with notebooks – increased cost, more difficulty repairing or swapping components, limited battery life, potential for damage due to dropping or fluid spills and the additional layer of technology needed for wireless connections.

With our hardware selections made, we set up a small, off-site test installation of the server, workstation, printer and scanner. Since the technical members of our project team were UWDFM’s information services staff, it was easier for them to work on the test installation at their office initially. Once the software was installed, we were able to do a large amount of testing and configuration on the test system before it was moved to the practice site two months before going live. At about the same time we moved the test system, we installed fully equipped workstations in all areas except exam rooms. This allowed office staff with less computer experience to become more familiar with the operating system and the e-mail and word-processing programs. About two weeks before going live, we installed the exam-room workstations.

Software configuration. Good EMR software can be adapted to your practice environment without expensive custom programming. However, the more built-in flexibility, the more work necessary to configure the software to meet your needs before you can start using it. Each vendor’s software will have its own configuration requirements, but the following considerations are common to all EMR products:

• Security. EMR software should have the ability to limit access to various portions of the record to particular users. In our practice, each user was only allowed access to the areas of the chart and functions within that area that were required for his or her job duties. Our goal was to restrict access to all but a few high-level users for functions that posed obvious risks for intentional or accidental compromise of the integrity of the chart, such as the ability to delete progress notes.

• Laboratory data management. We wanted all laboratory test results to be available as soon as we started using the EMR. This required either an electronic interface with each lab or a manual method of data entry. Though we are presently working on an electronic interface with only our main lab, we do have a manual method of data entry that allows us to enter lab results from other labs. While this makes all test results available to us now, using a manual method of data entry does pose some problems. For example, after going live, we found that the normal ranges we’d hand-entered from lab manuals weren’t always the most up-to-date, so we had to call each lab to get the correct age- and gender-specific normal ranges and correct them in our system – a problem we wouldn’t have with an electronic interface.

• Templates. A template is a set of structured text elements that prompt the user to add pieces of data to document the medical encounter. Some EMRs require templates for data entry, while others, such as the one we chose, are more flexible, allowing data entry by template, direct entry (typing), dictation/transcription or voice recognition. Developing templates (and even modifying existing templates) requires considerable time and effort. For this reason and because our clinicians were dictating the majority of their progress notes at the time, we chose to initially allow continued dictation with the transcriptionist typing directly into the application. We waited to encourage template development until providers became familiar with the software. Average users began to ask about using templates after three months. We saw a noticeable decrease in the use of transcription after six months that has continued as template use increases.

Developing a backup system. Though this may seem like an easy task, what should work and what does work are not always the same – something we learned a bit too late. We thought we had a good database and application backup system in place but, after going live, still managed to lose a day-and-a-half’s data due to unanticipated technical problems and human error. The key is to have multiple methods of backup and recovery and test them before you go live.

Entering old data. The amount of old data to load into the EMR before going live depends on available time and money, and the needs and desires of the clinicians. Options range from no preloaded data to extensive abstraction and data entry. We purchased an interface that loaded all of the demographic data from our billing system to our EMR and updates any changes every five minutes. We loaded the last three months’ worth of progress notes shortly before going live. Since our transcriptionist had always been typing our progress notes into a word-processing program, all she had to do with the last three months’ worth of notes was to start saving the files in such a way that they could be loaded into the EMR. After we went live, all data was entered electronically. Since completing the past medical, social and family history sections of the EMR was time-consuming at first, we started scheduling comprehensive examinations that were 15 minutes longer. We eliminated the extra time about 18 months later. We stopped pulling charts for telephone messages after six months and for most office visits after 18 months.

Dealing with paper. Many EMRs are not designed to completely replace the paper record, so if “going paperless” is your goal, you must be sure the software has all the tools required to accomplish it. The most important requirement for going paperless is to have a method of scanning outside documents as text or images and filing them in the EMR. Dealing with the massive amount of patient-related paper that comes into our office daily has been one of our biggest challenges. Every patient-related document has to be reviewed and filed, scanned or destroyed. As one of our implementation tasks, we had to analyze the various categories of test results, hospital paperwork and other information that flowed into our office each day and decide how to manage them. We decided to scan selected important documents, such as Pap smears and radiology reports, and file the rest. Once the documents are scanned, we keep them for at least a week to ensure reliable computer backup, and then they are destroyed. Some documents that do not add useful information to the record, such as the fourth chest X-ray report for a hospitalized critically ill patient, are simply destroyed. To decrease the demand for scanning, we are working on an electronic interface for transferring documents.

Training. Our training involved three phases – initial basic skills assessment, basic skills training and application-specific training – which were done three months, two months and one week, respectively, before going live. A vendor representative and our own trainer conducted the training sessions. A summary document outlining key work-flow changes was distributed during the application training so that anyone who was unsure how to do a task with the new system had a quick reference.

Going live

In November 2000, seven months after the implementation process began, we went live on a Tuesday, as Mondays are particularly busy. (See “A timeline of EMR implementation” for a breakdown of the entire implementation schedule.) The vendor’s trainer, UWDFM trainer, project manager, entire office staff and physicians seeing patients that morning (including one project team physician) arrived 90 minutes early to physically “walk through” a simulated patient visit from beginning to end, allowing questions to be asked and minor problems to be identified and corrected. To allow some extra time in the schedule to adapt to the new system, we added the 15 minutes to comprehensive examinations and avoided double-booking visits (i.e., filling the schedule with appointments and also seeing same-day patients with urgent needs) by leaving some open slots in the day for urgent-care visits. Signs were posted around the clinic advising patients that we were starting to use the new computer system.

By the time we went live, the staff members who had to change how they did their jobs were prepared to do so and had previously given input as to how we might solve problems that arose. This was one of the keys to our successful implementation. (See “Keys to success” for a list of others.)

The outcome

The vendor’s trainer stayed on site the day we went live and then moved on to his next installation. The project manager, UWDFM trainer or physician champion were on site during patient care hours for the following two weeks to answer questions and deal with problems. Within a few days, we discovered and corrected the majority of security access conflicts (situations in which users were unable to view or enter information in the EMR that their job required). After approximately three months, the physician champion noticed significantly fewer questions about the details of day-to-day application use. After four months, he noticed more questions about application features that were not in daily use and an interest in using the application for additional tasks still performed on paper. After six months, many providers still went home about an hour later than usual because of the additional data entry required for the EMR system. However, after 12 months, most of them were back to leaving the office at their normal times.

Currently, support for users is provided with a three-tiered approach. On-site support is available from “power users” that received additional training for problem solving. If they are unavailable or cannot solve the problem, a UWDFM information services staff member is called for support by phone. If that person is unable to solve the problem, the vendor technical support staff is contacted. This has allowed the majority of technical problems to be solved locally. As the local support staff has become more familiar with common problems, calls to the UWDFM information services staff and the vendor technical support staff have substantially decreased.

In the first few months after implementation, occasional meetings were called to address specific issues that arose. Otherwise, the clinicians have continued to meet monthly to discuss EMR problems and issues. And in a separate monthly meeting, the office staff and clinicians have discussed EMR issues along with general operational ones.

The power of an EMR

Implementing an EMR system in a clinical practice is a daunting task. It requires good planning, strong physician leadership and supportive staff. The most immediate benefits of our EMR system have been accurate medication lists, legible notes and prescriptions, immediately available charts, decreased chart pulls and lower transcription costs. We are still just beginning to scratch the surface of what’s possible, but we would never go back to paper again.