CPIA Module 21, Section 5: Epic Upgrade Cycle & Change Management
MODULE 21: VENDOR-SPECIFIC LAB – EPIC WILLOW INPATIENT

Section 21.5: Epic Upgrade Cycle & Change Management

Understand the rhythm of maintaining a live Epic system. This section details Epic’s quarterly upgrade cycle, the process for testing new features, and how to manage the constant flow of changes and enhancements.

SECTION 21.5

Epic Upgrade Cycle & Change Management

Mastering the Pulse of a Living System.

21.5.1 The “Why”: An EHR is a River, Not a Lake

It is a common misconception to view an Electronic Health Record as a finished product that is purchased and installed like a piece of lab equipment. This could not be further from the truth. An EHR is not a static lake; it is a constantly flowing river. The system you use on Monday will be subtly different from the one you use a year from now. This is not a sign of instability; it is a sign of a healthy, evolving ecosystem that is constantly being improved, updated, and refined by its vendor and by your own organization.

This constant evolution happens on two parallel tracks. The first is the highly structured, predictable rhythm of the Epic Upgrade Cycle. Several times a year, Epic releases a new version of its software, packed with new features, enhanced functionality, and mandatory regulatory updates. This is a massive, organization-wide undertaking that requires months of planning, testing, and training. It is the informatics equivalent of a planned, periodic system-wide remodel.

The second track is the daily, year-round process of Change Management. This governs the constant stream of requests, fixes, and optimizations that come from your own users. A pharmacist identifies an unclear order, a manager requests a new report, a nurse discovers a workflow bottleneck—all of these trigger the change management process. This is the continuous, day-to-day maintenance and improvement that keeps the system aligned with the evolving needs of your hospital.

As a pharmacy informatics analyst, you are a primary steward of this river of change. Your technical skills in building records, rules, and reports are the tools you use to navigate it, but your mastery of process and communication is what will keep the ship afloat. Without a disciplined approach to testing, validation, and communication, this constant change would devolve into chaos, eroding user trust and endangering patients. This final section of our module is dedicated to the most important “soft skill” in informatics: the ability to manage change with the same rigor and precision you apply to a medication build.

Retail Pharmacist Analogy: The Quarterly Corporate Remodel vs. The Daily Suggestion Box

To understand the two tracks of system change, imagine you are the manager of a flagship pharmacy in a large national chain.

Track 1: The Quarterly Corporate Remodel (The Epic Upgrade)

Your pharmacy is not an independent store; it’s part of a larger corporation that is constantly innovating. Every three months, the corporate office mandates a store-wide remodel. This is the Epic Upgrade Cycle.

  • The Blueprint Arrives (`Release Notes`): Six weeks before the remodel, a massive binder arrives from corporate detailing every planned change. It specifies new shelving units, an updated cash register system, new aisle signage, and a different workflow for prescription intake. Your first job is to read this entire binder and identify which changes will have the biggest impact on your staff.
  • Testing in the Back Room (`Testing Environment`): Corporate sends one of the new cash registers ahead of time and sets it up in your stockroom. You and your lead technicians spend days testing your most common transactions. Can you still ring up a co-pay? Does the coupon scanner work? Does it handle returns correctly? You identify a bug in the coupon software and report it back to corporate so they can fix it before the real remodel. This is **integration testing**.
  • The Weekend Remodel (`Go-Live`): The pharmacy closes at 6 PM on Friday. A massive crew descends on the store and works all weekend. They rip out the old registers, install the new shelves, and change all the signs. This is the **technical upgrade go-live**.
  • Monday Morning (`Post-Live Support`): When you open on Monday, an expert from the corporate office is standing beside you at the registers. When the first problem arises—a barcode won’t scan—they are right there to help you troubleshoot and fix it. This is **at-the-elbow go-live support**.

Track 2: The Daily Suggestion Box (Internal Change Management)

Separate from the big corporate remodels, your own staff and customers are constantly identifying smaller issues and opportunities for improvement. You keep a suggestion box at the front counter. This is your **change request intake process**.

  • Reviewing the Suggestions (`Triage & Governance`): Every Tuesday morning, you meet with your lead pharmacist and inventory specialist for your weekly leadership huddle. You pull out the suggestion cards. Card 1: “The waiting room chairs are wobbly – safety issue!” Card 2: “The sign for the ‘Pain Relievers’ aisle is spelled wrong.” Card 3: “We should move the entire vitamin section to the front of the store.”
  • Prioritization (`Change Control Board`): You can’t do everything at once. Your team decides: “Fixing the wobbly chairs is an **URGENT** safety fix. Correcting the misspelled sign is a **NORMAL** change we should do this week. Moving the vitamin section is a **MAJOR** project that will require more planning and a separate budget request.” You have just held a **Change Control Board (CCB)** meeting.
  • Making and Approving the Change (`Build & Test`): You assign the sign correction to your most artistic technician. They design and print a new sign in the office (`build in DEV`). Before hanging it, they show it to you and the lead pharmacist for approval (`User Acceptance Testing`).
  • Implementing the Change (`Migration to Production`): On Wednesday after hours, the tech takes down the old sign and hangs the new, approved one. The change is now live for all to see. This is a **migration to your production environment**.

