I wrote last week about preparations for a go-live I’m supporting. My client is a hospital that has had a stalled implementation of their inpatient EHR and decided to address it by completely re-implementing the systems rather than trying to tackle adoption system by system or provider by provider. Our official go-live started at midnight, although one could argue that we’ve had a soft live that’s been going on for several years.
Monday morning can be very busy at hospitals for a variety of reasons. Often major surgeries are scheduled on Mondays so that patients can recuperate and be discharged either to home or to another facility before the end of the traditional work week. There are many more providers on the floors than the weekends, as physicians resume covering patients that may have been covered by an on-call partner over the weekend. Additionally, patients may be coming in for tests that might not be performed on the weekends or were postponed because they weren’t urgent.
Many of the hospital’s component systems were already in full use prior to this project and that definitely helped things run smoothly. Knowing that your laboratory, radiology, communications, scheduling, bed management, pharmacy, and other systems would be under control definitely reduced the stress level for providers.
In walking through the nursing stations during peak rounding hours, the most stressed group of individuals were the unit secretaries and unit clerks. Many were concerned that providers would be hostile to them as they tried to redirect the providers to enter their orders using the CPOE module rather than accepting paper orders for transcription as they had in the past. Although we had a few providers who “forgot” that it was go-live day (not sure how they could have forgotten it given the hordes of support staff in bright green shirts everywhere one looked), those few were easily redirected to the computer for 1:1 assistance. Having enough hardware available for everyone to do their work was a critical piece of our strategy, and in looking at this morning’s statistics, we only had a couple of situations where people were waiting for a computer.
Speaking of statistics, we’re aggressively monitoring the provider roster and tracking who has logged in and what they’re doing on the system. We already have a list of physicians who were strong users prior to the reimplementation and I’m not very worried about them. However, as we see new physicians access the system, round on a number of patients, and use the various modules, we move them to a “live” tracking category.
As we prepared for this, we investigated the processes that the larger medical groups use to round on their patients – whether each partner sees his or her own patients or whether they rotate by day, week, etc. We know what those schedules look like and have a hit list of providers that we will need to be targeting over the next several weeks. With that kind of data, we can adjust schedules accordingly, reaching out to providers before their next rotation on the floors to make sure we have support staff ready to meet them as they start their days. Although conventional go-live wisdom assumes that the need for support will taper over time, their first day may be several weeks out and they will still need significant support.
In addition to dedicated support team members (a mix of IT staff, clinical super users working dedicated support shifts, and contractors) we’ve also identified clinical super users who are working their normal shifts and are prepared to field questions and assist providers. I often get questions on the best way to recruit and retain super users. This hospital took my advice that they should select nurses who have been proficient users for a long time and give them extra training on the physician workflow and how to best train and support physicians. The paid training sessions that they attended counted towards their average weekly schedule requirements, so they weren’t being asked to attend training on top of their already heavy shift schedules.
Additionally, they had to demonstrate a certain level of proficiency before they received the official title. I did lobby for additional hourly payments or cash bonuses for nurses working in the super user capacity during their normal shifts at go-live, but this didn’t happen due to contractual and tax issues. Instead, we’re doing our best to reward them with gift cards and other bonuses to make sure they know we appreciate their work.
The administration also took my advice to have leadership actively participating on the floors, even if they couldn’t field questions themselves. The CMO, VP of nursing, and CIO are spending a good chunk of time this week being out with the users and assisting in whatever way they can, even if it’s just dialing the desktop support team to ask for password resets.
Speaking of password resets, we did take the hard line of resetting the password of everyone who didn’t attend training. We did this immediately prior to our midnight go-live so that if they did try to use the system, they’d have to call in first and we’d be able to dispatch a support person to their location. We can also dispatch an administrator to them, ready to help manage any unpleasantness or reluctance to accept support. We knew we only had a handful of people in this situation, but they’ve been difficult in the past so we wanted to be prepared. So far, three of them have logged in and received on-the-job training without incident.
The physician super users we had previously identified were also out with their peers, delivering pre-scheduled 1:1 support for those physicians who were most concerned about the go-live. As expected, we saw that once those physicians were able to complete documentation on several patients in a safe and supported environment, their concerns were markedly reduced. Just talking to a few of the physicians involved, it seems that simply knowing that we have physician super users that are part of the informatics team and will be looking out for physician interests going forward has been a powerful factor in bringing reluctant physicians on board.
As I suspected, even though the system has been live for a while, having a greater number of users engaged has identified some defects and some concerns with some of the order sets. Physicians who hadn’t previously participated in the creation of the defaults are now concerned with their content, so we’re documenting those concerns and will invite those physicians to participate on the committees that approve content. What we’re not going to do though is create individual order sets for the physicians who are complaining. If there is a clear and compelling reason to add a particular order, it can be added to an existing set as optional. Leadership is on board with this and having solid decision making and change control will serve them best in the long run.
As far as the defects, we’re classifying them as technical, operational/workflow, or application and are involving the appropriate groups for expedited resolution. We did engage our vendor to have a couple of application specialists available (two on site and two remote) should we need them.
One of the other things we’re doing today is starting our post-mortem review of the go-live and our entire process. Even in the excitement and activity of a go-live, it’s important to start gathering that information and determining what worked and what didn’t work so that you have a jump start on the next project. One of the things that worked well here was including the business case for many features as we trained them. For example, requiring a diagnosis on every medication, not just an indication on PRN medications. Although this should be fairly straightforward, we explained exactly what the hospital was doing with that data – formulary management, pricing negotiation, patient risk stratification, and more.
We also did a lot of education around the use of discrete data and its impact on monitoring clinical quality and potentially on research projects. The majority of physicians had no idea how the data was being used beyond “because you have to” and that helped transform what might have been perceived as extra clicks into something of value. We also opened the door for physicians to receive more data about their patients and the work they were doing, including access to ad-hoc reporting on patients they are seeing in the hospital. Due to some previous physician engagement surveys conducted by the hospital, we suspected this would be a good approach.
We also did some specific pre-work to look at how providers wanted to be trained and where they wanted to be trained. We did perform some 1:1 offsite training for providers and I think that was a good way to achieve buy-in and participation. Although we weren’t resourced to do this for every provider, we did do it for those that specifically asked. During the design phase of the rollout, we also held listening sessions with providers who were concerned about the process. Many of them were under the assumption that this would create more work for them. We were able to present the actual workflows at those sessions, demonstrating that although the work would be different, it wouldn’t necessarily be more. They were able to see in person what we were planning and we believe this reduced resistance.
Although today has gone smoothly, we know this is a process and the needs will continue for the next several weeks until all of the active physician staff members have been to the hospital at least a couple of times. I anticipate some blips but think our preparations have been solid and we’ll be able to get through them.
Don’t you love it when a plan comes together? Email me.
Email Dr. Jayne.