SPCStatistical Process Control

Statistical Process Control is the practice of plotting a process output over time against calculated control limits derived from the process itself, so that you can distinguish the normal random noise the process always has from a real change that warrants investigation — before the change becomes a customer-visible failure.

Walter Shewhart developed the technique at Bell Labs in 1924. The insight is simple and durable: every process varies. The question is not whether variation exists but whether the variation you are seeing is the variation the process always has (common cause, do nothing) or the variation that indicates something has changed (special cause, investigate). SPC is the mathematical answer to that question.

Three things follow from that framing — and the most common SPC failures come from missing one of them:

1. Control limits are calculated from the process, not set by the customer. They describe what the process actually does, not what the customer requires. (See the spec-limits-as-control-limits failure later — this is the single most common SPC mistake in pharma.)
2. A chart with no alerts is not 'good news' — it is the chart doing its job in a stable process. A chart that never alerts is either tracking a perfectly stable process (rare) or has limits too wide to detect anything (common; usually because the limits were calculated from too few points, or the process has changed since the limits were set).
3. SPC is a detection mechanism, not an investigation mechanism. The chart trips → an analyst investigates → the investigation classifies the event (OOT / OOE / OOS) → the classification determines whether a CAPA is opened. SPC by itself fixes nothing.

There are dozens of control chart variants in the literature; in regulated batch manufacturing, you use a small subset. The table below is the practical operating set.

For pharmaceutical batch manufacturing the I-MR chart dominates because you typically only get one value per batch (one yield, one final assay, one bulk density). For per-shift weighings, fill-volume verification, or in-process sampling you typically have a subgroup of n=5–20 and X-bar/R or X-bar/S applies. CUSUM and EWMA are essential for continued-process-verification work because they catch the small persistent shifts (≤1σ) that Shewhart-style limits often miss for many subgroups.

Once you have a chart with control limits, you need to decide what counts as a pattern worth investigating. Two rule sets dominate: the original Western Electric rules (WECO, simpler, fewer false positives) and the expanded Nelson rules (more sensitive to small shifts and trends, more false positives).

The eight Nelson rules — which extend the four classical WECO rules — are:

1. WECO 1 / Nelson 1: One point beyond ±3σ of the centreline (the alarm rule everyone implements).
2. WECO 2 / Nelson 5: Two of three consecutive points beyond ±2σ on the same side.
3. WECO 3 / Nelson 6: Four of five consecutive points beyond ±1σ on the same side.
4. WECO 4 / Nelson 2: Eight consecutive points on the same side of the centreline (run rule).
5. Nelson 3: Six consecutive points trending upward or downward (trend rule).
6. Nelson 4: Fourteen consecutive points alternating up and down (oscillation rule).
7. Nelson 7: Fifteen consecutive points within ±1σ (stratification rule — limits may be too wide, or two processes mixed).
8. Nelson 8: Eight consecutive points outside ±1σ on either side (mixture rule — two distinct populations being charted as one).

Each rule has an associated false-positive rate. Rule 1 alone runs at about 0.27% (the classical ±3σ alarm rate). Adding Rules 2–4 raises the combined false-positive rate to roughly 1% per chart. Loading every Nelson rule on every chart pushes the false-positive rate past 2% — at a hundred points per chart you will get false alarms on a healthy process, the team will start dismissing alerts, and the chart becomes wallpaper.

SPC alerts are not quality events on their own — they are the detection layer that feeds into the quality-event classification stack. The mainline flow is:

1. SPC chart rule trips → 'potential OOT event' raised in the quality module.
2. Analyst confirms the result is real and not a measurement artefact → OOT investigation opened per the customer's OOT procedure (typically a 30-day investigation window).
3. If the trend continues or recurs → escalates to OOE (out-of-expectation) and the investigation deepens; root cause assigned to a category (raw material, equipment, method, environment, operator, measurement).
4. If a result eventually crosses a spec limit → OOS event opened per 21 CFR 211.192 (FDA OOS guidance applies) with the full OOS investigation, retest, and potential batch reject.
5. Confirmed systemic OOT, recurring OOS, or any OOS where root cause is process-related → CAPA opened per 211.100 / 820.100. The CAPA effectiveness check uses the SPC chart itself — if the corrective action worked, the chart should stop alerting.

Two things to notice. First, OOT is within spec by definition — the chart catches the drift before the product fails. The point of SPC is to live almost entirely in the OOT zone and never reach OOS. Second, the CAPA effectiveness check uses SPC. This makes SPC a feedback loop on the QMS itself, not just a manufacturing tool — which is why FDA expects to see SPC and CAPA as one programme, not two.

FDA's January-2011 Process Validation guidance restructured validation into a three-stage lifecycle, and SPC is named throughout:

