Constructing Interim Data Snapshots

Why Interim Snapshots Need an Explicit Definition

A simulated trial can generate outcomes for every participant before any analysis is run. That convenience creates a subtle risk: if a stage-specific dataset is built from the completed simulation rather than from the information available at the interim time, it can include outcomes that would not yet have been known. The simulated decision then uses future information and does not represent the intended trial.

An interim snapshot is a reproducible representation of the trial data available at one specified analysis time. It is not necessarily just “everyone enrolled by then.” For a fixed-follow-up endpoint, a participant may have enrolled before the interim but still be waiting for follow-up. Conversely, if the analysis plan permits partial follow-up or uses an event-driven endpoint, what counts as available must follow that plan.

Before constructing snapshots, specify the simulated trial’s analysis schedule, the population being analyzed, the endpoint, and the rule for when that endpoint becomes available. Also specify how the simulation represents data cutoffs, withdrawals, and missing outcomes. These are design choices, not details that a filtering operation can decide for you.

Representing What Was Available

A useful simulated record has, at minimum, a unique participant identifier, assigned arm, enrollment or randomization time, endpoint value if observed, and a time at which that endpoint became available to the interim analysis. The availability time is distinct from the event time or the end of follow-up: a value might be observed earlier but not entered and available by the analysis cutoff. In a simulation that assumes immediate reporting, the two times can coincide; that assumption should be explicit.

Let \(t_k\) be the data cutoff for interim \(k\), and let \(A_i\) be the time participant \(i\)'s endpoint is available. For an analysis that requires the endpoint to be observed, define the eligible endpoint set as

A roster snapshot may instead include all participants randomized by \(t_k\), including those whose endpoints are not yet available. Keep that roster distinct from \(D_k\). Whether participants with unavailable or missing outcomes enter a particular estimator depends on the analysis plan; they must not be silently treated as observed outcomes.

For a fixed-follow-up endpoint, one common rule is to include only participants whose required follow-up is complete and whose endpoint is available by the cutoff. For an event-driven endpoint, the rule may concern observed events or a prespecified information target. Do not substitute one rule for another just because it is easier to implement. The stage times and information fractions established for the simulation should be translated into a precise data cutoff and eligibility rule.

Constructing Cumulative Snapshots and Stage Increments

If each interim uses all eligible outcomes available by its cutoff, the snapshots are cumulative. For ordered cutoffs \(t_1\leq t_2\leq \cdots\), and consistent population and availability rules, a participant eligible at an earlier cutoff remains eligible at later cutoffs. Therefore \(D_1\subseteq D_2\subseteq\cdots\). The stage increment after interim \(k-1\) is the set of newly eligible records, \(I_k=D_k\setminus D_{k-1}\). For the first interim, take \(I_1=D_1\).

This set-based construction gives a direct consistency check: \(D_k\) should be the union of the increments through stage \(k\), and the increments should not overlap. The argument is simple. Each record in \(D_k\) is either already in \(D_{k-1}\) or newly enters through \(D_k\setminus D_{k-1}\); by definition it cannot be in both the prior set and the difference. Repeating this partition yields

This identity depends on a stable definition of eligibility and a consistent data history. If the protocol changes the analysis population, or if a previously recorded outcome is corrected, simple nesting may not hold for the stored versions of snapshots. In that case, retain versioned data and document the change rather than forcing the sets to appear nested.

A Practical Construction and Its Checks

A reliable workflow starts from an immutable simulated-data table and creates a separate snapshot for each cutoff. First determine the cutoff and eligibility rule from the design. Then select the analysis population, apply the availability rule, and preserve enough identifying information to audit the result. Compute summaries only after the selected records have passed validation.

Several diagnostics are especially useful. Check that every endpoint in an analysis snapshot has availability time no later than its cutoff. Check that each randomized participant has a single stable identifier and arm assignment. Tabulate roster counts and observed-endpoint counts separately, by arm and interim. If a cumulative analysis is intended, verify set nesting and reconcile cumulative counts with increments. Finally, inspect participants near the cutoff: boundary errors often arise from mixing inclusive and exclusive time comparisons, or from using dates with inconsistent time zones or rounding.

A missing endpoint is not the same as an endpoint that is merely unavailable at the cutoff. The first may represent loss to follow-up, a data-generation failure, or a genuinely missing measurement; the second is pending information. Preserve that distinction in the data and apply the intended missing-data or analysis rule. Do not replace either status with an invented numeric value or silently drop it without documenting the rule.

Comparing Snapshot Strategies and Their Limits

A cumulative snapshot is appropriate when an interim analysis uses all eligible information accumulated to date. An increment-only dataset is useful for representing new information between analyses, but it is not a substitute for the cumulative analysis set unless the analysis is specifically defined on new records alone. A roster snapshot answers a different operational question: who has entered the trial by the cutoff? It should not be mistaken for the endpoint analysis dataset.

One alternative is to filter the full final dataset separately for each interim. This is concise, but it is safe only if each filter uses the correct historical availability fields and does not use final values to decide interim eligibility. Another alternative is to save a materialized snapshot when each interim is reached. This can aid auditability, but it requires explicit versioning and can become inconsistent if records are later corrected. In either approach, the defining principle is the same: reproduce the information available under the specified data lock.

Snapshots do not determine which treatment arms should continue, what test should be applied, or how a terminal decision is made. They supply the stage-appropriate data for those later operations. They also cannot repair an incorrectly specified accrual process, endpoint model, missingness mechanism, or analysis population. Their value is narrower but essential: they prevent a simulation from giving an interim analysis data it could not yet have used.

Common Mistakes

• Using enrollment time alone. This includes participants whose required outcomes are still pending. Apply the endpoint-availability rule as well as any enrollment or randomization criterion.
• Filtering on final outcome status. A final dataset may reveal values that were not available at the interim. Use time-stamped availability and the interim cutoff.
• Confusing an increment with a cumulative snapshot. New records since the last interim do not include earlier eligible records. Reconstruct the cumulative set when the analysis requires accumulated data.
• Equating missing with pending. Pending outcomes may become available later; missing outcomes require the prespecified handling rule. Keep the statuses distinct.
• Checking only record counts. Equal counts can still hide a duplicated participant and a missing participant. Validate identifiers and membership, not just totals.