epic upgrades are epic events - optimum healthcare it · upgrades are small-scale implementations...

Epic Upgrades are Epic Events

© 2017 OPTIMUM HEALTHCARE IT, LLC. ALL RIGHTS RESERVED WWW.OPTIMUMHIT.COM

AUGUST 8, 2017

THOUGHT LEADERSHIP IN HEALTHCARE IT

1.904.373.0831 \ WWW.OPTIMUMHIT.COM

© 2017 OPTIMUM HEALTHCARE IT, LLC. ALL RIGHTS RESERVED \ WWW.OPTIMUMHIT.COM 2

ABSTRACT After years of research and planning, thousands of hours of work, several sleepless nights and a significant monetary

investment, you successfully implemented the electronic health record that would forever improve your organization’s

delivery and documentation of patient care and your clinicians’ workflows. You survived the rush of go-live and successfully

navigated the barrage of stabilization and optimization tickets. Your end users have worked through their fear of change, fear

of the unknown and uncertain futures, to become fully functional, happy users of an electronic health record. And just when

you think it’s safe to take a breath, you’re faced with the sobering reality that it’s now time for an Epic Upgrade.

After everything you’ve just gone through, an upgrade can’t be that bad, can it? It’s just an upgrade, right? It’s not like you must

undergo an entirely new implementation, right?

This paper discusses some of the key factors necessary for achieving a

successful upgrade and shares some of the potential areas of risk to the

project.

WHY UPGRADE?While there are numerous customer-specific reasons that support when

or why an upgrade should be adopted, the bottom line is that upgrades

are not optional. Epic’s Support and Maintenance agreement generally

requires that their customers be no more than one version behind the

current released version. So, for example, while some customers initially

went live on Epic 2012, and made the decision not to upgrade to Epic 2014

when it was released, they were obligated to plan for an upgrade that

included both 2014 & 2015 after Epic 2015 was released the following

year.

Epic continually invests in the ongoing development of its application

suite. Each upgrade brings changes that provide new features and

modules, a new look and feel to screens and data displays, fixes for known

issues and more efficient ways to enter or review data. As technology

advances, Epic also modifies the underlying architecture to make use of

these improvements to streamline database management & monitoring,

generate faster and more robust processing, enhance the storage

capacity, and so much more.

HOW COMPLEX IS AN UPGRADE?Upgrades are small-scale implementations and to be successful, they require hard work with a significant investment of

time, money and resources throughout the organization. They must be given the same attention to detail as your initial

implementation with adequate planning and preparation. Since Epic recommends that you plan for an upgrade every 12-18

months, the project to “upgrade” should be discussed each year during the annual budget planning process. You’ll need a full five-

phased approach that mirrors your initial implementation encompassing application changes, technical infrastructure updates

and end user adoption of new features, functionality and altered workflows. You’ll need a comprehensive communication plan

that incorporates a variety of messaging strategies to effectively communicate the details of when and how you’ll accomplish

the upgrade. Engaging the entire organization and keeping them abreast of upcoming changes is critical to the success of the

upgrade.


OVERVIEWEpic Upgrades typically consist of three distinct impact areas: Application Changes, Technical Infrastructure Changes, and

Usage Changes for End Users.

Application ChangesEpic Upgrades heavily focus around updates and improvements to its suite of applications. New functionality, new modules,

new screen designs, new reports, fixes to issues from previous versions and more are included in each new release from Epic.

Application changes directly impact end users. Not all application changes are desired by the organization and must be vetted.

Some changes that are automatic with the upgrade leave options for an organization to accept or reject the change. While

these types of changes are generally minor and benign, they still must be reviewed. Having the appropriate organizational

team structure in place to review each change is essential. Documentation about all Application changes reviewed, included,

built or deferred should be tracked using NOVA.

Technical InfrastructureEpic’s applications are dependent on the organization implementing and maintaining a technical infrastructure that utilizes

robust technology compatible with the Epic architecture. Each upgrade brings changes to the technical requirements for

supporting the system. Virtually everything that runs Epic or connects to Epic, all hardware & software, can be affected by

an upgrade. For this reason, a thorough analysis of the technical infrastructure is a shared responsibility between Epic and

the organization’s IT teams. Epic provides a technical document outlining its minimum requirements for each upgrade and

they will perform a review of servers and processors to determine what is needed to run the database. In conjunction, IT must

