Quality Event

What a quality event is

A quality event is anything that signals a potential or actual departure from approved processes, procedures, specifications, or regulatory expectations. The category is intentionally broad. It's the formal entry point into investigation, risk assessment, and corrective action across the quality system.

Quality events cover a lot of ground: deviations (unplanned departures from procedure), nonconformances (product not meeting specification), OOS and OOT results (lab findings outside or trending outside spec), complaints (customer-reported quality concerns), audit findings (internal or external), equipment failures, supplier issues, security incidents, and any other signal that warrants quality-system attention. Classification at intake determines which downstream workflow handles the event, but capture itself is universal.

Why it matters: events are the signal the system runs on. Programs that capture them promptly and classify them honestly catch issues before they become regulatory events. Programs that gate-keep at intake accumulate informal-handled signals that surface during inspection as evidence the system isn't seeing everything it should.

Why event capture is the leading indicator of QMS maturity

Inspectors read quality event volume, distribution, and trending as a diagnostic for QMS health. Counterintuitively, low event volume isn't always a good sign. It can mean quality is genuinely good, or it can mean the program isn't capturing what it should. The distinguishing signal is whether the events that are captured show evidence of rigorous handling, and whether trending data correlates with operational reality.

Programs with weak event capture usually share a shape. Operations handles things informally because 'it wasn't really a deviation' or 'it was just a one-off'. QA only sees the events someone decided were important enough to escalate. Trending data shows artificially low volume because the denominator is filtered. When inspectors find a deviation noted in a production log that doesn't appear in the quality event system, or a complaint mentioned in an email that wasn't formally captured, the conversation about what else might be missing gets serious.

The chromatography enforcement wave through the late 2010s produced repeated findings where the underlying quality events had been observed but never captured as formal records. The system saw. The system didn't log. It didn't trend. It didn't escalate. The eventual regulatory event was the consequence of months of unsignaled drift.

Inspector perspective: the strongest test for event capture is cross-reference. Pick three categories — deviations in production logs, complaints in customer service emails, OOS results in lab notebooks — and check whether each one is reflected in the quality event system. Inconsistencies here are the strongest signal of gate-kept capture, and they tend to predict broader QMS gaps.

Where quality event obligations come from

Quality event handling is implicit across most quality frameworks and explicit in specific event types:

• 21 CFR §211.192: investigation of any unexplained discrepancy. The implicit obligation: capture the discrepancies.
• 21 CFR §211.180(e): quality unit responsibility for evaluation; events are the primary record type.
• 21 CFR §211.198: complaint files — a specific quality event type.
• 21 CFR §820.90: identification, documentation, evaluation, segregation, and disposition of nonconforming product.
• 21 CFR §820.100: identification of quality data sources including processes, audit results, customer feedback, returned product, and complaints — the event categories that feed CAPA.
• 21 CFR §820.198: complaints as a specific quality event type.
• 21 CFR Part 803 (MDR): device events potentially reportable as Medical Device Reports.
• EU GMP Chapter 1 §1.4(xiv): deviations investigated and documented.
• EU GMP Chapter 8: complaints, quality defects, product recalls.
• EU MDR Article 87: serious incidents vigilance reporting; specific event type.
• ICH Q10 §3.2.1: process performance and product quality monitoring; depends on event capture and trending.
• ICH Q10 §3.2.2 (CAPA): CAPA inputs from quality events.
• ICH Q10 §3.2.4 (Management Review): quality event data is a standing input.
• ICH Q9(R1) (effective 2023): risk evaluation of quality events.
• ISO 13485 §8.3: nonconforming product control.
• ISO 13485 §8.4: analysis of data; trending of quality events.
• ISO 13485 §8.5.2: corrective action based on quality event data.
• MHRA GxP DI guidance (March 2018, updated September 2021): event capture as a data integrity expectation.

What a working quality event program contains

A defensible event program shares a common shape:

