What CROs actually do in early-phase studies
For a typical Phase I or early Phase II study, the CRO statistician performs: safety data review (adverse event tabulations, laboratory shift tables), pharmacokinetic descriptive summaries (NCA parameters by cohort and dose level), basic efficacy signal detection (response rates, descriptive statistics by treatment arm), and report generation for the clinical study report.
None of these tasks are statistically complex. They require domain knowledge (understanding what a relevant safety signal looks like, knowing how to interpret NCA parameters) and regulatory competence (correct ADaM structure, appropriate statistical terminology). But the actual analytical content, the models, the tests, the computations, is straightforward.
Where the value is (and is not)
The value a CRO statistician brings in early phase is primarily in three areas:
- Regulatory credibility: a named biostatistician on the study documents, ideally with FDA/EMA experience, who can respond to questions from health authorities.
- SAS infrastructure: most CROs have validated, audit-ready SAS environments that produce CDISC-structured output. This matters for submissions.
- Domain judgment: knowing when a laboratory finding is clinically relevant, when a PK anomaly warrants a note vs an alert, when to flag a safety signal to the medical monitor.
The value is not primarily in the statistical complexity of the models. An early-phase safety dataset rarely requires anything more sophisticated than frequency tables, shift tables, and descriptive PK statistics.
What a Shiny app can realistically do
A purpose-built Shiny application for an early-phase study can:
- Generate all standard safety tabulations from a cleaned ADAE dataset
- Compute NCA parameters using PKNCA and display them in interactive cohort-level summaries
- Produce Kaplan-Meier plots and log-rank tests for any time-to-event endpoint
- Apply predefined inclusion/exclusion criteria and flagging rules
- Allow the medical monitor to toggle dose cohorts, time windows, and safety population definitions in real time
- Export formatted tables suitable for the clinical study report
This covers perhaps 70-80% of the biostatistician's deliverables for a Phase I study by volume of outputs.
The regulatory boundary
Here is where the honest answer matters. A Shiny application that produces exploratory analysis for internal decision-making is not subject to the same regulatory requirements as a validated SAS environment producing submission-bound datasets.
For a Phase I first-in-human study, the statistical analysis in the clinical study report needs to be conducted in a documented, reproducible environment. It does not need to be SAS. But it does need: a locked analysis dataset, version-controlled code, a documented software environment (renv + lockfile), and an independent QC check of critical outputs.
A Shiny app alone does not provide the audit trail required for submission. What it provides is fast, interactive exploration during the study: which is where the actual decision support happens.
A hybrid model: Shiny for exploration, CRO for submission
The most cost-effective model for a small biotech running a Phase I study:
- Build a Shiny app for real-time exploration during the study: safety review, PK visualization, dose escalation decision support. Cost: 2-4 weeks of specialist time.
- Engage a CRO statistician for the clinical study report only: they work from locked datasets and generate the formal tabulations for the regulatory package. Cost: significantly lower than full-study CRO engagement.
- Use the Shiny app outputs to align the team on what the analysis should show before the CRO starts work. This reduces back-and-forth and scope creep during the formal analysis phase.
What this means for small biotechs
Small biotechs burning runway cannot afford to send every exploratory analysis through a full CRO engagement. They also cannot afford to make dose escalation decisions based on a 47-slide PowerPoint that nobody interrogated. The hybrid model, interactive tools for internal use, formal CRO for submission, is a better use of limited resources.
The key shift is recognizing that exploratory analysis and submission analysis are different tasks with different requirements. Conflating them is what makes early-phase data work expensive.
The honest answer
A Shiny app cannot replace a CRO for submission work. It was not designed to. But for the exploratory analysis that happens during a Phase I study, the analysis that actually drives decisions about dose escalation, cohort expansion, and go/no-go, a well-built Shiny application is not a lesser alternative. It is a better tool.
The CRO formalizes what you already know from the Shiny exploration. That is a different use of CRO resources, and a more efficient one.
Key takeaway
The question is not whether Shiny can replace a CRO. The question is which tasks actually require CRO expertise, and which can be done better and faster with an interactive tool. For early-phase exploration, the interactive tool wins. For submission, the CRO earns its cost.