An informatics analyst lives in both of these worlds simultaneously—managing the massive, scheduled, vendor-driven upgrades while also handling the continuous stream of smaller, user-driven changes that are essential for keeping the system safe and efficient.

Part 1: The Epic Upgrade Cycle: A Year in the Life

The Epic upgrade cycle is the predictable, semi-annual or quarterly rhythm that defines the life of an informatics analyst. It is a massive, multi-month project that consumes a significant portion of the IT department’s resources. Your health system pays a large sum for Epic maintenance, and a key part of that contract is the delivery of new software versions that contain performance enhancements, new modules, and critical updates to meet new federal and state regulations. Choosing not to take an upgrade is generally not an option.

As a Willow analyst, you are the designated expert responsible for understanding how each new version will impact every facet of the medication management process. You are the pharmacist’s advocate, the provider’s consultant, and the system’s guardian throughout this demanding cycle.

Phase 1: Planning & Analysis (Months 1-2) – Deciphering the Blueprint

Long before the upgrade occurs, the process begins with an intense period of analysis. Epic provides your organization with a vast amount of documentation detailing every single change in the new version. The most important of these is the “New Version Summary” and the detailed, application-specific release notes.

The Analyst’s Most Important Tool: The Impact Analysis Spreadsheet

You cannot possibly keep track of hundreds of changes in your head. The cornerstone of upgrade analysis is a detailed spreadsheet. You will create a master document, often shared with your entire Willow team, that lists every single new or changed feature relevant to pharmacy. For each item, you will create columns to track:

  • Feature Name: A short description of the change.
  • Epic’s Description: A copy-paste from the release notes.
  • Impact Level (High/Medium/Low): Your initial assessment of how much this will affect your users or workflows.
  • Affected Area: Which part of the system does this touch (e.g., Inpatient Ordering, Verification, BCMA, Oncology)?
  • Required Build (Y/N): Does this feature require configuration before it can be used?
  • Decision: Will we adopt this new feature? (Yes/No/Later).
  • Assigned Analyst: Who on the team is the primary owner for this item?
  • Testing Status: A column to track its progress through the testing phases.

This spreadsheet becomes your project plan and your source of truth for the entire upgrade cycle.

The Analyst’s Role in Phase 1

Your primary job in this phase is to read, analyze, and translate. You must:

  • Read Every Word: You must meticulously read the Willow, Order Entry, and other relevant release notes to identify every change.
  • Categorize Changes: You’ll mentally sort each change into categories:
    • New Opt-In Features: Exciting new tools that are off by default. Your organization must decide whether to invest the time to build and implement them.
    • Changed Features: Existing functionality that will now work differently. These are high-risk, as they can break existing workflows if not accounted for.
    • Mandatory Updates: Changes, often for regulatory reasons (e.g., new e-prescribing standards), that will be enabled automatically. You have no choice but to adapt.
    • “Look and Feel” Changes: Minor changes to buttons, colors, or screen layouts that require communication to users but little technical work.
  • Present to Stakeholders: You will present your impact analysis to pharmacy leadership and clinical governance groups. This is where decisions are made on which new features to adopt. You must be prepared to demonstrate the feature in a “preview” environment and explain its clinical and operational benefits.

Phase 2 & 3: Build and Rigorous Testing (Months 2-4)

Once decisions are made, the technical work begins. The new Epic version is installed in a series of non-production environments (e.g., `TEST`, `QA`). Your job is to perform any required build and then subject the system to the most rigorous testing imaginable.

The Multi-Layered Testing Strategy
Testing Type Who Performs It? Purpose Analyst’s Role & Example
Unit Testing The individual analyst. To verify that the specific build you configured works in isolation. Role: Tester. Example: “I just enabled a new setting for the verification screen. I will log in as a test pharmacist and verify five different types of orders to ensure my setting didn’t break anything.”
Integration Testing Teams of analysts from different applications. To verify that workflows that cross multiple applications still function correctly. These are highly scripted and formally documented. Role: Participant & Scripter. Example: “I will participate in the ‘Admit-Transfer-Discharge’ testing script. The registration analyst will admit the patient, the provider analyst will place orders, I will verify them, the nursing analyst will administer them, and the billing analyst will confirm the charges dropped. We follow every step of the script and document pass/fail.”
User Acceptance Testing (UAT) Clinical “Super Users” (pharmacists, nurses, providers). To get frontline staff to validate the changes and ensure they are clinically safe and logical from a workflow perspective. Role: Facilitator & Scribe. Example: “I will lead a UAT session with three ICU pharmacists. I will give them scenarios to test (e.g., ‘Verify this heparin drip order’) and watch them navigate the system. I will document their feedback, confusion, and any bugs they uncover.”
Inadequate Testing is the #1 Cause of Go-Live Failure

