Central monitors
Watch signals across all sites in a study and decide which ones need a closer look.
- Sites ranked against their peers
- Open signals with their age
- One click from a signal to the data behind it
Healthcare / CRO Analytics
Risk-based monitoring analytics for CROs
A contract research organization runs many studies for many sponsors, and every sponsor wants the same thing: early warning when a site starts to drift. Agnotic Technologies builds the analytics behind risk-based and central monitoring, from the cross-study data model to the sponsor view, with thresholds your study teams own.
KRIs
Calculated per site, per study and per sponsor
QTLs
Trial-level limits with a recorded evaluation
Tenants
Each sponsor sees only its own studies
Trusted by global innovators
Industry Overview
What is CRO analytics for risk-based monitoring?
CRO analytics for risk-based monitoring is software that pulls data from CTMS, EDC, IRT and eTMF into one model, calculates key risk indicators for every site, tracks quality tolerance limits for each trial and shows every sponsor only its own studies. Agnotic Technologies builds this layer for contract research organizations, while the thresholds stay with the study team.
Who reads it
Who uses each view of the analytics?
One data model, four audiences. Each view answers a different question, and each one is limited to the studies that person is allowed to see.
CRAs and clinical operations leads
Turn signals into targeted visits, calls and retraining.
- Visit list driven by risk, not only the calendar
- Site history before each contact
- Actions logged against the signal
Sponsor oversight teams
See the status of their own studies without asking for an export.
- QTL status and evaluations
- Important quality issues and actions
- No view of other sponsors' data
CRO portfolio leadership
Compare operations across studies that use the same indicator library.
- Enrolment pace against plan
- Query backlog by study
- Monitoring workload by region
Industry Challenges
Why do central monitoring programs miss site problems?
Most misses come from the data around the indicator, not from the indicator itself.
Stale inputs: indicators run on data entered weeks after the visit, so the signal appears after the damage is done.
Different definitions per study: one team counts query age from opening, another from the last response, so the portfolio view cannot be compared.
Thresholds in spreadsheets: nobody can show which limit applied on the day a site was reviewed.
Sites compared only with themselves: a site that has always under-reported adverse events looks stable.
Signals without a record: a breach is discussed in a meeting, but the evaluation and the action are not written down anywhere the sponsor can see.
Sponsor data in one pool: studies for different sponsors share tables, and every new report risks showing one sponsor another's data.
Our Approach
How should a CRO approach the build?
Three choices made early keep the analytics comparable, explainable and safe to share.
Define each indicator once
A shared indicator library holds the formula and source fields. Each study sets its own parameters and thresholds in the risk assessment, so portfolio views stay comparable.
Compare sites with their peers
Central monitoring looks for sites that differ from the rest of the study, not just sites that cross a fixed line. A person reviews every flagged site before anything happens.
Record every evaluation
Each signal moves from raised to reviewed to actioned to closed, with names and dates. That record is what the sponsor, and an inspector, will ask for.
Capabilities
What do we build into CRO monitoring analytics?
Modules we build or integrate, sized to your portfolio and the systems you already run.
KRI library and calculator
Indicator formulas defined once, with study parameters and thresholds versioned by effective date.
QTL tracker
Trial-level limits from the risk assessment, current values and the evaluation recorded for every breach.
Central statistical monitoring views
Site distributions for adverse event rates, entry lag and query rates, with outlier sites highlighted for review.
Signal and action log
Every signal with its owner, evaluation, action and closure, linked to the data that raised it.
Targeted monitoring planner
Visit and call lists built from open signals, so CRAs go where the risk is.
Sponsor portal
Dashboards and issue logs per sponsor tenant, with access limited to that sponsor's studies.
Portfolio operations dashboard
Enrolment, query backlog and monitoring workload across studies on the shared library.
Data lineage
Every number traced back to the source system, extract and mapping version it came from.
How It Works
How does study data become a monitoring signal?
The path we build for each study. Every step keeps the sponsor and study identifiers, so separation holds from source to screen.
Extract from study systems
Sites and visits from CTMS, data and queries from EDC, randomization and dispensing from IRT, document status from eTMF.
01
1
Map to one cross-study model
Study, site, participant, visit, query, adverse event and deviation, with study-specific mappings kept under version control.
02
2
Calculate indicators
On the schedule agreed with the study team, using the parameters in force on that date.
03
3
Compare with thresholds and peers
Fixed limits and peer comparisons both run, and each result keeps the rule that produced it.
04
4
Route signals to a person
The central monitor reviews each signal and decides whether it needs action.
05
5
Record the evaluation
Decision, action, owner and due date are saved against the signal.
06
6
Publish to the sponsor
The sponsor's tenant shows its studies, QTL status and open issues.
07
7
Engineering Stack
Systems and standards behind CRO analytics
Chosen to fit the study systems you already license and the sponsors you report to.
Study systems
CTMSEDCIRT or RTSMeTMFSafety database
Data exchange
CDISC ODM exports from EDCVendor APIs and scheduled extractsSecure file transfer to sponsors
Analytics
SQL data warehouseR or Python for statistical monitoringBI dashboards per audience
Security
Tenant separation per sponsorRole-based accessAudit trail on every changeEncryption in transit and at rest
KRI reference
Which key risk indicators should a CRO track?
Each indicator, the system it comes from, what it can point to and what a breach should start. Thresholds come from the study team's risk assessment; we build the calculation and the routing, not the numbers.
| Indicator | Source system | What it can point to | What a breach starts |
|---|---|---|---|
| Screen failure rate per site | CTMS or EDC screening log | Eligibility criteria misread, or recruitment from the wrong population | Central monitor review, then eligibility retraining for the site |
| Data entry lag (visit date to eCRF entry) | EDC audit trail and CTMS visit dates | Site staffing gaps, data entered from memory | Call with the site coordinator, then a targeted visit if it persists |
| Open query age | EDC query records | Unresolved data issues that will block database lock | Escalation to the CRA and the data management lead |
| Adverse event rate against peer sites | EDC adverse event forms | Possible under-reporting of adverse events | Medical monitor review and targeted source data review |
| Protocol deviations per participant | CTMS or deviation log | Procedures not followed as written | Root cause review, and escalation to the sponsor when a QTL is affected |
| Dispensing mismatches | IRT | Kit given to the wrong participant or arm | Immediate review with the unblinded team |
| Essential document gaps | eTMF | Missing or expired site documents | CRA follow-up before the next visit |
Measured Impact
How should a CRO judge its monitoring analytics?
Measures about the analytics itself, reviewed with your clinical operations leads.
Freshness
Data age
Time from a source update to the refreshed indicator.
Closure
Signals closed
Signals with a recorded evaluation and action, by study.
Coverage
Shared library
Studies and sites using the common indicator definitions.
Targeting
Risk-driven visits
Monitoring visits triggered by signals against calendar visits.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Women's Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
Which CROs build monitoring analytics with us?
Teams that have outgrown spreadsheets and vendor exports.
01
Mid-size full-service CROs
One indicator library across a growing portfolio of studies.
02
Functional service providers
Central monitoring offered as a service line to several sponsors.
03
Therapeutic specialist CROs
Indicators tuned to oncology, rare disease or device studies.
04
Central monitoring teams
Peer comparison and signal logs instead of manual listings.
05
CROs adding a sponsor portal
Sponsor dashboards without emailing exports every week.
06
Biostatistics groups
Statistical monitoring code moved from one-off scripts into a governed pipeline.
Integrations
Which systems does the analytics layer connect to?
The systems CRO monitoring analytics reads from and reports to.
Sites, visits and deviations
CTMS
Clinical data and queries
EDC
Randomization and dispensing
IRT or RTSM
Essential documents
eTMF
Adverse event reconciliation
Safety database
Reporting and transfers
Sponsor data platforms
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
General Data Protection Regulation
Implement lawful consent flows, data minimization, and secure processing for global data privacy.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does an analytics CRO engagement work?
We start with one study and grow to the portfolio. Timing depends on scope; we agree a fixed first release on the scoping call.
01
Scoping call
We review your study systems, sponsor reporting duties and the indicators you track today.
02
Indicator workshop
Your clinical operations and biostatistics leads agree the shared library and how studies set thresholds.
03
One study end to end
Extracts, the data model, indicators, signal routing and the sponsor view working for a single study.
04
Portfolio rollout
More studies and sponsors onto the same model, with mappings versioned per study.
05
Support under change control
New indicators and new study systems added through your change process.
Facts and sources
Which rules shape CRO monitoring analytics?
Short facts we design the indicators, records and sponsor separation around, each linked to its primary source.
ICH E6(R3), adopted on 6 January 2025, says the sponsor should set pre-specified acceptable ranges, such as quality tolerance limits at the trial level, and evaluate any deviation beyond them for a possible systemic issue.
Source: ICH E6(R3) Good Clinical Practice, section 3.10.1.3ICH E6(R3) describes centralised monitoring as a timely evaluation of accumulated data by qualified people, and says centralised data analytics can help identify systemic or site-specific issues, including protocol noncompliance and potentially unreliable data.
Source: ICH E6(R3) Good Clinical Practice, section 3.11.4.2A sponsor may transfer any or all of its IND obligations to a contract research organization, the transfer must be described in writing, and any obligation not covered by the written description is deemed not to have been transferred.
Source: 21 CFR 312.52(a) (eCFR)A contract research organization that assumes a sponsor obligation must comply with the regulations that apply to it and is subject to the same regulatory action as a sponsor for failing to comply.
Source: 21 CFR 312.52(b) (eCFR)FDA's final guidance A Risk-Based Approach to Monitoring of Clinical Investigations (April 2023) calls monitoring a quality control tool for determining whether investigation activities are carried out as planned, and covers the monitoring plan and how results are addressed and communicated.
Source: FDA guidance, April 2023
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related services
Related clinical trial software
This page covers monitoring analytics across studies. These pages cover the study systems it reads from.
Clinical data management system development
eCRF design, edit checks and database lock for a single study.
Clinical trial management software
CTMS features for sites, visits and study operations.
eTMF software development
Trial master file structure, document workflow and inspection readiness.
Life sciences software development
Software for sponsors, CROs and research teams.
Clinical trials data volume
What drives the data a study generates, and the platform we build to hold it.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
A key risk indicator is a site-level or study-level measure, such as data entry lag, that points to where monitoring should look. A quality tolerance limit is a trial-level range set in advance for a factor critical to quality. Crossing it starts a documented evaluation and, if needed, reporting.
Your study team does, in the risk assessment for each study, with the sponsor where the contract says so. We build the library, the calculation and the record of which threshold applied on each date. We do not choose clinical or statistical limits.
Yes. Every record carries its sponsor and study identifiers from extract to dashboard, and each sponsor gets a separate tenant with access limited to its studies. Cross-sponsor views are only available to CRO roles that are allowed to see them.
Not by itself. ICH E6(R3) says centralised monitoring can complement and reduce the extent or frequency of site monitoring, or be used on its own, depending on the monitoring plan. The analytics supports that plan; your team decides the mix.
Yes. We read from the systems you license through their APIs, scheduled extracts or CDISC ODM exports, and keep a mapping per study. Nothing in the study systems changes, and they remain the source of truth.
It depends on how many study systems and sponsors are in scope. We agree a fixed first release on the scoping call, usually one study working end to end, and give you a timeline for that release.
Our engineers use AI coding assistants for drafts, tests and refactoring, and every change still goes through code review, automated tests and the same release checks as hand-written code. AI never makes a regulated decision in the delivered system unless that is the agreed design and a person reviews the output.
Industries