Epic EHR and SAFe Agile: How Health Systems Run Epic Programs Inside PI Planning and ART Delivery

Most healthcare organizations that run Epic programs inside SAFe structures do so with a fundamental mismatch between how SAFe was designed to work and how Epic implementations actually deliver. The Epic module build cycle, the compliance requirements that govern every Epic configuration change, and the vendor-driven upgrade calendar do not map cleanly onto a generic 12-week PI. This article covers how large health systems structure Epic programs inside SAFe, what SAFe concepts translate well to Epic delivery and which do not, what analysts and product owners working on Epic ART teams must understand to be effective, and the adaptations that make the combination work in practice.

Why Large Health Systems Use SAFe for Epic Programs

Large health systems that operate multiple Epic modules across multiple facilities face a coordination problem that small-team agile methods cannot solve. A 14-module Epic implementation involving 180 analysts, dozens of clinical super-users, IT security, compliance, integration teams, and external vendors cannot run in a single product backlog with a single product owner. SAFe (Scaled Agile Framework) provides the coordination layer that aligns multiple teams working on the same Epic program toward shared Program Increment objectives.

SAFe’s ART (Agile Release Train) model is particularly relevant for Epic because it is built around the concept of a persistent cross-functional team structure that delivers value in Program Increments (PIs) of 8-12 weeks. An Epic implementation or a post-go-live optimization program delivers on a defined timeline with defined module milestones – a natural fit for PI-based planning. The alternative – running 14 separate module teams with no coordination layer – produces the dependency conflicts, integration failures, and conflicting release schedules that derail Epic programs.

SAFe for Epic is not a clean off-the-shelf application. The Epic delivery cycle has characteristics that require deliberate adaptation of the standard SAFe model. Understanding which SAFe practices translate directly and which require modification is the prerequisite for running an effective Epic ART. The broader Epic implementation context where SAFe is applied is covered in the Epic EHR Learning Hub.

How Epic ART Teams Are Structured

A well-structured Epic ART organizes teams around clinical and operational domains rather than around Epic module names. A module-centric structure (one team per Epic module) produces silos that make cross-module feature delivery difficult. A domain-centric structure groups modules by the clinical or operational capability they support – inpatient clinical (ClinDoc, Willow, Orders, Beaker), ambulatory clinical (Ambulatory, MyChart, CPOE), revenue cycle (Resolute, Prelude, Claims), and infrastructure (Bridges, Security, Cogito). This grouping aligns with how clinical stakeholders think about the system and makes feature ownership cleaner.

Core ART Roles for Epic Programs

Team Size and Composition for Epic Agile Teams

SAFe recommends team sizes of 5-11 members. Epic teams that follow this guidance tend to organize with: 3-5 build analysts who own specific Epic module configurations, 1 QA analyst who owns testing methodology and test execution (ISTQB-aligned practices apply here), 1 product owner who manages the team backlog and acceptance criteria, 1 integration analyst who handles interface and Bridges work, and 1 super-user or clinical SME who serves as the team’s clinical context reference. This composition keeps the team small enough to be agile while covering the range of skills that Epic build requires.

A common mistake is composing Epic agile teams entirely of build analysts with no dedicated QA presence. Epic build work generates configuration artifacts that must be tested before they reach production. Without a QA analyst on the team, testing becomes an afterthought that is compressed at the end of each sprint when the team runs out of build time – exactly the pattern that SAFe’s built-in quality practices are designed to prevent.

PI Planning for Epic: What Works and What Requires Adaptation

SAFe PI Planning is a 2-day event where all ART teams plan their work for the next 12 weeks. For standard software product teams, PI planning produces team iteration plans and a set of PI objectives. For Epic programs, the same event produces these outputs – but the planning inputs and constraints are different in ways that the RTE and product managers must understand and prepare for.

What PI Planning Works Well for Epic

PI planning’s dependency identification process is particularly valuable for Epic programs. Cross-module dependencies – where the CPOE team’s order routing configuration depends on the Bridges team’s interface build, which depends on the external lab system’s acceptance testing schedule – are exactly the type of dependency that PI planning’s team board visualization makes visible. Without a structured dependency identification exercise, these inter-team dependencies are managed through informal communication that breaks down under schedule pressure.

