From an Allocation Idea to an Implementable Rule
A delayed-outcome allocation rule is not operational until staff can determine, for every participant, which outcome information is eligible to affect the next assignment. A protocol must settle questions that a formula alone leaves open: What counts as a resolved response? When is the data snapshot taken? Are pending responses predicted, ignored, or awaited? What happens if the scheduled update cannot be produced?
The protocol below is a concrete two-arm example for a binary endpoint. Its choices are illustrative, not a universal recommendation. The earlier material on delayed-data allocation calculations establishes why update timing and the set of observed responses matter; the purpose here is to make those choices explicit enough to implement and audit.
Specify the Outcome Before the Update Rule
Consider a hypothetical trial with treatments A and B and a binary endpoint, confirmed response at day 30. Suppose success is defined as meeting a prespecified clinical threshold on an assessment performed from day 28 through day 32. Death before the assessment window counts as failure. A response is resolved when the assessment and any required adjudication are complete and the status is recorded as success or failure.
A participant whose day-30 window has not yet occurred has a pending response, not a failure. If the window has passed but the assessment is absent or a data query remains open, the response remains pending during a defined query period. In this example, day 45 after enrollment is the resolution deadline. If the status is still unknown then, it is classified as missing for the allocation update, not automatically converted to failure. A protocol may choose a different endpoint and deadline, but it must define them before assignments are made.
The allocation calculation below uses resolved outcomes only. It relies on a working model in which, within each arm, binary responses are independent with a stable success probability, and the resolved responses are representative of the arm’s enrolled participants. The second condition can fail if resolution depends on the unobserved response or is associated with prognosis. Excluding pending and missing outcomes does not itself correct such selection. The protocol therefore needs monitoring and a contingency, not just a formula.
A Fully Specified Example Rule
For clarity, the illustrative rule has a 20-participant burn-in with equal assignment probabilities. After burn-in, assignments are issued in cohorts of four. A data snapshot is taken at 17:00 local time each Friday before a new cohort opens. All four assignments in that cohort use the same probabilities, calculated from the snapshot; outcomes resolving during the cohort are not used until the next scheduled update.
Let \(n_A\) be the number of resolved responses on A in the snapshot, and let \(y_A\) be the number of those responses that are successes. Define \(n_B\) and \(y_B\) in the same way. Pending and missing responses are not included in these counts. For each arm, use a Beta(1,1) prior for its binary success probability. The resulting smoothed estimate is the posterior mean:
If at least 10 responses are resolved on each arm, calculate the raw probability for A as \(\tilde p_A/(\tilde p_A+\tilde p_B)\). Limit the probability to the interval from 0.20 to 0.80: values below 0.20 are set to 0.20, values above 0.80 are set to 0.80, and values inside the interval are unchanged. The probability for B is one minus the probability for A. If either arm has fewer than 10 resolved responses, use equal probabilities for the next cohort. The minimum-information rule avoids basing the adaptive step on extremely sparse resolved data; it does not guarantee accurate estimates.
Why the Smoothing and Allocation Calculation Work
The calculation starts with a simple binomial model for each arm. For an arm with success probability \(\theta\), \(y\) observed successes among \(n\) resolved responses have likelihood proportional to \(\theta^y(1-\theta)^{n-y}\). A Beta(1,1) prior has density 1 over probabilities from 0 to 1. Multiplying likelihood and prior gives a Beta posterior with parameters \(y+1\) and \(n-y+1\). The mean of a Beta distribution with parameters \(a,b\) is \(a/(a+b)\), giving:
The added one success and one failure prevent an estimate of exactly 0 or 1 when a small sample happens to contain only failures or only successes. They are a declared smoothing choice, not extra observed participants. The subsequent proportional rule assigns more probability to the arm with the higher smoothed response rate, before the probability limits are applied. That is an allocation convention, not a claim that the rule is optimal for every trial objective.
Worked Example: Writing the Snapshot and Pending-Response Rule
At a Friday cutoff, 32 participants have been enrolled. Of the 16 assigned to A, 11 have a resolved day-30 status: 7 successes and 4 failures. The other 5 have not yet reached day 45, and their assessments or queries are still pending. Of the 16 assigned to B, 12 are resolved: 6 successes and 6 failures; 4 remain pending.
The snapshot therefore records \(n_A=11,\ y_A=7,\ n_B=12,\ y_B=6\). It does not record 16 as the resolved sample size in either arm, and it does not code the nine pending responses as failures. Both arms meet the minimum of 10 resolved responses, so the adaptive calculation can proceed.
The remaining four participants are assigned using the probabilities calculated from this Friday snapshot, even if a pending response resolves while those assignments are being made. That outcome enters the following scheduled snapshot, not the current one. This fixed rule prevents the cohort’s allocation probability from changing midway through its assignments.
Worked Example: Calculating a Cohort’s Allocation Probabilities
In a hypothetical later snapshot, A has 12 successes among 20 resolved responses, while B has 8 successes among 18 resolved responses. Additional enrolled participants have pending outcomes, so they are not counted.
The smoothed success estimates are:
The raw probability of assigning A is:
This is between 0.20 and 0.80, so the cap does not change it. Thus \(P(A)=0.5677\) and \(P(B)=1-0.5677=0.4323\) for the next cohort of four. For one assignment, suppose the randomization system draws \(u=0.61\) from a uniform distribution on \([0,1]\), assigning A if \(u<0.5677\) and B otherwise. Since \(0.61\) is not less than \(0.5677\), that participant is assigned to B. The random draw, the probability in force, the snapshot identifier, and the resulting assignment should be recorded.
Schedule the Steps and Define the Fallback
A protocol should give the allocation team and the data team the same operational sequence. The following sequence is one way to state the rule without leaving timing decisions to informal judgment.
During the first 20 assignments, use probability 0.50 for A and 0.50 for B. Afterward, issue assignments in cohorts of four.
Apply the day-30 endpoint definition, assessment window, query process, and day-45 deadline. Keep not-yet-due or queried outcomes pending; do not label unknown status as failure.
At 17:00 on the scheduled Friday, extract the resolved statuses available at that cutoff. Record arm-specific counts and the number pending, missing, or under query.
If both arms have at least 10 resolved responses, apply the smoothing, proportional allocation, and probability limits. If not, use 0.50 for each arm.
Hold the probabilities fixed for the next four assignments. If a valid snapshot is unavailable at cutoff, use 0.50 for each arm, log the reason, and do not reconstruct assignments after the fact.
The fallback is not permission to keep adapting from an unreliable stale snapshot. In this example, adaptation is paused and equal-probability randomization continues if the data feed or calculation is unavailable at cutoff, if a material discrepancy is found in the arm-level counts, or if more than 20% of participants whose day-45 deadline has passed still lack a resolved status. A responsible trial team should specify who verifies the problem, how it is documented, and what conditions must be met before adaptive updates resume. A restart should use a new validated snapshot and the same prespecified algorithm, not a retrospectively chosen probability.
Worked Example: Applying a Feedback-Unavailable Contingency
Suppose a scheduled Friday snapshot cannot be validated because the response feed is unavailable. The next cohort is ready to enroll, and the most recent valid adaptive probability was \(P(A)=0.62\). The protocol says that a current snapshot must be available at the cutoff; it does not authorize reusing the previous adaptive probability.
The contingency therefore sets \(P(A)=0.50\) and \(P(B)=0.50\) for all four assignments in the next cohort. Each assignment is still randomized using those probabilities. The allocation log records the missed cutoff, the fallback probabilities, and the cohort affected. Once the data feed is restored, the team reconciles and validates the data, checks the unresolved-outcome threshold, and calculates the next scheduled update from a valid snapshot. It does not revise the four assignments already made.
If a subsequent quality check finds 9 unresolved responses among 30 participants whose day-45 deadlines have passed, the unresolved proportion is \(9/30=0.300\), or 30%. This exceeds the 20% threshold, so the protocol’s pause condition is met even if the data feed is working. Equal-probability assignment continues while the issue is reviewed.
Diagnostics, Alternatives, and Limitations
At each update, monitor whether the rule is being applied to the intended data. Useful checks include matching the arm-specific success and resolved counts to the source records; confirming that pending cases have not entered the calculation; checking that probabilities sum to 1 and lie within the stated limits; and verifying that the probability used for each cohort is the probability in its recorded snapshot. A sudden increase in overdue unresolved cases, inconsistent endpoint coding, or unexplained changes in counts is a reason to investigate before relying on the next adaptive estimate.
Resolved-only updating is transparent and avoids pretending to know outcomes that have not yet occurred. It can, however, be slow when few outcomes have resolved, and its estimates can be unrepresentative if outcome resolution is related to response. The day-45 missing-status rule and backlog trigger make that risk visible; they do not eliminate it. If resolution is systematically informative, a protocol needs a justified model or another prespecified approach, with sensitivity analysis and adequate data quality safeguards. A rule based on a simple binary response model is also limited if response probabilities change over the trial or important prognostic differences are ignored.
| Approach | Operational choice | Main trade-off |
|---|---|---|
| Wait for all outcomes | Do not update until a specified group’s outcomes resolve. | Simple to explain, but can delay adaptation substantially. |
| Use resolved outcomes only | Update at fixed cutoffs using observed statuses; keep pending cases out. | Transparent and easy to audit, but may be biased if resolved cases are unrepresentative. |
| Predict pending outcomes | Use a prespecified statistical model to incorporate partial follow-up. | May use information sooner, but depends on model assumptions and validation. |
| Use fixed equal probabilities | Do not adapt allocation based on interim responses. | A clear fallback with no response-adaptive feedback dependency, but it forgoes adaptation. |
These choices are not interchangeable without consequences. Predicting pending responses requires a model for response and resolution times; simply substituting predictions into the resolved-only formula would define a different procedure. Waiting for more information may reduce dependence on partial data but can leave assignments unchanged for longer. The appropriate choice depends on the trial’s goals, endpoint, expected resolution process, and safeguards. The protocol must say which choice is in force rather than allowing it to vary informally from update to update.
Common Mistake
A second operational error is to update probabilities after each newly received response even though the protocol specifies cohort-level updates. That changes the method: participants within the nominal cohort no longer share the same probability, and the recorded snapshot no longer explains their assignments. Keep the update times and within-cohort probabilities fixed as written.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- At a cutoff, arm A has 9 resolved responses and arm B has 14. Under the example protocol, what probabilities are used for the next cohort, and why?
- Arm A has 5 successes among 10 resolved responses; arm B has 7 successes among 12 resolved responses. Calculate the smoothed estimates and the probability for A before applying the limits.
- Why should a pending response not automatically be coded as a failure in the allocation calculation?
- At a cutoff, 8 of 25 participants past their day-45 deadline lack resolved outcomes. Does the example protocol’s backlog trigger apply?
- What should happen if the most recent valid probability is available but the current scheduled data snapshot cannot be validated?
Solutions. (1) Use \(P(A)=0.50\) and \(P(B)=0.50\), because A has fewer than the required 10 resolved responses; the minimum-information rule takes precedence over the adaptive formula. (2) \(\tilde p_A=(5+1)/(10+2)=6/12=0.5000\), and \(\tilde p_B=(7+1)/(12+2)=8/14=0.5714\). Thus the raw probability for A is \(0.5000/(0.5000+0.5714)=0.4667\), which lies within the 0.20 to 0.80 limits. (3) Pending means the endpoint status is not yet known under the resolution rule. Coding it as failure would replace unknown information with an outcome that has not been observed. (4) Yes. The proportion is \(8/25=0.3200\), or 32%, which exceeds the 20% trigger. (5) Use equal probabilities for the next cohort, record the reason, and resume adaptation only after a valid snapshot and the prespecified checks are available.