Epic IVT: Integrated Validation Testing Explained – How It Works and Who Owns What

Epic Integrated Validation Testing (IVT) is misunderstood more often than any other phase in an Epic implementation. Most analysts know their own module – they build and test in isolation. What they do not understand until it fails is that clinical workflows cross module boundaries constantly, and a defect in one module’s build silently breaks workflows in three others. This article explains exactly what IVT is, how it differs from unit testing, what each analyst role owns during an IVT cycle, and what the most common cross-module failure patterns look like before they become go-live incidents.

What Is Epic IVT?

Epic Integrated Validation Testing (IVT) is the structured testing phase that validates end-to-end clinical and operational workflows across multiple Epic modules simultaneously. It is not a test of individual module builds. It is a test of whether those builds work correctly together when a patient flows through a real clinical sequence – from registration through clinical care through billing.

The ISTQB (International Software Testing Qualifications Board) defines system integration testing as testing that verifies interoperability between integrated components. IVT is exactly that in the Epic context. In the ISTQB framework, unit testing validates individual components in isolation. System integration testing validates that those components communicate and interact correctly. IVT is Epic’s system integration testing phase – the point at which analysts stop testing their own module and start testing the seams between modules.

Epic implementations typically run IVT in three cycles – called Cycle 1, Cycle 2, and Cycle 3 – before dress rehearsal. Each cycle runs complete patient workflow scenarios from start to finish. Defects found in earlier cycles are remediated before the next cycle runs. By Cycle 3, the expectation is that the system performs the defined workflows without critical failures. The full module architecture that IVT connects is described in the Epic EHR Learning Hub.

IVT vs Unit Testing: The Critical Difference

Unit testing in Epic validates individual build objects in isolation. A Prelude analyst tests that the EMPI matching logic produces the correct outcome for a test patient. A Cadence analyst tests that a provider template has the correct slot configuration. A Willow analyst tests that a drug record has the correct dosing algorithm. These tests are necessary. But they do not validate that the system works end to end.

IVT tests the handoff points. When a Prelude registration creates a patient record and fires an ADT A04 message, does that message arrive in the correct downstream systems? When a provider places a lab order in CPOE, does it route correctly to the Beaker LIS, generate the right charge trigger in Resolute, and produce a result that flows back to the provider’s in-basket? When a pharmacist verifies a medication in Willow, does the nursing eMAR reflect the correct administration window? None of these questions can be answered by unit testing alone.

The gap between unit testing completion and IVT readiness is where most Epic implementations experience their first shock. A module that passed all its unit tests may fail IVT immediately – not because the build is wrong within that module, but because the interface between that module and the next one was never tested. Build analysts who have never participated in a cross-module testing exercise often underestimate how many seam-level defects exist in a fully built but unintegrated Epic environment.

IVT Cycle Structure: How Three Testing Rounds Work

Each IVT cycle follows a defined structure: environment preparation, script execution, defect logging, triage, remediation, and sign-off. The three cycles are not repetitions of the same test. They are progressively more complete and more stable versions of the same end-to-end workflows.

Cycle 1: First Pass – Find the Critical Breaks

Cycle 1 is the first attempt to run end-to-end patient workflow scenarios in the integrated environment. Expectations for Cycle 1 are intentionally low. Critical defects are expected – interfaces that are not connected, workflow steps that do not advance correctly, ADT messages that do not fire. Cycle 1’s purpose is to surface all critical failures so they can be prioritized and resolved before Cycle 2.

Cycle 1 test scripts cover the most fundamental workflows – patient registration, inpatient admission, basic order placement and resulting, medication administration, and discharge. Complex edge cases and specialty-specific workflows are typically deferred to Cycle 2 or 3. The Cycle 1 defect list is expected to be long. An organization that completes Cycle 1 with zero defects either has an unusually well-built system or did not test thoroughly enough.

Cycle 2: Remediation Verified – Expand Coverage

Cycle 2 runs after Cycle 1 defects are remediated and verified. Its purpose is twofold: confirm that critical Cycle 1 defects are actually fixed (regression testing), and expand test coverage to more complex clinical scenarios. Specialty workflows, order set testing, advanced medication administration scenarios, and specialty billing paths are added in Cycle 2.

Cycle 2 is also when interface-specific testing intensifies. ADT message timing, lab result turnaround, pharmacy dispensing workflows, and billing charge trigger testing all receive focused attention in Cycle 2. The defect list from Cycle 2 should be shorter than Cycle 1 and should not contain any critical defect categories that were identified and resolved in Cycle 1. If the same class of defect reappears in Cycle 2, the remediation in Cycle 1 was insufficient.

Cycle 3: Stability Confirmation and Go-Live Readiness

