Cykl dekontaminacji VHP może przejść pomyślnie każdą serię produkcyjną, a mimo to pozostawić dokumentację kwalifikacyjną, która nie spełnia wymagań audytu. Problemem nie jest wydajność, lecz brak dowodów. Wiedza o tym, które dokumenty powinny znajdować się na danym etapie oraz kto jest odpowiedzialny za ich sporządzanie i zatwierdzanie, decyduje o tym, czy wdrożony system VHP jest faktycznie gotowy do przekazania, czy też jedynie do użytkowania.
Identyfikowalność zaczyna się od zatwierdzonego URS i założeń projektowych
| Pozycja dotycząca identyfikowalności | Zatwierdzony wymóg | Założenia projektowe | Odpowiednie dowody dotyczące FAT, SAT, IQ lub OQ | Postanowienie końcowe |
|---|---|---|---|---|
| Każdy zatwierdzony wymóg URS (jeden wiersz na jeden wymóg) | Identyfikator i treść wymagań dotyczących konkretnego projektu | Dokument uzasadniający projekt lub udokumentowana decyzja projektowa | Zapis spełniający wymagania na danym etapie lub etapach | Zatwierdzone odstępstwo, wniosek, czynnik powodujący zmianę lub czynnik powodujący ponowną kwalifikację, w zależności od sytuacji |
Wiarygodność pakietu kwalifikacyjnego systemu VHP zależy w całości od jego punktu wyjścia: zatwierdzonej specyfikacji wymagań użytkownika oraz dokumentów projektowych, które są zgodne z tą specyfikacją. Jeśli w specyfikacji wymagań użytkownika (URS) znajduje się wymaganie, które nie ma widocznego odpowiednika w podstawach projektowych, wymaganie to zostało utracone jeszcze przed rozpoczęciem testów FAT i nie da się go odzyskać na żadnym późniejszym etapie testów. Jest to praktyczny powód, dla którego planowanie kwalifikacji nie może rozpocząć się od FAT czy SAT — w tym momencie zestaw wymagań został albo poprawnie przeniesiony, albo nie.
Warunkiem, który zmienia tę ocenę, jest sposób, w jaki sam dokument URS został sporządzony. URS, który określa wyniki funkcjonalne w sposób podlegający weryfikacji, daje projektantom konkretną podstawę do działania oraz zapewnia testom FAT, SAT, IQ i OQ wspólny punkt odniesienia co do tego, co oznacza “spełnienie wymogu”. URS, który określa zamierzenia w sposób nieprecyzyjny, zmusza zespół projektowy, a później zespół kwalifikacyjny, do interpretowania tego, co miało być rozumiane, a interpretacja ta może nie wytrzymać konfrontacji z audytorem pytającym, gdzie dany wymóg został zweryfikowany. Załącznik 15 do EudraLex rozwiązuje tę kwestię bezpośrednio poprzez powiązanie systemu URS z kwalifikacją projektu oraz poprzez wymóg, by kwalifikacja ta opierała się na zatwierdzonych, identyfikowalnych podstawach, a nie na założeniach.
W szczególności w przypadku systemu VHP — gdzie parametry cyklu, rozmieszczenie czujników, konfiguracja komory lub obudowy oraz kompatybilność materiałów wynikają z decyzji podejmowanych konkretnie dla danego projektu — podstawy projektowe stanowią dokumentację, w której decyzje te są rejestrowane jako punkt odniesienia, na podstawie którego oceniane są wszystkie późniejsze testy. Jeśli po zatwierdzeniu projektu nastąpi zmiana wymagań, to właśnie w dokumentacji identyfikowalności zmiana ta jest albo uwzględniana w testach FAT, SAT, IQ i OQ, albo po cichu znika.
Zadaniem zamawiającego na tym etapie nie jest sporządzanie dodatkowej dokumentacji, lecz potwierdzenie, że każdy zatwierdzony wymóg ma wyraźną ścieżkę prowadzącą do co najmniej jednego etapu kwalifikacji. Jeśli wymaganie nie ma takiej ścieżki, właśnie wtedy należy to zgłosić — nie podczas fazy IQ ani podczas kontroli regulacyjnej. Jest to również moment, w którym informacje dostarczone przez zespół projektowy dotyczące przeznaczenia, mediów, połączeń z pomieszczeniami i warunków eksploatacji trafiają do konfiguracji dostawcy lub do przeglądu oferty, ponieważ podstawy projektowe proponowane przez dostawcę zależą od tego, jak dokładnie informacje te zostały zdefiniowane na samym początku.
FAT weryfikuje skonfigurowane funkcje przed dostawą
| Etap | Główny nacisk na dowody | Granica decyzji projektowej |
|---|---|---|
| FAT | Skonfigurowane funkcje, które można przetestować przed wysyłką | Należy korzystać z dokumentacji dostawcy wyłącznie w uzasadnionych przypadkach i po jej ocenie pod kątem z góry określonych kryteriów projektowych |
| SAT | Instalacja, infrastruktura obiektu, interfejsy i funkcje, na które ma wpływ transport lub integracja | Należy sprawdzić, czy warunek dotyczący konkretnego obiektu jest spełniony, zamiast zakładać, że wynik testu FAT go uwzględnia |
Testy odbiorcze w fabryce (FAT) są przeprowadzane, ponieważ niektóre funkcje można zweryfikować jeszcze przed opuszczeniem zakładu dostawcy przez system VHP, a ich wczesna weryfikacja zmniejsza liczbę nieznanych czynników, z którymi zespół projektowy musi się zmierzyć na miejscu. Funkcje, które rzeczywiście powinny zostać sprawdzone podczas testów FAT, to te, które zależą od konfiguracji samego sprzętu — logika sterowania, skonfigurowane parametry, reakcja czujników wewnętrznych, wydajność generatora w warunkach testowych dostawcy — a nie od tego, jak system zostanie zainstalowany w obiekcie odbiorcy.
Istotne w tym kontekście jest rozróżnienie między tym, co test FAT może wykazać, a tym, czego nie jest w stanie wykazać. Środowisko testowe dostawcy pozwala potwierdzić, że generator VHP działa zgodnie z konfiguracją przy zasilaniu z sieci i w warunkach dostępnych w tym środowisku. Nie pozwala ono jednak potwierdzić, jak ten sam system będzie się zachowywał po podłączeniu do rzeczywistej sieci projektowej, po zintegrowaniu z systemami napowietrzania lub monitorowania w pomieszczeniu odbiorczym, ani po zainstalowaniu w fizycznej lokalizacji wybudowanej dla niego w ramach projektu. Załącznik 15 uwzględnia tę kwestię, zezwalając na wykorzystanie wyników testu FAT zamiast powtarzania tego samego testu podczas SAT, ale tylko wtedy, gdy takie poleganie na tych wynikach jest uzasadnione, a wyniki testu FAT są oceniane w oparciu o z góry określone kryteria uzgodnione przed testem, a nie po nim.
Ma to bezpośredni wpływ na sposób, w jaki zespół projektowy planuje swoje procedury. Jeśli kryteria akceptacji FAT są sformułowane nieprecyzyjnie lub uzgodnione dopiero po przeprowadzeniu testu, trudno jest później polegać na dokumentacji dostawcy dotyczącej FAT, ponieważ audytor lub osoba oceniająca kwalifikację nie ma udokumentowanej podstawy, by uznać ją za równoważną z testem na miejscu. Natomiast w przypadku, gdy kryteria FAT są z góry określone, powiązane z konkretnymi skonfigurowanymi funkcjami i formalnie zaakceptowane, dokumentacja ta może w uzasadniony sposób ograniczyć zakres powtórzeń w ramach testów SAT.
Zadaniem zespołu projektowego na tym etapie jest określenie, funkcja po funkcji, które elementy są rzeczywiście zależne od konfiguracji i możliwe do przetestowania w siedzibie dostawcy, a które zależą od warunków lokalnych, które nie istnieją jeszcze podczas testów FAT. Pomylenie tych dwóch kategorii prowadzi później do sporów dotyczących tego, czy testy SAT są zbędne, czy też testy FAT były niewystarczające.
SAT rozwiązuje kwestie związane z infrastrukturą obiektu, interfejsami i skutkami instalacji
Testy akceptacyjne na miejscu (SAT) mają na celu przede wszystkim sprawdzenie tego, czego nie są w stanie zweryfikować testy FAT: jak system VHP zachowuje się po zainstalowaniu w rzeczywistej lokalizacji, podłączeniu do lokalnych sieci użytkowych oraz zintegrowaniu z interfejsami udostępnianymi przez obiekt odbiorczy. Transport, instalacja i podłączenie do lokalnych sieci użytkowych to zdarzenia, które same w sobie mogą wpłynąć na działanie sprzętu, dlatego testy SAT nie są powtórzeniem testów FAT pod inną nazwą — dotyczą one innej kategorii ryzyka.
Istotne elementy w tym kontekście to wszystkie elementy, od których zależy działanie konkretnej instalacji VHP, a istotne interfejsy to te, które łączą system z pomieszczeniem, procesem lub infrastrukturą monitorowania i sterowania obiektu. W przypadku integracji systemu z wentylacją pomieszczenia, punktami przelotowymi lub systemem monitorowania na poziomie obiektu, test SAT stanowi pierwsze sprawdzenie łącznego działania systemu i jego interfejsów, ponieważ żadne środowisko testowe dostawcy nie odtwarza tej kombinacji.
Czynnikiem wpływającym na zakres testów SAT jest to, w jakim stopniu działanie systemu zależy od instalacji na miejscu, a w jakim stopniu można było je już w pełni przetestować podczas testów FAT. System o prostych podłączeniach do sieci użytkowej i minimalnej zależności od interfejsu lokalnego może mieć węższy zakres testów SAT, ponieważ większość jego funkcji została już wcześniej potwierdzona. System zintegrowany ze złożoną infrastrukturą pomieszczenia, z blokadami lub monitorowaniem wspólnym dla wielu urządzeń, ma szerszy zakres testów SAT, ponieważ większa część jego zachowania staje się obserwowalna dopiero po instalacji.
Rzeczywistym ryzykiem, które ten etap ma na celu wykryć, jest założenie, że funkcja zweryfikowana podczas testów FAT pozostaje sprawna po transporcie i instalacji. Poparcie zawarte w załączniku 15 dla uzasadnionego polegania na wynikach testów FAT nie obejmuje funkcji zależnych od lokalizacji; ma ono zastosowanie wyłącznie w przypadkach, gdy sama funkcja nie uległa zmianie w wyniku instalacji. Zespół projektowy powinien traktować testy SAT jako etap, który potwierdza konkretnie wpływ instalacji i interfejsy z lokalizacją, a nie jako formalność polegającą na ponownym sprawdzaniu tego, co zostało już uwzględnione podczas testów FAT.
IQ dokumentuje zainstalowany i skalibrowany system
Kwalifikacja instalacji polega na porównaniu rzeczywistego stanu systemu VHP z tym, co zostało określone w specyfikacji, na rysunkach i w zamówieniu. Porównanie to obejmuje rysunki, zainstalowane elementy, podłączone media oraz stan kalibracji, a jego celem jest ustalenie udokumentowanego stanu odniesienia dla tego, co faktycznie zostało zainstalowane, a nie tego, co planowano zainstalować.
Powodem, dla którego to uzgodnienie ma znaczenie jako odrębny etap, niezależny od FAT czy SAT, jest fakt, że instalacja może odbiegać od zamierzeń projektowych w sposób, który nie stanowi awarii funkcjonalnej, lecz lukę w dokumentacji. Zastąpienie komponentu częścią równoważną, poprowadzenie przyłącza mediów w sposób inny niż na rysunku lub przeprowadzenie kalibracji w oparciu o inny punkt odniesienia niż pierwotnie określony — żadna z tych sytuacji niekoniecznie wpływa na wydajność eksploatacyjną, ale każda z nich, jeśli nie zostanie udokumentowana, przerywa łańcuch identyfikowalności prowadzący do zatwierdzonej podstawy projektowej. Etap IQ służy do identyfikacji tych rozbieżności i albo ich akceptacji na podstawie udokumentowanego uzasadnienia, albo skorygowania przed przystąpieniem do kwalifikacji.
Wymagania zawarte w załączniku 11 Wymogi dotyczące identyfikowalności wymagań użytkownika oraz udokumentowanych zapisów systemowych mają tutaj zastosowanie wszędzie tam, gdzie system VHP obejmuje sterowanie komputerowe, ponieważ stan zainstalowania i kalibracji każdego elementu komputerowego istotnego z punktu widzenia GMP wymaga takiego samego uzgodnienia, jak w przypadku elementów fizycznych. W przypadku gdy logika sterowania, przetwarzanie danych lub konfiguracja ścieżki audytu stanowią część zainstalowanego systemu, to właśnie na etapie IQ ustala się, czy konfiguracja ta jest zgodna z tym, co zostało określone i zatwierdzone, a nie na etapie OQ, który zakłada, że stan po instalacji jest już prawidłowy, i zamiast tego bada, jak zachowuje się system.
Czynnikiem decydującym o stopniu złożoności tego uzgadniania jest złożoność samego zainstalowanego systemu. Prosta, samodzielna jednostka ma mniej elementów i mediów, które trzeba uzgodnić. System zintegrowany ze wspólnymi mediami budynku, sterowaniem sieciowym lub wieloma skalibrowanymi przyrządami wiąże się z dłuższą listą uzgodnień, a każdy dodatkowy interfejs to kolejny punkt, w którym stan faktyczny może odbiegać od założeń projektowych. Zadaniem zespołu projektowego jest potwierdzenie, że dokumentacja IQ uwzględnia wszystkie media, elementy i skalibrowane przyrządy określone w założeniach projektowych, a nie tylko te, które najłatwiej zweryfikować.
OQ – testowanie limitów eksploatacyjnych, alarmów i procedur reagowania na awarie
| Obszar wyzwań OQ | W protokole należy z góry określić | Dowody niezbędne do wyciągnięcia wniosku |
|---|---|---|
| Zakresy działania | Zakres właściwy dla projektu w odniesieniu do kryteriów weryfikacji i akceptacji | Wyniki surowe dla całego badanego zakresu oraz zatwierdzony wniosek |
| Alarmy | Warunki testu, oczekiwane reakcje i kryteria akceptacji | Zapisy dotyczące zdarzeń alarmowych, odchylenia oraz zatwierdzony wniosek |
| Interlocks | Warunki testu, oczekiwane reakcje i kryteria akceptacji | Interlock challenge records, deviations and the approved conclusion |
| Abort and recovery scenarios | Scenario, expected abort and recovery responses, and acceptance criteria | Scenario records, deviations and the approved conclusion |
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
| Record group | Handover evidence to retain | Granica decyzyjna |
|---|---|---|
| Approved protocols | Predefined acceptance criteria and the approved test basis | Exact tests and criteria remain project-specific |
| Odchylenia | Approved deviation records and their effect on the relevant result or conclusion | A deviation requires an approved disposition rather than an undocumented exception |
| Responsibility split | Supplier-provided records and the corresponding site qualification decisions | Supplier evidence does not make the site decision unless that responsibility is explicitly assigned |
| Final cycle evidence | Representative-load definition, sensor and indicator placement, raw records and conclusions | Indicator results do not replace physical measurements or define a universal cycle |
| Change and requalification | Defined change or requalification triggers | Trigger conditions remain specific to the approved project basis |
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, Załącznik 1 do GMP UE 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 Generator nadtlenku wodoru VHP 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.
Często zadawane pytania
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.
