Continuous Monitoring in Clinical Trials: How to Turn RBQM Into a Decision Advantage

RBQM becomes a decision advantage when three conditions are met:

• The data feeding your Key risk Indicators (KRIs) and Quality Tolerance Limits (QTLs) is current at the moment of review
• Every finding carries a documented lifecycle from identification through resolution
• KRIs and QTLs are calculated as separate mechanisms operating at different scales. 

When those three things are in place, the monitoring program starts indicating where the trial is heading.

‍

Most sponsors have the methodology right. The KRI frameworks, QTL boundaries, and escalation procedures developed at protocol design are sound. ICH E6(R3) doesn't mandate a specific technical architecture, but its shift toward proportionate, risk-based oversight and timely issue detection may be challenging to satisfy using infrastructure originally built for periodic, batch reporting.

‍

Three Conditions for RBQM That Generates Decision Advantage

1. Data That Is Current at the Moment of Review

A KRI is only useful if the data feeding it reflects what is happening at the trial now, not what was happening at the last scheduled extract. The same applies to QTLs. An aggregate view of study-level risk calculated on last week's data is not a basis for intervention. It is a basis for confirming, after the fact, that something went wrong.

‍

The standard integration model in clinical trials runs on output-layer aggregation. Data managers extract files from each source system on a fixed schedule, join them through a third-party tool (in some cases Excel or SAS), and produce a listing for review. In a study with weekly data cuts, that listing is between one and seven days stale by the time it reaches a central monitor. For enrollment rates and visit compliance, that lag is manageable. For a site-level spike in an adverse event category, a clustering of protocol deviations around a specific procedure, or a laboratory value trend preceding a reportable event, it is not. Those signals can develop and resolve within the gap between two data cuts: a structural limitation of periodic, sampled review.

‍

Closing that gap is, in our view, is key to real-time detection: not something the guideline itself prescribes. Moving from weekly to daily exports still produces a flat file. A flat file carries no persistent state, supports no concurrent reviewer workflow, and captures nothing about what a reviewer did with a finding or what the data showed at the moment of review. Persistent source system connections, where the EDC, central lab, protocol deviation tracker, and safety database feed a unified view continuously, are what make real-time KRI and QTL calculation possible. This is in line with findings of a study of 1,111 at-risk sites across 159 trials, continuous statistical surveillance confirmed actionable quality issues that standard source data verification had not caught, indicating that continuous monitoring approaches can detect site-level problems that periodic, sampled review is structurally prone to miss.

‍

2. Findings With a Documented Lifecycle

The difference between a monitoring listing and a monitoring system is state. A listing tells you what the data shows at a point in time. A monitoring system records what happens to each finding over time: when it was identified and by whom, what the data showed at the moment of review, what action was taken and when, whether the issue was resolved or escalated, and what the corrective action produced.

‍

That lifecycle record makes it easier to demonstrate the contemporaneous, attributable, and traceable record keeping (ALCOA+/ALCOA++) that ICH E6(R3) applies to trial data and quality oversight records. When a regulator asks whether a site-level KRI spike in month three was investigated and resolved, a documented lifecycle. Timestamp, reviewer attribution, rationale, corrective action: this is the kind of evidence that supports this expectation. If that record has to be assembled from email threads and spreadsheet notes after the fact, it is harder to demonstrate that oversight was timely and traceable.

‍

A quality management plan documenting KRI thresholds, combined with a series of periodic listings showing values at each data cut, demonstrates that monitoring occurred on a schedule. It does not demonstrate that the schedule was sufficient to detect and respond to the signals that appeared between cuts. That gap is a plausible source of inspection findings, though the actual rate at which periodic-cut monitoring produces inspection findings, versus continuous monitoring, has not been established in published data we are aware of.

‍

3. KRIs and QTLs Calculated Separately 

A common implementation error is treating KRIs and QTLs as interchangeable. Though they can share the same statistical threshold-setting methods, they serve different regulatory purposes and reporting obligations: a QTL breach signals a potential systemic issue and requires documented evaluation (and disclosure in the CSR if significant), while a KRI is an operational risk signal without that reporting requirement."

‍

A KRI is most commonly a  site-level metric. A breach at a single site signals that something at that site warrants investigation. It does not, on its own, indicate a study-level problem.

‍

A QTL is a study-level parameter. It is designed to detect the pattern that looks unremarkable at any individual site but represents a systemic issue when viewed across the full trial population. That view requires cross-system aggregate data maintained continuously. It cannot be inferred from site-level KRI signals.

‍

A monitoring program that relies only on per-site KRI threshold breaches without a separate, trial-wide aggregate view risks missing the category of risk QTLs are designed to catch: patterns that are sub-threshold at every individual site but represent a systemic shift across the trial population. This is a real gap, but it's a gap in aggregation, not a categorical property of KRIs versus QTLs: a study-level KRI or a properly aggregated KRI review can partially close it, which is why regulators and practitioners emphasize designing QTLs deliberately rather than assuming site-level KRI monitoring covers the same ground by default.

‍

Why This Is Harder Than It Looks: is your  Infrastructure ready?

The three conditions above are straightforward in principle. In practice, they run into the same obstacle: trial data is distributed across systems that were each built to perform a specific function within their own domain.

‍

The EDC captures site-entered clinical data. The central lab manages laboratory results. The protocol deviation tracker records and categorises deviations by site. The safety database handles adverse event processing. None of these systems were originally designed to integrate with the others at the point of clinical review.

‍

