Otwiera się w nowej karcie

M47 WIEDZA

Walidacja WMS w hurtowni farmaceutycznej — wymagania DPD i testy

Jak zaplanować walidację WMS w hurtowni farmaceutycznej? Wymagania Dobrej Praktyki Dystrybucyjnej (DPD, ang. GDP), analiza ryzyka, URS i testy w odniesieniu do konfiguracji systemu oraz procesów magazynowych.

Autor: Marek Jaranowski • Pharma Compliance

Ostatnia weryfikacja merytoryczna: 24.09.2026

Walidacja WMS a wymagania DPD

Ustęp 3.5 pkt 1 polskich wymagań DPD przewiduje przeprowadzenie odpowiednich badań walidacyjnych lub weryfikujących przed rozpoczęciem korzystania z systemu skomputeryzowanego. Mają one potwierdzić, że system osiąga pożądane wyniki w sposób „dokładny, niezmienny i powtarzalny”. Wymagania obejmują również opis systemu, kontrolę dostępu, ochronę danych, kopie zapasowe i sposób postępowania w razie awarii. [1]

Pełny zakres ust. 3.5 załącznika do polskiego rozporządzenia DPD obejmuje osiem wymagań:

PodstawaWymaganie
Ust. 3.5 pkt 1Przed rozpoczęciem korzystania z systemu należy wykazać w odpowiednich badaniach walidacyjnych lub weryfikujących, że osiąga on pożądane wyniki dokładnie, niezmiennie i powtarzalnie.
Ust. 3.5 pkt 2Sporządzić pisemny, szczegółowy opis systemu i na bieżąco go aktualizować. Opis obejmuje metody postępowania, cele, środki bezpieczeństwa, zakres, główne cechy, sposób korzystania oraz interakcje z innymi systemami.
Ust. 3.5 pkt 3Zapewnić, aby dane wprowadzały i zmieniały wyłącznie upoważnione osoby.
Ust. 3.5 pkt 4Zabezpieczyć dane fizycznie lub elektronicznie i chronić je przed zmianami przypadkowymi oraz nieuprawnionymi.
Ust. 3.5 pkt 5Okresowo sprawdzać dostępność przechowywanych danych.
Ust. 3.5 pkt 6Sporządzać kopie zapasowe w regularnych odstępach czasu.
Ust. 3.5 pkt 7Przechowywać kopie zapasowe w osobnym zabezpieczonym miejscu przez okres ustalony przez przedsiębiorcę, nie krótszy niż pięć lat od ich utworzenia.
Ust. 3.5 pkt 8Określić procedury postępowania w razie błędu lub awarii systemu, obejmujące odzyskiwanie danych.

Częstotliwość wykonywania kopii, okres ich przechowywania i testy odtworzenia to trzy odrębne kwestie. Pięcioletnia retencja nie oznacza wykonywania jednej kopii na pięć lat. Regularność tworzenia kopii wynika z pkt 6, a minimalny okres ich przechowywania z pkt 7. Zakres i częstotliwość testów odtworzenia należy uzasadnić ryzykiem oraz potrzebą wykazania, że procedura odzyskiwania danych działa. Rozporządzenie nie narzuca w ust. 3.5 jednej architektury kopii ani jednakowego harmonogramu testów dla wszystkich systemów.

Dokumentacja i testy dostawcy są materiałem wejściowym do walidacji. Nie zastępują wykazania, że system w konfiguracji i sposobie użycia konkretnej hurtowni spełnia jej wymagania. Oceną należy objąć istotne interfejsy, role i uprawnienia, przepływ danych oraz właściwe scenariusze procesowe i negatywne. Dowody dostawcy można wykorzystać po sprawdzeniu ich jakości, zakresu i przydatności.

Zakres walidacji: WMS, ERP i integracje

Przed opracowaniem scenariuszy testowych określ wersję systemu, objęte projektem moduły i lokalizacje, interfejsy oraz role użytkowników. Ustal, czy walidacja obejmuje wyłącznie WMS, czy również ERP, integracje z ZSMOPL, obsługę serializacji, terminale i etykiety. Wyraźnie oznacz elementy objęte odrębnym projektem.

W specyfikacji wymagań użytkownika (URS) trzeba określić między innymi, które statusy produktu mają uniemożliwiać jego wydanie. Wymaganie powinno opisywać oczekiwane działanie systemu w procesie magazynowym, tak aby można było jednoznacznie sprawdzić jego spełnienie.

Zwalidowany system skomputeryzowany może zastępować fizyczne oddzielenie tylko w zakresie dopuszczonym przez właściwe wymagania i przy zapewnieniu równoważnego bezpieczeństwa. Należy rozróżnić status produktu oraz podstawę segregacji. Sama blokada sprzedaży nie dowodzi spełnienia wszystkich wymagań przechowywania i dostępu. Wycofanie produktu z obrotu nie jest tym samym co wycofanie go z zapasów przeznaczonych do sprzedaży. Wymagania trzeba ocenić dla konkretnego statusu, z uwzględnieniem ust. 3.2 pkt 6–8, ust. 5.5 pkt 8 i ust. 6.4 polskich wymagań DPD. [1]

Integrację z PLMVS i obsługę alertów opisujemy w artykule o serializacji w hurtowni.

Analiza ryzyka i wymagania użytkownika — podstawa testów

