Identifying Nonconcurrent Control Observations

Why the Classification Is Arm-Specific

In a platform trial, control participants may enroll at different times, while treatment arms can open, pause, or close at different dates. Whether a control observation is concurrent therefore cannot be decided from the trial’s overall start and end dates alone. It is a classification made for a particular treatment arm, using that arm’s availability and the comparison window specified by the protocol.

The classification is a record of timing and eligibility, not a finding that two groups are comparable or that a particular treatment effect is unbiased. Those are separate questions. The immediate task is narrower: determine whether each candidate control participant was enrolled in the relevant cohort during dates when the target arm was available within the prespecified comparison window.

Specify the Dates Before Classifying Observations

A reliable classification starts with an explicit rule. The protocol or analysis plan should state which date determines enrollment timing, such as randomization date, and how that date is recorded. The rule should be applied uniformly to controls and treatment-arm participants. Do not switch between consent, screening, randomization, and treatment-start dates according to which one gives a preferred classification.

Let \(a\) denote the target treatment arm and \(t_i\) the prespecified reference date for control participant \(i\). Let \(A_a\) be the set of dates on which the arm was available for enrollment, and let \(W_a\) be the protocol-defined comparison window for that arm. Either set may contain more than one interval. Define the relevant date set as their intersection:

For a control participant who meets the target arm’s eligibility requirements, the rule is:

If the candidate control’s reference date is known and \(t_i \notin T_a\), that observation is nonconcurrent for arm \(a\). If the date or the applicable window cannot be determined, record the status as indeterminate rather than forcing it into either category. If eligibility is unknown, resolve that uncertainty separately; timing alone cannot establish that a control participant was eligible for the arm.

A Consistent Classification Procedure

Use the same sequence for every candidate control observation. Keeping eligibility, dates, and arm availability distinct makes the resulting data set easier to audit and reduces accidental relabeling.

Worked Examples With Multiple Availability Periods

Why the Set-Intersection Rule Works

The classification requires two timing conditions to hold at once: the arm must be available on the participant’s reference date, and that date must be inside the prespecified comparison window. A date satisfying both conditions is exactly an element of \(A_a\cap W_a\). Thus:

If either condition fails, the reference date is outside the shared period. For an eligible candidate with a known date, the control is then nonconcurrent under this definition. This also explains why using only one of the two date criteria is insufficient: arm availability alone can include dates excluded by the protocol window, while the protocol window alone can include dates when the arm was closed.

Diagnostics, Alternatives, and Limitations

Before accepting a classification file, check it for inconsistent date definitions, unexplained gaps, and impossible or ambiguous intervals. In particular, verify that each interval has a start date no later than its end date; that opening, closing, and reopening dates match the operational record; and that boundary dates are handled as the protocol specifies. A table by arm and calendar period is often useful for spotting controls labeled concurrent during a closure or labeled nonconcurrent inside the shared window.

The main alternatives are less precise shortcuts. Using the platform’s overall calendar dates ignores arm-specific openings and pauses. Using only the target arm’s active dates ignores any narrower protocol-defined comparison window. Applying an arbitrary cutoff after seeing the outcomes risks making the classification depend on observed results rather than a prespecified rule. The intersection rule makes the required information and decision transparent.

Some cases cannot be resolved by dates alone. For example, an amendment may change which disease subtype is eligible, or a record may contain a consent date but not the reference date required by the protocol. Such cases require checking the applicable eligibility rules or resolving the missing record; they should not be silently assigned a convenient status. Likewise, a date-based concurrent label does not establish that patients enrolled in different parts of the window are otherwise comparable. The classification describes timing and protocol eligibility; it does not, by itself, establish the assumptions needed for an effect estimate.

A useful record for each observation includes the target arm, eligibility status, reference date, applicable comparison-window version, arm-availability interval, classification, and reason for any indeterminate status. This makes the decision reproducible if the protocol changes or the data are reviewed later.

Common Mistake

Wrong reasoning: “This control was enrolled while the platform trial was running, so it is concurrent for every arm.” This treats the whole platform calendar as if every treatment arm had been continuously available to every participant.

Correction: Classify separately for each arm. Confirm arm eligibility, use the prespecified reference date, and test whether it falls in the intersection of that arm’s availability and its protocol-defined comparison window. A control may be concurrent for one arm, nonconcurrent for another, or not eligible for a third.