Table 3 Overview of features for platform trial simulation software. We differentiate two programming steps: the base features necessary for the majority of platform trials (Core) and features that may be necessary for certain platform trials, but will not be necessary for all, or even a majority of platform trials (Prospective). These features do not need to be part of the core, or initial software package, but the software should be constructed with the perspective that these may become required extensions to the simulation software in the future. We furthermore differentiate features that belong to active investigator design choices (Design), features that belong to investigators’ assumptions about the reality at the design stage (Assumption) and features that belong to essential simulation information that need to be reported (Reporting)
From: Systematic review of available software for multi-arm multi-stage and platform clinical trial design
Step | Type | Feature |
|---|---|---|
Core | Assumption | Simulate the availability and timing of arrival of new treatments |
Core | Assumption | Specify the response of the treatment - this might be the specific response of each treatment, or the distribution(s) of possible treatment response to sample from |
Core | Design | Number of active arms at start and maximum number of active arms throughout trial |
Core | Design | Specify the allocation between treatments and control, possibly varying with the number of treatments in the trial (ideally including option for response-adaptive randomization) |
Core | Design | Different options for control arm data sharing - either comparison with all control subjects or only contemporaneous subjects |
Core | Design | Specify interim timings - either a trial sequence of interim analyses, or per-treatment sequence |
Core | Design | Specification of interim (early success/futility/enrichment) and final decision rules (frequentist or Bayesian) |
Core | Design | Specify “full information” rules for when a treatment completes |
Core | Design | Specify platform stopping rules (e.g., Maximum time, number of subjects or number of treatments) |
Core | Design | Rules to cater for times when a) there is no treatment in the trial and b) there is only one treatment in the trial |
Core | Reporting | Reporting of time to find first success, the number of treatments tested to find the first success, the number of subjects tested to find the first success, the number of subjects on control to first success |
Core | Reporting | Reporting of proportion of treatments with a target response or better that are successful, the proportion of treatments with the same response as control that are successful, applicable error rates and power concepts |
Core | Reporting | Built-in comparison with comparable classical development program to evaluate efficiency gains, which will depend on the trial under investigation (i.e., is it a phase 2a/2b or 2b/3) |
Prospective | Assumption | Correlation between surrogate endpoint and final endpoint |
Prospective | Design | Ability to simulate a surrogate endpoint for interim decisions or early visit data of the final endpoint |
Prospective | Design | Ability to choose type of endpoint (binary, continuous, time-to-event, ...) |
Prospective | Design | Simulate non-constant accrual over time (e.g., piecewise exponential), possibly varying with the number of treatments in the trial |
Prospective | Design | Flexible cohort structures allowing for heterogeneity across treatments evaluated with potential biomarker enrichment in some cohorts, different control groups in other cohorts, the ability to evaluate for dose-response relative to the primary outcomes in other cohorts |
Prospective | Design | There may be just two or three patient subgroups, it should be possible for treatments to fail or succeed in subgroups separately (i.e., be stopped with respect to one treatment but to carry on being assigned in another) |
Prospective | Design | There may be many subgroups, in which case treatment stopping might be decided on the treatment’s performance in predefined “signatures”. Combinations of sub-groups that are medically consistent and a large enough sub-population to be clinically and commercially significant |
Prospective | Design | If response adaptive randomization is being used in a trial with sub-groups it should be performed based on the treatment effect at the sub-group level |
Prospective | Design | Allow treatments to have sub-arms (e.g., different doses, possibly with dose response models across the arms, and adaptive allocation between the arms) |
Prospective | Design | Allow Treatments to have differing treatment duration within the trial: different subject allowance, different stopping rules |
Prospective | Design | Allow treatments to be used in combination therapy. It maybe that treatments are only combined if they are from different treatment groups, it maybe that some treatments are only used in combination. |
Prospective | Design | Allow participants to be re-randomized to new intervention after completing participation in another cohort within the platform trial |
Prospective | Reporting | Simulation (and analysis) of longitudinal response trajectories for participants, along with reporting of patient-level simulation data |