Form: Quality Event Triage and Classification Record

This is a ready-to-use triage record. It enforces the order that keeps classification honest: contain, capture facts, scope, assess patient impact, score, then assign a tier with a justification including why not higher, and screen for reportability before the investigation starts. Replace every <<FILL: ...>> placeholder with your own specifics and route the completed record per your classification SOP. A worked filled specimen follows the blank form. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Facts (objective, no root cause)

2. Immediate containment

3. Affected scope

4. Patient-impact statement

Anchoring rule: if “could this reach a patient and cause harm” is yes or unknown, the event is critical until proven otherwise.

5. Severity drivers / risk ranking (for non-obvious tiers)

6. Classification

7. Reportability screen (complete at classification)

8. Escalation triggered

9. Re-classification log (evidence-based only)

10. References

21 CFR 211.192, 211.100(b), 314.81, 600.14 / 1271.350; EU GMP Chapter 1 and Annex 16; ICH Q9(R1) and Q10; ICH E6(R3); 21 CFR Part 4 where applicable.

Confirm the current version of each reference before issue.

Filled specimen

Illustrative completed record. Replace with your own.

• Event. OOS-2026-0207. HPLC integration parameters were changed by an analyst with no audit trail entry, and the change moved a finished-product assay result from OOS toward passing.
• Facts. Discovered during routine audit trail review of run HPLC-07-2206-031; the chromatogram, audit trail, and sequence were frozen.
• Containment. Result placed on hold; the analyst’s account activity preserved; batch held.
• Scope. All results from the same analyst and instrument in the review period pulled for examination.
• Patient impact. SISPQ: yes (assay/strength is reportable). Reach patient: batch in quarantine. Harm: serious if a sub-potent batch released. Data trustworthy: no, this is a confirmed data integrity event, defaults high.
• Classification. Critical. Drivers: confirmed DI event affecting a reportable result that drives disposition. Why not major: the integrity of the very result used for release is compromised, so the result cannot be trusted at all.
• Reportability screen. Field alert screen: monitored, product contained; no distribution. Documented at classification.
• Escalation. QA head and site quality lead notified same day; formal investigation with batch impact across the analyst’s other results; CAPA opened on access controls and audit trail configuration.
• Re-classification. None; remained critical.

Common inspection findings this record prevents

• A tier with no written justification and no “why not higher.”
• No explicit patient-impact statement.
• A reportability decision made after the investigation, missing the regulatory clock.
• A scope that stopped at one batch when others were associated.
• A silently overwritten initial classification.

How to adapt this record

1. Map the event-type field to your QMS categories.
2. Keep the “why not one tier higher” field mandatory; it forces reasoning and gives the inspector their answer.
3. Wire the reportability screen so it is completed at classification, not at closure.
4. Preserve the re-classification log; never overwrite the first tier.
5. Confirm every cited regulation against the current version before use.