Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Form Plug-and-play starting point Clinical & GCP

Form: Quality Tolerance Limit (QTL) Definition and Breach Record

A plug-and-play form and register for clinical quality tolerance limits under ICH E6: the critical-to-quality factor, the parameter, the limit and secondary threshold, the rationale, monitoring, and the breach investigation and action, with a filled specimen.

Document type: Form

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use form for defining a clinical quality tolerance limit (QTL) and recording a breach and its investigation, under the risk-based quality management expectations of ICH E6. A QTL is a predefined threshold on a parameter important to participant safety or result reliability; crossing it flags a possible systematic problem and triggers investigation, not an automatic pass or fail. Breaches and the actions taken are summarised in the clinical study report. Replace every <<FILL: ...>> placeholder with your specifics and route it through your quality management plan and document control. A worked filled specimen follows. Verify cited regulations against the current source. This is general guidance to adapt, not regulatory advice.

Part A: QTL definition (set at protocol design)

FieldEntry
Study / protocol<<FILL>>
QTL ID<<FILL: e.g. QTL-01>>
Critical-to-quality (CtQ) factor<<FILL: e.g. reliability of the primary endpoint>>
Parameter measured<<FILL: e.g. % of primary-endpoint events lacking source to adjudicate>>
Quality tolerance limit<<FILL: the threshold that signals a systematic issue>>
Secondary (warning) threshold, if used<<FILL: an earlier trigger for a closer look>>
Rationale for the limit<<FILL: why this level; statistical basis where relevant>>
Detection method / frequency<<FILL: how and how often the parameter is monitored>>
Predefined response if breached<<FILL: escalation, investigation, likely actions>>
Owner<<FILL: role accountable>>
Approved by / date<<FILL>>

A QTL is a tripwire for a systematic problem, not a target every site or subject must always meet. Set a small, meaningful set of QTLs on the factors that actually drive safety and reliability, rather than a limit on every metric.

Part B: Breach record (completed if the limit is crossed)

FieldEntry
QTL ID<<FILL>>
Date limit crossed / detected<<FILL>>
Observed value vs limit<<FILL>>
Scope (which sites/regions/subjects)<<FILL>>
Investigation summary (root cause)<<FILL>>
Systematic issue confirmed?<<FILL: Yes/No>>
Action taken (CAPA)<<FILL>>
Effectiveness check<<FILL>>
To be reported in the CSR<<FILL: Yes>>
Reviewed by / date<<FILL>>

Field definitions

FieldFormatRequiredWhoWhen
CtQ factor / parametertextYesStudy teamAt design
Limit / thresholdnumericYesStudy team + statisticsAt design
RationaletextYesStudy teamAt design
Breach detected / valuedate / numericYes (on breach)Central monitoringOn detection
Root cause / actiontextYes (on breach)Study team / QAOn investigation
CSR reporting flagYes/NoYes (on breach)Study teamOn investigation

Filled specimen

Illustrative, values invented, from a multinational cardiovascular outcomes trial.

Part A. Study CV-500. QTL-02. CtQ factor: reliability of the adjudicated primary endpoint (major adverse cardiac events). Parameter: percentage of events submitted to the adjudication committee that lack the source documentation needed to adjudicate. Limit: <<FILL: an agreed small percentage>> of submitted events, set at protocol design. Warning threshold: half the limit. Rationale: above this rate, missing source would systematically weaken endpoint reliability; the level was agreed with the statistician against the expected event rate. Detection: central monitoring dashboard, reviewed monthly. Predefined response: escalate to the quality management lead, investigate across sites, deploy corrective action. Owner: clinical quality lead. Approved 2026-03-01.

Part B. Limit crossed and detected 2026-09-15; observed value exceeded the limit, driven by three sites. Investigation found a common cause: the sites were not uploading discharge summaries with the event packet. Systematic issue confirmed: Yes. Action: a source-document checklist added to the event-submission workflow and targeted re-training at the three sites, with the coordinating centre confirming the next month’s submissions were complete. Effectiveness check: the parameter returned below the warning threshold within two monitoring cycles. To be reported in the CSR: Yes, the breach and the action are summarised there. Reviewed by clinical quality lead 2026-10-20.

The point the specimen makes: the QTL did its job. It surfaced a systematic documentation gap early enough to fix it and to describe transparently in the clinical study report, rather than discovering at database lock that a set of primary events could not be adjudicated.

Use madhadi.com as an app Full screen, works offline, one tap from your home screen.