• Stage 1 (Process Design): statistical techniques used to characterise variability and define the design space. SPC concepts inform CQA / CPP selection.
• Stage 2 (Process Qualification): PPQ batches confirm the validated state. SPC is used to demonstrate the process is in a state of control across the PPQ campaign.
• Stage 3 (Continued Process Verification — CPV): the explicit SPC stage. The guidance requires an 'ongoing program to collect and analyze product and process data that relate to product quality… in such a way to detect undesired process variability'. The 2011 guidance, Section IV.C: 'data collected during continued process verification should be subject to scrutiny, including evaluation of process trends'.

EU GMP Chapter 1 §1.10(b) and ICH Q10 §3.2.5 give the equivalent expectation in their respective frameworks. The practical effect is the same: without an SPC-based CPV programme, your process validation lifecycle has no defensible Stage 3, and the regulator sees a one-time PPQ campaign followed by no evidence the process stayed in control.

The CPV programme is reviewed in the APR / PQR (21 CFR 211.180(e) / EU GMP §1.10) — the annual product review must summarise process performance and any out-of-trend signals, recommend changes, and demonstrate the CAPA effectiveness loop. SPC outputs feed the APR/PQR directly.

1. Inputs from where the data is generated — kiosk weighing events, dispense yields, in-process samples (operator-entered with e-signature), and lab results from the LIMS module (CoA values, particulate counts, dissolution profiles). No separate data-entry layer.
2. Per-chart configuration: chart type (I-MR / X-bar/R / X-bar/S / CUSUM / EWMA / p / np / c / u), subgroup definition, sampling rule, control-limit calculation method (Shewhart constants per ISO 7870-2, custom σ estimator), and the chosen rule set per chart.
3. Auto-calculated control limits from the first 20–25 stable subgroups (or 50 individuals for I-MR), with explicit lock + audit trail when the limits become live; subsequent points use the locked limits until a controlled recalculation event.
4. Real-time alerts as new points are added — Rule tripped + contributing subgroups + chart snapshot pushed to the chart owner via in-app notification, email, and (optionally) SMS via the tenant's configured Twilio channel. Owner acknowledgement requires a reason code and an e-signature per Part 11 §11.50.
5. OOT / OOE / OOS classification workflow — the alert acknowledgement screen offers one-click escalation into the Quality module's OOT/OOE/OOS investigation, with the chart context pre-attached as evidence.
6. Cpk / Ppk calculation per CQA with the chosen subgroup definition — visible on the same screen as the chart, recalculated as new data arrives.
7. Control-limit recalculation as a governed event — requires QA e-signature, captures the rationale (process change, equipment requalification, period review), preserves the previous limits + the date of the change for audit, and re-evaluates historical points against both old and new limits so the change-effect is visible.
8. APR / PQR / CPV pack generation — one-click PDF that includes every chart for the product, a written interpretation of any alerts and CAPAs in the period, the Cpk / Ppk trend, and the regulator-facing summary required by 211.180(e) / EU GMP §1.10. Powered by @react-pdf/renderer (Worker-safe), version-stamped, exported to the regulated-reports bucket with the tenant.id as the first folder of the object name.
9. Mobile-safe at the kiosk and on the QA dashboard — every chart and alert workflow renders correctly at ≤390px CSS width on iPhone with no horizontal scroll, per the project standard.

1. Spec limits used as control limits — guarantees the chart only trips on OOS, defeating the entire point. Spec limits are what the customer requires (set externally); control limits are what the process delivers (calculated from data). Conflating them turns a detection mechanism into a redundant OOS detector. This is the single most common SPC mistake we see in pharma; usually it's because the team confused control limits with action limits.
2. Control limits never recalculated as the process changes — limits from 2022 still in force in 2026 after two validated changes; the chart now describes a process that no longer exists. Worse, the team thinks the chart is healthy because no alerts are firing.
3. Too many rules enabled — every Nelson rule on every chart pushes false-positive rate past 2% per chart-month; alerts get dismissed; the chart stops being useful. Pick the rules that fit the risk profile of the CQA.
4. Chart owners not assigned — alerts fire into the void, no one acknowledges, no investigation is opened. An SPC programme with no named owners per chart is a paper programme.
5. Manual chart maintenance in Excel — slow, error-prone, drifts from the source data, no audit trail, no Part 11 e-signature, no automatic alert dispatch. Acceptable for ad-hoc exploration; not acceptable for the validated CPV programme.
6. Charts only built for finished-product attributes — drift in the process isn't caught until release, at which point the batch is already made. Stage 3 CPV expects charts on the CPPs and on the in-process attributes, not just final release.
7. No link to CAPA — alerts get investigated, root causes get noted in a paragraph, but the CAPA system has no record of what the SPC programme detected and the CAPA effectiveness check is never wired back to the chart. The two programmes drift, regulators notice.