This is part two of a two-part interview. Click here to read part one.
Oklahoma Heart Hospital is a fully digital cardiovascular center, where David Miles is the chief information officer. Recently, Miles oversaw a huge project for each hospital: the transition of Cerner’s 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 fully digital hospital, its design, tools and results. Today in part two we focus exclusively on the EHR switchover. Miles gives his colleagues tips on the big transition, how to deal with staff resistance to change and how to work with a consultancy to get the job done right.
Ask. You recently led Oklahoma Heart Hospital through a complex transition from Cerner EHR to Epic. What are some tips from that project that you would like to give to your colleagues?
A. That’s a big question. There are a few things that I think everyone should keep in mind. The first thing I would say is spend as much time as you have before the project starts to build momentum. Things will have to be done differently.
Regardless of which EHR you come from, the automation within Epic and the workflows and the tools and the way Epic is designed is based on best practices from a lot of their customers. But I would say use that time to encourage change and build momentum to do things differently.
It’s normal for everyone, including your staff, to want to keep doing what they enjoy. We all like to stick to what we know and what we are good at, right? It’s just a natural feeling. So by setting the tone for change early in a positive way, making it okay to change, making people feel like we’re inviting it rather than fighting it, that will really help make the transition smooth. Smoother.
Have mercy on others and yourself. Someone who was great with the old system yesterday may not be great with the new one, and that’s okay. It’s fine. It’s even expected. So having grace for yourself and grace for others as they learn and get better is an important part too. But stick with it. Help each other.
Second, spend time before the project defining the roles within your organization and what responsibilities each of these roles fulfills. Role-based provisioning is not a new concept in the IT world. But it offers so many benefits in terms of security, and it really helps to mitigate threat actors and limit the ability to dig deeper into your systems.
If a threat actor gets behind your firewalls and into your system, role-based provisioning ensures that he or she cannot reach other parts of your system. By being proactive and ensuring your departments and job titles are consistent, you will help maintain that role-based access and give staff the benefit of the right security that suits their role.
So that was a real key for us. We started that a little late and it took us some time to get through that.
Another piece I would say when it comes to tips to help you move from one EHR to another, especially Epic, is that structured training isn’t all your staff needs to be effective within the new system.
Set a clear expectation that this is to become familiar with the look and feel of the new system. Specific job training is just as important, and those responsible for providing that type of training should be closely involved in understanding the design and construction of the system from the outset.
In my opinion, if this team really wants to be successful, they should probably be part of the Epic project two to three months before go-live and continue intensively for the first few months after go-live. Become familiar with the system and continue training in specific job-related matters. Make it very clear from the start that the training will be rigorous. The more training you do, the more success you will have when you go live.
My final tip would be to ensure the organization is adequately resourced with advanced insight at go-live and beyond. This means that the need for immediate, what we call ‘at-the-elbow’ educational support will be absolutely unavoidable.
Almost every physician who uses the system as part of his or her job will have this need after implementation. So by ensuring that both the project team members, who are generally from the vendor, and your own permanent staff, you have enough of these people who have a deeper understanding of the system they can roll out and that level of immediate, on-site training that may not be overarching, but just for a few issues or just for a sub-segment of your workforce.
Q. You encountered resistance from staff during the transition to the EHR. What strategies have you used to tackle this challenge?
A. The demand is very high and the rewards are even greater if you make it happen. People are generally resistant to change. I certainly am. I like what feels good and what I have confidence in. So from that perspective, I think that’s a given for everyone.
But when we experience these types of issues here at OHH, we rely on our working groups, our advisory boards, and our executive steering committee to deliver the message that we are 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 about hearing you. We understand you are having problems and we are listening. We hear you. We understand that you are having a hard time. Then we had to demonstrate that we were making changes that would help address these concerns and provide comfort.
Those were some of the strategies we used. We were certainly open to the idea that when we made decisions during the project, they might not be the right ones.
We were learning too. We wanted to make sure we addressed the patient-centeredness that was part of our founders’ physician group. We want to design the system with the patient in mind. But again, we had to be honest: “Hey, we may not have made the right decisions ahead of time.” But by being sincere and listening, being honest in our research and implementing the changes, testing the changes, training the staff and ultimately implementing them in our production environment, I think it will take the pain out of the nervousness that accompanied the change.
It’s a process and we wanted to make sure everyone was invested in it.
Q. You worked with consulting firm CereCore during the transition, focusing on addressing interface complexity. Explain your work with the company and the outcome.
A. When we sat down after signing our contract to move to Epic, and well before the project started, we listed all the systems we had connected to our previous EHR. We found that we had about 35 different systems connected together. And when we looked a little deeper, we discovered that we had about 125 unique interfaces that automatically exchanged information and data.
We employ one full-time interface engineer here. We realized very quickly that we wouldn’t be able to meet our timelines without some help. So what we did is we went out and interviewed different companies. We looked at CereCore, and what they brought to the table for us was that they did most of the engineering work on those interfaces.
They brought some expertise to our open engine, Rhapsody, as well as to our Epic interfaces, which run through an engine called Bridges, which belongs to Epic. We really felt like their skills helped us raise the bar for our documentation and notations in our interfaces. In the past, we really hadn’t really noticed what the interface was designed for and what its construction was.
The CereCore staff really helped us make that much more robust. And for that we are very grateful. Some other things we did with CereCore – we really had to make sure that other engineers in the future could pick up the work and understand what it did.
CereCore helped us simplify some of our interfaces, which was very helpful. I’m a big fan of simplicity. Simplicity usually equals reliability in the IT world. And finally, CereCore took care of some project management around the interfaces.
Overall, we were very pleased with the people we got from CereCore, as well as the leadership and oversight their project leaders brought. We couldn’t have been happier with the choice we ultimately made.
Click here to watch the video of this interview, which includes a bonus not included 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