The Site-Friendly RBQM Platform: Design Specification

Platform Design Specification · ICH GCP E6(R3)

An RBQM platform that is gentle at the site, and relentless at the center.

One operational system, two very different experiences. For the Clinical Research Coordinator, a low-burden workspace that removes transcription, triages work by risk, and prevents deviations before they occur. For the Remote Monitoring Team, a centralized, proportional, and fully explainable risk engine, cross-disease by design, and inspection-ready under E6(R3) and 21 CFR Part 11.

Regulatory frame

ICH E6(R3) · Part 11

Data standard

HL7 FHIR → CDISC

Monitoring model

Risk-based · Centralized

Configuration

No-code KRI / QTL

Section I

The CRC Experience: designed to be little, friendly, and quiet

Coordinators are historically buried under complex interfaces, endless queries, and double data entry. Compliance improves when burden falls: the platform's job at the site is to remove work, not add oversight.

FHIR · eSource

EHR-to-EDC direct integration

Labs, vitals, and demographics flow from the site's EHR into the EDC over HL7 FHIR: site-driven, provenance-preserving, and scoped to the protocol. Manual transcription disappears, and with it, the need for routine Source Data Verification.

Risk-sorted work

“Next Best Action” dashboard

No unfiltered wall of 500 open queries. Tasks are ranked by risk severity: a missing blood pressure on a safety visit (Critical to Quality) sits at the top; a typo in a concomitant medication waits at the bottom.

Prevention > detection

Proactive deviation guards

If a CRC schedules a critical visit outside the protocol window, the system flags it gently before it happens, preventing the deviation rather than logging it for a monitor to find weeks later.

site workspace · next best action · sorted by risk to critical-to-quality factors

Critical

Missing blood pressure: Subject 1042, Safety Visit 3 Critical-to-Quality endpoint · visit locked in 48h

Resolve now →

Critical

Visit 5 scheduled outside protocol window: Subject 0977 Deviation guard: window closes 14 Jul · reschedule to prevent deviation

Reschedule →

Moderate

Verify 3 AI-extracted adverse events from progress notes Split-screen review · source text highlighted for one-click acceptance

Open review →

Low

Spelling query: concomitant medication, Subject 1103 No impact on safety or primary endpoint · batch with weekly cleanup

Defer

“The site owns its source data. Every transfer is initiated at the site, by the coordinator; the sponsor never reaches in. Friendliness and compliance are the same architecture.”

Design principle · site-driven eSource

Section II

The Remote Monitoring Engine

Under ICH E6(R3), regulators no longer want 100% manual data checking. They expect a proactive, centralized, proportional approach. The platform acts as an intelligent hub, watching every site at once, escalating only where risk demands it.

Capability	How it satisfies GCP E6(R3)
Configurable KRIs & QTLsMetric thresholds per study	Study builders define Key Risk Indicators and Quality Tolerance Limits that adapt to the disease. A missed daily symptom log is critical in an asthma trial, and far less so in a slow-moving dermatology study. Proportionality is configured, not hardcoded.
Multivariate anomaly detectionStatistical + AI surveillance	Algorithms scan data across all sites to surface anomalies: “too perfect” data suggesting fraud, or drift suggesting miscalibrated site equipment, all without a CRA ever travelling. Centralized monitoring becomes the primary detection layer.
Dynamic monitoring plansEscalation by evidence	The system dictates monitoring intensity. Clean sites remain on remote review only; when a site's composite risk score crosses its threshold, the platform automatically triggers a targeted on-site visit, with effort applied exactly in proportion to risk.

Central risk console: live sensitivity control

Monitors tune the anomaly threshold and watch site flags respond in real time. Drag the slider: lower sensitivity surfaces more sites for review; higher tolerance keeps only the outliers.

Amber threshold55

Currently flagging 0 of 8 sites for elevated review. Red escalation is fixed at threshold + 20 and mandates an on-site visit under the dynamic monitoring plan.

Section III

The Explainability Log

E6(R3)'s decisive expectation: decision explainability. It is no longer enough to track data changes for Part 11; inspectors expect to see exactly why a monitor acted, or chose not to act, on every risk signal. Dismissing a flag without a rationale is not an option the interface offers.

09 Jun 2026 · 14:22 UTCMonitor: E. Ferreira
Signal: KRI-07 amber

Risk flag dismissed: Site 204, enrollment velocity. Signal reviewed against regional holiday calendar; the dip is seasonal and mirrors the prior year. Rationale: Known external factor (seasonal, documented)

11 Jun 2026 · 09:05 UTCMonitor: E. Ferreira
Signal: KRI-02 red

Risk score raised: Site 311, SAE reporting lag. Progress notes referenced hospitalization 11 days before the formal AE eCRF was verified. Escalated to on-site visit; site retraining scheduled. Rationale: Safety underreporting lag, action taken

11 Jun 2026 · 16:40 UTCSystem: NLP model v2.1
Reviewed by: Site 311 CRC

AI-suggested adverse event accepted after human verification. “Data suggested by NLP Model v2.1 (confidence 94%); accepted and verified by Coordinator M. Adel at 16:40 UTC.” Provenance: model version · confidence · verifier · timestamp

12 Jun 2026 · 10:18 UTCMonitor: L. Okafor
Signal: QTL-01 warning

QTL trend acknowledged: study-level drop-out approaching limit. Drop-out at 8.4% against a 10% tolerance limit; mitigation plan opened with the sponsor's quality lead rather than waiting for the breach. Rationale: Preventive action, mitigation plan opened

“The audit trail must prove the risk was actively evaluated by a human, not silently ignored by an algorithm. Every dismissal carries a standardized, selectable rationale.”

E6(R3) · contextual decision audit trails

Section IV

Cross-Disease by Construction: the No-Code Logic Builder

KRIs and QTLs can never be hardcoded. A 5% drop-out rate over a 3-year Alzheimer's study is excellent; the same 5% in a 2-week influenza study is a crisis. So the rules live in a visual logic builder: plain-English statements and drop-downs, never SQL.

The Metric Library

Every rule starts from a standardized metric, aligned with industry consortium definitions (e.g., TransCelerate). For therapeutic specificity, a Custom Metric maps any eCRF field (tumor size reduction in oncology, HbA1c in diabetes) into a first-class variable.

Category	Metrics available in the dropdown
Safety	Serious Adverse Event (SAE) rate · SAE reporting delay
Quality	Protocol deviation rate · Data query rate · Missing data %
Operational	Enrollment rate · Screen failure rate · Drop-out rate
Custom	Any protocol-specific eCRF field, mapped to a named variable per study

Compose a rule that reads like a sentence

The interface guides the monitor through a sentence-like structure. Conditional logic underneath; plain English on the surface. Try changing the dropdowns; the compiled rule updates live.

If at is then

Compiled rule · version-controlled · effective from next review cycle

QTL example: IF [Drop-out rate] at [Study level] is [greater than] [10%] THEN [declare QTL Breach]

KRI example: IF [SAE reporting lag] at [Site level] is [greater than] [5 days] THEN [trigger Amber Alert]

The node-based constructor: a monitor drags metric, condition, threshold, and action nodes onto the canvas, and can trace visually how a single trigger fans out into proportionate monitoring responses.