How to Successfully Catch Up on Overdue EHR New Version Upgrades Part I

By Joncé Smith, Vice President of Revenue Cycle Management

Industry turbulence significantly plagued the healthcare industry over the past two years. In an attempt to effectively manage ongoing changes, many hospital and health system CIOs slowed or halted IT EHR upgrades. Now, however, as indicated by the 9th annual HIT Outlook Report, healthcare CIOs say their biggest IT investment in the next year will be toward catching up on EHR new version upgrades. That may mean upgrading internal EHR instances, or aligning hosted, community-shared EHRs with surrounding health systems. Regardless, hospitals and health systems may need to perform double or even triple jumps in version upgrades to catch up.

This two-part blog series explores how to effectively manage overdue EHR system new version upgrades without sacrificing operational success, quality testing or vendor compliance.

Best practices for performing double/triple version upgrades

There are several considerations when planning a multi-jump EHR version upgrade. The first is understanding how many upgrade items will be within the scope of the project. In addition, it's crucial to determine which upgrade items the vendor automatically turned "on" versus those that internal IT teams must fully activate to deploy.

Then, adopt these best practices for multi-version upgrades:

• Maintain an internal software functionality testing team. Preview the upgrade documentation early on–during planning–to identify which members of your upgrade team you need for the release's testing and approval. Non-IT staff should be involved from the start of upgrade planning, too, so they understand the upgrades' scope and how much testing they will need to do.
  
  The team should include IT analysts and top end users to ensure the upgrade addresses both technical and "workability" needs. While analysts can do simple testing on the system, key non-IT department staff should be responsible for testing. Their working knowledge of the applications' daily operations is critical. Plus, not only can a blended team help the IT department gain traction during the upgrade rollout, but it can also build cross-organizational support for future IT initiatives.
  
  
• Map out and test the impact on coordinating systems and applications. When the upgrade item scope list is complete for each version, the next step can be initiated. For each item on your scope list, upgrade teams will need at least four testing scenarios. These include:
  1. Simple forward testing to ensure the item works as expected according to the upgrade documentation.
  2. Simple backward regression testing to ensure the item doesn't cause an unintended result or consequence.
  3. End-to-end testing within the application (no interfaces) to ensure the logic of the item is fully maintained, and it works within that functional pathway.
  4. End-to-end testing with interface messaging to respective downstream system targets. This test scenario ensures that necessary downstream applications receive the appropriate information, while downstream applications that should not receive an interface message do not receive one. This is especially important when interface messaging traffic is controlled by logic within the interface engine rules and/or where table values are used to determine messaging targets. (Note that if a single test scenario cannot be developed for this step, interface validation will require multiple scenarios.)

The main objective of the upgrade project is to validate each upgrade item as if each upgrade version had been applied separately. The vendor will have tested each upgrade version as it was released, and that testing will have proven compatibility across versions. However, vendor testing cannot take into account a specific organization's daily operational use of the application. That can only be fully vetted specifically by your healthcare organization’s team through rigorous testing following the stringent strategy outlined.

Stay tuned for Part II of this blog series, in which we examine best practices for designating responsibilities, scheduling go-live, and go-live workflows.