There is immense pressure during an upgrade cycle to meet deadlines. The area that is most often squeezed is testing. Cutting corners on testing is the single most reliable predictor of a disastrous go-live. A single untested workflow that breaks in the live environment can halt patient care, cause significant safety events, and destroy the clinical staff’s trust in both the system and the IT department. As an analyst, you must be a fierce and vocal advocate for a rigorous, comprehensive, and uncompromised testing plan. Your professional credibility and your patients’ safety depend on it.

Phase 4 & 5: Training, Go-Live, and Support (Month 5)

As testing concludes and the go-live date approaches, your focus shifts to preparing the end-users for the changes and preparing yourself for the intense period of support that will follow.

  • Training & Communication: Based on your analysis and UAT feedback, you now know which changes will be most impactful. Your role is to work with the training team to create materials—tip sheets, newsletter articles, short videos, formal training curricula—that explain these changes to the pharmacy staff. You will likely attend staff meetings and huddles to present the key changes.
  • The Go-Live Event: This is typically a weekend event where the technical teams perform the actual upgrade on the production (`PROD`) environment. As an analyst, you will often be involved in post-upgrade validation—logging into the newly upgraded PROD environment in the early morning hours to run a series of quick checks to ensure everything is working before the hospital wakes up.
  • Post-Live Support: The first one to two weeks after a major upgrade are the most critical. You will be assigned to a “command center” or will be scheduled for highly visible “at-the-elbow” support shifts in the central pharmacy or on high-acuity units. Your job is to be the instant-response expert, troubleshooting issues, providing quick answers, and triaging bugs as they are discovered by frontline staff.

Part 2: The Change Management Process (The Other Days of the Year)

While the major upgrades set the macro-rhythm of your year, the daily reality of an informatics analyst is governed by the constant, smaller-scale process of internal change management. This is the formal, structured process by which your health system manages the hundreds of requests for fixes, improvements, and new functionality that arise from your user base. Without a formal process, this would be a chaotic free-for-all, with analysts working on unapproved, low-priority tasks while critical issues go unaddressed.

Most mature IT departments base their change management process on a framework like ITIL (Information Technology Infrastructure Library), but the core principles are universal: document, prioritize, build, test, and deploy in a structured and auditable way.

The Lifecycle of a Change Request

Let’s follow a single request from idea to implementation.

1
Intake

A user submits a “ticket” via a service desk portal, describing their issue or request.

2
Triage & Analysis

The ticket is assigned to you. You investigate the issue, replicate the problem, and document the root cause and proposed solution.

3
Governance & Prioritization (CCB)

You present your findings to the Pharmacy Change Control Board. Leadership reviews the request and decides whether to approve, deny, or defer it based on clinical need, safety risk, and resource availability.

4
Build & Unit Test

If approved, you perform the necessary build in a development environment (`DEV`) and conduct your own unit testing.

5
Validation & UAT

The change is migrated to a testing environment (`QA`). You have the original requester and other stakeholders test the fix and provide their official sign-off.

6
Migration & Closure

The approved and tested change is scheduled and migrated to the live production environment (`PROD`) during a designated change window. You validate the change in PROD and close the ticket.

The Role of the Change Control Board (CCB)

The CCB, sometimes called a Change Advisory Board (CAB), is the central nervous system of your change management process. It is a formal governance meeting, typically held weekly or bi-weekly, where IT analysts and clinical/operational leaders convene to make decisions.
Who attends?

  • Director of Pharmacy (Chair)
  • Inpatient & Outpatient Pharmacy Managers
  • Clinical Pharmacy Coordinator/Specialists
  • Key Pharmacy Technicians (e.g., Inventory or Automation Lead)
  • The Willow Inpatient Analyst Team
What is your role as an analyst? You are not a decision-maker in this meeting; you are an expert consultant. For each ticket you bring to the CCB, you must be prepared to concisely explain:
  • The nature of the request.
  • The root cause of the problem.
  • The proposed solution.
  • The estimated effort/time to complete the build and testing.
  • The potential risks of making (or not making) the change.
The CCB will then weigh your recommendation against all the other competing priorities and give you the official approval to proceed with your build. This process ensures that the limited IT resources are always focused on the issues that are most important to pharmacy leadership and patient safety.