Review by exception is only defensible if the tool that decides what counts as an exception is itself specified, validated, and negative-tested. This document specifies that rule set: what each rule looks for, why it covers a real data integrity risk, its acceptance criteria, and the planted-event test that proves it fires. Without this specification, an inspector’s first question (“how do you know the report catches a deletion?”) has no answer. Replace every <<FILL: ...>> placeholder, route the specification through change control, and hold it as the requirements baseline the exception tool is tested against. A filled specimen for a chromatography data system follows. Verify each cited regulation against the current source before you rely on it.
Why this specification exists (regulatory basis)
The MHRA GxP Data Integrity guidance and PIC/S PI 041 permit review by exception only when the exception process is documented, risk-justified, and demonstrated to be effective. The exception query, report, or system function is a GxP function: if it misses a real exception, the whole review misses it. It must be specified, validated, negative-tested, and change-controlled like any other computerized-system function under 21 CFR Part 11 and EU GMP Annex 11, using an effort proportionate to risk consistent with the FDA Computer Software Assurance approach.
Document control header
| Field | Entry |
|---|---|
| Specification title | Audit Trail Review-by-Exception Rule Set for <<FILL: system type / name>> |
| Document number | <<FILL: SPEC-ID, e.g. DI-SPEC-007>> |
| Version | <<FILL: version>> |
| Effective date | <<FILL: date>> |
| System(s) in scope | <<FILL: system name / ID / environment>> |
| Exception tool implementing this spec | <<FILL: report/query/script name + validation record ref>> |
| Owner | <<FILL: role, e.g. Data Integrity Lead>> |
1. Purpose and scope
This specification defines the exception rules the review tool must implement so that human review focuses on the audit trail entries that carry data integrity risk. It applies to the systems listed in the header. It defines requirements only; the tool that implements them is validated separately against this specification and referenced above. The non-exception population is covered by the deterministic application of these rules plus the periodic leak check in section 4.
2. Rule catalog
Each rule has a unique ID, a trigger definition, the risk it addresses, the fields the exception output must carry, and an acceptance criterion. Add or remove rules to match the system’s real audit-trailed events and your data criticality assessment.
| Rule ID | Trigger (what the rule flags) | Data integrity risk addressed | Required output fields | Acceptance criterion |
|---|---|---|---|---|
<<FILL: R-01>> | Record, file, or injection deleted or aborted | Removal of a failing result | Timestamp, user, object ID, action, reason | Flags every delete/abort in the period; zero misses in negative test |
<<FILL: R-02>> | Result reprocessed or re-integrated | Manipulation of a reported value | Timestamp, user, old/new result, reason | Flags every reprocess; original value retained and shown |
<<FILL: R-03>> | Manual integration applied | Subjective change to a peak | Timestamp, user, object ID, reason | Flags every manual integration event |
<<FILL: R-04>> | Sample renamed or re-identified | Mislabeling a failing sample | Timestamp, user, old/new name | Flags every rename |
<<FILL: R-05>> | Method or parameter changed during/after acquisition | Test-into-compliance | Timestamp, user, method version delta | Flags every mid-sequence method change |
<<FILL: R-06>> | Reason-for-change blank or non-meaningful (single character, “x”, “n/a”) | Concealment via empty reason | Timestamp, user, object ID, reason text | Flags blank and non-meaningful reasons per the defined pattern list |
<<FILL: R-07>> | Acquisition outside the planned sequence | Unofficial or trial injection | Timestamp, user, sequence context | Flags out-of-sequence acquisitions |
3. Reason-quality rule detail
The blank/non-meaningful reason rule (<<FILL: R-06>>) needs an explicit definition so it is deterministic and testable. The tool flags a reason for change as non-meaningful when it matches any of: empty; length below <<FILL: n>> characters; equals any value in the block list (<<FILL: e.g. x, n/a, na, see analyst, correction, error>>, case-insensitive); or is auto-filled default text. Maintain the block list under change control; do not let it be edited outside this specification.
4. Leak check (non-exception population)
Because the human never reads the non-flagged entries individually, verify periodically that the rules are not leaking. On a defined cadence (<<FILL: e.g. quarterly>>), pull a sample of the non-exception population and review it manually; any risk-relevant event found there that no rule flagged is a specification gap and triggers a rule update under change control. Record the leak-check result on the periodic review record.
5. Negative-test protocol (proves the rules fire)
Validation of the tool against this specification must include planted events. Running the report and getting output is not evidence; catching a known planted event is. For each rule, create a controlled test event in a test or qualification environment, run the exception tool over the period containing it, and confirm the event appears in the output with the required fields.
| Test ID | Planted event | Rule expected to fire | Expected output | Result (Pass/Fail) | Tester / date |
|---|---|---|---|---|---|
<<FILL: NT-01>> | Delete one injection | <<FILL: R-01>> | Deletion flagged with user, time, object | <<FILL>> | <<FILL>> |
<<FILL: NT-02>> | Reprocess one result | <<FILL: R-02>> | Reprocess flagged, old and new value shown | <<FILL>> | <<FILL>> |
<<FILL: NT-03>> | Enter a one-character reason for change | <<FILL: R-06>> | Reason flagged as non-meaningful | <<FILL>> | <<FILL>> |
<<FILL: NT-04>> | Change the method mid-sequence | <<FILL: R-05>> | Method change flagged | <<FILL>> | <<FILL>> |
Acceptance for the negative-test set: every planted event is flagged with its required output fields, and no rule requires more than the defined number of <<FILL: e.g. one>> re-runs. A single missed planted event fails validation until the rule is corrected and re-tested.
6. Change control and revision
Any change to a trigger, the block list, or the output fields is a change to a validated GxP function. It goes through change control, re-runs the affected negative tests, and updates this specification’s version. A silently editable rule set is not review by exception; it is an unvalidated filter.
7. References
21 CFR Part 11 (electronic records; audit trails); 21 CFR 211.194. EU GMP Annex 11, sections 1 (risk), 4-7 (validation), 9 (audit trails). MHRA GxP Data Integrity Guidance; PIC/S PI 041 (review by exception). FDA Guidance, Computer Software Assurance for Production and Quality Management System Software (risk-based assurance).
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows the rule catalog and two negative tests completed for an example chromatography data system. Values are illustrative.
| Rule ID | Trigger | Risk addressed | Acceptance criterion |
|---|---|---|---|
| R-01 | Injection deleted or aborted | Removal of a failing result | Flags every delete/abort; zero misses in negative test |
| R-02 | Result reprocessed / re-integrated | Manipulation of reported value | Flags every reprocess; original retained and shown |
| R-06 | Reason blank or < 3 chars or in block list | Concealment via empty reason | Flags all non-meaningful reasons per block list |
Negative test extract:
| Test ID | Planted event | Rule | Result | Tester / date |
|---|---|---|---|---|
| NT-01 | Deleted injection HPLC-07-2207-014 in QUAL env | R-01 | Pass, flagged with user analyst_test, 21 Jul 2026 14:03, object 014 | J. Ruiz, 21 Jul 2026 |
| NT-03 | Reason for change entered as “x” | R-06 | Pass, flagged as non-meaningful reason | J. Ruiz, 21 Jul 2026 |
Both planted events were flagged with the required fields, so the tool is shown to detect real events, not merely to execute. That is the difference between a validated exception process and a report nobody has tested.
Common inspection findings this specification prevents
- Review by exception claimed, but the report was never validated or negative-tested.
- The exception report was edited ad hoc, narrowing what gets flagged, with no change control.
- Non-meaningful reasons (“x”, “n/a”) pass because no rule defines what “meaningful” means.
- Trivial events flagged while high-risk events (method changes, deletions) are silently omitted.
- No leak check, so nobody can say whether the non-exception population is trustworthy.
How to adapt this specification
- Set the document number and name the exact system(s) and exception tool it governs.
- Replace the rule catalog with the real audit-trailed events your platform produces and rank them against your data criticality assessment.
- Define the reason-quality block list and minimum length explicitly so the rule is deterministic.
- Write and execute the negative tests in a test or qualification environment, and reference the validation record.
- Put the whole rule set under change control and confirm every regulation in section 7 before issue.