Skip to main content
Back to Blog
Platform

From cohort data to simulation: what your data team needs to provide

The quality of a virtual patient simulation is bounded by the quality and completeness of the input data. This is obvious in the abstract but consistently underestimated in practice. Development teams often arrive at the modeling stage with fragmented cohort data, missing cross-tabulations, and biomarker variables that are measured on non-comparable scales across sources. The gap between what a team can provide and what a simulation needs is the single most common reason projects take longer to set up than expected.

This post describes what the platform requires at minimum, what it can work with but prefers not to, and what genuine blockers look like.

The minimum viable data package

A simulation requires, at minimum, the following from each cohort source:

  • Marginal distributions for each variable that will appear in the eligibility criteria or the subgroup analysis. This means summary statistics sufficient to fit a parametric distribution: mean and standard deviation for continuous variables, proportions for binary variables, ordered category frequencies for ordinal variables.
  • At least one cross-tabulation between the two most clinically correlated variables. In most oncology programs, this is disease stage by prior treatment line. In CNS programs, it is often severity score by age band. The specific pair should be the one where the correlation is most clinically expected, because it will have the most impact on the simulation output.
  • Population description: what diagnosed condition, what time window, what geography, what line of therapy or disease stage were these patients drawn from. Without this, the representativeness question cannot even be framed.
  • Source sample size. The width of the simulation's credible intervals is calibrated to sample size. A summary table derived from 15 patients is treated differently than one derived from 150.

This is genuinely the minimum. Simulations built on only this data will have wide credible intervals and will require explicit prior elicitation for the dependence structure. They are still useful for feasibility filtering and go/no-go framing, but they will not support detailed subgroup carve-outs.

Preferred data formats

Summary tables from published cohort studies are workable, though the labor cost of extracting and reformatting them is non-trivial. The preferred format is a machine-readable summary file, either a structured CSV with clearly labeled variable names and distributional statistics, or an ODM-formatted data definition document.

When individual patient records are available under a data sharing agreement, they can be used to estimate the joint distribution directly, which bypasses the copula parameterization step and produces substantially tighter simulation outputs. If your institution has a data sharing arrangement with a disease registry or academic center, leveraging that pathway significantly improves simulation quality.

Image-based data, such as radiology reports or pathology reads, needs to be translated into structured variables before it enters the simulation. A qualitative imaging finding is not a simulation input; a scored or categorized variable derived from that finding is. If your team relies on imaging phenotypes as eligibility or subgroup criteria, plan for the variable extraction step when estimating data preparation timelines.

Where data teams under-prepare

The most common preparation gap is missing cross-tabulations. Teams routinely provide clean marginal statistics for each variable but have not tabulated any cross-variable relationships. This is partly because marginal statistics are the default output of most clinical database query tools, and cross-tabulations require a more deliberate query. It is worth requesting cross-tabulations in your initial data pull request rather than returning to the data source for them later.

The second gap is temporal provenance. A team will provide a summary table for a biomarker and not specify when those measurements were taken relative to treatment initiation or disease stage assessment. Biomarker distributions often shift substantially over the natural history of a disease or over the course of treatment. A pre-treatment baseline biomarker distribution is not the same thing as a distribution measured at any treatment window, and using the wrong one in the simulation produces bias in the subgroup fractions.

The third gap is assay or measurement harmonization. If your eligibility criterion is defined as a threshold on a biomarker measured by a specific assay, and your cohort data includes that biomarker measured by a different assay with different reference ranges, the distributions are not comparable. This needs to be flagged before the simulation setup, not discovered during it. The platform supports explicit assay conversion factors when validated conversion functions exist in the literature, but the conversion function itself must be provided by the clinical team.

A typical data package preparation timeline

From our experience with early-access programs, the gap between "we have cohort data" and "we have a data package ready for simulation" is typically three to five weeks. This includes: identifying and querying the appropriate cohort sources, extracting the marginals and cross-tabulations, resolving assay harmonization questions, and writing a brief population description document that includes the source, time window, and inclusion/exclusion criteria for the source cohort itself.

Teams that start this preparation in parallel with eligibility criteria finalization, rather than sequentially, save time. The data requirements are directly downstream of the eligibility and subgroup criteria, so the criteria and the data extraction can be prepared in parallel by different team members.

Multi-source data packages

Many programs have access to more than one cohort source, for example a proprietary biobank, a published registry extract, and retrospective EHR data from a collaborating academic center. Multi-source packages are handled as a Bayesian updating problem: each source contributes to the posterior distribution over the joint patient characteristics, weighted by sample size and estimated representativeness.

Combining sources requires an explicit weighting decision. The platform offers a default weighting by sample size, but development teams often have prior knowledge that one source is more representative of the target trial population than another. For example, a registry covering only academic centers in a single country may be systematically different from the target population of a multi-regional trial. That difference should be reflected in the source weights, not ignored.

When sources disagree substantially on the marginal distribution of a key variable, this is a signal worth investigating before proceeding. Either the sources are drawn from genuinely different populations, which requires acknowledging the population heterogeneity in the simulation, or there is a measurement harmonization issue between the sources, which needs to be resolved at the data level.

Data sharing and security

The platform operates on summary statistics and structured data files, not on individual patient records. In standard use, no individual-level data is transmitted to or processed by the platform. The copula-based synthesis happens on summary statistics, and individual patient records are never required for the core simulation workflow.

When individual patient records are available under a data sharing agreement and the team wants to use them for direct joint distribution estimation, that computation happens in an isolated environment with appropriate access controls per the governing data sharing agreement. The platform does not retain individual patient data beyond the computation session.

This architecture is relevant for IRB and data governance considerations at the providing institution. The default workflow's reliance on summary statistics rather than individual records is a deliberate design choice that reduces the regulatory burden on data providers.

What a good data package enables

When the data package is complete, the simulation can answer questions that are currently answered, if at all, by informal judgment. What proportion of the patients likely to enroll will fall into the subgroup where the mechanism of action predicts lower efficacy? How does that fraction change if the eligibility criterion on biomarker X is raised or lowered by one standard deviation? How much does the uncertainty in the subgroup fraction depend on the correlation assumption between variables Y and Z?

These are pre-IND questions. They are answerable before you commit to a trial design, a site selection strategy, or an enrolment projection. The limiting factor is the data package, not the modeling capacity. Teams that invest in data package preparation at study design time are getting the most value from the simulation, and teams that defer data preparation to study initiation are not.

Explore the platform

The science described here is the basis for the platform's inference architecture. If you are working on a Phase I-II decision, request early access.

Request access Learn how it works