VHP FAT SAT IQ OQ Süreci: Devir Teslim Kanıtlarının Oluşturulması

A VHP decontamination cycle can pass every production run and still leave a qualification package that cannot support an audit. The gap is not performance; it is evidence. Knowing which records belong at which stage, and who is responsible for generating and approving them, determines whether a fixed VHP system is actually ready for handover or only ready for use.

Traceability Starts with the Approved URS and Design Basis

A VHP system qualification package is only as reliable as its starting point: the approved user requirements specification and the design documents that respond to it. Where a requirement exists in the URS but has no visible counterpart in the design basis, that requirement has already been lost before FAT begins, and no later test stage recovers it. This is the practical reason why qualification planning cannot start at FAT or SAT — by that point, the requirement set has either been carried forward correctly or it has not.

The condition that changes this judgment is how the URS itself was written. A URS that states functional outcomes in testable terms gives the design basis something concrete to respond to, and gives FAT, SAT, IQ and OQ a shared reference for what “meeting the requirement” means. A URS that states intentions loosely forces the design team, and later the qualification team, to interpret what was meant, and that interpretation may not survive contact with an auditor asking where a given requirement was verified. EudraLex Ek 15 addresses this directly by linking URS to design qualification and by requiring that qualification build on an approved, traceable basis rather than on assumption.

For a VHP system in particular — where cycle parameters, sensor placement, chamber or enclosure configuration, and material compatibility all originate in project-specific decisions — the design basis is where those decisions get recorded as the reference against which every later test is judged. If a requirement changes after design freeze, the traceability record is where that change either gets carried through to FAT, SAT, IQ and OQ or quietly disappears.

The buyer’s task at this stage is not to produce more documentation; it is to confirm that every approved requirement has a visible path to at least one qualification stage. Where a requirement has no such path, that is the moment to raise it — not during IQ, and not during a regulatory inspection. This is also the point at which the information a project team supplies about intended use, utilities, room interfaces and operating conditions enters a supplier’s configuration or quotation review, because the design basis a supplier proposes depends on how completely that information was defined upfront.

FAT Confirms Configured Functions Before Delivery

Factory acceptance testing exists because some functions can be verified before a VHP system ever leaves the supplier’s facility, and verifying them early reduces the number of unknowns the project team has to resolve on site. The functions that genuinely belong at FAT are those that depend on the equipment’s own configuration — control logic, configured parameters, internal sensor response, generator performance under the supplier’s test conditions — rather than on how the system will sit inside the receiving facility.

The distinction that matters here is what FAT can represent versus what it cannot. A vendor test environment can confirm that a VHP generator behaves as configured when supplied with the utilities and conditions available in that environment. It cannot confirm how the same system behaves once connected to the project’s actual utilities, integrated with the receiving room’s aeration or monitoring systems, or installed in the physical location the project has built for it. Annex 15 recognizes this by permitting FAT evidence to stand in place of repeating the same test at SAT, but only where that reliance is justified and the FAT evidence is assessed against predefined criteria agreed before the test, not after.

This creates a direct consequence for how a project team plans its protocols. If FAT acceptance criteria are written loosely, or agreed only after the test has already run, the supplier’s FAT evidence becomes harder to rely on later, because an auditor or qualification reviewer has no documented basis for treating it as equivalent to a site test. Where FAT criteria are defined in advance, tied to specific configured functions, and formally accepted, that evidence can legitimately reduce what SAT needs to repeat.

The project team’s task at this stage is to identify, function by function, which items are genuinely configuration-dependent and testable at the vendor’s site, and which depend on site conditions that do not yet exist at FAT. Confusing the two categories is what later creates disputes over whether SAT is redundant or whether FAT was insufficient.

SAT Resolves Site Utilities, Interfaces and Installation Effects

Site acceptance testing exists specifically to verify what FAT cannot: how the VHP system behaves once it is installed in its actual location, connected to the site’s own utilities, and integrated with the interfaces the receiving facility provides. Transport, installation, and connection to site-specific services are themselves events that can change equipment behavior, so SAT is not a repeat of FAT under a different name — it targets a different category of risk.