Przykład powiązania ryzyka z testem: ryzyko wydania produktu zablokowanego — wymaganie blokady — scenariusz próby wydania — oczekiwany wynik — zapis wykonania. W teście negatywnym sprawdza się, czy niedozwolona operacja rzeczywiście zostaje zatrzymana, także w istotnych ścieżkach alternatywnych.

ISPE GAMP 5 przedstawia podejście do systemów GxP oparte na ryzyku. Jest to wytyczna branżowa, nie przepis prawa. Korzystając z niej w hurtowni farmaceutycznej, trzeba uwzględnić wymagania DPD i rzeczywiste zastosowanie systemu. [2]

Podstawą oceny systemów skomputeryzowanych w hurtowni są wymagania DPD. Aneks 11 EU GMP i GAMP 5 mogą wspierać metodykę w odpowiednim zakresie, ale nie zastępują oceny wymagań właściwych dla działalności. Gdy organizacja prowadzi również procesy objęte GMP, należy osobno określić ich zakres i podstawę regulacyjną.

Stan sprawdzony 29.09.2026 r.: katalog Komisji Europejskiej nadal wskazuje Aneks 11 „Computerised Systems”, rewizja ze stycznia 2011 r. Projekt konsultacyjny nie jest nową obowiązującą wersją. Publikację dokumentu końcowego i datę rozpoczęcia jego stosowania należy sprawdzić odrębnie. [4]

Dobierz reprezentatywne scenariusze

Zakres testów może obejmować przyjęcie i wydanie, statusy serii, uprawnienia, zmiany danych, zwroty, raportowanie oraz odtworzenie danych. Nie jest to zamknięta lista wymagana dla każdego WMS. Każdy scenariusz powinien wynikać z zastosowania i oceny ryzyka.

Jeśli system przekazuje dane do innego rozwiązania, sprawdź także błędną transmisję i sposób jej obsługi. Potwierdzenie wysłania komunikatu nie zawsze dowodzi, że odbiorca przyjął go poprawnie i że obie strony mają zgodne dane.

Jak dokumentować wyniki testów walidacyjnych

Protokół powinien wskazywać warunki testu, dane wejściowe, wynik oczekiwany, wynik uzyskany i osobę wykonującą. Zrzut ekranu jest użyteczny wtedy, gdy wiadomo, co przedstawia i z jakim krokiem się wiąże. Sam zbiór obrazów bez scenariusza nie wyjaśnia, czy sprawdzono wymaganie.

W raporcie rozdziel testy zaliczone, odchylenia i ograniczenia. Wniosek o przydatności systemu do użytkowania musi odpowiadać sprawdzonemu zakresowi. Jeżeli projekt nie obejmował określonych funkcji lub środowisk, trzeba to wyraźnie zaznaczyć.

Aktualizacja nie oznacza automatycznie pełnej rewalidacji

Przed aktualizacją oceń wpływ zmiany na wymagania użytkownika, interfejsy i procesy magazynowe. Sprawdź, które wcześniejsze wyniki pozostają aktualne. Na tej podstawie określ testy nowych lub zmienionych funkcji oraz testy regresji, sprawdzające działanie funkcji, które mogły zostać naruszone pośrednio. Istotnej zmiany nie można zwolnić z wymaganej weryfikacji wyłącznie dlatego, że dostawca określa ją jako standardową aktualizację.

Po wdrożeniu potrzebne jest utrzymanie dokumentacji i nadzoru. Przegląd okresowy powinien pomagać odpowiedzieć, czy pierwotne założenia nadal odpowiadają działaniu systemu. Częstotliwość i zakres ustala się dla konkretnego systemu; sam upływ roku nie przesądza o konieczności ponownego wykonania wszystkich testów.

Zmiana systemu i zakres rewalidacji →

Przy ocenie zapisów elektronicznych warto uwzględnić wytyczną PIC/S PI 041-1 dotyczącą zarządzania danymi i ich integralności w środowisku GMP/GDP. Obejmuje ona między innymi możliwość przypisania danych do osoby wykonującej czynność, ich kompletność, spójność i dostępność w całym cyklu życia. To wskazówki interpretacyjne, a nie odrębny polski przepis. [3]

Źródła i zakres opracowania

[1] Polskie wymagania DPD, ust. 3.2 pkt 6–8, ust. 3.5 pkt 1–8, ust. 3.6, ust. 5.5 pkt 8 i ust. 6.4 — Dz.U. 2022 poz. 1287, z późniejszą zmianą

[2] ISPE: GAMP 5 Guide, Second Edition — opis zakresu wytycznej

Wytyczne UE DPD 2013/C 343/01, pkt 3.3.1 i 3.3.2

[3] PIC/S PI 041-1: Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, 1 lipca 2021 r.

[4] Komisja Europejska: EudraLex Volume 4 — aktualny wykaz wytycznych EU GMP, w tym Aneks 11 „Computerised Systems”. Status Aneksu 11 sprawdzono 29.09.2026 r.

Weryfikacja źródeł: 24.09.2026. Przykłady testów są wskazówkami do opracowania własnego planu walidacji, nie gotowym zakresem dla każdego WMS.

Walidacja systemów WMS i ERP — zakres wsparcia M47 →

Porozmawiajmy o Twoim projekcie.

Omówimy sytuację, zakres wsparcia i pierwszy krok.