Deviations & CAPA¶

When something goes wrong — a deviation from procedure, an out-of-spec result, a near-miss — the response is a structured investigation that ends with action and proof the action worked. QStack provides one opinionated flow: Deviation → Root Cause Analysis → CAPA → Effectiveness Check. Each stage is mandatory, signed, and traceable.

You'll use this module as a Discoverer logging what happened, an Investigator running the root cause analysis, a CAPA Owner carrying an action to completion, an Effectiveness Reviewer confirming it actually worked, or a Quality role holder approving classification, closure, and effectiveness conclusions.

Log a new deviation¶

1. Click New Deviation and fill in:

   Field	What to enter
   Event date	When the deviation actually happened
   Discovery date	When it was noticed — defaults to today
   Discovered by	You, auto-filled — editable if you're reporting on someone else's behalf
   Location / equipment / batch	Where it happened
   Description	What happened, in plain language
   Immediate action taken	What containment happened at the moment of discovery
   Attached evidence	Optional records, photos, or documents

2. Submit. QStack assigns a default investigator based on your tenant's configuration — usually a Quality role holder or their deputy. The investigator can reassign if needed.

Classify a deviation¶

Within a tenant-configurable window (default one business day), the investigator must classify the deviation:

Conduct a root cause analysis¶

Pick one of the supported RCA methods:

• 5-Why — QStack guides you through each "why" iteratively.
• Fishbone (Ishikawa) — a structured form with the standard categories: People, Process, Equipment, Materials, Environment, Measurement.
• Other — free-text narrative, for cases needing a more specialized method.

The RCA must conclude with a stated root cause (or causes), a list of contributing factors, an assessment of whether other batches, processes, or products are similarly at risk, and a QA reviewer signature with meaning Reviewed and approved.

If you conclude "no root cause identifiable" — rare, and something an inspector will scrutinize — you need a Quality role signature and a written justification to record it.

Manage CAPA actions¶

A CAPA is made up of one or more actions, each assigned to a single owner with a target date.

The plan needs at least one of each type unless you explicitly justify skipping one — for example, a genuine one-off event with no recurrence vector, which requires Quality role sign-off.

Each action captures a description, its type, an owner, a target date, effectiveness criteria (how you'll know it worked), and the evidence requirement (a record, a revised SOP, a training completion, etc.).

To complete an action, the owner links the evidence and signs with meaning Performed the work; a reviewer then signs with meaning Verified the information. Each action can complete on its own schedule — the CAPA as a whole is complete only when every action is.

Effectiveness check¶

When the last CAPA action is signed off, QStack automatically schedules an Effectiveness Check for a tenant-configurable lookback window after that action completes — default 90 days. The deviation sits in Awaiting EC until the check concludes; only an Effective verdict closes it.

The Effectiveness Reviewer evaluates against the effectiveness criteria declared in the CAPA actions: were the criteria met in the lookback window, have any similar deviations occurred, and is the new control operating as intended?

The verdict is signed by the Effectiveness Reviewer; closure is signed by a Quality role holder with meaning Authorised for release.

Deviation states¶

Open → In RCA → In CAPA → Awaiting EC → Closed, with a shortcut from Open directly to Closed — No CAPA for deviations classified No GxP Impact.

Cross-module linkages¶

Deviations and CAPAs connect to nearly every other module:

• A CAPA action of "revise SOP-0042" creates a draft revision in Quality Documents, linked back to the CAPA.
• A CAPA action of "re-train QC team" creates ad-hoc training assignments in Training, linked back to the CAPA.
• An audit finding (see Vendors & Audits) can spawn a CAPA, linked to the finding and the audit.
• A complaint (see Complaints) triaged Major or Critical opens a linked deviation; the complaint shows the deviation's live status.
• A CAPA action to change a process, piece of equipment, or supplier raises a change request in Change Control, linked back to the CAPA.
• Records attached as evidence are linked both ways.

The "linked items" panel on a deviation shows every connected object, and a similar panel on every other object shows back-links to deviations.

Reporting¶

• Open deviations by classification (live dashboard tile)
• CAPA on-time closure rate
• Effectiveness pass rate
• Recurrence rate — the percentage of effectiveness checks that fail
• Top root-cause categories (from fishbone analyses)
• Aging — deviations open more than 30, 60, or 90 days
• Per-product, per-process trending

What an inspector sees¶

QA shows the dashboard tile with open deviations and the classification mix, then picks a recent Major deviation so the inspector can follow the full chain — log, RCA, CAPA actions, effectiveness check, closure — with a signature at every stage. If the inspector asks whether there are similar deviations, QA filters by root-cause tag and the trending screen answers.

What this module doesn't do¶

• It doesn't calculate deviation severity for you — classification is a human judgment, captured with rationale.
• It doesn't auto-write the deviation narrative or RCA conclusion.
• It doesn't notify regulators directly — reportability decisions are a human, Quality role responsibility outside the system.