The utilities that matter here are whatever the specific VHP installation depends on for its function, and the interfaces that matter are whatever connects the system to the room, the process, or the facility’s monitoring and control infrastructure. Where a system is being integrated with room aeration, pass-through points, or facility-level monitoring, SAT is where the combined behavior of the system and its interfaces gets verified for the first time, because no vendor test environment reproduces that combination.

The condition that changes the scope of SAT is how much of the system’s function depends on site-specific installation versus how much was already fully testable at FAT. A system with simple utility connections and minimal site interface dependency may have a narrower SAT scope, because most of its function was already confirmed earlier. A system integrated into complex room infrastructure, with interlocks or monitoring shared across multiple pieces of equipment, carries a wider SAT scope, because more of its behavior only becomes observable after installation.

The practical risk this stage is designed to catch is the assumption that a function verified at FAT remains verified after transport and installation. Annex 15’s support for justified FAT reliance does not extend to site-dependent functions; it applies only where the function itself was not affected by installation. For a project team, the discipline is to treat SAT as the stage that confirms installation effects and site interfaces specifically, rather than as a formality that revisits what FAT already covered.

IQ Documents the Installed and Calibrated System

Installation qualification is where the as-built condition of the VHP system gets reconciled against what was specified, drawn, and ordered. This reconciliation covers drawings, installed components, connected utilities, and calibration status, and its purpose is to establish a documented baseline of what was actually installed, not what was planned to be installed.

The reason this reconciliation matters as its own stage, separate from FAT or SAT, is that installation can diverge from design intent in ways that are not functional failures but documentation gaps. A component substituted for an equivalent part, a utility connection routed differently than drawn, or a calibration performed against a different reference than originally specified — none of these necessarily affects operating performance, but each of them, if undocumented, breaks the traceability chain back to the approved design basis. IQ is where those divergences get identified and either accepted through a documented justification or corrected before qualification proceeds.

Annex 11’s requirements for traceable user requirements and documented system records apply here wherever the VHP system includes computerized control, since the installed and calibrated condition of any GMP-relevant computerized element needs the same reconciliation as physical components. Where control logic, data handling, or audit-trail configuration is part of the installed system, IQ is the stage that establishes whether that configuration matches what was specified and approved, not OQ, which assumes the installed condition is already correct and instead tests how the system behaves.

The condition that changes how demanding this reconciliation needs to be is the complexity of the installed system itself. A straightforward standalone unit has fewer components and utilities to reconcile. A system integrated with shared building utilities, networked controls, or multiple calibrated instruments carries a longer reconciliation list, and each additional interface is another point where as-built condition can diverge from the design basis. The project team’s task is to confirm that the IQ record accounts for every utility, component, and calibrated instrument the design basis specified, not only the ones that are easiest to verify.

OQ Challenges Operating Limits, Alarms and Failure Responses

Operational qualification is where the VHP system is challenged against its approved operating ranges, its alarm responses, its interlocks, and its behavior under abort and recovery scenarios. Where IQ confirms that the system was installed and calibrated as specified, OQ confirms that the installed system actually behaves as intended when operated, including when it is deliberately pushed toward its limits or into fault conditions.

Each of these challenge categories carries a different kind of evidence requirement. Operating range challenges need a protocol that defines, in advance, the specific range being tested and the criteria for an acceptable result — a VHP cycle’s parameters are project-specific, so the acceptance basis has to be established for that system rather than assumed from general practice. Alarm and interlock challenges need defined trigger conditions and an expected response, confirmed through records that show the system responded as specified when that condition was deliberately created. Abort and recovery scenarios need the same discipline extended further: a defined scenario, an expected abort behavior, an expected recovery behavior, and a predefined basis for judging whether both were acceptable.

What ties these categories together is that none of them can be verified informally. An operator confirming that “the alarm worked” during commissioning is not equivalent to a challenge record showing the specific condition created, the response observed, and the conclusion reached against a criterion agreed before the test. This is the distinction Annex 15 reinforces in requiring predefined acceptance criteria and documented deviations — a deviation encountered during OQ is not a failure of the qualification exercise, but it does require an approved disposition before the result can be relied upon.