conduct its own independent review of all third-party software, its workstations, printers, interface engine, and other systems

that connect with or communicate with Epic. Epic is not responsible nor knowledgeable about the requirements of other

systems that could conflict with Epic when the upgrade is complete. Only through a comprehensive analysis, communication

with vendors, and robust testing will issues be identified in advance of the upgrade so that appropriate interventions can be

made.

End User UsageOne of the goals of an upgrade is to preserve or improve the ease of use of Epic. Ultimately, since end users are those most

impacted by the upgrade, it is important for those reviewing Release Notes to understand the current workflows so that the

impact of a change can be identified and minimized as needed. They also stand to gain the most by the new functionality. The

“if only Epic could…..” list of requests for enhanced functionality from end users can be daunting. In many cases, the upgrade

provides users with the long-awaited functionality they’ve desired. It is important to identify and emphasize these when

sharing new features with end users. As with the original implementation, user competence and confidence in using Epic will

impact their enthusiasm to engage and adopt use of the new functionality or altered workflow. They must feel there is some

value added or benefit to them for the upgrade to have a positive impact.

Documentation about all Application changes reviewed,

included, built or deferred should be tracked using NOVA.

Application Changes

Technical Infrastructure Changes

Usage Changes for End Users

1

2

3


FIVE-PHASED APPROACH TO AN UPGRADEThe same five-phased approach that most customers utilize during an

initial Epic implementation should be replicated for an upgrade. It is highly

recommended that an upgrade be led by a strong Project Manager who not

only has excellent use of project management tools and methodologies,

but also possesses several years of Epic application experience along with

a solid understanding of the technical infrastructure used to support and

run the applications. Due diligence should be given to the development and

execution of plans that support all five phases of the upgrade project.

PlanningMost Epic customers implement the full suite of Epic’s core applications. This results in virtually all areas of the organization

being impacted by Epic in some way daily even if not by direct use of one of the applications.

Epic application and technical support teams generally fall under the direction of IT leadership. For this reason, few customers

identify key stakeholders throughout the organization when it is time to discuss the timing of an upgrade. Directors and VPs

from all departments should be represented in that discussion.

The IT department’s annual budget planning is where the timing for an Epic upgrade is often initiated. Preliminary timelines

are penciled in based on IT’s other ‘known’ project work that is planned for upcoming year. The risk and potential downfall to

this approach is their lack of knowledge of what other equally important departments are also planning for during the same

period. This can create conflicts, constraints and overlapping demands on vital team resources needed to execute the upgrade.

For example:

Facilities may be looking at expansion or the redesign/relocation

of existing hospital departments

Business development may be in early negotiations on the

acquisition of new provider practices

A department may be looking to purchase and implement a new

or software application that may or may not need to interface

to Epic

Finance may need to overhaul its billing/payment/

reimbursement practices due to regulatory changes

These examples emphasize the critical need to view the upgrade

as a ‘collaborative’ effort that impacts the entire organization.

Therefore, the initial upgrade planning discussions should

include the appropriate key decision makers from across the

organization along with the upgrade project manager, the

technical team lead, application leads and an Epic technical coordinator. An ideal forum would be a half-day workshop/retreat

where a sufficient amount of time can be given for discussion, Q&A and next steps.

Planning

Build

Testing

Training

Go-Live Preparations & Support

1

2

3

4

5


PLANNING (Cont.)

Why the upgrade is necessary and if the plan is to upgrade

just one release level or two

A comparison of the two primary types of server upgrade

processes – “Transparent vs. Conventional” with some

discussion on the overall goal for a maximum production

downtime

Epic’s schedule of upgrade dates for the upcoming year –

“Upgrade weekends or evenings”

Epic “Special Updates” that are released approximately

every 8 weeks which include fixes for software issues

that need to be factored into the timeline at appropriate

intervals so the teams can pause to do a review of these

fixes and plan for how & when these are applied to

Production and Non-Production environments

When and how to upgrade all ‘non-production’

environments including Training

How much change does the organization want to try to

adopt?

Competing projects within or outside of IT that might

require shared IT resources, application team resources

with a potential impact on the upgrade timeline?

Preparation time expectations for teams and end users in

advance of the upgrade date

Who are the key decision makers to resolve issues that are

impacting the forward progress of the upgrade project?

Primary tools and frequency of communication that should

be disseminated throughout the organization about the

upgrade’s status

Team structure, project plan, issue tracking, use of NOVA

