EHR Migration - Eighteen Months Later

It's been eighteen months since my organization migrated from one EHR to another. The road has been bumpy, as would be expected. It's been hard for everyone, including the IT team, so I thought I'd write a bit about the migration process in hopes that other organizations might avoid some of these pain points.

Ten Thousand Decisions, Some Will Be Wrong

As the organization embarks on the migration effort, you'll have to make tens of thousands of decisions around how you want the system to work. When I say "you" I mean operational and clinical leaders, not IT. A phrase we borrowed from our EHR vendor (Epic, thank you), everything should be "operations-led, IT-enabled." This means that IT builds the system the way you specify.

You (operational, clinical owners) WILL make some wrong decisions. You may misunderstand a question, lack the insight into how the new system works, or you'll simply lose the thread. It doesn't matter how or why you make wrong decisions, you will and that's not really important. A good EHR vendor will not allow you to make really bad decisions without at least challenging you. Ultimately, you (your organization) is responsible for your business, so the EHR vendor won't stop you from making these decisions, but they should alert you when you're veering away from best practice or standard configuration. Ours did and we still made some bad decisions. You will too. When you understand and accept that is normal, you can focus on identifying the fix more quickly.

Once the system goes live, you'll begin to see the impact of your decisions. Some may be glaring errors, some may be more of a slow leak. Regardless, the key is to identify how the system is working (current state), what it needs to do instead (future state), and what the impact is. Report all the issues (via IT ticketing system) and indicate relative priority. Most IT teams can work high priority items quickly while also working low priority items. For example, an analyst might be working on a high priority item but to take a mental break, they might work for an hour or two just fixing spelling errors or correcting the order of a list of elements. Things can move in parallel.

Be patient. It took nine or twelve or eighteen months to build it, it will not all get fixed in the first 90 days. Critical items certainly should be resolved in a timely manner, but the complexity and dependencies mean that re-work must be as methodical as the original build. Ideally, if you made the bad decision, own it. Understand why it happened but more importantly, identify what needs to be done to fix it.

Ten Thousand Build Points, Mistakes Will Happen

The IT team will be taking lots of notes and working to build and configure the system as you specify. Like you, they'll make mistakes for the same reasons. Lack of expertise in the new system, misunderstanding the request or the result needed, fat-fingering an entry, forgetting that last step. Like you, they'll monitor the results after the system goes live and they'll work to identify issues regardless of whether they were bad decisions or bad build. It doesn't matter, it just needs to get fixed. Priorities should be driven by impact - by dollar, volume, or people impacted.

Be patient. Report issues clearly, specifically. Be available to answer questions and provide updated guidance, as needed. The first 30-60 days post go live are hectic and stressful for everyone. Remember, there are no enemies here; everyone made a best effort and things will need to be fixed. How you behave as a leader puts you into one of two camps - you're either part of the solution or part of the problem. Choose wisely.

Changing Electronic Systems is Easier than Changing Human Behavior

Moving from one electronic health record system to another is a massive change, but the change is less about the electronic system than it is about the human system.

People have become comfortable with the old system; they have learned workflows, patterns of screens (where buttons and lists are located), and the 'quirks' of the old system. Suddenly, we're beginners all over again. That includes users and IT analysts. Everyone has to start over and rebuild that expertise. It doesn't happen overnight.

We know that some people are fast learners, others are slower; some learn by watching, some by doing. It doesn't matter how your team learns, what matters is setting the expectation that proficiency in the new system must be attained. And then, as a leader, you have to provide support for each person to get their via their own unique path - but they must get there in order to move into a stable state on the new system.

Understand that change drives loss - loss of expertise, loss of comfort, loss of knowledge, loss of certainty. Address the fear and uncertainty by providing training and continuous conversations about change, competency, and future state. Map out how workflows and processes will change. Engage your team in these discussions, prepare them to be successful when the new system goes live and beyond.

Drive Expectations Around Increasing Competency