The condition that changes the depth of OQ needed is how much of the system’s safety or product-protection function depends on dynamic response versus static configuration. A system whose protective function activates only under fault conditions needs those fault conditions actually created and observed, because a static review of the control logic cannot confirm dynamic behavior. Where VHP cycles interact with other equipment — pass-throughs, BIBO transfer points, or room-level monitoring — the OQ scope has to decide whether those interactions are challenged as part of this system’s qualification or addressed separately, and that boundary needs to be explicit in the protocol rather than assumed.

Handover Closes Deviations, Records and Requalification Triggers

A qualification package is complete only when every deviation raised during FAT, SAT, IQ or OQ has an approved disposition, every protocol’s predefined criteria and approved test basis are retained in the final record, and the boundary between supplier-provided evidence and site qualification decisions is explicit rather than assumed. An undocumented exception — a result that was accepted informally without a recorded justification — is the single most common way a qualification package fails to support an inspection, because the absence of a documented disposition leaves no basis for an auditor to understand why an anomalous result was considered acceptable.

The responsibility split matters because a VHP system supplied and qualified through a vendor relationship generates two categories of record: what the supplier tested and documented, and what the site qualification team concluded and approved. Supplier records can inform a site decision, but they do not substitute for it unless that responsibility has been explicitly assigned in the project’s qualification plan. Where that assignment is unclear, the handover package risks containing records that look complete but do not actually establish who approved what.

For the final cycle evidence specifically, AB GMP Ek 1 is explicit that sterilization or decontamination validation relies on physical measurements, with biological or chemical indicators used where appropriate and placed at suitable locations — indicator results do not replace the physical measurements, and neither replaces a defined, representative load. A handover package for a VHP system needs to retain the representative-load definition used during qualification, the placement of sensors and indicators, the raw records from the qualification runs, and the conclusions drawn from them, because a future review of cycle performance depends on being able to reconstruct what was actually tested, not only what the summary report states.

The final element is the set of conditions that would trigger a change evaluation or a requalification — a modification to the load configuration, a change to room interfaces, a change to the control system, or any other condition the project’s qualification basis identifies as relevant. These triggers are specific to the approved project basis rather than generic, which is why they need to be stated explicitly in the handover package rather than left for a future reviewer to infer. Equipment such as a VHP hidrojen peroksit jeneratörü configured for a specific project enters service against this exact record set, and the completeness of that record set is what determines whether the system can be maintained, modified, or requalified later without reconstructing the qualification basis from memory.

Sıkça Sorulan Sorular

Q: What should be agreed before FAT, SAT, IQ and OQ protocols are drafted?
A: Start with the approved URS, recorded design decisions, project-specific acceptance criteria and a clear split between supplier records and site qualification decisions. For final cycle evidence, also define the representative load and planned sensor and indicator locations so the protocol can produce evidence that matches the intended conclusion.

Q: When can FAT evidence be carried into the site qualification package?
A: It can support a requirement when the tested configured function remains applicable and its use is justified against predefined project criteria. Installation, utilities, interfaces and functions affected by transport or integration still need site-specific verification rather than an assumption that the FAT result remains sufficient.

Q: How should a requirement change after FAT be handled in the traceability record?
A: Update the requirement-to-evidence mapping and identify which design documents, tests, conclusions or requalification triggers are affected. The handover package should preserve the change and its approved disposition so the original FAT record is not treated as evidence for a condition it did not test.

Q: Who should decide whether a deviation is acceptable at handover?
A: The protocol should assign that responsibility explicitly and require an approved disposition tied to the affected result or conclusion. A supplier deviation record can document what occurred, but it should not be treated as the site’s qualification decision unless that authority was clearly assigned.

Q: Do indicator results alone demonstrate that a VHP cycle is acceptable?
A: No. Indicator results do not replace physical measurements or establish a universal cycle. The conclusion should follow the approved project criteria and retain the representative-load definition, sensor and indicator placement, raw records, deviations and final approved conclusion.