and the status reporting process that will be utilized to

manage the project

Any known deficiencies in the IT infrastructure that would

need to be updated or replaced prior to the upgrade (servers,

processors, network, data center, data storage, internet

portal, etc.)

Any known application incompatibilities between the new

version of Epic to be implemented & existing software in use

by departments on shared Epic workstations

Contingency planning and some criteria that may impose

a “go/no-go” decision or adjustment to the original planned

upgrade date

Some agenda topics that should be discussed in this extended meeting include:


PLANNING (Cont.)

This outcome of this meeting should provide the framework for

A Project Charter that includes a defined project scope

A master project plan to be developed with a target date for the upgrade

A list of other supporting plans that need to be developed (i.e. Communication Plan, Training)

A high-level upgrade timeline that supports the major phases of the project

A decision on the priority of the upgrade and whether it is primary over other organizational initiatives

Identification of a strategic owner outlining the management of the Epic environments and data migration

A decision on the type of upgrade to be performed (i.e. Transparent vs. Conventional)

Identification of the Technical Lead to coordinate all areas of IT infrastructure changes required

An organizational chart with the entire project team structure required to support the upgrade

Identified known Risks at the outset of the project

The core key decision makers to address if the project timeline or go live date becomes at Risk


COMMUNICATION PLANThe purpose of the Communication Plan is to develop a strategy for distributing timely upgrade information through a variety

of communication channels. It is an attempt to minimize statements such as:

”No one told me that!”

”I didn’t know anything about that!”

”When did that change!”

Upgrade communication may highlight some of the benefits of the system, however, much of this is defined under the Training

Plan while the focus of the Communication Plan may place a greater emphasis on sharing with all staff the upgrade timeline,

specific deadlines, scheduled downtimes, special events, actions to take for upgrade preparedness etc.

A good Communication Plan will make use of many different methods and at varying intervals to emphasize key information

for the intended audience. Alert-type messages or “Important Notice” broadcasts should be reserved for more critical and

very timely information that has a significant impact. Other communication may include eye catching graphics to draw the

reader’s attention to what is being communicated. Each organization has a culture around communication and the plan should

be as robust as is needed to fit your organization.

Sample “High Level” Project Timeline


BuildSecond only to the Master Project Plan, NOVA is the most important project management tool for an Epic Upgrade. Nova is the

primary source of information about application changes included in the new release.

It is imperative that NOVA be used as a review tool & reference database for Enhancements and Release Notes, but it must

also serve as the “source of truth” for documenting and managing the changes that will be implemented with the upgrade. Epic

has made this a robust tool capable of the following:

A notification of Enhancements that are “automatic with

the upgrade”

Tracking the “selected” Enhancements to be included

in the upgrade project and which team(s) have build to

complete

The ability to monitor the “build complete” status indicated

on any Release Note to monitor progress towards timeline

deadlines

Indicating the Testing or Training needs associated with

each Release Note to ensure detailed plans are developed

to include those items

The ability to include comments at various levels and

between “Advisors” and responsible application team

members which allows for collaboration and input for joint

decision making

The ability to run reports indicating percent complete on

the review of assigned notes

The ability to export to Excel to utilize filtering, for tracking

and monitoring the work effort where build has been

indicated, but is yet to be done as well as that already

marked complete

When build is complete and a workflow has been altered

to accommodate new functionality, a cross reference to the

updated workflow test script number can be entered into

testing comments

While many organizations desire to implement as much of the upgrade as possible, time, money, human resource limitations

and effort to implement often hinder teams from including some changes at the time of the upgrade. The organization may

choose to defer these changes to a post-upgrade period for implementation. Input into making these types of decisions

should be obtained from appropriate clinical or financial operational departments. Some consideration should be given to the

following questions when determining if an Enhancement should be selected or excluded:

What is the potential added value or benefit to be realized?

The creation of “Advisory Roles” within NOVA allows for selected representatives from operational departments to read a

Release Note and share their comments or recommendations with the assigned application team. The final decision to include

or exclude an Enhancement with supporting rationale should be made by a committee of key stakeholders and documented in

the comments of the Release Note. In this way, NOVA can also serve as a Decision Tracker for each Enhancement.

Is this an Enhancement that clinicians have been asking

for?

What if any, regulatory requirement will be satisfied if

implemented?

What cost, time, work flow steps or other benefits could be

realized?

