Wat te doen als SMEPAC-tests mislukken: hoofdoorzaak, hertesten en technische oplossingen

A containment run that produces a failure result is not, by itself, a request to retest. It is a request to investigate. Teams that go directly from a failed result to a retest protocol—without resolving what changed, what leaked, or what the test was actually measuring—often reproduce the same nonconformance at full cost, then face a harder conversation about whether the equipment or the program is the problem. The core judgment is simpler than it first appears: before any retest is authorised, the team must be able to describe what caused the failure, what was changed in response, and why that change prevents recurrence under comparable conditions.

Root-Cause Review Before Retesting

The first error most teams make after a failed SMEPAC run is treating it as a hardware confirmation rather than as an open question. A failed result tells you that containment was exceeded under the conditions of that test. It does not tell you whether the source was equipment, operator, protocol design, or the gap between the laboratory test environment and the real-world process being simulated.

One condition worth checking immediately is whether a static leak test result and the SMEPAC result are telling the same story. They often do not. A machine can fail a static leak test by a small pressure margin while remaining in functional depression and producing acceptable SMEPAC data. The reverse is also possible: an isolator that passes a static leak test can still emit detectable surrogate during a dynamic run if the failure originates at an operator-dependent step rather than a structural interface. Reading the two datasets together—rather than treating either one as definitive—is a more reliable basis for root-cause direction.

A failed static leak test does not confirm a SMEPAC failure; the two datasets require joint interpretation before any root cause is named.

A second boundary condition is the lab-to-manufacturing disconnect. SMEPAC testing measures containment device performance under laboratory conditions, with specific task sequences, defined airflow, and controlled operator movements. If the process being simulated does not reflect what actually happens at the equipment during production—different transfer rates, additional penetrations in use, varied operator technique—then the failure may be reflecting that gap rather than a fundamental equipment deficiency. Before attributing a failed result to hardware, the review should confirm that the test conditions were representative of the intended process, and that any differences have been examined as potential contributors.

Material transfer remains the highest-risk moment in isolator operation, and this is where containment performance most often degrades. A root-cause review that does not specifically examine what happened at each transfer step—entry, exit, and intermediate transfers—is likely to miss the actual event that produced the emission.

Protocol, Operator and Hardware Causes of Failure

Once the decision is made to investigate rather than retest, the review needs a structured way to sort candidate causes before committing to a corrective action. Failures typically fall into three overlapping categories: protocol design issues, operator execution issues, and hardware integrity issues. The overlap matters because a hardware leak point may only activate under a specific operator motion or task sequence, meaning a single root cause may not fully explain the result on its own.

The table below maps common failure sources across these categories and identifies where the inspection should focus.

Hardware micro-leak sources deserve specific attention because they are easily missed during a post-run review that focuses on the procedure rather than the physical system. From field experience with isolators, common micro-leak points include Rilsan fittings installed without nose cones, through-wall penetrations, gaskets embedded in instrumentation, joints on inflatable gaskets, valves retaining residual particles that prevent full closure, pressure measurement ports, electro-pneumatic valve housings, and compartments that are external to the main containment envelope but share penetrations with it. This list reflects observed failure patterns from isolator operation, not an exhaustive fault tree for every containment system, but it provides a practical inspection sequence when a micro-leak is suspected and no obvious macro-leak is present.

Micro-leak sources at instrumentation penetrations and valve housings are regularly missed in post-run reviews that focus only on procedural execution.

The risk in this phase is narrowing the investigation too quickly. A protocol gap and a hardware gap can both be present in the same failed run. If the review resolves the protocol issue without checking physical interfaces, and the retest is subsequently run under a corrected procedure, any remaining micro-leak will produce the same emission—this time under improved conditions, which makes the next failure harder to explain.

Procedure Change Versus Interface Redesign

The choice between a procedural fix and an interface redesign is not a resource decision; it is a root-cause decision. Implementing a procedure change when the emission source is a physical interface produces a result that may pass under controlled test conditions while remaining vulnerable under normal operational variability. The distinction matters because a procedural fix depends on consistent operator execution in every subsequent run, while an interface change removes the failure mechanism regardless of how the operator performs.

