Information States for Allocation Updates

Why an Allocation Update Needs a Defined Information State

An adaptive trial may assign participants to treatment arms using information accumulated during the study. But “the information available” is not self-defining. A participant might already be enrolled while their outcome is not yet recorded; another participant might have an outcome recorded after the data cutoff for the current decision. If these statuses are blurred, an update can use information that was not available when the decision was made, or count a pending outcome as though it were known.

An information state is a dated, auditable description of the trial data available to an allocation decision. It says which participants have been enrolled, which arm each was assigned to, which outcomes and other variables have actually been recorded by the cutoff, and which enrolled participants still have outcomes pending. The state is a snapshot for a particular decision, not a claim that the data will remain unchanged.

The cutoff may be a scheduled date, a specified enrollment milestone, or another protocol-defined trigger. Whatever rule is used, it must be possible to determine which records qualified for the update. The state should reflect the data actually available under that rule, rather than data that could be obtained later or inferred from a participant’s treatment assignment.

Partition Enrolled Participants by Outcome Status

For update \(t\), let \(\mathcal{I}_t\) be the set of participants enrolled by cutoff \(c_t\). For a prespecified outcome, divide this set into those with an outcome recorded by the cutoff, \(\mathcal{O}_t\), and those whose outcome is still pending, \(\mathcal{P}_t\). If every enrolled participant is classified as either observed or pending for that outcome, the sets are disjoint and together make up the enrolled set.

“Pending” has a specific bookkeeping meaning here: the outcome is not available by the cutoff. It is not the same as a recorded outcome of zero, no response, no event, or treatment failure. Likewise, a participant who has withdrawn or whose outcome is permanently missing should not silently be labelled pending if the protocol’s status definitions classify that case differently. The categories used in the snapshot must follow the trial’s outcome and data-status definitions.

For each arm \(a\), let \(n_{a,t}\) be the number enrolled by the cutoff, \(r_{a,t}\) the number with the outcome observed, and \(q_{a,t}\) the number with that outcome pending. Under the two-status partition above, the arm-specific accounting check is \(n_{a,t}=r_{a,t}+q_{a,t}\). These counts answer different questions: \(n_{a,t}\) describes allocation to the arm so far, while \(r_{a,t}\) describes how many outcomes are currently available for an outcome-based summary.

From Participant Records to Arm-Specific Summaries

An arm-specific summary is a compact description calculated from the records in an information state. Which summaries are useful depends on the endpoint and the planned analysis. For a binary endpoint, useful bookkeeping summaries include the number observed and the observed event count. For a continuous endpoint, they might include the number observed, the sum, and a measure of spread. For a time-to-event endpoint, an analysis may need event times and censoring information; a simple count of events alone generally does not preserve all relevant information.

A summary is not automatically a sufficient summary for every statistical model. Aggregation is safe for a particular analysis only when the retained summaries preserve the information that analysis requires. For example, with independent binary outcomes and a common event probability \(p_a\) for all observed participants in arm \(a\), the likelihood contribution from the observed outcomes is determined by the number observed and the number of events. The observed record can then be summarized by those counts for that likelihood. If the model uses participant-level covariates or varying probabilities, the same two counts may not retain what the model needs.

where \(s_{a,t}\) is the number of observed events in arm \(a\). This expression is conditional on the specified independent Bernoulli model and refers only to outcomes observed by the cutoff. Pending outcomes do not appear as observed events or observed non-events in these counts. That bookkeeping fact does not mean the pending participants have no outcomes; it means their outcomes are not yet available in this snapshot.

A Short Justification for the Accounting Checks

The participant-level record is the basis for the snapshot. Each enrolled participant is assigned an arm and, for the endpoint in question, has one status at the cutoff. If the protocol’s status categories for this purpose are “outcome observed” and “outcome pending,” each participant contributes to exactly one of those two groups. Counting participants by arm therefore gives the identity between enrolled, observed, and pending counts.

This justification depends on accurate enrollment, assignment, and outcome-status records, and on a clear endpoint definition. If there are additional statuses, such as permanent missingness or withdrawal, the two-group identity must be extended to include them; it should not be forced to hold by relabelling those cases. If a participant can contribute more than one record, the unit being counted must also be specified so that the counts do not mix participants and measurements.

Choosing Between Records, Summaries, and Update Conventions

Keeping participant-level records and keeping arm-level summaries serve different purposes. Participant-level records make it possible to audit the cutoff, check outcome status, and calculate different summaries when the analysis requires them. Arm-level summaries are concise and can be useful for documenting an update, provided they retain all information needed by the planned analysis. A robust workflow keeps the underlying records and treats the summary as a reproducible calculation, rather than as a replacement for the data.

An update may be based on a calendar-time cutoff or on a prespecified enrollment milestone. Either can define an information state, but the rule must be explicit and applied consistently. A cutoff that is vague, changed after seeing outcomes, or applied differently across arms makes it difficult to determine what information was eligible for a decision. The state itself describes what was available; it does not choose an allocation rule or imply that any particular rule is preferable.

Useful checks before an update include confirming that each enrolled participant appears once, arm counts reconcile with the enrollment log, observed and pending records match their timestamps and status definitions, and arm-specific outcome totals reconcile with the observed records. Review whether the summary matches the endpoint type and analysis model. For example, a count of observed binary events is not a valid substitute for recorded event times in a time-to-event analysis.

The principal limitation is that a snapshot can be accurate as a record of available information while still being an inadequate summary for an analysis. A mean and sample size, for example, do not retain the ordering of observations or their relationship to covariates. Similarly, an outcome marked observed does not guarantee that it was measured correctly or that the endpoint definition was followed. Data-quality checks and model assumptions remain necessary.

Common Mistakes and Corrections

• Wrong: “There are 12 participants in the arm, so the outcome summary uses 12 observations.” Correction: State both the enrolled count and the observed-outcome count. Calculate an outcome summary using only outcomes available by the cutoff.
• Wrong: “A pending participant has no event recorded, so count that participant as a non-event.” Correction: Lack of a recorded outcome is not a value of zero. Keep the participant in the pending count until the status is resolved under the protocol.
• Wrong: “The arm’s event count and sample size are sufficient summaries for any endpoint model.” Correction: Sufficiency depends on the model and endpoint. Check that aggregation retains every data feature the planned analysis uses.
• Wrong: “An outcome recorded after the meeting can be included because it arrived on the same day.” Correction: Apply the stated cutoff. Information first available afterward belongs to a later snapshot.