Gearing Up for Meaningful Use? It Takes More than Software

• Scheduling: Some offices required setting an appointment in advance. Once logged in, the appointment would trigger the EHR to update the physician’s calendar and, prior to the visit, “pull” the patient’s record. But other offices took mostly walk-ins. That necessitated an entirely different EHR protocol, to enable the doctor to retrieve a patient’s record on the spot and navigate a less orderly schedule.
• Renewing Prescriptions: Some nurses had retrospective authority to renew prescriptions. The nurse would write the scrip and the doctor would review it after the fact. Generally a big time saver, retrospective authority was most often granted to trusted, experienced nurses. Some nurses, usually those with less experience, had prospective authority. The physician had to approve each prescription before the nurse could call it into the pharmacy. From office to office, it was up to each physician, based on his or her judgment, to determine what type of authority each nurse would have. That would change. To standardize the procedure across the healthcare network, the new EHR system would set objective criteria for approval authority. Not a welcome change for most providers.
• Charting: Some physicians typed their notes into the system while meeting with the patient. Some dictated directly into the computer using voice recognition software. Still others dictated their notes and had their staff enter the information. It was a balancing act. Requiring absolute uniformity in how patient information was entered into the system was probably impossible, but that was the desired trajectory. The team had quite a task: configure the new EHR to handle a variety of ways staff would input patient records, yet ensure the system could deliver data that were able to be categorized and analyzed—that could be meaningfully used. The IT team took eight weeks to configure the EHR system, in collaboration with two RNs to make sure it would actually satisfy the needs of staff “in the trenches.”

WHAT WERE THE INHERENT RISKS OF THE PROJECT, AND HOW COULD THEY BE MITIGATED?

Identifying and addressing what could go wrong—in advance—would help keep disaster from striking. Through an exercise with stakeholders to flush out the flashpoints, the team discovered, much to their surprise, that no test system was in place for the upgraded EHR. The system was loaded with actual patient data that was set to go live when the time came without a practice run. Fraught with obvious risk, the IT group was tasked with creating a test application that could be tweaked and fiddled with, launched and relaunched behind the scenes until it was absolutely ready for prime time.

The team unearthed and tackled other risks, as well. But as with most complex projects that require change, many were related to the human factor:

HOW COULD THE TEAM GENERATE BUY-IN FROM EHR END-USERS?

Change is rarely welcome, especially when it adds to stress (at least initially) instead of alleviating it. Lack of staff acceptance was a risk stakeholders identified as one that could delay or even undermine the project. Knowing how and when to communicate to each audience is key to a successful EHR implementation. The project team went to work.

• Collaboration: Including stakeholders throughout the EHR’s development was an important element in defusing pushback. For example, at regular cross-functional meetings, the project manager elicited feedback from every attendee on the elements being built into the EHR system. Not only was this collaboration essential to developing an effective EHR, participants across the clinical spectrum knew and felt that their input was valuable—down to how many clicks it should take to access a lab test. This wasn’t just the administration’s EHR, it was theirs, too.
• Communication: No one likes surprises. The project team developed a communication program to inform all staff about the exact changes that were coming, when they were coming, and why. The campaign was timed to feed information regularly, often, and for the six months leading up to the launch. It was a reality people could not ignore, even if they wanted to. The timing also allowed the staff to react. If there were really a problem with some of the plans, the project team took note and could make adjustments.
• The Messenger:. While the message was important, so was the messenger. The team asked a physician to be the communicator for the physician audience. As one of their own, he was a trusted peer that could “speak their language” and successfully address their concerns.
• Training: Training was mandatory. For everyone. From doctors to desk clerks, people were told well in advance that they couldn’t take vacation or attend medical conferences during the final training period before the go-live date. It was that urgent.  Despite grumbling, physicians and staff completed all five classes in their training modules over a three-week period and were well equipped for launch.

• Deliberate Reduction in Productivity: The administration allowed offices to schedule only half the usual patient load during the first two weeks of the conversion, despite the financial impact. With a full roster of patients, the project team had noted convincingly, productivity would suffer anyway, no matter how well prepared the staff. This way, patients wouldn’t get frustrated while physicians got used to the new system.
• Minute-by-Minute Planning: The weekend before go-live, the project team went into overdrive. The project plan included an intense final two days of execution, to begin the moment after the staff went home on Friday. As much work that had gone into the first six months went into the final 48 hours. It was one giant exercise in risk management.  The team had built in decision points that enabled the project manager to put the kibosh on the go-live if necessary, should they miss a critical deadline that would delay implementation. The new system had to be up and running by Monday morning, or the old system would have to remain in place. Thirty-five people worked around the clock, some not sleeping for two days. An hour-by-hour, minute-by-minute schedule dictated who did what and when, maximizing efficiency and preventing lag time during handoffs, whether at two in the afternoon or at three in the morning.

• Command Center Triage: The project team established a temporary command center for the first two weeks following launch, manned by temporary receptionists. They would field questions by end-users and log tickets. The project team manager would continually monitor the tickets and assign them to individual analysts to resolve. That enabled the analysts to focus on their work instead of juggling incoming calls. And by filtering the tickets, the project manager could track the issues. If certain types of problems were trending up, the analysts could focus on them as a priority and stem the tide.