The condition that determines which approach is appropriate is whether the leak source is operator-dependent or physically fixed. If the failure trace points to transfer technique, airlock use sequence, or sampling method, a procedural correction is faster to implement and may genuinely address the root cause. If the failure trace points to a seal joint, a filter housing connection, a transfer port interface, or any other mechanical boundary, a procedural fix may reduce but is unlikely to eliminate the emission.

A case-based lesson from HPAPI oral solid dosage facilities is relevant here: where SMEPAC-supported risk assessments identified leakage at specific equipment interfaces, the response prioritised engineering measures—closed transfer systems, safe-change filter arrangements, redesigned isolator interfaces—rather than relying on additional PPE requirements. The logic is straightforward: heavy PPE shifts exposure control to the operator rather than removing the exposure mechanism. Whether this prioritisation is appropriate for a specific project depends on the risk assessment outcome for that process, but it reflects a sound engineering hierarchy that is difficult to argue against when containment data shows a physical leak point.

There is also a narrower consideration on the static leak test side. If a machine fails a daily leak test by a small pressure margin but produces acceptable SMEPAC results, the manufacturer recommendation is that the automatic leak test cycle parameters and acceptance criteria may be candidates for optimisation—not that the containment system is compromised. Treating a marginal self-test deviation as a disqualifying failure without examining what it actually predicts about SMEPAC performance can create unnecessary downtime. This is a manufacturer-level decision that should be made with the supplier, not assumed to be within the user’s authority to change unilaterally.

Supplier and User Accountability for Failed Results

Before assigning a corrective action, teams need to determine who owns what part of the failure—and this is consistently where the recovery process stalls. The static leak test result is primarily a function of design and construction: seal integrity, weld quality, mechanical interface design, and structural choices made by the equipment supplier. The SMEPAC result is primarily a function of how the machine is used: operator technique, transfer execution, procedural adherence, and environmental conditions during the test. That split is a useful troubleshooting heuristic, not a fixed liability assignment. Some failures genuinely sit at the boundary, and some hardware failures only manifest under specific operational conditions.

One procurement-stage risk that creates accountability confusion later is specifying containment performance by occupational exposure band without defining which banding system applies. OEB systems vary significantly between companies—four-level, five-level, and six-level systems are all in use—so a specification that calls for an “OEB5 glove box” has no single technical meaning. If the supplier designs to one banding interpretation and the user or their toxicologist is working from a different one, the containment performance the system was built to achieve may not match what the SMEPAC protocol was designed to verify. This mismatch can produce a test failure that neither party fully owns because the specification was ambiguous at the outset. The corrective action in this case is not hardware or procedure—it is an alignment of the numerical exposure target that both sides are working toward, expressed in absolute terms that are independent of any company-specific banding convention.

Specifying containment by OEB level without defining the banding system creates a verification gap that no hardware change or procedure update can resolve.

When a failed result sits at the boundary between supplier and user accountability, the practical approach is to verify each side’s contribution separately before concluding. This means checking that the equipment was delivered and installed in accordance with design specifications, that any field modifications are documented, and that operator training records and procedural adherence can be confirmed for the failed run. An accountability review that skips either side because the failure pattern appears to favour one explanation tends to produce an incomplete corrective action.

Retest Readiness After Corrective Action

Retest authorisation is a decision point, not a scheduling step. The conditions under which the original test failed must be understood, the corrective action must address the identified root cause rather than simply the symptom, and the retest conditions must be demonstrably comparable to the original protocol so that the new result is a valid comparison.

The physical preparation sequence before any retest should begin with macro-leaks: tightening flanges and connections to specified torque values and confirming that no gross leaks remain. This step is foundational and should be documented with torque values and visual inspection records before the more sensitive micro-leak search begins. The micro-leak search then covers all potential penetration points—fittings, gaskets, valves, instrumentation ports—using leak detection methods appropriate to the system. This sequence reflects field practice in isolator qualification; treating it as a shortcut to the retest rather than as a prerequisite tends to produce a retest that fails for the same reason as the original.