Provide training. Support your team. And set a clear expectation around gaining competency. Supporting your team is not about coddling nor is it about allowing old mindsets and behaviors to persist. It's about saying "yes, change can be scary, let's get there together." A recent user survey in our organization indicated people were pleased with the quality of the initial training but wanted more on-going training. Interestingly, that on-going training has been provided regularly but users aren't taking advantage of it. As a leader, you need to look at trends like that and determine how to best engage your teams in continuous learning and find ways to carve out time for required on-going training.

Numerous change management systems address these elements, but perhaps the most potent one with respect to driving the expectation around competency is the ADKAR change management model, which really focuses on gaining proficiency in a new system [more about that here.]. Identifying ways your team can continue to develop system proficiency will be time well-spent both before and after go live.

Drive Accountability Across All Teams

Once you go live, ensure organizational leaders are ALL holding their teams accountable for gaining proficiency and identifying potential issues. As a leader, you have to avoid finger-pointing, especially toward the 'system' or toward IT. Something might be broken, but please don't say "the system doesn't work," or "IT didn't build this right." Instead, be very specific, such as "this isn't working as expected. I was looking for X, but it seems to produce Y. Here's an example."

Every team is responsible for making appropriate build decisions; IT is responsible for building it correctly. Everyone will get something (or many somethings) wrong. Identify the problem and solution and move on. Blaming and blanket negative statements are counterproductive and drive a culture of divisiveness and defensiveness. Worse, those types of statements are simply not actionable. If you want it fixed, help create the solution with very specific feedback.

When things do go wrong (and they absolutely will), ask what each team's action plan is. Don't just look to IT to fix things; ask operational owners what they can do to improve the situation as well. Sometimes that means they have to go to a Plan B while the system changes are being analyzed. Sometimes that means they have to change their workflow and fix how they approach the work. In other words, not everything that is wrong is an IT problem. Focusing solely on IT as the source of solutions obscures the fact that many times, the system is working as designed, the design is good, but staff are not following the new workflows correctly. Assess clinical and operational and IT elements in your solutions.

Be Kind, Be Flexible, Keep Moving Forward

An EHR migration is one of the most difficult transitions a healthcare organization can go through. It takes strong, positive, collaborative leadership on all fronts. It takes people being willing to admit mistakes but more importantly, to focus on solutions. Sometimes it matters what caused the problem; sometimes it does not. When it matters, get to root cause fast and move on.

Remain flexible during your first few months. Have Plan A, B, and C ready to go. Work with your colleagues in a clear, transparent manner. Ask for help; ask for support; offer help; offer support. It's a tough challenge but one you can weather.

I'm happy to say that after 18 months, we've made it through the vast majority of these issues. We have moved from stabilization to optimization and even to innovation in some areas of the organization. Where we're now innovating are areas in which the clinical or operational leaders were fully engaged, enthusiastic, and committed to positive change. And to be fair, many of the areas that are thriving have leaders who have experience either with an EHR migration or this EHR system (or both). Other areas still need focused attention to get to a more stable state, but we're almost there.

If I had to do it over again, one thing I would really emphasize is defining, documenting, and monitoring EHR proficiency across the entire organization. Where that happened, we've had extraordinarily strong results. Where that didn't happen (for lots of different reasons), we initially had fear, resistance, and related challenges. We've addressed those areas and we're well on our road to a stable, robust environment.

The IT team has really not had a break since about ten months prior to go live - so for about two years (and yes, through the thick of the pandemic as well). They've been running at a very fast pace for a very long time. First to learn the system, then to build it according to clinical and operational requirements, then to test, revise, and test again. Then came go live and all the stresses of that post go live period; all the quick fixes and the slow rebuilds needed. They've been addressing the last of the challenging areas of the build.

I've been very fortunate to have an incredibly talented, committed IT team on this journey. I've also had colleagues across the organization step up and partner with IT in remarkable ways. And so, I'm very optimistic that at our twenty-four month post go live milestone (November 2023 and right after our second major system upgrade since go live), we'll find ourselves finally able to take a deep breath, reset our pace (a bit), and begin to contemplate fully leveraging this powerful system in new, innovative ways.

If you're embarking on an EHR migration and want to chat, reach out to me. I'm happy to share my experiences and lessons learned! Best of luck.