Cycle 3 is the stability cycle. Critical and high-priority defects from Cycles 1 and 2 must be resolved before Cycle 3 begins. Cycle 3 runs the complete workflow scenario library – all patient types, all service lines, all order types, all disposition paths. The Cycle 3 pass rate determines whether the organization is ready to proceed to dress rehearsal. A Cycle 3 with unresolved critical defects means the dress rehearsal is premature.

Dress rehearsal follows a successful Cycle 3. Dress rehearsal simulates go-live day operations in the production environment – data conversion validation, interface activation sequence, user login at scale, and command center procedures. Dress rehearsal does not introduce new test scenarios. Everything tested in dress rehearsal should already have passed in Cycle 3. The connection between IVT results and go-live readiness is covered in the Epic EHR Go-Live Support framework.

IVT Workflow Scenarios: What Gets Tested

IVT workflow scenarios are end-to-end patient journeys. Each scenario starts at a clinical entry point (registration, ED arrival, direct admission) and follows the patient through every Epic module touchpoint until the encounter is complete and billing is triggered. A scenario is not complete until the last step fires correctly – not until the test gets stuck.

Core Workflow Scenarios Every IVT Must Cover

The inpatient admission scenario is the most cross-module intensive workflow in any Epic implementation. It touches Prelude (registration), Cadence (if pre-scheduled), Grand Central (bed assignment), the ADT interface, the clinical modules (CPOE, nursing documentation, pharmacy), Beaker (laboratory), the ADC interface, Willow (pharmacy verification), eMAR (medication administration), and Resolute (billing). A single patient flow from ED registration through inpatient discharge and final charge generation tests fifteen or more interconnected build elements simultaneously.

The medication administration loop is a specific sub-scenario that tests the CPOE-to-bedside workflow. A provider places a medication order in CPOE. Willow pharmacy verifies it. An ADC cabinet dispenses it. The nurse scans the patient wristband and medication barcode at BCMA. The eMAR records the administration. A charge fires to Resolute. If any link in this chain breaks, the scenario fails. CPOE workflows and the order-to-administration sequence are covered in depth in the Epic EHR Orders and CPOE guide.

Interface-Specific Scenarios in IVT

Interface testing within IVT validates that ADT messages, lab order/result messages, SIU scheduling notifications, and billing charge transactions transmit correctly and are processed by receiving systems. These are not separate interface tests – they are embedded in the end-to-end workflow scenarios. When the Prelude analyst registers a patient, the integration analyst simultaneously monitors the Bridges interface monitor to confirm the ADT A04 fires. When the CPOE analyst places a lab order, the Beaker analyst confirms it arrives in the LIS queue.

This is why IVT requires all relevant analysts to be present simultaneously during scenario execution – not running tests asynchronously and comparing notes afterward. A workflow step in one module that produces no visible error but fails to trigger the correct downstream action is undetectable unless someone is watching the downstream system at the exact moment the upstream action occurs.

Analyst Responsibilities by Module During Epic IVT

Every analyst role has distinct responsibilities during IVT. Understanding exactly what each role owns – and where handoffs occur between roles – is the single most important organizational clarity a project team can establish before IVT begins. When responsibilities are ambiguous, defects fall through cracks at handoff points.

Common Cross-Module Failure Patterns in Epic IVT

The same categories of cross-module failures appear in nearly every Epic IVT program, regardless of hospital size, Epic version, or implementation scope. Knowing these patterns in advance allows project teams to prioritize test scenarios and monitor specifically for them in Cycle 1.

Defect Management and Remediation During IVT

Every defect found during IVT must be logged, triaged, assigned, and tracked to resolution. Defect management during IVT is not optional overhead – it is the mechanism that ensures problems found in testing actually get fixed before go-live. An IVT cycle that produces a long list of defects without a systematic remediation process produces the same list again in the next cycle.

Defect Severity Classification

IVT defects are classified by severity: Critical, High, Medium, and Low. Critical defects block patient care workflow entirely – a medication cannot be ordered, a patient cannot be registered, a result cannot post. Critical defects must be resolved before the next IVT cycle begins. High defects significantly impair a workflow but have a workaround – a report gives wrong data but the clinical workflow proceeds. High defects must be resolved before dress rehearsal. Medium and Low defects are cosmetic or minor – wrong label on a button, incorrect default value in a non-critical field. These may be deferred to post-go-live if resource constraints require it.

The ISTQB defect severity model aligns directly with this framework. ISTQB defines severity as the degree to which a defect affects the operation of a product – exactly the question build teams must answer for each IVT defect. Applying structured severity classification prevents the common IVT dysfunction where all defects are logged as “critical” because every analyst considers their own module’s issues to be the most important ones.

