No matter what electronic health record system you are on, if you work in healthcare, you’ve likely experienced an “upgrade” at one time or another. And while these upgrades are not complex when compared to a new EHR implementation, organizations struggle to handle these system upgrades that include system fixes, workflow enhancements, and net-new functionality.

The four main reasons we see organizations struggle with successfully upgrading their system are:

1. Lack of emphasis/urgency – There’s a never a slow day in healthcare, and organizations can struggle to prioritize the upgrade with the daily volume of work. The easy approach is to push the long-term items (i.e. the upgrade) out as you focus on short-term items (i.e. tickets, current issues, etc). The right approach is to balance these two together.
2. Lack of communication – More to come on this below, but communication is possibly the easiest piece of the upgrade approach in theory, and the one organizations struggle with the most.
3. Key decision makers/end users are not involved – How can an organization expect to successfully implement new build, features, and workflows without working with the people who will be utilizing the functionality daily? They can’t.
4. Enhancement delay – This is more a result of a bad upgrade approach to begin with, but many times, organizations are under the gun to take the next upgrade version. With tight time constraints, any enhancement deemed as a large request will often get pushed out to another phase. Unfortunately, without a circle back on that list, these delayed enhancements never come to fruition causing your organization to be behind the times on Epic’s latest and greatest.

But it doesn’t have to be this way, and it doesn’t take a revolutionary overhaul of your current processes to make your organization successful in taking on an upgrade.

In our time assisting organizations with taking on new upgrades, we have identified these  quick steps you can take to get your team headed for success.  

1. Bring the right people to the party – This means the people actually doing the daily operational work need to also be involved with deciding what goes into the system. Too often, we see Nova notes being delivered to organization’s IT teams for review. While that is not the problem, the problem is when these tickets are then not reviewed with the operational folks who will actually be seeing the changes. And this brings me to my next point.
2. Overcommunicate and continuously collaborate – Everyone is busy, but it’s pertinent that when an upgrade is going to be taking place the impacted parties communicate. That means instead of sending a few Nova notes via email to an operational leader for review, setup recurring meetings that include the operational leaders, necessary IT team members, and members of the training team to discuss these Nova notes.
   
   The Nova notes themselves should be divided up into three groups after initial review (definitely not taking, need to review, and definitely taking). Anything labeled “definitely not taking” should essentially group notes that are just not applicable to the organization therefore not needing further review. Anything labeled as “needs to review” should be discussed with the impacted operational leader to determine if it will be taken or not, and finally, anything marked as “definitely taking” just needs to be have any system build questions answered in these meetings so the IT team can prepare the system for the upgrade.
3. Conduct operational testing and validation – During the initial Epic implementation, operational stakeholders are a key component of testing and the subsequent signoff. This shouldn’t go away when defining the upgrade approach.
4. Identify all workflow or view changes that will be going into effect, and provide training – This might seem obvious, and if you take care of the first two steps, it should (for the most part) fall into place, but it’s worth mentioning because of how crucial this step is. For example, with some of the most recent upgrades in Epic, the general layout is changing. Where you found information previously isn’t where you can find it today, and if you don’t want your staff to suffer a productivity setback, then you must be willing to carve out chunks of time to receive training and guidance on the impacts.
5. Establish a project approach that includes a post-upgrade review of delayed enhancements – Upgrades should have a specific project plan set aside to ensure their successful implementation, and within that project plan, there should be a specific step aimed at reviewing any enhancements that were pushed out past the upgrade for whatever reason. Essentially, as an organization, you need to actually review enhancements that your organization didn’t take (for whatever reason) but probably should or could and develop a plan to implement that post-upgrade.

Upgrades are meant to make your system better, not make it worse, but that’s the risk organizations run when they don’t appropriately prioritize the upgrade effort and bring all appropriate parties to the table. By getting the right people on the bus, constantly communicating with those members, and providing training to end-users, your upgrade process will no longer be a pain point, it will be what it is meant to be, an enhancement to your system. 

And with the transition to quarterly upgrades, this is no longer something you can avoid. More frequent upgrades require better project management and operational processes to be in place in order to accomplish the goal these upgrades are meant to accomplish.

If your organization has struggled or is struggling with operationalizing the upgrade process, reach out to us at The Wilshire Group. We would be happy to provide assistance.