Rework Routing

Rework routing is the explicit, controlled path in MES that diverts nonconforming or at-risk work-in-process (WIP) to additional or alternative operations, test gates, and QA decisions so it can be brought back into specification. Unlike ad hoc fixes, a rework route is predesigned, risk-assessed, capacity-aware, and procedurally defined with required materials, tools, equipment states, signatures, sampling plans, and pass/fail criteria. It also encodes reintegration logic: when reworked lots or units can rejoin the nominal route and under what release conditions.

In pharmaceuticals, the practice is framed as reprocessing (repeating a step) and reworking (using a different process to meet specs). Both require scientific justification, documentation within the batch record, and QA approval under 21 CFR 211.115 and 211.188. In medical devices, 21 CFR 820.90 requires documented rework instructions and re-verification to ensure reworked product meets current approved specifications. Regardless of sector, electronic records and signatures, audit trails, and access control must satisfy 21 CFR Part 11 when systems are electronic.

Regulators differentiate repeat of the same step (often termed reprocessing in pharma) from use of an alternative path (reworking). 21 CFR 211.115 allows reprocessing when there is written procedure, defined testing, and stability/quality not compromised; 211.188 requires the batch production record to capture specific data describing any reprocessing/reworking performed, including results of testing. For devices, 21 CFR 820.90(b)(2) requires documentation of rework, including re-evaluation and retesting per current approved procedures, and records of the rework activities.

All electronic evidence—procedural execution, parameter values, decisions, and outcomes—must be trustworthy, attributable, contemporaneous, and available. 21 CFR Part 11 requires validated systems, secure, computer-generated, time-stamped audit trails, and binding electronic signatures; MHRA’s GxP data integrity guidance reinforces the need for robust controls on user access, audit trail review, and configuration management. An MES rework route therefore is not only process control—it is a compliance mechanism linking QMS decisions (NCR/deviation, CAPA) to executed work and release.

• Pharma: reprocessing/reworking allowed with scientific justification; record in BPR; QA approval (21 CFR 211.115, 211.188).
• Devices: rework requires defined instructions and full re-verification against current specs (21 CFR 820.90).
• Electronic controls: validation, audit trails, and e-signatures per 21 CFR Part 11; follow MHRA DI expectations for review.

Rework routing is most robust when encoded in ISA-88 recipe artifacts. Master recipes define rework as exception branches or alternative procedures with explicit entry conditions (e.g., test failure modes, parameter out-of-bounds) and exit criteria (e.g., in-spec confirmation, QA disposition). Unit procedures, operations, and phases localize the tangible steps (e.g., reblend, reheat, re-inspect), each with parameter limits, interlocks, and sampling plans. This structure prevents uncontrolled operator improvisation and supports versioned change control.

At runtime, control recipes inherit the branch logic and instantiate work instructions, test steps, equipment states, and hold points. ISA-88 procedural elements map directly to MES operation steps and electronic work instructions with enforced e-signatures and double-witnessing where required. The result: predictable, auditable behavior when nonconformance is detected, with enforced repeatability and complete data capture for investigation and release.

Rework routing lives at ISA-95 Level 3 (MES), but depends on Level 4 (ERP) for cost, lot availability, and rework authorization economics; on LIMS for re-test requests and results; and on WMS for physical movement and quarantine. Production performance and genealogy events must harmonize across systems to prevent orphaned or duplicate history when a lot splits for rework and later merges back. Interfaces should carry: disposition codes, operation/phase results, sample IDs and results, lot-sublot relationships, and release status changes.

Electronic controls must align with 21 CFR Part 11: interfaces should preserve original timestamps, user IDs, and system-origin flags; audit trails must capture payload, before/after values, and reason for change where rework parameters are adjusted under deviation. Practical implementation follows GAMP 5 risk-based validation—focusing testing on rework decision logic, branching, reconciliation, and data integrity at boundaries.

• ERP: cost collection, WO updates, and material availability for rework lots.
• LIMS: test orders/results for re-qualification gates; CoA updates.
• WMS: status transitions (available → quality hold → rework WIP → releasable), bin/zone enforcement.
• QMS: NCR/deviation linkage, approvals, and CAPA triggers tied to rework frequency or severity.

Every rework route requires clear decision gates. Typical flow: detection (in-process check, OOS/defect), containment (quarantine), investigation (deviation/NCR), risk assessment (product impact, material mix-up risk, stability implications), authorization (QA approves rework with conditions), execution (procedural steps), verification (tests/inspections), and final disposition (release, downgrade, or scrap). Limits should be encoded (e.g., max rework cycles, allowable parameter ranges, permissible blending ratios) with automated stops when exceeded.

Pharma-specific considerations include potential stability impact and need for additional validation if reworking becomes routine; device-specific considerations include maintaining biocompatibility/sterility claims and ensuring verification against current specifications. In all cases, the batch record or DHR must contain the justification, the exact instructions used, identities of operators and approvers, equipment states, measured results, and final verification outcomes per 21 CFR 211.188 and 820.90.

1. Define rework entry conditions mapped to specific failure modes.
2. Pre-authorize procedural content with QA signatures and effectivity dates.
3. Enforce lot/serial holds and physical segregation via WMS.
4. Require independent verification post-rework; disallow self-approval.
5. Record all data contemporaneously with secure audit trails (Part 11).