The PI objective commitment process also transfers well. Each Epic team defines its PI objectives – the specific outcomes it commits to delivering by the end of the PI – and rates each objective’s confidence level. For Epic build teams, a PI objective might be: “Complete IVT Cycle 2 for the Inpatient Clinical module with zero open Critical defects and Clinical SME sign-off.” This is a meaningful, testable objective with a clear acceptance standard.

What Requires Adaptation

Standard SAFe PI planning assumes that teams can commit to delivering working software at the end of every sprint (typically every 2 weeks). Epic build teams do not always produce “working software” at that cadence – they produce build configurations that are not testable until the test environment is refreshed, interfaces that cannot be validated until a connected system is ready, or clinical workflows that cannot be evaluated until super-users are available for testing. The PI planning template must be adapted to account for these dependencies on external readiness factors that are outside the team’s control.

Epic’s annual upgrade calendar is an external constraint that must be factored into PI planning explicitly. If the annual Epic upgrade falls in PI 3, the PI 3 plan must reserve capacity for Upgrade Companion review, regression testing, and cutover preparation. This is not recoverable in the innovation sprint – it is planned work that requires dedicated team capacity. Epic ART teams that do not reserve this capacity during PI planning will sacrifice PI objectives to upgrade work, which looks like underperformance on PI metrics but is actually a planning failure.

Translating Epic Work into SAFe Features and Stories

The most common breakdown in SAFe-for-Epic programs is the failure to correctly define Features and Stories at the right level of granularity. Teams either write Features that are too large (a single Feature that encompasses an entire Epic module build) or write Stories that are too technical (a Story for each individual Epic configuration record rather than for the workflow step it enables).

What Makes a Good Epic Feature in SAFe

A SAFe Feature is a deliverable of business value that can be completed within one PI. For Epic programs, a Feature is a clinical or operational capability that a defined user role can perform after the Feature is complete. “Configure Sepsis Order Set” is not a Feature – it is a build task. “Enable hospitalists to place the org’s evidence-based sepsis bundle orders from a single order set within 60 seconds of sepsis identification” is a Feature. It has a who (hospitalists), a what (place sepsis bundle orders), a how good (within 60 seconds), and a why (evidence-based sepsis bundle compliance).

Features must have Acceptance Criteria that confirm the Feature is done. For an Epic Feature, acceptance criteria typically include: the clinical workflow can be completed end-to-end in the test environment by a super-user without analyst assistance, all integration touchpoints are confirmed working, any associated regulatory or compliance requirements are met, and the clinical SME has signed off that the Feature meets the clinical need that drove the request.

How to Write Epic Stories in User Story Format

The standard SAFe User Story format – “As a [role], I want [capability] so that [benefit]” – transfers directly to Epic build stories with one important adaptation. Epic stories must specify the Epic module and workflow context in the story description, not just the role and capability. A story that says “As a nurse, I want to document medication administration so that the record is complete” is too vague for an Epic team. It does not tell the analyst which Epic module (Willow BCMA), which workflow step (scan and document administration), or what “complete” means in clinical terms.

A correctly written Epic Story looks like: “As an inpatient nurse using Epic Willow BCMA, when I scan a patient wristband and then scan a medication barcode, I want the system to confirm the 5 rights and allow me to document administration in one screen so that bedside documentation takes less than 60 seconds and the eMAR is updated in real time.” This story contains enough specificity for a build analyst to identify the Epic configuration objects, for a QA analyst to write a test case, and for a clinical super-user to validate the result.

Managing Cross-Team Dependencies in Epic ART Delivery

Dependencies in Epic programs are more complex and more consequential than in typical software product development. An Epic interface dependency – where the CPOE team cannot complete lab order routing testing until the Beaker team has configured the receiving lab queue – is not just a scheduling inconvenience. If the Beaker team misses their commitment, the CPOE team cannot demonstrate a working Feature at the end of the PI, and the sprint demo is meaningless.

The System Demo as the Integration Gate

SAFe’s System Demo – a demonstration of integrated working software at the end of each sprint – is the mechanism that makes cross-team dependency management actionable rather than theoretical. For Epic ART teams, the System Demo should demonstrate end-to-end clinical workflows that cross module boundaries, not isolated module-level configurations. A System Demo that shows a lab order placed in CPOE, transmitted through Bridges as an ORM message, received in Beaker, resulted, and returned as an ORU to the provider’s in-basket demonstrates that four teams’ work actually integrates. A System Demo that shows only the CPOE order entry form (because the Bridges and Beaker teams are not ready) is not a System Demo – it is a partial build walkthrough.

