This is a ready-to-use specification for the statistical methods behind a trial’s centralized monitoring function. The Clinical Monitoring Plan states that KRIs and statistical checks exist; this document states exactly how each one is calculated, what it assumes, where it breaks, and how its output is validated before anyone relies on it to trigger a signal. Replace every <<FILL: ...>> placeholder and route it through your normal review. A filled specimen follows. This is general guidance to adapt and verify, not statistical or regulatory advice.
Why this specification earns its place
A KRI dashboard that says “Site 014 is red” is only as trustworthy as the calculation behind it. Two sponsors can both claim central statistical monitoring and mean very different things: one runs a validated, threshold-tested set of methods matched to each data type, the other runs whatever came preloaded in a vendor platform. This document is where the difference becomes visible and auditable. It also treats the calculations themselves as what they are, a computerized process that produces a GxP-relevant output, so it carries the same validation expectation as any other system that decides where monitoring attention goes. See risk-based monitoring of clinical trials for the full monitoring-program context and computer software assurance for the validation approach applied here.
Document control header
| Field | Entry |
|---|---|
| Document title | Central Statistical Monitoring Methods Specification |
| Document number | <<FILL: doc ID>> |
| Version | <<FILL>> |
| Effective date | <<FILL>> |
| Governing Clinical Monitoring Plan | <<FILL: CMP ID>> |
| Governing risk assessment | <<FILL: RACT/risk register ID>> |
| Statistical owner | <<FILL: role, e.g. Lead Biostatistician>> |
1. Purpose and scope
This specification defines, for protocol <<FILL>>, the statistical methods used in centralized monitoring: the mechanism of each method, the data it runs against, its threshold or control-limit basis, its assumptions and known weak points, and the KRI or QTL it feeds. It applies from the first central monitoring run through database lock. It does not restate the KRI/QTL definitions themselves, which live in the paired register; it defines how each one is actually calculated.
2. Method inventory
Every method in production use is listed here. A method with no row here should not be running against live trial data.
| Method ID | Technique | Mechanism (plain language) | Data source / domain | Control limit or threshold basis | Minimum-n floor | Assumptions / known weak point | Feeds (KRI/QTL ID) |
|---|---|---|---|---|---|---|---|
<<FILL: CSM-01>> | <<FILL: Shewhart control chart>> | <<FILL: metric plotted vs pooled mean +/- 3 SD>> | <<FILL>> | <<FILL: derived from first N weeks of accrued data, not a borrowed default>> | <<FILL: e.g. 5 subjects>> | <<FILL: insensitive to small sustained drift>> | <<FILL>> |
<<FILL: CSM-02>> | <<FILL: CUSUM chart>> | <<FILL: cumulative deviation from target crosses a tuned threshold>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: threshold tuning required or it over- or under-fires>> | <<FILL>> |
<<FILL: CSM-03>> | <<FILL: funnel plot>> | <<FILL: rate vs sample size with widening limits for small n>> | <<FILL>> | <<FILL: assumed binomial/Poisson distribution>> | <<FILL>> | <<FILL: misleads if the rate does not fit the assumed distribution>> | <<FILL>> |
<<FILL: CSM-04>> | <<FILL: mixed-effects / hierarchical model>> | <<FILL: site random effect separated from trial mean>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: requires statistician review, not a dashboard read>> | <<FILL>> |
<<FILL: CSM-05>> | <<FILL: digit-preference / Benford-type check>> | <<FILL: terminal-digit distribution vs expected>> | <<FILL>> | <<FILL>> | <<FILL: only meaningful above a minimum data-point count>> | <<FILL: useless on categorical/low-count data>> | <<FILL>> |
<<FILL: CSM-06>> | <<FILL: duplicate / near-duplicate detection>> | <<FILL: record-similarity match across subjects/visits>> | <<FILL>> | <<FILL: similarity threshold>> | <<FILL>> | <<FILL: threshold too loose or too tight>> | <<FILL>> |
3. Minimum-n and small-site handling
A site below the minimum-n floor for a given method is not flagged alone from that method. State the standing rule:
<<FILL: e.g. "Sites with fewer than 5 evaluable subjects for a given metric are excluded from direct statistical comparison on that metric and are instead corroborated against other KRIs (enrollment pace, AE rate) until the floor is reached.">>
Document, per method, whether the floor is a hard exclusion or a “flag with a caveat” treatment, and who reviews the flagged-but-below-floor case.
4. Threshold-setting methodology
- Thresholds are derived from this trial’s own accruing data during a defined baseline window (
<<FILL: e.g. first 10% of planned enrollment or first 90 days>>), not copied from a different trial’s historical rates. - State the confidence or control-limit convention used per method (for example, three standard deviations for a control chart; a stated alpha for a funnel-plot boundary).
- Re-baseline trigger:
<<FILL: e.g. a protocol amendment changing the population, or a planned interim review>>.
5. Validation of the statistical code and pipeline
The calculations that produce KRI values are a computerized process with a GxP consequence (they route monitoring attention and evidence what a sponsor knew and when). Treat them accordingly.
| Element | Control |
|---|---|
| Source of the calculation code | <<FILL: in-house script, vendor platform, statistical software package and version>> |
| Verification against known inputs/outputs | <<FILL: test cases with expected results run before go-live and after any code or platform change>> |
| Change control | <<FILL: any change to a formula, threshold, or minimum-n rule follows change control and is version-dated here>> |
| Access control | <<FILL: who can alter a threshold or formula>> |
| Reproducibility | <<FILL: can the same inputs regenerate the same flagged output on demand, for example for an inspector>> |
6. Review and disposition handoff
Every method’s output is a candidate KRI/QTL value, not a final decision. It is reviewed at the central monitoring meeting cadence defined in the Clinical Monitoring Plan and, when it crosses threshold, is entered in the signal disposition log with the assessment, action, and outcome. See the KRI/QTL Register and Signal Disposition Log.
7. Acceptance criteria
- Every method running against live data has a row in the method inventory with a stated mechanism, threshold basis, and minimum-n floor.
- No threshold is a value borrowed from another trial without a stated re-baseline plan against this trial’s own data.
- The calculation code or platform has documented verification evidence and is under change control.
- Every method’s output routes to a named KRI or QTL and into the signal disposition log; no method runs in isolation from the rest of the monitoring program.
- Someone not involved in building the method can read this specification and explain, for a given flagged site, why it was flagged.
8. References
ICH E6(R2) Good Clinical Practice, section 5.18.3 (centralized monitoring); ICH E6(R3) Annex 1. FDA guidance, A Risk-Based Approach to Monitoring of Clinical Investigations (2019) and its Questions and Answers (2023). FDA guidance and current agency expectations on computer software assurance, for validation of the calculation pipeline.
Confirm the current status of each reference before use.
9. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
10. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Biostatistics) | <<FILL>> | ||
| Reviewer (Central Monitoring Lead) | <<FILL>> | ||
| Approver (Clinical Quality) | <<FILL>> |
Filled specimen (excerpt)
The following shows two method-inventory rows completed for an example 40-site rare-disease trial. Illustrative only.
| Method ID | Technique | Mechanism | Data source | Control limit basis | Minimum-n floor | Weak point | Feeds |
|---|---|---|---|---|---|---|---|
| CSM-01 | Funnel plot | AE rate per subject plotted against site enrollment, with 95% control limits widening for small sites | EDC adverse event log | Binomial control limits derived from the pooled AE rate observed in the first 90 days of accrual | 5 evaluable subjects | Misleads if the true AE rate is not well described by a binomial process, for example if events cluster in time | KRI-06 (AE/SAE rate vs expected) |
| CSM-04 | Mixed-effects model | Site-level random intercept on primary-endpoint measurement, separating true site variation from noise | eCRF primary endpoint field | 95% prediction interval from the fitted model, re-baselined at the planned interim review | 8 evaluable subjects | Requires the biostatistician to re-check model fit each time it reruns; not a fire-and-forget dashboard number | QTL-03 (rate of incomplete primary endpoint data) |
Worked disposition: Site 22 (3 subjects) shows an AE rate of 0 against a pooled rate of 2.1. Because Site 22 is below the CSM-01 minimum-n floor of 5, it is not flagged from this method alone; it is logged as “below floor, corroborate at next enrollment milestone” and cross-checked against KRI-02 (enrollment rate) and KRI-01 (screen failure rate) instead. At 6 subjects, Site 22 clears the floor and CSM-01 flags it, at which point the standard signal disposition process in the KRI/QTL log takes over.
Common inspection findings this specification prevents
- A KRI or QTL exists in the register with no documented calculation behind it, so nobody can reproduce or defend the number that triggered an action.
- Thresholds borrowed from a different trial’s historical rates, misfiring against this trial’s actual site-size and event-rate distribution.
- No minimum-n rule, so small sites are flagged constantly on raw mean comparisons and the review team stops trusting the dashboard.
- The calculation code or vendor platform configuration changes with no change control and no re-verification, so a threshold silently drifts.
- Nobody can explain, at inspection, the mechanism behind a specific flagged signal, only that “the system flagged it.”
How to adapt this specification
- Populate the method inventory directly from the central monitoring activities named in your Clinical Monitoring Plan; every method referenced there should have a row here.
- Set minimum-n floors and threshold-setting rules to your trial’s actual site-size distribution and event rates, not a vendor default.
- Confirm the calculation pipeline, whether an in-house script or a vendor platform, has verification evidence and sits under change control.
- Point section 6 to your actual signal disposition log and central monitoring meeting cadence.
- Re-baseline thresholds at the trigger points you define, and version this document each time.