Blog >  
News

Basket Trials and the Data Infrastructure Problem FDA's Guidance Doesn't Address

Joseph Farrell
7 min

Introduction

On June 22, FDA issued a revised draft guidance on master protocols for drug and biological product development, adding a new section on basket trials in response to stakeholder requests for more specific recommendations. The revision covers design and analysis for trials conducted under a master protocol: a trial framework with multiple substudies that may have different objectives and require coordination to evaluate several drugs simultaneously across a multitude of diseases or conditions.

The guidance covers what sponsors need to address statistically: prespecification of primary objectives, justification for combining or leveraging data across substudies, and the distinction between analyzing each substudy population independently versus conducting a combined analysis across the full basket. FDA emphasized that statistical methods lie along a continuum depending on how clinical trial data are combined or leveraged across substudies, and that sponsors should specify and justify a clear primary objective along with a rationale for how the design and analysis will accomplish it.

What the guidance does not address is the operational infrastructure required to execute a basket trial consistently across substudies that may have different eligibility criteria, different endpoint definitions, different visit schedules, and different safety monitoring obligations, all running simultaneously under a shared protocol structure. That is a data architecture problem, and it is one of the more complex ones in clinical trial execution.

What a Basket Trial Actually Requires Operationally

A basket trial enrolls participants across multiple disease subtypes or conditions and evaluates the same investigational product in each. The shared element is the drug and the overarching protocol structure. What is not shared is everything that makes each substudy distinct: the patient population, the eligibility criteria specific to that subtype, the endpoint capture requirements, the expected safety profile, and potentially the visit schedule.

FDA noted that the complexity of master protocols means longer start-up times, potential design challenges, and requires greater coordination among parties. That characterization is accurate but underspecifies the execution layer problem. The coordination challenge is not primarily a governance challenge, although that is part of it. It is a data challenge: how do you configure a single platform to enforce different protocol logic across substudies simultaneously, maintain a shared data infrastructure that supports the combined analyses the guidance requires, and preserve the substudy-level separation that independent analyses demand?

Consider a concrete example. A basket trial evaluating a targeted therapy across three solid tumor subtypes, each with a distinct biomarker-defined eligibility criterion. Subpopulation A requires a specific mutation confirmed by a central laboratory assay before enrollment. Subpopulation B requires a different biomarker threshold measured by a local laboratory within a defined window before screening. Subpopulation C has a third eligibility criterion that combines a clinical assessment with a laboratory value.

In a platform designed to enforce protocol logic at the point of data entry, each of these eligibility conditions must be separately encoded, separately enforced, and separately auditable. The platform must know which substudy a participant belongs to, apply the correct eligibility logic for that substudy, validate incoming laboratory data against the correct threshold for that population, and prevent enrollment of participants who do not satisfy the correct criteria for their assigned subpopulation.

That is not a single protocol configuration. It is three distinct eligibility workflows, linked to a shared participant record and a shared data model, with substudy identifiers that persist throughout the trial and determine which endpoints, visit schedules, and safety monitoring obligations apply to each participant at every subsequent data entry point.

The Shared Infrastructure Problem

FDA noted that a master protocol may offer logistical advantages by leveraging shared protocol elements such as visit schedule and measurement procedures, shared infrastructure including network of clinical sites, central facilities, and central randomization systems, and shared oversight such as steering committees and data review committees.

The shared infrastructure argument is sound in principle. A basket trial that shares site networks, central laboratory relationships, and randomization infrastructure across substudies is more efficient than three independent trials running in parallel. But shared infrastructure only delivers efficiency if the data layer underneath it is designed to manage the heterogeneity between substudies without collapsing it.

The specific risk in a basket trial is that shared data infrastructure creates pressure toward uniformity that the substudies do not actually have. When the same EDC system, the same eCOA platform, and the same data management workflow are applied to three substudies with different eligibility criteria, different endpoint definitions, and potentially different adverse event coding requirements, the infrastructure designed for uniformity will produce data quality problems at the points of difference.

An eligibility criterion that is correctly enforced in Subpopulation A because the EDC was configured for that subtype may be incorrectly enforced in Subpopulation B if the configuration was not substudy-aware. An endpoint that is correctly captured for the primary analysis of Subpopulation A may not map correctly to the endpoint definition required for the combined analysis across all three substudies if the data model did not anticipate both use cases from the beginning.

FDA noted that in some cases the primary objective may be to evaluate the average effect of the drug in the combined population by conducting a single combined analysis of data across the individual substudy populations. In other cases, the primary objective may be to evaluate the effects within each disease, condition, or disease subtype. Often, both analyses are required. That means the data model must support simultaneous access to substudy-level and combined-population views of the data, with substudy identifiers preserved throughout the trial record.