Teams on an Epic ART that cannot demonstrate integrated workflows at the System Demo have a dependency problem that must be escalated to the RTE. The RTE’s role is to resolve ART-level impediments – including cross-team dependency failures – before they become PI objective failures. The build defect triage process that supports this inter-team quality gate is described in the Epic Build Defects troubleshooting guide.

Dependency Board Management

The PI planning dependency board – where teams draw dependency arrows between their plans – is often treated as a planning exercise that ends when PI planning ends. For Epic ART teams, the dependency board must be a living artifact reviewed weekly in the ART sync meeting. Epic dependencies change mid-PI when interfaces are delayed, when super-users are unavailable for testing, or when the test environment is not refreshed on schedule. A dependency that was green at PI planning can become a critical blocker by Sprint 4 if nobody is tracking it.

HIPAA and Compliance Work Inside a SAFe Structure

HIPAA compliance requirements do not pause for sprint boundaries. A security template change, a FHIR API access grant, or a clinical documentation configuration that touches PHI must go through the organization’s privacy and security review process regardless of which sprint it falls in. SAFe programs running Epic must integrate compliance review into the Definition of Done rather than treating it as an external gate that is consulted after development is complete.

The Definition of Done for Epic build Stories should include compliance checkpoints explicitly. A Story that involves a security template change must not be marked Done until the privacy officer has reviewed the access grant for HIPAA minimum necessary compliance. A Story that involves a new FHIR API connection must not be marked Done until the BAA status for the connected application has been confirmed. These checks are not optional gates that slow down delivery – they are part of what “done” means for healthcare IT delivery under HIPAA.

Some compliance work does not fit into a Story or Feature at all – it is enabling infrastructure that makes compliant delivery possible. Security architecture review, audit log monitoring program setup, and HIPAA risk assessment updates are examples of work that should be classified as SAFe Enablers and managed in the team backlog alongside functional Stories. Treating compliance work as non-backlogged overhead makes it invisible in planning and allows it to be de-prioritized under schedule pressure – which is how HIPAA gaps accumulate in Epic programs.

What Analysts and Product Owners Do on Epic ART Teams

The analyst role in an Epic SAFe program is more expansive than in a traditional Epic waterfall program – and more demanding. In a waterfall Epic implementation, analysts build to a design document and hand off to testers. In a SAFe program, analysts own Story definition, acceptance criteria, build, and demonstration within the same sprint. The analyst is simultaneously the builder and the first validator of the work they produce.

Product Owners on Epic ART teams must have enough Epic domain knowledge to write meaningful acceptance criteria and to evaluate whether a completed build actually meets the Story’s clinical intent. A product owner who cannot open Epic’s test environment and verify that a build analyst’s completed configuration produces the correct clinical workflow outcome is not able to perform the PO’s core function. For Epic programs, PO roles are often filled by senior analysts or clinical informatics professionals rather than by general Agile practitioners without Epic experience. The BAT vs UAT methodology that the PO uses to verify Epic Stories before marking them Done is described in the BAT vs UAT guide.

Measuring ART Performance for Epic Programs

Standard SAFe ART metrics apply to Epic programs but require healthcare-specific calibration. PI Predictability – the ratio of completed PI objectives to committed PI objectives – is the primary ART-level performance metric. Feature completion rate by sprint tracks whether teams are delivering Features at a sustainable pace. Business Value delivered per PI is the metric that clinical and operational leadership care about most and that connects ART output to health system outcomes.

The post-go-live optimization program where these ART metrics apply over time is described in the Epic Post-Go-Live Optimization guide. The go-live support phase that the ART’s early PIs support is covered in the Epic EHR Go-Live Support framework.

Common Failures When Applying SAFe to Epic Programs

Authoritative References

• Scaled Agile Framework (SAFe) – ART Structure, PI Planning, Feature and Story Definition, and ART Performance Metrics
• IIBA BABOK v3 – Stakeholder Engagement, Requirements Life Cycle Management, and Solution Evaluation in Agile Contexts

Downloads: Epic SAFe ART Templates