This is part two of a two-part interview. Click here to read part one.
Oklahoma Heart Hospital is an all-digital cardiovascular center, whose chief information officer is David Miles. Recently, Miles oversaw a massive project for any hospital – switching over from its Cerner electronic health record to an Epic system. He and his team had their work cut out for them.
Yesterday in part one of this interview with Miles, we discussed the all-digital hospital, its setup, its tools and its outcomes. Today in part two, we focus exclusively on the EHR changeover. Miles offers tips to his peers on the big switch, how to deal with staff resistance to change, and working with a consulting firm to get the job done right.
Q. You recently led Oklahoma Heart Hospital through a complex transition from the Cerner EHR to Epic. What are some tips from that project you would offer your peers?
A. That’s a big question. There are a few things I would consider everyone should be aware of. The first thing I’d say is spend as much time as you have before the project begins building momentum. Things will have to be done differently.
No matter what EHR you’re coming from, the automation inside Epic and the workflows and the tools and the way that Epic is designed is based off best practices from many, many of their clients. But I would say use that time ahead to encourage change, build momentum toward doing things differently.
It’s natural for anyone, including your staff, to continue to want to do what’s comfortable. We all like to stick with what we know and what we’re good at, right? It’s just a natural feeling. So, setting the tone early for change in a positive way, making it okay to change, making people feel like we’re inviting that as opposed to fighting it, that really will help make the transition smooth. Smoother.
Have grace for others and yourself. Somebody who was really good yesterday on the old system may not be as good on the new one, and that’s okay. It’s perfectly fine. It’s expected, even. So having grace for yourself and grace for others as they learn and get better, that’s a key component, as well. But stick with it. Help one another.
Second, before the project, spend time defining the roles inside your organization and what responsibilities each of those roles carry out. Role-based provisioning is not a new concept in the IT world. But it offers so many security advantages, and it truly helps limit threat actors and the ability to burrow deeper inside your systems.
If a threat actor gets behind your firewalls and inside your system, that role-based provisioning will keep them from getting to other parts of your system. Being proactive and ensuring your departments and job titles are consistent will work to help preserve that role-based access and allows the staff to have the advantage of appropriate security, which fulfills their job roles.
So that was a real key for us. We got started a little late on that and it took us a bit of time to move through that.
Another piece I’d say as far as tips to help you move from one EHR to another, in particular, Epic, is know that structured training is not all that your staff needs to be effective inside the new system.
Set a clear expectation that this is to familiarize yourself with the look and feel of the new system. Specific job training is equally as important, and those responsible for delivering that type of training need to be heavily involved in understanding the design and build of the system from the early stages.
In my mind, this team, if they are to be truly successful, would probably be part of the Epic project two to three months before go-live and continue heavily through the first several months of post-go-live. Making sure you get familiar with the system and then continue that training into specific job-related stuff. Make that very clear from the very beginning that training will be rigorous. The more training you do, the more success you’ll have at go-live.
My last tip would be to ensure the organization has enough resources with advanced understanding at go-live and beyond. Meaning the need for immediate, what we call at-the-elbow education support, will definitely be inevitable.
Almost every clinician who uses the system as part of their role will have that need post-go-live. So making sure both the project team members who generally are from the vendor, as well as your own permanent staff, you have enough of these folks who have a deeper understanding of the system that they can roll out and provide that level of immediate, on-the-spot training that might not be overarching but just for an issue or two or just for a subsegment of your workforce.
Q. You experienced staff resistance during the EHR switch. What strategies did you use to address this challenge?
A. The demand is very great, and the rewards are even greater, if you can pull this off. Human beings in general are resistant to change. I certainly am. I love what feels comfortable and what I have confidence in. So, I think from that perspective, that’s just a given for everyone.
But when we experience those types of issues here at OHH, we rely on our workgroups, our advisory councils and our executive steering committee to help carry messages that we’re all in this together. It’s still new. We are all learning what works and what may not work as well as it used to.
We wanted to be very intentional that we hear you. We understand you have issues and we’re listening. We hear you. We understand you’re struggling. Then subsequently, we needed to show we were making changes that help address those concerns and that provide comfort.
Those were some of the strategies we used. We were definitely open to the idea that when we made decisions during the project, that they may not have been the correct ones.
We, too, were learning. We wanted to make sure we were addressing the patient focus that was part of our founding physician group. We want to design the system with the patient in mind. But again, we had to be honest that, “Hey, we may not have made the right decisions upfront.” But being genuine and listening, being honest in our investigations and building the changes, testing the changes, educating the staff, and ultimately implementing those in our production environment, I think helped ease the pain of the nervousness that came with the change.
It’s a process, and we wanted to make sure everybody was invested in it.
Q. You worked with consulting firm CereCore during the transition with a focus on addressing interface complexity. Please explain your work with the firm and the outcome.
A. When we sat down after we signed our contract to move to Epic, and long before the project started, we listed out all the systems we had connected to our previous EHR. We found we had about 35 different systems that connected. And then when we looked a little deeper, we found we had around 125 unique interfaces automatically exchanging information and data.
We have one full-time interface engineer on staff here. We realized very, very quickly we were not going to be able to meet our timelines without some help. So, what we did is we went out and interviewed several firms. We looked at CereCore, and what they brought to the table for us was they did most of the nuts-and-bolts engineering work on those interfaces.
They brought some expertise to our open engine, which is Rhapsody, as well as our Epic interfaces, which run through an engine called Bridges, which is Epic’s. We really felt like their skill helped us raise the bar on our documentation and notations in our interfaces. We really, in the past, hadn’t done a good job of noting what the interface was designed to do and what the construction of it was.
The staff we use from CereCore really helped us make that much more robust. And for that, we’re very grateful. Some other things we did with CereCore – we really needed to ensure that moving forward, other engineers could pick up the work, understand what it was doing.
CereCore helped us with simplifying some of our interfaces, which was very helpful. I’m a big fan of simplicity. Simplicity generally equals reliability in the IT world. And then lastly, CereCore provided some project management around the interfaces.
Overall, we were very pleased with the people who we got from CereCore, as well as the leadership and oversight their project leaders brought with them. We couldn’t have been happier about the choice we ultimately ended up making.
Click here to watch the video of this interview that contains bonus not found in this story.
Follow Bill’s HIT coverage on LinkedIn: Bill Siwicki
Email him: bsiwicki@himss.org
Healthcare IT News is a HIMSS Media publication
Source : Healthcare IT News