The most commonly missed retest readiness criterion is comparison condition preservation. If the surrogate, the airflow settings, the task sequence, the operator, or the sampling method changed between the original run and the retest, the results are not directly comparable. A pass under changed conditions does not demonstrate that the corrective action resolved the original failure; it demonstrates that the new conditions produced an acceptable result. This distinction matters during audits and regulatory inspections, where reviewers may examine whether the retest was designed to confirm a fix or to obtain a passing number.

Under risk-based quality management expectations consistent with frameworks such as EudraLex Annex 15 en ICH Q9(R1), the corrective action should be documented in change control before the retest proceeds, and the retest protocol should reference both the root cause finding and the corrective action taken. Where the real-world process involves multiple exposure-risk steps—not just the one where the original failure was detected—the retest readiness review should confirm that corrective action covers the full process path, not only the task that produced the emission in the test run.

A failed SMEPAC result creates a decision sequence, not a retest schedule. The sequence runs in this order: determine whether the failure reflects equipment, operator, protocol, or specification; assign accountability with enough precision to direct the corrective action; implement a change that addresses the physical or procedural source rather than the test outcome; and document everything in a way that allows the retest to serve as a genuine comparison rather than a second attempt under loosened conditions.

The most persistent risk across all five phases is moving too quickly. Teams that skip the lab-to-manufacturing gap check, miss micro-leak sources at instrumentation penetrations, conflate static leak test results with SMEPAC conclusions, or issue a retest before comparison conditions are locked tend to produce a pass that does not represent durable containment performance. Before retesting, the relevant question is not whether the equipment is ready to run—it is whether the team can state, specifically and on paper, what changed and why that change prevents the same outcome.

Veelgestelde vragen

Q: What if our team lacks the in-house expertise to perform a structured root-cause analysis after a SMEPAC failure?
A: Bring in the equipment supplier or a qualified third-party containment specialist immediately. The article’s investigation sequence relies on technical interpretation of leak test data, micro-leak inspection, and accountability assessment that may exceed internal capabilities. Delaying expert involvement while attempting trial-and-error retests can compound the budget impact and create an audit trail that is harder to explain than a single failure event.

Q: After a failed SMEPAC run, what is the single first step we should take before any team meeting?
A: Preserve the as-is condition of the test setup and data. Lock down the equipment configuration, retain all surrogate samples and sampling media, secure operator logs, and prevent any physical adjustments to the hardware. The article outlines the investigation path, but the immediate prerequisite is preventing alteration that could obscure the root cause. Once the evidence is preserved, the structured review can begin on a reliable factual record.

Q: At what point does a failed SMEPAC result indicate that the containment equipment design itself is inadequate, rather than a procedural or operator issue?
A: When the failure reappears under multiple independent operators following a verified protocol and no micro-leak source is found after exhaustive physical inspection. The article notes that hardware faults may only manifest under specific operational conditions, so a design inadequacy is suspected only after systematically eliminating protocol gaps, operator variability, and physical integrity leaks. If emissions persist despite these eliminations and the equipment passes static leak checks, the interface or system design may be fundamentally mismatched to the process.

Q: How do we compare the long-term cost and risk of a procedural fix versus an interface redesign after a SMEPAC failure?
A: A procedural fix has lower initial cost but transfers ongoing containment risk to operator consistency, whereas an interface redesign removes the hazard at its source and typically proves more cost-effective over the equipment lifecycle. The article’s engineering hierarchy favours hardware solutions, but the financial trade-off is not laid out. Factor in the cost of repeated retests, potential batch losses, operator training overhead, and regulatory scrutiny: a procedural-only fix may survive a single retest but becomes expensive to maintain across real production variability.

Q: If our SMEPAC failure was marginal and the static leak test passed, is a full root-cause investigation really worth the effort?
A: Yes, because a marginal failure still reveals an uncontrolled variable that will remain until it is understood. A retest that passes under identical conditions without explanation builds a compliance record that the containment system is inconsistently reliable. The article shows that static leak and SMEPAC data do not always correlate, so ignoring a small excursion leaves the root cause unresolved. Documenting what caused the marginal result is far less costly than justifying an unexplained past failure during a regulatory review.