When a KRI needs to track the ratio of laboratory abnormalities to adverse event reports, it needs laboratory data and AE data joined at the patient level, at the moment of calculation. That join is technically routine, but in a post-hoc, periodic export process it is only as current as the last reconciliation cycle. Lab and AE data originate from different systems on different refresh schedules and are typically reconciled by different teams; each additional manual step between source and joined view adds lag, and mismatches between sources (naming conventions, timing, format differences) still require review to resolve even when the underlying join logic is sound.

‍

The same fragmentation creates a blind spot between RBQM and safety monitoring.Both functions are often managed on separate timelines: the quality management function tracking KRIs and QTLs, the safety function reviewing adverse events and managing aggregate reporting obligations including DSUR preparation. But safety signals do not always surface first in the safety database. They may appear first as a cluster of protocol deviations at a particular site, a pattern of early discontinuations not yet linked to an adverse event, or a laboratory value trend that precedes a reportable event. A monitoring program that reviews these data streams on separate schedules is more likely to miss, or catch only after significant delay, the cross-domain connection between them.

‍

This is close to the precondition behind FDA's emerging Real-Time Clinical Trials (RTCT) initiative, announced in April 2026: cross-domain signal detection benefits from integrated data at the point of review. Note that RTCT is currently a proof-of-concept program (two oncology trials, via a single vendor platform) plus a Request for Information on what a broader pilot should look like: it is not yet a finalized framework or a requirement sponsors must meet.

‍

What ICH E6(R3) Requires from Sponsors Directly

ICH E6(R3) requires sponsors to maintain direct quality oversight, not delegate it to the CRO. The guideline does not prohibit sponsors from using CROs for monitoring activities. It requires documented evidence that the sponsor's quality management function is actively engaged with the trial's risk profile, rather than simply receiving reports from the CRO on a cycle.

‍

In practice, sponsors whose monitoring data lives primarily in CRO systems cannot independently verify that KRI thresholds are set appropriately for the specific study risks, that the underlying data is complete and current, or that signals appearing between reporting cycles were identified and acted on. The audit record a regulator inspects should reflect the sponsor's active oversight. A CRO's reporting cadence is not a substitute for it.

‍

FDA's RTCT initiative signals a possible future direction toward more direct, continuous data access between sponsors and regulators, though the model is still in early proof-of-concept and RFI stages with no finalized requirements. Sponsors that depend solely on periodic CRO reporting cycles may find it harder to adapt if and when such expectations become standard.

‍

What Happens When the Infrastructure Is Not There

At the site level

KRI calculated post-hoc tells you which sites have already crossed a threshold. With current data, it can flag sites approaching a threshold earlier, which may give more lead time to intervene before a breach, though the incremental benefit of continuous vs. periodic KRI review has not been established in controlled studies.

‍

At the study level

A QTL breach that develops in week three of a six-week data cut interval is not identified until week six. The investigation begins six weeks after the issue started. The corrective action begins later still. The data that could have enabled earlier detection was in the source systems throughout that period. It was not visible to the monitoring program because the monitoring program was not connected to those systems continuously.

‍

At the regulatory level

ICH E6(R3) emphasizes proportionate, risk-based, and timely oversight. The FDA's 2013 risk-based monitoring guidance cites a review of on-site monitoring findings from one multi-center international trial suggesting that centralized monitoring can identify "the great majority" of on-site monitoring findings. This is a single cited study, not a general finding: a later, more rigorous prospective study (TEMPER, 2018) found that triggered/centralized-monitoring signals were not sufficiently discriminatory. Matched control sites not flagged by central monitoring had similarly high rates of Major/Critical findings as flagged sites. The evidence on how well centralized/continuous monitoring substitutes for on-site findings is mixed, not settled, and the mechanism most likely to help is data currency and integration, not central monitoring alone.

‍

A quality management program running on periodic exports can satisfy the regulatory requirement on paper. Whether the data layer underneath it can support what the guideline expects in practice is a different question.

‍

If you want to see what this looks like when the infrastructure is in place, including the specific workflow, the live KRI and QTL tracking, and the point at which a monitor intervenes before a threshold is crossed rather than after, Operationalizing RBQM Through Centralized Data Automation walks through it in detail.

‍

References

1. International Council for Harmonisation. ICH E6(R3) Guideline for Good Clinical Practice. Final version adopted January 6, 2025; came into effect July 23, 2025. Available at: https://database.ich.org/sites/default/files/ICH_E6(R3)_Step4_FinalGuideline_2025_0106.pdf
2. U.S. Food and Drug Administration. Guidance for Industry: Oversight of Clinical Investigations — A Risk-Based Approach to Monitoring. August 2013. Available at: https://www.fda.gov/media/116754/download
3. U.S. Food and Drug Administration. FDA Announces Major Steps to Implement Real-Time Clinical Trials. Press release, April 28, 2026. Available at: https://www.fda.gov/news-events/press-announcements/fda-announces-major-steps-implement-real-time-clinical-trials
4. de Viron S, Trotta L, Steijn W, Young S, Buyse M. Does Central Statistical Monitoring Improve Data Quality? An Analysis of 1,111 Sites in 159 Clinical Trials. Therapeutic Innovation & Regulatory Science. 2024;58:483–494. DOI: 10.1007/s43441-024-00613-w. Available at: https://pmc.ncbi.nlm.nih.gov/articles/PMC11043176/
5. Stenning SP, Cragg WJ, Joffe N, Diaz-Montana C, Choudhury R, Sydes MR, Meredith S. Triggered or Routine Site Monitoring Visits for Randomised Controlled Trials: Results of TEMPER, a Prospective, Matched-Pair Study. Clinical Trials. 2018;15(6):600–609. DOI: 10.1177/1740774518793379. Available at: https://pubmed.ncbi.nlm.nih.gov/30132361/

‍