Rework creates complex genealogy: a lot may split into a rework sublot and a conforming sublot, which later merge. MES must maintain forward and backward trace across all splits/merges and track each unit’s processing history. WMS and ERP must reflect matching quantities and statuses to avoid ghost inventory and yield distortion. Backflush logic must be re-executed or reversed where materials are removed/added during rework; reconciliation rules should check for mass balance plausibility.

Define whether reworked output inherits the parent lot number with a suffix (preferred for traceability) or is assigned a new child lot; both approaches must retain linkages for one-up/one-down traceability. Sampling plans should recognize mixed-homogeneity risk in reworked blends. Finally, disposition codes should be granular (e.g., reblend, re-wash, re-inspect, re-label) to support trending and CAPA thresholds.

Rework must culminate in verification activities that are at least equivalent in rigor to the original acceptance criteria. For drugs, this may include additional potency, impurity, or stability-indicating tests depending on the rework’s impact; for devices, dimensional, functional, and where applicable, sterility or packaging integrity verification must reflect current specifications. LIMS integration should enforce test plan selection based on rework type and product risk profile.

Where rework becomes frequent or systemic, management review and CAPA should evaluate root causes and process capability, with potential updates to the control strategy. Continuous monitoring programs (e.g., CPV) should flag shifts in first-pass yield and rework rate; thresholds can trigger engineering change or validation impact assessment. Release decisions, with QA signatures, must cite the specific rework instruction version executed and the objective evidence reviewed.

Because rework often occurs under deviation or time pressure, data integrity risk is elevated. Part 11 requires validated systems, unique user IDs, time-stamped audit trails that are secure and computer-generated, and binding e-signatures for approvals. MHRA DI guidance expects periodic audit trail review, segregation of duties, and lifecycle control of configurations (e.g., rework parameters, limits, and instructions).

• Capture the full decision chain: detection → investigation → risk assessment → authorization → execution → verification → disposition.
• Require dual signatures for QA authorization and final release; implement two-person rule for high-risk products.
• Enforce contemporaneous data entry with system clocks synchronized; restrict backdating.
• Audit trail events for all critical fields (limits, instructions, test plans) with reason-for-change prompts.
• Link every rework record to its originating NCR/deviation and CAPA identifiers.

Ensure that interface messages preserve source-system identifiers and user attribution; avoid transforming or overwriting original values in downstream systems. Validate filters/reports used for release to confirm they render complete and unaltered data sets relevant to the rework decision.

Rework routing configurations are high-impact GxP functions and demand risk-based Computer Software Assurance (CSA)/CSV per GAMP 5. Treat routing logic, holds, and e-signature steps as GxP-critical; test normal path, each rework branch, boundary conditions (e.g., max rework cycles), and failure handling. Validate integrations to ensure that rework state transitions, genealogy splits/merges, and test results propagate accurately and are reconciled.

Change control must cover recipe versions, rework instruction content, limits, equipment qualification states, and training. Where a rework path is novel or materially changes product risk, assess validation impact and, for drugs, evaluate whether supplemental stability or process validation evidence is warranted. Maintain a validation traceability matrix tying user requirements (entry/exit criteria, approvals, data capture) to test evidence and objective acceptance results.

Rework rate is a lagging indicator of process capability and control strategy effectiveness. Track first-pass yield (FPY), rolled throughput yield, rework cycle time, and cost of poor quality (CoPQ) by product, line, and failure mode. Trend rework by instruction type to identify the biggest drivers; use statistically valid sampling and Nelson-rule-based SPC alerts to catch emergent shifts. Integrate with S&OP and capacity planning—rework consumes constrained resources and can cause schedule risk.

On the financial side, allocate rework labor, material, and scrap to the originating work order and, where possible, to the specific defect code. Feed CAPA and design-control loops (for devices) or QbD control strategy updates (for drugs) with empirical outcomes of rework. Management review should set action limits (e.g., trigger CAPA if rework exceeds X% or repeats for the same mode 3 times in 90 days) and verify CAPA effectiveness with sustained metric improvement.

• Define rework action limits by product risk and lifecycle phase.
• Instrument routes to emit granular events for SPC and OEE/FPY calculations.
• Use A3/8D to eradicate top rework causes; verify with backsliding checks.

V5 Ultimate implements rework routing as versioned, risk-classified branches within the MES recipe model, with enforced QA disposition steps, parameter limits, test-plan linkage, and inventory/quarantine controls. A single record spans MES execution, QMS deviation/NCR and CAPA linkage, LIMS test orders/results, WMS status and movement, and maintenance state for equipment used, enabling contemporaneous evidence collection for 21 CFR 211.188 and 820.90. Part 11 controls include binding e-signatures, secure audit trails, and role-based access with segregation of duties.

Frequent issues include informal, undocumented fixes; uncontrolled parameter overrides; failure to place lots on quality hold; missing lineage on splits/merges; and reconciling only ERP quantities while leaving MES/WMS histories inconsistent. Another pitfall is using generic rework instructions that do not map to the specific failure mode, undermining verification sufficiency. Finally, audit trails that omit configuration changes to rework limits or instructions will not meet Part 11 or MHRA DI expectations.

• Use specific rework instructions per defect code; avoid omnibus procedures.
• Disallow rework loops beyond a defined maximum; require escalation.
• Automate holds and physical segregation; never rely on paper tags alone.
• Continuously reconcile genealogy and inventory across MES/ERP/WMS.
• Periodically review audit trails for rework-related changes and approvals.