Is there any potential difficulty or widespread effort to roll

out or adopt the change and if so, can it easily be done

within the upgrade timeline?

Is there any new hardware or interface required to

implement this Enhancement that was not already

identified as ‘in scope & budgeted for’?


TestingIt is a given that any change requires some level of testing to ensure that the functionality works as designed, the outcome

produced meets expectations and that the end user experience is not negatively impacted. No matter how much change is

introduced a well-defined comprehensive testing plan for Epic upgrades includes the following standards for testing:

Incorporate the different types/levels of testing

Unit = Component

Application = Functional

Integrated/Interface = Cross application

Regression = maintain current state when no change made/intended

User Acceptance

Utilize Test scripts that have been updated with the changes built for a specific Release Note and reference the script number used

for testing in NOVA

Integrated testing is not limited to just Interface message testing. It includes any other means of communicating with, transmitting

from or interacting directly within Epic. (Ex: Dragon Dictation)

Interface testing should include all inbound/outbound interfaces down to the level of the individual message type

The overall testing strategy & scope should define the number of rounds of testing required, the sequence in which they should be

executed and the number of scripts that will be tested

Hard copy printouts for certain test scripts should be generated to validate the script (i.e. claims)

All hardware devices and peripherals connected to Epic and used in a work flow need to be available and tested as part of the script

test plan. (iPads, iPhones, tablets, scanners, dictation microphones, printers, signature pads etc.)

All ‘third party’ software that resides on the same workstation as the upgraded version of Epic should be tested as part of Regression

testing to ensure compatibility and that current state functionality is maintained. (Ex; software used by Radiologists for PACS or

documenting Ultrasound readings, Dragon Dictation)

Test scripts should be executed for My Chart and EpicCareLink, to ensure remote access/ internet portal access along with

functionality and display is appropriate

As a validation for Finance that all month end processes will work post upgrade, consider the strategy of taking a copy of Production

database (will have all patient financial information) and applying that to a separate upgraded instance of Epic for Finance to run

a full month end process

A significant factor and key to successful testing is having a designated Testing Coordinator. This resource should have

responsibility for drafting the overall test plan and coordinating the location, resources, and schedule for testing. During the

execution of the integrated testing phase, the coordinator monitors each script as it progresses to completion and works with

application or interface teams to resolve issues. Daily debriefs, morning & afternoon, should be conducted with all testers as

an integral part of the communication plan for that testing day. An end of day summary status report on the testing outcomes

should be shared with the project leadership.


TrainingAll changes related to an upgrade require some form of communication that informs end users about the change and how the

change impacts their use of Epic. There is a direct correlation between the amount and complexity of these changes and the

delivery method chosen. In many cases, for screen display changes or minor workflow changes, a simple tip sheet will suffice.

Many customers make use of pre-recorded videos by Instructional Designers or conduct Webinars to provide demonstrations

of new features and the execution of step-by-step workflow changes.

It is extremely time consuming and expensive for an organization to require its users to participate in Instructor-led classroom

training. Even those customers who embrace large scale changes and the implementation of many Enhancements successfully

upgrade using a variety of teaching methods that do not require classroom training. A Training Manager or Training Lead

should be responsible to work with all of the Instructional Designers from each application to make the necessary updates to

the appropriate The keys to success in establishing a training plan include:

The use of various types of communication tools & training methods

as an alternative to classroom training.

Learning Home Dashboards

Tip Sheets

E-learnings

Webcast Demonstrations

Departments/Advisory Committee Mtg presentations

Newsletters

Memos

Posters/Fliers

E-mail

Upgrade website

Choosing the appropriate training delivery method based

on the complexity of the change

Provide specific details on new or revised work flows and

communicate about retired/obsolete work flows

Revise ALL classroom training material & curriculum

used in new employee training classes

Dates for upgrading the training environments and how

the new build will be migrated/validated in the training

environments

If the date to begin training new employees must use

the new curriculum and the upgraded version of Epic in

advance of the actual upgrade date

Use of all organizational education departments to assist

in training (Nursing Ed, Corporate Ed, Medical Staff Ed etc.)

What education is necessary for Super Users in advance of

the upgrade

What education is necessary for the Help Desk staff in

advance of the upgrade and if KBAs (Knowledge Based

Reference Material) are used by them, then a plan for who

and when these will be update is required

Where and who is responsible to maintain a central “on line”

access point to all updated Upgrade related educational