Defect Log Structure and Ownership

Every IVT defect log entry must contain: a unique defect ID, the IVT cycle in which it was found, the test scenario and step where it occurred, the observed behavior, the expected behavior, the severity classification, the module(s) affected, the assigned owner, the remediation action taken, and the verification status. A defect log without remediation action and verification status is a list of complaints, not a managed process.

Defect ownership must be assigned to the module analyst responsible for the fix – not to the analyst who discovered the defect. A Beaker analyst who discovers that a lab order is not routing correctly from CPOE logs the defect. But the defect is assigned to the CPOE analyst whose order routing rule is misconfigured. The integration analyst may need to assist both. Clear ownership prevents defects from sitting in a “team” ownership state where nobody acts.

Clinical Validation: The Role of SMEs in Epic IVT

IVT without clinical subject matter experts (SMEs) validates that the system does what the build says. It does not validate that the build says the right thing clinically. A Willow analyst can confirm that a medication order routes to the pharmacy queue and the pharmacist can verify it – but only an oncology pharmacist can confirm that the chemotherapy dosing formula in the treatment plan is clinically correct. Clinical SME involvement in IVT is what distinguishes technical acceptance testing from clinical safety validation.

The BABOK v3 framework for Business Analysis describes acceptance testing as a collaborative process involving stakeholders who can verify that requirements are met. In Epic IVT, the clinical stakeholders – physicians, nurses, pharmacists, department managers – are the acceptance authority. Their role during IVT is to observe the system executing clinical workflows and confirm that the outcomes are clinically appropriate. When a physician observes that a CDS alert fires for a routine clinical scenario that should not trigger an alert, that is a clinically significant defect that a build analyst alone would not recognize as a problem.

The relationship between BAT (Business Acceptance Testing) and IVT is important to understand. BAT in Epic is the clinical and operational acceptance gate – can the clinical staff complete their actual workflows using the system? IVT is the technical integration gate – do the modules work together correctly? Both are necessary and both are part of the overall pre-go-live validation program. The distinction between BAT and UAT methodologies, and how each applies in the Epic context, is covered in depth in the BAT vs UAT guide. Clinical documentation workflows that SMEs validate during IVT are described in the EpicCare Inpatient ClinDoc guide.

From IVT to Dress Rehearsal and Go-Live

The transition from IVT to dress rehearsal is gated. An organization that attempts dress rehearsal before completing a successful Cycle 3 is running production simulation in a system that has known critical defects. This does not save time – it generates a failed dress rehearsal, which demoralizes the team and delays the go-live date.

Dress rehearsal focuses on three things that IVT does not: data conversion validation (are migrated patient records correct in the production environment?), interface activation sequence (can the team activate all Bridges interfaces in the correct order without errors?), and user access at scale (can all user accounts log in and access the correct modules?). These are dress rehearsal-specific activities. They do not belong in IVT and should not consume IVT cycle time.

The IVT-to-go-live continuity requires that every analyst who participated in IVT also participates in the go-live command center for the first 72 hours. IVT gave them direct experience with what the system’s failure modes look like. When an interface fails on go-live day, the analyst who recognized the same failure pattern in Cycle 1 can diagnose and resolve it faster than anyone else. The organizational knowledge built during IVT is one of the most valuable assets an implementation team produces.

IVT Governance, RACI, and Documentation Standards

IVT requires a defined governance structure to function. Without it, cycles run without consistent participation, defects are not tracked systematically, and cycle completion criteria are not enforced. The IVT governance structure defines who is accountable for each component of the testing program, how defects are escalated, and what the exit criteria are for each cycle.

RACI Matrix for IVT Key Activities

R = Responsible, A = Accountable, C = Consulted, I = Informed

IVT Exit Criteria and Go-Live Gate

IVT exit criteria must be defined before the first cycle begins – not after Cycle 3 when the project is under pressure to declare readiness. Typical IVT exit criteria include: zero unresolved critical defects, high defect resolution rate above a defined threshold (commonly 95%+), all core workflow scenarios achieving a defined pass rate (commonly 90-95%+), and clinical SME sign-off obtained from all major service lines.

Projects that skip formal exit criteria for IVT cycles end up in a situation where the project manager declares IVT complete based on calendar date rather than quality gate achievement. This is how Epic implementations go live with known critical defects that were never resolved because the cycle ended before remediation was complete. Defined, enforced exit criteria are the only protection against this pattern.

Authoritative References

• ISTQB – Certified Tester Foundation Level Syllabus: System Integration Testing and Defect Classification
• IIBA BABOK v3 – Business Analysis Body of Knowledge: Acceptance and Evaluation, Stakeholder Engagement in Testing

Downloads: Epic IVT Templates and Tools