There are thousands of things to consider before, during, and after your EHR go-live. Preparing super users, application teams, and end users requires initial and ongoing planning and support. Creating a strategy for your upcoming go-live can improve team preparedness, boost morale, help predict problems before they happen, and have your team crushing tickets on day one.
To discuss the topic, Nordic Vice President of Business Line Development Matt Schaefer sat down with Implementation Strategy Director Lindsey Manzuk and Director of Managed Services Ian Mamminga to share some tips and tricks (including which shoes to pull from your closet) learned while participating in over 60 Epic go-lives. You can play the episode below, or download the episode here. Also, the full transcript is below.
If you’re interested in learning more after you’ve listened, visit our Implementation page for more information.
Show Notes
[00:52] Introduction
[01:50] Preparing for the month before go-live
[03:03] Defining personalization labs
[05:40] Understanding super users
[07:04] Making super users super
[10:18] Discussing broader organizational involvement
[15:28] Prioritizing the top 10 at 10
[17:20] Predicting problems
[18:16] Getting your application team ready
[20:04] Go-live ticket volume
[21:56] Learning to support your end users
[29:03] Post-live considerations
Transcript
Matt: Welcome everyone to this episode. We're here today to talk a little bit about go-lives. My name is Matt Schaefer. I'm the Vice President of Business Line Development here at Nordic. Welcome, Ian and Lindsey to the room. Between us we've got experience with what, probably 60 go-lives. We really want to help educate our audience today on how to visualize the time leading up to go-live, how to make sure that your go-live's going to be really successful, there are a lot of things to think about. It's the culmination of a year or two years, maybe even more, of work. It's a major event for your organization, and if you've never done it before, sometimes it can be really daunting. We want to help paint that picture for you and help you understand some of the ins and outs, some of the experiences that we've had, so hopefully you can learn from them.
Let's start with Lindsey. Tell us a little bit about your experience, and then walk us through the month before a go-live. What does that feel like?
Lindsey: Yeah, so I have led a lot of implementations at Epic, gone through a lot of go-lives. The month beforehand, very much a whirlwind. You have a lot of things happening, you're finishing up your training, your physicians are doing their personalization labs, you're finishing your technical dress rehearsal which is where you test all of your devices, you're doing an end user dress rehearsal, which is where your end users are actually going in and kind of practicing their workloads in the system before a go-live, and then you're also working on all of your go-live logistics, so setting up your command center, organizing all of your support, and then finalizing and starting your assets for all of your users before the big day. The month before is interesting because you have all of these things happening, and then about 1 or 2 weeks before go-live, there's this calm where you've gotten through most of the things you need to do. Some things you've accepted and just aren't going to get done until after go-live, and everyone is sort of mentally and emotionally preparing for cut over in the big day.
Matt: Can you expand a little bit on what's a personalization lab, why is that important, what does that mean for your physicians, what kind of time commitment, and what does that look like?
Lindsey: Personalization labs are where physicians come in after their training, and they sort of set up the system to really make it efficient for them day one. They'll go in and they can set up their schedules, they can set their order set preferences, and then really when they're actually live, they're not sitting with a patient doing that in the room. They can be more efficient. It also gets them some extra practice in the system. Again, getting them ready to be speedy on the first day when they start using the system.
As far as commitment, typically there's a trainer or two trainers that will help oversee them and then physicians come in for two hours or some, if they really want to do a lot of customization maybe four or six hours. They actually get access into production during that time, so it's important that you have a space available and they're able to sit down and take that time away from their day to actually go meet with the trainers.
Matt: Great, thanks. Ian, why don't you give us a little bit about your experience and then walk us through some of the meeting structure during go-live, what does clinical operation involvement look like?
Ian: Hello everybody, this is Ian Mamminga here at Nordic. I've got 16 years of healthcare IT experience, most of that in the acute care world, but I did spend a couple years also in the behavioral health care market as well. In terms of at the go-live operational structures and the meetings, it is very important to continue some of the involvement with your clinicians, so a super user program is very important to a successful go-live. That starts before the go-live, but continues throughout the go-live event and then on down as well. Involving the super users is important not only in daily meetings immediately after the go-live but in ongoing operational meetings to see what are the top issues that are being seen, what are the themes to that end, it's also I think important to have your own IT teams meeting regularly with the super users and the end users doing some rounding and actually getting out to the floor is very important, while everything should be in the ticketing system it's always important to kind of keep that pulse and do some hands-on approach.
Matt: Let's talk a little bit more about that super user program. I think this is a good opportunity to educate our listeners on what is a super user and how do you create a good super user program? Then, let's get back into that clinical and operational buy-in and how you have the rest of your organization as a whole engaged during that go-live. One thing that I'd like to point out is that it's really important to, at least in your first couple days after a go-live, ensure that your super users are able to fully dedicate themselves to supporting the rest of the users, so they need to not have a typical load of whatever it is that they would do during the day. If they're nurses, they do not have actual patients that they're scheduled to work with, at least for that first week or two, and then they can transition back into patient care. That is very similar for the revenue cycle, though you probably need a lower ratio, so one to six or one to eight rev cycle from an operational perspective where from a nursing, from a clinical perspective, you're probably more like one to four from a super user perspective.
That is a major financial commitment from the institution. The other thing that I've seen folks fall down on time and time again is actually spending the time upfront to make sure that your super users are super. You'll probably hear that from the teams that you're working with, if you're working with any consulting companies, that sort of thing, you'll hear that. You've got to make your super users super. Why don't we open it up here, what is that? What does that mean to you both? In your experience, how do you make your super users really super?
Ian: I think one of the ways to make your super users super is involvement early in the process, so make sure that they're very involved in the training curriculum and are also people that have input on the system, the designs, and also know the workflows, the clinical workloads are important. As you were mentioning, Matt, typically super users have a different job and typically they're clinicians. We've seen that work very well, but as you were mentioning it is important to separate the clinical roles from the super user, and really allocate time for that, where I've seen problems in the past is where that hasn't been at the time allocated appropriately, and trying to juggle both jobs. Especially after a go-live, that's a very tough thing to do. Separating those out I think allows your super users to really be super.
Lindsey: Ian, you mentioned having them involved in training. I think the more you can have them actually support end user training, they'll understand some of the common questions that they might find while they're supporting on the floor. Then also just making sure that they understand the logistics around go-live, so where do they report in the morning, where are they covering, how do they call in an issue, is it their responsibility to call them in as the end users, what communication will they get around things they need to communicate back to end users? Just those things that you can communicate early and before go-live to make sure day one they can get in there and really focus on supporting those end users.
Ian: I have a little story that I think supports that. One of the go-lives that I did, there was an OB nurse that brought down all of her staff a little bit at a time into the training room. They went together, they walked over, it was a little bit of a bonding experience, and they went through training as a group. Then they went back and they took the next group. She was so involved in the training and making sure that everyone knew where they needed to be at go-live. That's typically a high-acuity area from a support perspective for go-live. They went off without a hitch. We didn't hear from them during a go-live because everyone felt really comfortable. They had taken, that operational group had taken such clear ownership over their area that they didn't need the same acuity of floor support during go-live because they had already experienced that with their super user. Then on the other side, groups where sorry, we just don't have the time to dedicate to this, we don't have the organizational capability to really organize this department, you know those are going to be the areas that are tougher.
There's always going to be those areas within organizations, and I would not recommend trying to fix those as part of your go-live. At least know that they're going to need more floor support, they're going to need more attention. Just budget for that accordingly. Make sure that you have someone from a leadership perspective that's checking in there. If you didn't engage them before, they're going to be engaged at go-live because that becomes their world.
Matt: Ian, thank you. Super users I think is critically important and we could probably talk about that all day and we'd be happy to. I think let's move onto some other topics so we can make sure we get through some more stuff. Let's talk about some of that, the broader organizational involvement. Paint the picture for what it feels like to them and how they're supposed to get involved during that go-live period.
Ian: Yeah, good question, Matt. There's a couple different thoughts around that. One, we have talked about the super users being a tie to the clinical community, but in addition to that communication is key to any go-live. Keeping two-way communication both in terms of end users and IT flowing is essential to a successful go-live. Part of that is regular communications, what I've seen as successful approaches around that are including daily meetings. You might hear of the top 10. The daily meetings where some of the top issues are discussed, and that's a place for everybody to come together both clinically, operational IT groups, to really review updates, status, and any new items. Communication I think is one key area. Then leadership involvement, too, this doesn't necessarily just start at the Go-live but people that have been involved all throughout the implementation in leading up to the Go-live, making sure your stakeholders are there, accessible, and on the meetings and status update.
Matt: Yeah, and I would just add one piece to that from a leadership perspective- your senior leadership at your organization is going to have lots of questions about what they're supposed to do at go-live or they won't have questions, they just won't know. It is important to educate them that they have a really critically important piece of the puzzle and that is visibility. They need to be visible, they need to be out on the floors, they need to be talking to people, they need to be having conversations, supporting the project. When they hear of things they need to bring things back and put them through the standard process, and they need to be reminding folks that using your typical operational work flows are the most important. The system is a tool to support that, but there are down times in their normal day. If someone doesn't know how to do a particular work flow, that's similar to a down time. They can always do that clinical care, that comes first.
The system is really a means to support that, so visibility is really important. I had a go-live where the whole senior leadership team created everyone as they entered the hospital for their first shift after they had gone live with balloon and things like that, just congratulations, we're live. It's going to be hard but we're here to support you. It was a great message. Then they, I think the CNO brought around ice cream, like an ice cream cart for people. The CIO served food to the command center. Little things like that that just say we are all pitching in I think are really important, really powerful messages that do not go unnoticed.
Lindsey: Yeah, just one quick thing I would add is if you're working a 24 hour go-live, don't forget your night shift. I think most people are there during the day, but there are people there overnight too, so if you can also show them some love they'd very much appreciate it.
Matt: Thinking about from a logistics perspective, all of the logistics that go around go-live, making sure that you have a go-live coordinator that coordinates all of those logistics that Lindsey, you talked about space and making sure that you have a command center and you have places to have meetings and personalization labs and things like that, but knowing that people are going to be in that command center 24 hours a day and things like making sure that the garbage gets taken out and that the work stations get cleaned up and things like that, that can become a gross place to work for that period of time. It becomes really sad if you're not deliberate about making sure that those things are planned. The other thing is food, coffee, water, things like that.
Those are important logistics that sometimes, if you haven't done a go-live before, at least talk to someone who has or bring in someone who's versed in coordinating those go-live events because once you've done a couple, you've seen those things and you know, we've got to make sure that we schedule someone to come in and take out the trash or we have somebody from the project team that we tap on the shoulder and say, hey, this is your job for 20 minutes at 2:00 a.m., this is really important. Those are things that can sometimes get missed and become bigger issues than they really need to be. Ian, you mentioned that top 10 at 10, I think that's a really powerful meaning where you ask operations to prioritize those issues and you walk through the status of each thing so that everyone is on the same page for what the project team and the greater IT community and the operations is doing to solve the top issues for the organization. That's really important. It also helps you celebrate the ones that are no longer on the list and make sure that they're really not so that everyone talks through those things.
Lindsey, I wonder, tell me a little bit about your experience with those meetings. Maybe even an example of an issue or two that you've seen hit the top 10. I think that would be really interesting to our listeners.
Lindsey: Yeah, I think one of the big things that comes with those top 10 at 10—for some reason they're always at 10:00 a.m. —meetings is perspective. You get your operational leadership together and maybe in your billing areas they need a small change to their work queue, and that's the most important thing to them, but then they also hear that device integration isn't working in the ORs and they kind of understand that there's a lot happening and the team really is trying to prioritize for the organization and maybe they're a little more patient with some of their issues. As far as common issues, there are two that always start Go-lives towards the top of the lists- security and printing. The more you can test those devices before Go-live, the smoother that'll go. Then also if you're able to do end user login labs or have your users login at the end of training, just to make sure they can access the system. That can help lessen those issues and then allow the teams to work on issues that more directly impact the user work flows.
Matt: I have a good friend who has done a lot of technical go-lives. What she'll tell me is she knows how prepared customers are before their go-live, and she'll either wear heels to go-live if they're real prepared, or she'll wear tennis shoes if they're not because she knows she's going to be walking around to all of the devices in the whole organization. I always think that's a very poignant story about that. I agree, and it's not a question of if it will be an issue, it's how much. The more you can do- the other problem with security is if you have major security issues it means you can't get to the rest of your issues until those are fixed, until people are actually getting to the system. The more you can do before hand is great, but also- and we talked about space before- having a dedicated place for people to just pop in and get their security fixed, have the security team there so they can go there in person and just say, hey, I'm so and so, either I need a password reset, I can't log in, or I just feel like I can't see the right thing, or I should see what Susie sees, but I see what Jim sees. I need to be Susie and not Jim.
That type of information will really help that security team move very quickly and be able to fix those issues so you can move onto the next type of issue that you're going to see. Ian, tell me a little bit about getting your application team ready. What does it feel like for the app team for that go-live period? What makes a good go-live from an application perspective?
Ian: The go-live itself, obviously we talked a little bit about security and printing, but all the applications it's going to be a very busy time. I think getting your application team ready, both from a cultured perspective, it is going to be a big change event for the organization, but also from a system perspective. There are things that you'll want to have covered ahead of time that you can carry forward into the go-live event and beyond, things like your change control policies and procedures, how are you going to move forward with an emergency change versus standard change? You'll want to have those ready and everybody on the application teams on the same page and practice that before the Go-live as well. In addition to that, there's plumbing and infrastructure things too that you'll want to make sure you've tested and taken care of ahead of the go-live. How are tickets going to be reported? We mentioned super users before.
A good protocol I've seen is end users can communicate to the super users who would then call something into the command center. At that point you also need the infrastructure. Every item needs to go into a ticketing tool set and be accounted for and people need to have the protocols and how we're going to update those tickets. That also lays the ground work for those meetings, the top 10 at 10, how can we decide one issue is now something much broader, so we can coordinate and see that with the data sets if everybody's using the same structures.
Matt: How many tickets do you expect during the period?
Ian: I think a good rule of thumb is about one ticket per day, per physician for the first week or so. Now, we talked about security and printing being very high volume the first week or two. In my experience, the issues can taper off pretty quickly. It is going to be, there's going to be a high volume of tickets the first week or two and then it will taper off. The unique part of that is those first few weeks, the volume might be higher but there is a higher percentage of easier items too- printing and security being a couple of those examples. Then really what remains later are going to be those common issues where maybe there's only one ticket in the system but it's affecting 20 or 30 people and it's much tougher to solve for. That leads out into weeks 3, 4, and beyond.
Matt: Yeah, absolutely. I like that one issue per physician per day, it kind of a good back of the napkin, it accounts for the rest of your users, but all you need is the physician number to know about how many issues you're going to have during those first couple days after that go-live instance. Yeah, I think that's very interesting.
What does your application team do, we've switched on the system, we've gone through our 150 minute by minute cut over steps, we've hit the big red button, if there was a big red button, and we communicated out to all your users you're live. You're live, it's time to go into Epic to do your workflows, to go through and start entering orders, start filling out your flow sheet rows. That happened. What does your project team, what is your application teams doing it, how do they get out ahead? How do they have the best experience during a go-live and really best support those users? That's all they want, right? They've been doing this for two years, they just want it to go smoothly. What's the best way to get that to happen?
Ian: A couple thoughts on that. One is around just the planning component. You definitely want to have a go-live plan and a staffing schedule. For the first period that's going to be a 24/7 model, so obviously that's just infrastructure components that everybody needs for a successful go-live. I think in that plan, baked in there somewhere you need to have your application teams also spending times on the floors and seeing their end users. Teams are very well-positioned and they've gotten to know these people over the course of the implementation. To continue to build those relationships is key, and also be a face and be seen out there. I've seen very successful things too, very simple tragedies, but having shirts or different ways to identify people, it's a comfort level for the end users. I think that's a great approach, and then having backups working through some of the tickets back in the command center or remotely is a great strategy to continue to work with your end users.
Lindsey: I would also say that the end users generally know how the system's supposed to be set up, but they don't know it as well as your project team. Unless you actually get your project team out there, seeing the same things that the end users are seeing, you might not get all of your issues called in. If an end user doesn't know something is an issue, they're not going to know to talk to someone about it, but your project team might go out and a physician will pull up a screen and it just looks wrong, and they'll be able to take that back and make sure that gets fixed.
Matt: Yeah, and those are both great points. From my experience with go-lives, that's really hard. There are so many issues coming in, your project team feels like they need to be all up in that command center, fixing issues. The other complicating factor is you've probably brought in some number of at the elbow support personnel from some organization and you try to train them as much as possible on your work flows and they're out there on the floor and they're the ones working with your end users. I've seen that cause significant issues during go-live, that it is hard to get them your work flows and they may have some experience with some other organization but they may not do it the way that you do it, or even worse- they may think it's supposed to work that way and say oh hey, absolutely the project team can fix that, when really you've made a conscious decision not to go in that direction.
That can cause some real anxiety between your end users and your project team. If you can figure out a way to at least allow your project team to get out onto the floor, work with the elbow support, do some oversight of that group, and be able to see exactly what those end users are seeing, you're going to have a better Go-live. Things are going to go better, that cycle of issue resolution is going to move faster. What that leaves is a vacuum of those issues that are coming in. If you're out on the floor, you're not cranking through issues in the system. One thing we've done here at Nordic, we've been able to assist some of our customers in just crushing through issues for people. We hook up a number of our senior consultants from a remote capacity and say, hey, we're just going to work through some large percentage of your issues so that that one issue per physician per day, that number, but we can work some of those down while still allowing the project to get out on the floor. That can be really powerful.
Anyway, that's one option I think in terms of doing that. Another option is just setting expectations with operations that there's going to be a period of time where we're not going to fix as many issues. We're going to get out there and we're going to observe, because that's important, because that should be a priority. There are definitely some ways around that, but definitely thinking about how do we get people out of the command center and into the areas that they've spent two years implementing?
Ian: One other thing I was going to add too around the application teams is just flexibility. No matter how much you plan the go-live event is a bit of an unknown. What can happen afterwards, everybody has to be flexible. May even necessitate people working in applications that that's not their primary responsibility. You may plan for this many tickets in the Willow space. Overnight, that may double. Something may happen. Being flexible and in building that into your application plan I think is of paramount importance, too.
Matt: Absolutely, yeah. In every go-live there's one application that you didn't know was going to be a problem. There's probably one or two that you knew were going to be a problem so you planned for them and then they were, but you had that plan, you had brought in some additional resources, or you had just told nobody that they could have vacation for the next couple months. You planned for it, but there's probably one that you thought was going really well, and for some reason there was a really key stakeholder that wasn't as engaged as they should've been or there was a work flow that we thought would work but didn't work for some reason. It is really important to have some type of pressure release valve, some way to be able to mitigate those issues.
Ian: Matt, I think you bring up a good point too on vacations too. I think that's something that can be overlooked, the tail end of the implementation usually you are sprinting up to the finish line and that's pretty trying time and it can take a lot of cycles. The go-live event is kind of a continuation of that and in many cases, people can't take vacation around the go-live event. Baking that into the plan that a couple months after go-live people need to take some time is very important and sometimes overlooked, in my experience.
Matt: Absolutely. Yeah, we actually used to say instead of sprinting to the finish line, we called it sprinting to the starting line because go-live is the start, it's the start of your new world. It's a sprint at the end, there's a lot to do even in that calm before the storm. It's all training and things like that. It's just not system built but it's still a sprint. Then you went live and it's a whole new marathon. You just ran there, you're already out of breath. Yeah. In most organizations that I've worked with have had some freeze, vacation freeze around go-live, but once that freeze is over your whole application team wants to go on vacation. There are definitely ways to plan for that or at least stagger that, or as we mentioned, some of our services, bringing in, keeping some of those remote resources that continue to work on tickets so that your team can breathe a little bit before they get back into the day to day. That can be really helpful.
Lindsey: I've also had organizations actually do vacation freezes on the operation side too, so if you think about your nurses and there's a vacation freeze, and then you might have a lot of folks that want to be off four weeks after go-live, so how can you work with your managers and leadership to plan for that and sort of have strategies so you're not struggling to staff for those weeks?
Matt: Yeah. I like that we've transitioned into more the post-live conversation. I think this is probably a good, we talked about pre-live, we talked about what go-live is like, what's a month after it look like? How does it change, how does the world change now that we're one month post-live? What issues should people expect? What happens now?
Lindsey: Everyone's tired. About a month post-live, you typically will shut down your command center, but you're still going to be getting tickets in. You'll always be getting tickets in. Really it's important that you are able to separate the keep the lights on break fix issues, what are the things that we need to do to make the system usable from the optimization or enhancements? What are the work flows that aren't working well that we can make some changes to make them work better, additional content that we could build out, your team will be balancing those two things and maybe you'll start even an add-on so an application that you didn't initially go-live with but you want to bring into your organization? I've seen organizations either have a single team and they just kind of work on both of those things, or really split up those areas but still working as a cohesive team because communication is important. You'll find that some folks really like to do the day to day support and that break-fix stuff, and then other folks really want to focus on the optimization sort of thing. Sometimes, there's a natural split that can happen.
Matt: I'd like to actually point out one more piece of one month post-live that's typically your month end for your revenues that come up somewhere in that region. As we kind of did here, sometimes your clinical application teams' total number of issues happens in that 1-2 weeks post-live, and then they may try to take a breath, but at that point your revenue cycle is going through their paces and they're getting their issues in at that point. You definitely should make sure that your clinical team is engaged in that. There are going to be many, many issues that are integrated between those two areas, and if your clinical team for some reason, application team and operations has checked out, then your charges for your physicians and your closing of your cases and that sort of thing will not go smoothly. You need to make sure that you have a plan to review that in that you have some both clinical and application team involvement around that month end, that first month end and then the second month end as well.
Those are 1-2 months post-live. It's really important to bake that into the plan so that you can make sure that the financial health of your institution can continue. We've all seen in the news some organizations that have struggled post-live with cash flow or that sort of thing. Part of the reason is some of the planning. Is planning pre-live, a lot of it is testing and that sort of thing, making sure that you've got all your right operational buy-in and everyone knows what to do, but a lot of it is making sure that you have a really good, solid operational hierarchy and work flow to fix issues quickly post-live.
Ian: One other thing I would say a month or two after go-live that I've seen come back around is items during the implementation that were differed or placed on hold. Usually a month or two after go-live those come back to the table, so it's also important to plan and have some bandwidth allocated for those, along with the new optimization requests that are coming through.
Lindsey: Another thing to think about is just how are you going to let your end users know what the team is working on? They're sending in these issues, they're sending in all these change requests, they're sending in these optimization requests, and then it can be really frustrating if it just goes into a black hole and no one's aware of what the project team is doing. Having some sort of regular communication process either through the leadership or through the super users so the end users are aware of what the project team is focused on and maybe what their request is in the queue.
Matt: The best customers that I've seen have included that conversation into their typical operational meetings that they had pre-live, and that they will continue to have post-live. They make Epic and their EHR just a part of every stating meeting where they talk about hey, these are the top five for us. These are the top couple things that we're working on right now, that the super users are working with the project team on to optimize and that sort of thing. That is an incredibly critical process, it just becomes part of the day. Don't try to force a bunch of new meetings on everyone and raise the number of uses of, or amount of time that folks need to spend, but if you can leverage some of the existing tools and then add that important communication, that's really important.
Now in our chronology of walking through the go-live period, we're 2-3 months post-live. We walked you through what does the pre go-live world look like, how do we get everyone involved during that go-live instant and then what do you do for those next couple months post-live? Now we're at the point where we're going to talk about long-term support maintenance of your system, how do you keep the system healthy over time? That's going to happen at another date. Thank you for listening in. We hoped you learned something about what go-lives look and feel like. If you'd like more information, feel free to reach out to Nordic and we'll talk to you about your upcoming go-live and some of our experiences and how we can help. Thanks!