Skip to content Skip to navigation

Gearing Up for Meaningful Use? It Takes More than Software

May 23, 2012
by Tom Waddell
| Reprints
Learn how a major healthcare network harnessed project management to successfully convert its EHR system—and the people who used it

A hospital-based outpatient network needed to significantly update its EHR system—and fast. Government incentives beckoned early adopters of EHRs that met meaningful-use requirements. The payout? About $45,000 per eligible provider who saw patients on Medicare, and $65,000 per doctor who accepted Medicaid patients. With more than 160 physicians across the outpatient network, that added up to a sizeable sum. With the clock ticking, the hospital’s administration set a firm six-month deadline to complete the electronic health record (EHR) revision.

The network, based in New England, includes 30 outpatient practices providing 300,000 office visits per year. Each office had its own internal, unique workflows, such as for setting appointments, for retrieving patient records, and for approving prescription renewals. As a requirement of the EHR upgrade, everyone would have to operate more or less the same way. Not an easy task or an easy sell. Success would depend not just on honing their EHR system to meet the needs of all 30 practices, but on winning the cooperation of more than 400 less-than-eager physicians, nurses, and other end-users.
To minimize risk, especially given the tight timeframe, the administration took a rigorous project management approach. The first two steps were analytical:
Only by fully understanding how each office operated individually could the project team configure an effective and uniform EHR system. That meant interviewing key stakeholders across all 30 clinical practices, from receptionists to nurses to physicians to billing staff, as well as IT, legal, and other essential players. What was the workflow from appointment through reimbursement? How did it differ from office to office?  How did the staff use their current EHR systems?
Some examples:
  • 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.”


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:


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.