A data model designed for a single-population trial will not produce this naturally. It must be designed for it from the start.

The Amendment Problem in a Multi-Substudy Context

Protocol amendments in a basket trial create a specific version control challenge that single-population trials do not face. When an amendment modifies the eligibility criteria for one subpopulation but not others, changes the endpoint definition for the combined analysis but not the individual substudy analyses, or adds a fourth subpopulation partway through the trial, the platform must be capable of applying the amendment to the correct scope without affecting the data already collected under the prior protocol version.

In a BDD-based clinical data platform, each substudy's eligibility logic, visit schedule, and endpoint capture conditions are expressed as separate executable specifications. When an amendment affects only Subpopulation B, the specification for Subpopulation B is updated, the change is reviewed and documented, and the platform begins enforcing the new logic from the amendment effective date forward. The specifications for Subpopulations A and C are unchanged and continue enforcing the pre-amendment logic. The audit trail captures exactly which specification was in effect for each participant at each data entry point.

Struggling to manage substudy-specific protocol amendments? See how Alethium handles complex version control with a clean audit trail.

Request Demo

In a platform that does not separate protocol logic by substudy at the specification level, an amendment to one subpopulation's eligibility criteria may require manual workarounds to prevent the change from affecting the other substudies. Those workarounds are not self-documenting, and the audit trail that results from them is ambiguous: it records what changed in the configuration, not what the platform was enforcing for which participants at which points in the trial.

For a basket trial, where FDA may ask the sponsor to demonstrate that the data collected in each substudy reflects the correct protocol version for that subpopulation throughout the trial's history, an ambiguous audit trail is not a minor documentation gap. It is an inspection finding waiting to happen.

The Combined Analysis Data Model

Prespecifying a combined analysis requires knowing, before the trial starts, how the data from each substudy will be structured to support that analysis. Specifically: what is the unit of analysis in the combined dataset, how are substudy-specific covariates handled, how are baseline characteristics defined consistently across substudies with different enrollment criteria, and how are adverse events coded and attributed when different substudies may have different expected safety profiles.

Each of these questions has a data architecture answer. The combined analysis dataset is not assembled after the fact from substudy-level exports. It is the product of a data model that was designed from the beginning to support both substudy-level and combined-population analyses, with substudy identifiers, protocol version identifiers, and endpoint mapping tables that are part of the platform's operational structure rather than a post-hoc reconciliation artifact.

This is the connection between what FDA's guidance requires statistically and what the platform running the trial must provide architecturally. The guidance asks sponsors to prespecify and justify their combined analysis approach. Prespecification is only meaningful if the data infrastructure is capable of executing it. A data model that was not designed for the combined analysis cannot produce a prespecified combined analysis dataset without introducing the kind of post-hoc data manipulation that 21 CFR Part 11 and ICH E6 are specifically designed to prevent.

Conclusion

FDA's revised master protocol guidance is a useful clarification of how basket trials should be designed and analyzed. It addresses the statistical complexity of evaluating a drug across multiple disease subtypes with appropriate rigor. What it does not address is the operational infrastructure required to execute those designs consistently and produce the data that the analyses require.

Basket trials are not more complex versions of single-population trials. They are structurally different trial designs that require a clinical data platform built to manage heterogeneous protocol logic across simultaneous substudies, preserve substudy-level separation in a shared data model, handle amendments with substudy-specific scope, and produce both substudy-level and combined-population datasets from the same operational record.

Sponsors who read the guidance and update their statistical analysis plan without examining whether their data infrastructure can support it have addressed the easier half of the problem.

FDA's revised master protocol draft guidance was issued June 22, 2026. The original draft was issued December 2023. Comments are accepted at www.regulations.gov under docket no. FDA-2023-D-5259 until August 22, 2026.

Request a tailored demo to see how Alethium’s event-driven architecture can help basket trial sponsors manage heterogeneous protocol logic, preserve substudy-level separation, handle amendments, and produce datasets from day one.

Struggling to manage substudy-specific protocol amendments? See how Alethium handles complex version control with a clean audit trail.

Request Demo

Stay in the know with our quarterly roundup of what’s new and what’s next.

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Close

Schedule a Tailored Demo

A tailored demo is the fastest way to understand how Alethium removes operational friction, reduces risk, and accelerates execution for emerging biopharma and CRO teams.

Tell us what you are working toward, and we will show you exactly how Alethium's platform and team can help emerging biopharmas and CROs meet each of their goals.

Your Submission Was Successful!

Thank you for requesting a demo of Alethium's CDP. Our team is preparing a custom Alethium demo tailored to your goals.

If any questions arise before our meeting, please contact us at info@alethium.health.
Oops! Something went wrong while submitting the form.
By using this website, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.