From an Event Target to an Analysis-Ready Date
An event-triggered look is tied to an event-count target, not to a date on the calendar. But reaching that target does not necessarily mean that the analysis can begin immediately. The count may need to be confirmed, and the analysis dataset may then need to be assembled. A plan that forecasts only when the target will be reached can therefore underestimate when results will be ready.
The timing plan should distinguish three dates: when the operational event count reaches its target, when that count is confirmed under the plan, and when the analysis dataset is ready. This tutorial focuses on translating the first date into the third. The earlier material on projecting event accrual and planning calendar dates supplies the event-date forecast; here, the key addition is an explicit allowance for operational lag.
The definition requires a precise operational meaning for \(N(t)\). For example, the plan might count events reported in the trial system, or it might count only events that have passed a specified confirmation step. These are different triggers and can occur on different dates. The plan must state which count defines \(D\); otherwise, “the target has been reached” is ambiguous.
If confirmation and dataset assembly are sequential, non-overlapping stages, write the total lag as \(L=L_C+L_A\), where \(L_C\) is the confirmation duration and \(L_A\) is the assembly duration. If tasks overlap, adding their durations overstates elapsed time; instead, use the measured total elapsed time from trigger to readiness, or model the overlapping stages explicitly. All durations must use the same time unit and calendar convention.
Assumptions and the Data-Cutoff Rule
A useful plan states the following assumptions before calculating a readiness date:
- Trigger definition: Specify the event definition, target \(D\), and whether the count is preliminary or already confirmed.
- Cutoff rule: Specify which events and follow-up information belong in the analysis dataset. One clear option is to freeze the analysis cutoff at the trigger time and use the operational lag only to prepare that frozen dataset.
- Lag convention: State whether durations are calendar days or working days, and whether stages are sequential or overlapping.
- Forecast interpretation: Distinguish a projected target date from the date the target is actually reached. A projection is uncertain; the event trigger itself is determined by observed accrual under the stated rule.
The cutoff rule matters because events may continue to accrue while confirmation and assembly are under way. If the dataset is frozen at \(T_D\), those later events do not change the event count or information for that look. If instead the analysis includes data through a later cutoff, the look may contain more than \(D\) events, and its information fraction may differ from the fraction associated with the target. That is a different analysis-timing rule and should be planned explicitly rather than arising accidentally from operational delay.
The simple equation \(R=T_D+L\) treats lag as a duration measured from the trigger and assumes that the dataset is usable at the end of that duration. If operational stages have uncertain durations, then \(L\) is uncertain too. If the event-date forecast is also uncertain, readiness uncertainty depends on both sources. A single expected date does not describe the chance of meeting a particular deadline.
Worked Example: Calculating Readiness From Sequential Stages
In a hypothetical trial, the planned operational count reaches \(D=120\) events on August 3. The plan requires four calendar days to confirm the count and seven additional calendar days to assemble the dataset. Assume the stages are sequential, the cutoff is frozen at the trigger, and the durations are fixed.
The total lag is
Therefore,
The event-triggered look occurs when the specified count reaches 120 on August 3, but the analysis is not ready until August 14. The eleven-day difference is operational lag, not additional follow-up required to reach the target. Under the frozen-cutoff assumption, events occurring after August 3 do not alter the dataset’s target count.
Justifying the Readiness Calculation Under Uncertainty
When target timing and lag vary, represent them as random quantities. If \(T_D\) is the random target-reaching time and \(L\) is the random operational lag, then \(R=T_D+L\) by definition. For any deadline \(c\), the relevant planning quantity is \(P(R\le c)\), the probability that the analysis is ready by that date. If \(T_D\) and \(L\) are independent and their distributions are known, the distribution of \(R\) follows by combining their possible values. Independence should not be assumed automatically: unusually high workload, for example, could affect both event processing and dataset assembly.
A useful expectation and variance identity follows from the sum rule. Under finite means and variances,
The mean readiness time is the sum of the mean target time and mean lag. The variance includes a covariance term, so variances can be added only if target time and lag are independent (or at least uncorrelated). Even when the mean is useful for summaries, a deadline decision generally needs a probability or a suitably chosen planning quantile, not just the mean.
Worked Example: Probability of Being Ready by a Deadline
Suppose a hypothetical projection assigns probability 0.60 to reaching the target in 8 weeks and probability 0.40 to reaching it in 10 weeks. The combined confirmation and assembly lag is 1 week with probability 0.50 and 2 weeks with probability 0.50. Assume these two quantities are independent and the data cutoff is fixed at the trigger.
The possible readiness times and their probabilities are:
| Target time | Lag | Readiness time | Probability |
|---|---|---|---|
| 8 weeks | 1 week | 9 weeks | 0.60 × 0.50 = 0.30 |
| 8 weeks | 2 weeks | 10 weeks | 0.60 × 0.50 = 0.30 |
| 10 weeks | 1 week | 11 weeks | 0.40 × 0.50 = 0.20 |
| 10 weeks | 2 weeks | 12 weeks | 0.40 × 0.50 = 0.20 |
For a deadline of 10 weeks, the first two outcomes meet the deadline. Thus,
The expected target time is \(0.60(8)+0.40(10)=8.8\) weeks, and expected lag is \(0.50(1)+0.50(2)=1.5\) weeks. Hence \(E(R)=8.8+1.5=10.3\) weeks, which also agrees with the readiness-time table:
The mean readiness time is later than the deadline, but the deadline probability is 0.60. Neither summary can replace the other: the mean does not say that readiness by week 10 is unlikely, and the probability does not give the average readiness time.
Turning the Timing Model into an Operational Plan
A plan should make the transition from the event trigger to an analysis-ready dataset actionable. In particular, the team needs a trigger rule, an owner for confirming that the rule has been met, a stated cutoff, and an estimated duration for making the frozen dataset available. The planned review date can then be based on the target-date forecast plus the lag allowance. If the target-date forecast is uncertain, scenario analysis or a deadline probability is more informative than adding lag to a single date without qualification.
State the target count, the event-count source, and whether the threshold is based on preliminary or confirmed events.
Specify the data included in the look and whether events accruing during the operational lag are excluded or included under a separately defined rule.
Use the stated calendar convention and account for sequential, overlapping, or uncertain stages without double-counting time.
Combine target-time and lag assumptions. For a deadline, calculate or estimate \(P(R\le c)\), rather than relying only on an average date.
Verify that staffing, review schedules, and the planned analysis date are consistent with the trigger and lag assumptions.
Worked Example: Checking Calendar Contingency
In a hypothetical study, the projected target date is October 1. The operational plan allows six calendar days for confirmation and five more calendar days for dataset assembly. A review meeting is scheduled for October 20. Assume the trigger date is October 1, the stages are sequential, and the cutoff is frozen on the trigger date.
The planned total lag is \(6+5=11\) calendar days, so the dataset is projected to be ready on October 12. The interval from October 12 to the October 20 meeting is eight calendar days. The meeting therefore has an eight-day buffer beyond the planned readiness date.
This arithmetic establishes only that the schedule contains the stated buffer under the assumed durations. It does not establish an eight-day statistical guarantee: if the target is reached later than October 1 or the operational stages take longer than planned, readiness may also be later. The plan should therefore check the target-date uncertainty and the possibility of longer lag before treating the meeting date as reliable.
Diagnostics, Alternatives, and Limitations
Several checks can reveal that a timing plan is internally inconsistent. Compare the trigger count named in the plan with the count that staff will actually monitor. Check whether each lag estimate starts at the same operational point and ends at the same definition of “ready.” Verify whether weekend and holiday time is included. Finally, compare the cutoff rule with the count used to set the look’s target: a frozen dataset at the trigger and a dataset that continues to accumulate events during the lag do not represent the same analysis timing.
The main alternative is a fixed-calendar-date look. A calendar-triggered analysis has a scheduled date, but the event count at that date may be above or below the intended target. An event-triggered look instead waits for a count threshold, so its calendar timing varies with accrual. A further operational choice is whether to trigger on a preliminary count and confirm afterward, or to trigger only once the specified number of events has already been confirmed. The former may allow earlier preparation but makes the lag and confirmation rule especially important; the latter gives a different trigger date and should be projected using that definition.
| Planning approach | What fixes the look | Main timing trade-off |
|---|---|---|
| Event-triggered | A specified event count | Calendar date varies; operational lag still affects readiness |
| Fixed-calendar-date | A prespecified date | Date is stable; event count at analysis may vary from the target |
| Confirmed-count trigger | The specified number of confirmed events | Trigger is defined by confirmation status; the date depends on when confirmation occurs |
A practical pitfall is to add the planned lag to the projected target date and then describe the result as the date the event target will be reached. That is wrong: the target date and readiness date answer different questions. The correction is to label them separately, for example, “target projected October 1; dataset projected ready October 12 under an eleven-day lag.” Another mistake is to count events accruing during the lag while still treating the analysis as though it were frozen at the target. The correction is to state the cutoff and use the event count corresponding to that cutoff.
Operational lag is not a substitute for uncertainty in event accrual, and a precise lag estimate cannot make an uncertain target-date projection certain. Nor does this timing calculation determine whether a group sequential boundary or information fraction is appropriate. Those analysis properties depend on the actual data and the prespecified analysis plan. The purpose of the timing model is narrower: to prevent a planned event threshold from being mistaken for immediate analysis availability.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A target is reached on March 6. Confirmation takes three calendar days and dataset assembly takes four more calendar days. Assuming sequential stages, when is the dataset ready?
- A plan freezes data at the instant the target count is reached. Events accrue during the following ten days of assembly. Should those later events be included in that look’s event count under the stated rule? Explain.
- The target date is 6 weeks from now with probability 0.70 and 8 weeks from now with probability 0.30. The lag is fixed at 2 weeks. What is the probability that the analysis is ready by week 8?
- Why is it generally insufficient to report only the mean readiness time when deciding whether a scheduled review deadline is feasible?
Solutions. (1) The total lag is \(3+4=7\) calendar days, so readiness is March 13. (2) No. The cutoff is frozen at the target time, so events accruing afterward are excluded from that look under the stated rule. (3) Readiness occurs at week 8 with probability 0.70 and week 10 with probability 0.30; therefore \(P(R\le 8)=0.70\). (4) A mean does not give the probability of being ready by a particular deadline. The distribution of readiness, or at least a relevant deadline probability or quantile, is needed to assess that decision.