R Shiny Dashboard for a
Multisite Stroke Rehabilitation Trial

RESEARCH QUESTION

What the Monitoring Dashboard Has to Show

This R Shiny dashboard example follows the coordinating team of a 12-site randomized trial of a cognitive rehabilitation program after stroke. The team sends monthly PDF tables to its steering committee and wants a dashboard that refreshes from the weekly data export, so that slow recruitment, missing assessments and drifting assessors are seen while they can still be corrected.

The study team must stay blinded. The dashboard therefore holds no allocation data and shows no results by arm. Any unblinded report for the data monitoring committee is prepared separately, by a statistician outside the blinded study team, and is not produced in this app.

STUDY DESIGN AND DATA

A Weekly Export From 12 Sites

An ongoing multisite randomized trial with 12 sites and a target of about 360 participants. The weekly export holds study codes, site, enrollment date, visit dates, assessor identifier and the scores of a primary cognitive outcome at each visit. The allocation variable is never part of the export that feeds the app, and names and contact details are not included.

METHOD AND ASSUMPTIONS

Why Each Panel Carries Its Uncertainty

Recruitment is projected from site-level accrual with a Poisson model that allows for sites opening at different dates and for extra variation between sites. The projection is shown with its prediction interval and not as a single completion date, because a forecast built on a few months of accrual is uncertain. Data checks are scripted and run on every refresh: visits outside their windows, impossible dates, duplicate records and scores outside the instrument's range.

Completeness of the primary outcome is shown by site and visit, with the pattern of missingness, because a site that loses the final assessment threatens the analysis more than a slow site does. Assessor consistency is screened on pooled baseline scores, collected before treatment can matter. A random-intercept model for site and for assessor within site shows constant offsets, and each assessor's baseline scores are tracked against calendar time, so drift, and not only a fixed difference, becomes visible. An unusual site or assessor effect prompts a look at how assessments are done and is not a finding in itself. Automated tests of the app's calculations run before each release, so a code change that alters a tested figure is caught before the team sees it.

OUTPUT AND INTERPRETATION

How the Dashboard Is Read

The app has a recruitment panel with cumulative enrollment against target and the projection with its interval, a visit window panel, a completeness panel by site and visit, and an assessor consistency panel. Each panel states the date of the export behind it and offers the underlying table for download.

Two role-based views exist, one for the coordinating team with site-level detail and one for the steering committee with aggregate figures, and neither shows outcomes by arm. The flags are prompts to follow up with sites, not stopping rules. The monitoring plan, not the app, decides which thresholds trigger action.

REPORTING

What the Researcher Received

A monitoring plan section that describes each panel, its data source, its refresh schedule and its flag thresholds, informed by the risk-proportionate approach to trial quality in ICH E6(R3), with open and closed reporting kept separate as data monitoring committee charters usually describe. The trial design, the monitoring decisions and the conclusions remain with the research team.