• Universal capture access. Anyone who sees a signal can capture an event. Low-friction intake, accessible from operational floors and lab benches, not restricted to QA.
• Capture criteria documented but broad. The SOP defines what should be captured and errs on the side of broader capture. 'When in doubt, log it' is the explicit default.
• Intake metadata complete. Date, time, location, observed-by, witnessed-by where applicable, immediate containment action taken, initial description in the operator's own words.
• Initial triage by QA. Within a defined timeline (typically same day for production-floor events). Classification (deviation, complaint, OOS, audit finding, security, other), severity, routing to the appropriate workflow.
• Severity-driven routing. Critical events route to immediate management notification; major events to investigation assignment within defined SLA; minor events to operational disposition with QA oversight.
• Workflow routing by classification. Deviation goes to deviation investigation; complaint goes to complaint handling; OOS goes to FDA 2006 Phase 1/2 investigation; audit finding goes to audit follow-up; systemic patterns go to CAPA initiation.
• Investigation triggered per workflow. Each event type has defined investigation expectations.
• Aggregate trending. Counts by category, severity, area, root cause, time period. Recurring patterns flagged.
• Escalation per severity. Risk-based, SLA-driven, automatic where the system can drive it.
• CAPA linkage where systemic. Events with systemic root cause route to CAPA.
• Closure with documented disposition. Every event closes with conclusion, action taken, and any CAPA reference.
• Standing Management Review input. Event metrics under ICH Q10 §3.2.4.
• Cross-record traceability. Events link to related batches, equipment, suppliers, prior similar events, and resulting CAPAs.

What strong event programs do

The patterns that hold up at inspection:

• Capture broadly at intake. Default 'log it when in doubt'. No gate-keeping at capture.
• Universal access to capture. Operations, lab, supply chain, customer service can all log events.
• Intake metadata complete. Sufficient for triage without back-and-forth.
• Initial triage by QA promptly. Within defined timeline, not days later.
• Severity classification consistent. Per documented criteria, not improvised per event.
• Routing by classification automatic. The workflow handles it; humans don't decide each one.
• Investigation triggered per type. Each event type follows its defined investigation discipline.
• Aggregate trending visible. Counts, distributions, time series; dashboards or scheduled reports.
• Escalation per severity automatic. SLA-driven; doesn't require a human escalation decision.
• CAPA linkage for systemic patterns. Recurring root cause means CAPA.
• Closure with documented disposition. No event closes without conclusion, action, and CAPA reference where applicable.
• Standing MR input. Event metrics in MR under ICH Q10 §3.2.4 and ISO 13485 §5.6.2.
• Cross-reference to operations. Periodic check that operational records (production deviations, complaints in customer service, lab OOS) actually appear in the event log.
• Training on event capture. Operational personnel trained on what to capture and how.

How Complere supports quality event management

Capture culture belongs to your team. No platform can decide for your operators what's worth logging. What Complere can do is stop being the reason people don't capture — so the door stays open, the form stays short, and the signal actually reaches you.

Anyone on your team with access can log an event from wherever they are: production floor, lab bench, QA workstation, supplier handling. The intake form asks for what your team needs at the moment of capture — description in the operator's own words, location, severity, immediate containment, evidence — and nothing more. The friction stays low because the captured event is the start of the story, not the end. Classification comes after, when QA can look properly.

Once captured, the event drives what happens next. The severity matrix your team has configured decides the routing. Critical events trigger immediate notifications to the people you've named. Major events get investigation assignment inside the SLA windows you've set. Minor events route to operational disposition with QA oversight. As your investigators learn more, they can revise the classification, and every change — who changed it, when, why — stays preserved on the record.

Each event type follows the investigation discipline your team has set up for it. Deviations move through your root cause analysis with your controlled cause taxonomy. Complaints route through complaint handling with reportability assessment. OOS results trigger the Phase 1 / Phase 2 path aligned to FDA 2006 guidance. Audit findings link back to the audit they came from. Events with systemic root cause route into CAPA from the same record.

You can see your aggregate event data the way regulators want to see it: counts by category, severity, area, root cause, time-to-closure, trends over time. Your Management Review pulls this directly. Your auditor can see the line from a batch to the events on it, the suppliers behind them, and the CAPAs that closed them out.

What stays with your team: protecting the capture culture (no gate-keeping at intake), the classification criteria, the severity matrix, the SLA windows, the investigation discipline applied to each event type, the cadence of trending review, and the judgment about when patterns warrant CAPA or escalation to senior leadership. Complere runs the workflow; the quality system is your team's.

Related event and follow-up terms

Quality event is the broad category that connects to most quality-system processes:

• Deviation — specific quality event type
• OOS — laboratory quality event type
• Complaint Handling — post-market quality event type
• CAPA — quality events with systemic root cause route to CAPA
• Management Review — event metrics are MR inputs