material, tip sheets or videos


Go-Live Preparations & SupportIt is inevitable that as the Go Live date rapidly approaches, there will be unresolved reported issues to Epic for which Sherlock

tickets have been opened. It is prudent to review the list of open tickets with key organizational leaders or project stakeholders

so that they are aware of those outstanding items. The organization must determine if the remaining open issues are of a

critical nature that pose any significant threat to patient safety or other serious concerns.

Most organizations plan for no more than 2 weeks of post go-live upgrade support. The support plan should ensure that end

users have enough immediate access to circulating “at the elbow” support resources, knowledgeable Help Desk Staff, or a

phone line that connects users directly to the application build team. These resources should be available immediately when

the system is back online. The duration and requirement for 24X7 coverage by each application team or the organization’s

support resources is dependent on:

The hours of operation for each department where end users are on the system

The number of issues identified that remain open in the post upgrade window

The severity of the issues being experienced by end-users with or without a workaround that needs to be communicated and

supported

The breadth of impact – widespread vs. localized

OPERATIONAL READINESSApproximately 1-2 weeks before the upgrade event, a joint meeting with all Operational Leaders, Department Directors and

Project Team Leads should be held to give a quick overview of what to expect during the final days before and the night of the

upgrade. These are efficiently held as WebEx calls where many can attend and review the information by slide presentation.

The agenda topics should include:

Timeline – what remaining events will precede the upgrade

Transparent lockdown – what to expect, restrictions & limitations

Downtime/cutover – duration & activities the night of the upgrade

Recovery – the order of data entry post downtime event

End user support – Super Users, Help Desk, Direct line to Application Teams

Examples of new features in Epic 2015

Action Items – what you can do to prepare for upgrade

If the organization has chosen the Transparent upgrade approach,

there is a “Lockdown” period in which restrictions and limitations

are placed on changes to the Production environment.


ISSUE MANAGEMENT & DAILY DEBRIEFSThe Upgrade Project manager should monitor daily reports obtained from the Help Desk on call volumes, ticket generation

and similar issue trends. The support plan should include a time for “Daily Debriefs” with Operational Leadership to share

“Wins & Reminders” and apprise them of the call volumes and any significant issues that are being worked on or that have

been resolved. It also provides an opportunity to obtain comments and feedback from Operations on how well their users

are managing the changes introduced by the upgrade, obtain any additional information on issues already being worked, and

to communicate issues they have noted that have not yet been called in. In many cases, the Support Command Center is able

to close down well before the 2 week support period is complete if sufficient attention to detail was given during testing &

training.

Sample Call Volume/Issues Reported Template


CONCLUSIONIn summary, one of the best compliments an upgrade team can hear is “This was the biggest organizational non-event”. To

be able to guide an organization through the process of an upgrade and embrace the magnitude of change it brings can only

be achieved by giving due diligence to topics addressed in this paper. While not intended to be an upgrade handbook or an

exhaustive list of every topic to be worked through, it does provide insight into those areas of an upgrade that require attention

to detail in order to be successful.

Optimum Healthcare IT can help you get there.

Your success is our success.

A few major takeaways:

To not underestimate the amount of time needed to develop multiple

comprehensive detailed plans for every area of the project

Ensure you have full organizational commitment on engagement and

participation in the upgrade plan from start to finish

Factor into the budget planning process (that often takes place before any

upgrade specific analysis is done) the potential need for:

Additional/upgraded hardware to support or run with Epic or to

implement new functionality as an upgrade Enhancement

Third party application upgrades that would be separate but necessary

parallel projects

Extra experienced staff resources to work the upgrade or backfill /

supplement teams to maintain the organization’s use of production

Epic pre-upgrade

Upgrades are now part of our everyday lives. And while they can be daunting,

updated features and functionality that can improve patient care is certainly

worth the time and resource commitments necessary to successfully install an

upgrade.

Optimum Healthcare IT has years of experience in EHR Strategy, Planning,

Work flow Design, Systems Design and Build, Testing, Training and Go-Live

Support and was recently named 2017 Best in KLAS Overall IT Services Firm,

2017 Best in KLAS HIT Enterprise Implementation Leadership, 2017 Category

Leader for Go-Live Support and the Top-Rated Firm in Implementation Services.

We have the proven track record to guide you through your Epic Upgrade.

epic upgrades are epic events - optimum healthcare it · upgrades are small-scale implementations...

Documents