Walidacja systemów komputerowych w hurtowniach farmaceutycznych Warszawa, 18.11.2016 r. Katarzyna Mańkowska Bożena Giza 1
Obowiązek walidacji systemów komputerowych wspomagających pracę hurtowni farmaceutycznej wynika z Rozporządzenia Ministra Zdrowia z dnia 13 marca 2015 r. w sprawie wymagań Dobrej Praktyki Dystrybucyjnej (Dz. U. z 2015 r. poz. 381 z późn. zm.) Zgodnie z pkt 3.5 ppkt 1 ww. rozporządzenia: przed rozpoczęciem korzystania ze skomputeryzowanego systemu należy wykazać, w formie odpowiednich badań walidacyjnych lub weryfikujących, że system ten jest w stanie osiągać pożądane wyniki w sposób dokładny, niezmienny i powtarzalny. 2
Zasady i wytyczne dotyczące walidacji systemów skomputeryzowanych zawarte są w dokumentach GAMP 5 (Good Automated Manufacturing Practice) i Aneksie 11 do przewodnika GMP (Good Manufacturing Practice). 4
Ogólne zasady walidacji: 5
Jeżeli system komputerowy wspomaga proces mający istotne znaczenie dla jakości produktów leczniczych, konieczne jest zarówno zwalidowanie samego systemu komputerowego, jak i zwalidowanie wdrożenia tego systemu w konkretnej hurtowni. 6
Systemy komputerowe wykorzystywane w dystrybucji produktów leczniczych: Systemy magazynowo księgowe wspierające procesy przebiegające w hurtowni (m.in. zamówienia, zakup, sprzedaż, reklamacje, wstrzymania, wycofania, zwroty, utylizacja) Urządzenia skanujące dane z opakowań do systemu Systemy wspomagające zarządzanie transportem Systemy zarządzające kontrolą warunków otoczenia podczas przechowywania i transportu: Zapewnienie warunków przechowywania w całym łańcuchu dystrybucji Zbieranie danych Przechowywanie i archiwizacja danych Systemy elektronicznego zarządzania dokumentacją: Tworzenie, dystrybucja, archiwizacja dokumentacji 7
Przed zwolnieniem systemu komputerowego do użytkowania należy wykazać, w formie odpowiednich badań walidacyjnych, że system ten jest w stanie osiągnąć pożądane wyniki w sposób dokładny, niezmienny i powtarzalny. Fakt ten powinien być potwierdzony zakończeniem walidacji z wynikiem pozytywnym. Na podstawie analizy ryzyka należy określić zakres, rodzaj i skalę kwalifikacji i / lub walidacji: przed wdrożeniem systemu, w celu zapewnienia prawidłowej instalacji i działania, po wprowadzeniu znaczących zmian (rekwalifikacja/ rewalidacja). 8
Rodzaje działań dla systemu komputerowego: Kwalifikacja infrastruktury DQ, IQ, OQ, PQ Walidacja aplikacji Rekwalifikacja / rewalidacja (w zależności od zakresu zmian po naprawach, konserwacji, wymianie, dużych awariach) Działania związane z walidacją systemu muszą być planowane i udokumentowane, a zapisy dokumentujące działania zatwierdzane przez upoważnionych pracowników. 9
Dokumentacja niezbędna do przeprowadzenia działań walidacyjnych: Analiza ryzyka krytyczność systemu i jego elementów Inwentaryzacja wszystkich istotnych systemów, bazująca na ocenie ich krytyczności funkcjonalność systemów w odniesieniu do DPD (wpływ na spełnienie wymagań DPD, bezpieczeństwo pacjenta i produktu) Kwalifikacja dostawców systemu: ocena systemu jakości dostawcy systemu pisemna umowa szczegółowo określająca obowiązki stron Specyfikacje: URS (specyfikacja wymagań użytkownika), DS (specyfikacja projektowa), FS (specyfikacja funkcjonalna), IS (specyfikacja wymagań instalacyjnych) Plan Walidacji Procedura walidacyjna (wzory protokołów, raportów, formularzy testowych) 10
Fazy procesu walidacyjnego, definicje, dokumenty, opis przeprowadzanych działań. 11
Procesem walidacyjnym proponowanym w GAMP i powszechnie stosowanym jest model V : 12
Fazy procesu walidacyjnego : Główny plan walidacji Specyfikacja wymagań użytkownika (URS) Specyfikacja funkcjonalna (FS) Specyfikacja projektowa przegląd projektu IS specyfikacja wymagań instalacyjnych ( określenie przez twórcę wymagań systemu względem środowiska, w którym ma być zainstalowany) IQ kwalifikacja instalacyjna sprawdzenie w środowisku testowym, czy system się prawidłowo instaluje i uruchamia OQ Kwalifikacja operacyjna sprawdzenie w środowisku testowym, czy poszczególne fragmenty systemu zachowują się tak, jak opisano w FS 13
PQ kwalifikacja procesowa sprawdzenie, czy system zachowuje się tak, jak opisano w URS PQ/FAT kwalifikacja procesowa przeprowadzana przez twórcę systemu PQ1/SAT - kwalifikacja procesowa przeprowadzana przez użytkownika, w jego środowisku testowym PQ2/SAT - kwalifikacja procesowa przeprowadzana przez użytkownika, w jego środowisku roboczym podczas pracy eksploatacyjnej systemu pod nadzorem Główny rejestr odchyleń Raport z walidacji Certyfikat walidacji 14
Główny Plan Walidacji Formalny dokument systemu zapewnienia jakości, nadzorowany zgodnie z wymaganiami dla dokumentacji zatwierdzony, przeglądany przez kierownictwo i Zapewnienie Jakości. Opisuje ogólne podejście do walidacji w przedsiębiorstwie, zamiary i zapewnienie właściwego wykonania działań. Określa przedział czasowy wszelkich planowanych prac wraz z ich strukturą organizacyjną rodzaj działań, ich organizację i odpowiedzialności personelu. Podaje zasady kontroli zmian, zarządzania odchyleniami, rekwalifikacji, rewalidacji. 15
Główny Plan Walidacji powinien zawierać następujące elementy: Historia dokumentu - wydanie, wykaz zmian, Wstęp cel, zakres, opis systemu, Odpowiedzialności i uprawnienia, Harmonogram działań, Inwentaryzacja systemów, Infrastruktura opis, schematy, konfiguracja sprzętu i oprogramowania, Analiza wpływu usługi zewnętrzne, serwery, sieć, stacje robocze, Analiza ryzyka założenia i metoda, Kwalifikacja infrastruktury założenia, zakres, metodyka, warunki i zakres kwalifikacji sprzętu i oprogramowania kwalifikacja IQ i OQ, Kryteria akceptacji IQ i OQ, Kontrola odchyleń, Układ i wzory dokumentacji (plany, protokoły, formularze, raporty), Definicje, skróty, Literatura podstawy prawne, procedury. 16
URS - Specyfikacja wymagań użytkownika Określa jasno i precyzyjnie wymagania klienta, które powinny być zrozumiałe zarówno przez klienta jak i sprzedawcę. Definiuje funkcje systemu, które będą wykorzystywane, dane, na których system będzie działać i środowisko pracy. Musi być powiązany z określoną wersją zatwierdzonej aplikacji, jeśli system jest zaktualizowany do nowej wersji. URS musi zostać przejrzany i poprawiony, jeśli ma mieć zastosowanie do nowych wersji oprogramowania. Jest żywym dokumentem, który musi być uaktualniany poprzez procedury kontroli zmian, w całym cyklu życia systemu informatycznego. 17
Ogólne wymagania dotyczące pisania URS: Każde wymaganie powinno być jednoznacznie wymienione i zwięźle opisane. Dokument powinien być spójny, wymagania nie powinny być powielane lub sprzeczne. Dokument określa wymagania, a nie projektuje rozwiązania Każdy wymóg powinien być sprawdzalny, co pozwala na szybkie zaprojektowanie testów po zatwierdzeniu URS. Dokument musi być zrozumiały dla klienta i sprzedawcy, dlatego należy unikać żargonu, zaś słowa kluczowe powinny zostać zdefiniowane w konkretnej sekcji URS. Wymagania powinny być zaklasyfikowane według priorytetu jako obowiązkowe lub pożądane. URS powinien być modyfikowany zgodnie z procedurą kontroli zmian. 18
URS jest dokumentem wyjściowym do tworzenia kolejnych specyfikacji oraz dokumentacji kwalifikacyjnej, dlatego ważne jest, aby można było identyfikować wymagania w tych kolejnych dokumentach, stąd ważny jest sposób prezentowania i zarządzania wymaganiami. Każde wymaganie musi być: Unikalnie i jednoznacznie numerowane, Opisane tak, aby mogło zostać przetestowane, jeśli jest to wymagane w PQ, Mieć nadany priorytet jako obowiązkowe (O = istotne dla wydajności systemu) lub pożądane (P = dobrze mieć, ale system może być używany bez niego). Priorytety te mogą być wykorzystywane w analizie ryzyka funkcjonalnego, a także do śledzenia wymagań przez resztę cyklu życia. 19
Specyfikacja funkcjonalna (FS) - dokument opracowywany przez twórcę systemu, opisujący i określający zachowanie i działanie systemu. Specyfikacja projektowa przegląd projektu (DS) - dokument potwierdzający prawidłowość przebiegu procesu powstawania systemu oraz jego dalszego rozwoju. Dokument przygotowywany przez użytkownika. Specyfikacja wymagań instalacyjnych (IS) - dokument przygotowany przez twórcę systemu, określający wymagania systemu względem środowiska, w którym ma być on instalowany i instrukcję instalacji. 20
Kwalifikacja (Q Qualification) - działanie mające na celu wykazanie i udokumentowanie, że urządzenia lub instalacje pomocnicze są odpowiednio zainstalowane, pracują właściwie, a ich działanie rzeczywiście prowadzi do uzyskania oczekiwanych wyników. Kwalifikacja jest częścią walidacji, lecz poszczególne, pojedyncze etapy kwalifikacji nie stanowią procesu walidacji. 21
Pierwszym etapem kwalifikacji powinna być : Kwalifikacja projektu (DQ - Design Qualification) - udokumentowana weryfikacja stwierdzająca, że proponowany projekt obiektów, systemów i urządzeń jest odpowiedni do zamierzonego celu. 22
Kwalifikacja instalacyjna (IQ Installation Qualification) - udokumentowana weryfikacja stwierdzająca, że obiekty, systemy i urządzenia, zainstalowane lub zmodyfikowane są zgodne z zatwierdzonym projektem i zaleceniami producenta. Sprawdzanie, testowanie lub inne weryfikacje mające na celu potwierdzenie poprawności: instalacji sprzętu i oprogramowania konfiguracji sprzętu i oprogramowania. Jest weryfikacją poprawności specyfikacji projektowej DS. Kwalifikacja instalacyjna powinna być przeprowadzona dla systemów nowych, a inwentaryzacja dla już działających. 23
Kwalifikacja operacyjna (OQ Operational Qualification) - udokumentowana weryfikacja stwierdzająca, że obiekty, systemy i urządzenia, zainstalowane lub zmodyfikowane, funkcjonują tak, jak zamierzono. Celem tej kwalifikacji jest dostarczenie dowodów, że wszystkie parametry danego urządzenia działają poprawnie. W tym celu przeprowadzane są testy dokumentujące dowody, iż wszystkie krytyczne elementy urządzenia działają zgodnie z wyspecyfikowanymi limitami. Jest potwierdzeniem spełnienia wymagań kwalifikacji projektowej DS i funkcjonalnej FS. 24
Kwalifikacja procesowa (PQ Performance Qualification) udokumentowana weryfikacja stwierdzająca, że obiekty, systemy i urządzenia, jako całość, działają skutecznie i w sposób powtarzalny w odniesieniu do zatwierdzonego procesu i specyfikacji produktu. Udokumentowana weryfikacja, że system jest w stanie wykonywać działania związane z procesem zgodnie z pisemnymi, uprzednio zatwierdzonymi wymaganiami w zakresie danego procesu i środowiska operacyjnego. Pozwala na akceptację systemu w oparciu o określone wymagania i zwolnienie do użytkowania. Jest potwierdzeniem spełnienia wymagań specyfikacji wymagań użytkownika URS. 25
Protokół kwalifikacji - schemat postępowania podczas planowania działań i zapisywania wyników i obserwacji, opisujący prospektywnie metodę, którą należy zastosować, kryteria akceptacji, które muszą zostać spełnione w celu potwierdzenia założonej jakości walidowanego systemu, procesu, obiektu. Opisuje precyzyjnie w jaki sposób wykonać poszczególne czynności walidacyjne. Raport kwalifikacji jest to podsumowanie działań opisanych w protokole, odnoszące się do uzyskanych podczas testów wyników, w świetle spełnienia kryteriów akceptacji oraz stwierdzonych odchyleń. Zawiera jednoznaczne podsumowanie stwierdzenie spełnienia kryteriów akceptacji oraz zwolnienie do kolejnego etapu działań. 26
Ogólny schemat formularza stosowany dla wszystkich testów: Odniesienie do numeru protokołu kwalifikacji Kryteria akceptacji dla testu Tabela: czynności krok po kroku przeniesione z procedury wykonania testu (można wprowadzić numerację) oczekiwany rezultat dla każdego kroku otrzymane wyniki potwierdzenie spełnienia oczekiwanych rezultatów: tak / nie odniesienie do numeru komentarza Podpisy wykonawców Miejsce na obserwacje i komentarze Podpis, data zatwierdzenia 27
Końcowy Raport Walidacji powinien zawierać: Przegląd całego procesu walidacji, Potwierdzenie zgodności z planem walidacji (GPW), Podsumowanie wyników procesu, Potwierdzenie kontroli odchyleń, Potwierdzenie bezpieczeństwa, jakości, skuteczności systemu, Potwierdzenie zgodności z GDP (lub brak i podanie przyczyny) Dla większych projektów odniesienie do raportów z poszczególnych etapów, Zwolnienie do użytkowania w środowisku GDP. 28
Dystrybutor powinien posiadać następujące dokumenty SZJ opisujące system i proces jego walidacji: Specyfikacja Wymagań Użytkownika (URS): aktualna w całym cyklu życia dla systemów zastanych jest rodzajem inwentaryzacji Specyfikacje: Projektowa, Funkcjonalna, Instalacyjna Główny Plan Walidacji Ocena wpływu i analiza ryzyka dla systemu i generowanych danych Protokoły i raporty: IQ, OQ, PQ (protokoły FAT i SAT) Formularze testowe, zrzuty ekranu, dane elektroniczne Końcowy raport walidacji formalne zwolnienie do użytkowania Inwentaryzacja systemów Certyfikat walidacyjny Procedury zarządzania systemami 29
Wykaz procedur odnoszących się do systemów skomputeryzowanych: Procedury ogólne oddzielne dla systemu lub ogólne: zarządzania ryzykiem kwalifikacja dostawców szkolenia kontrola zmian odchylenia CAPA nadzór nad dokumentacją Procedury specyficzne: Walidacja systemu Zarządzanie danymi w systemie (wprowadzanie, przechowywanie, monitorowanie, archiwizacja, dostęp, odzyskiwanie) Zarządzanie systemem (instrukcja obsługi, walidacja, bezpieczeństwo i zasady dostępu, postepowanie w przypadku awarii, odchylenia, ocena okresowa, kontrola zmian, naprawy, konserwacja). 30
Utrzymywanie systemu skomputeryzowanego w stanie zwalidowanym 31
Niezbędne są dwa elementy: Zasady kontroli zmian dla systemu skomputeryzowanego Ocena okresowa systemu skomputeryzowanego 32
Zasady kontroli zmian dla systemów skomputeryzowanych zapewnienie wystarczającej liczby danych aby wykazać, że zmieniony proces będzie zgodny z wytycznymi i zapewni, że jakość produktów leczniczych i integralności łańcucha dystrybucyjnego jest utrzymywana w całym procesie dystrybucji, zmiana musi zostać formalnie zgłoszona, udokumentowana i zaakceptowana przez osobę uprawnioną, ocena prawdopodobnego wpływu zmiany na system przeprowadzona w oparciu o zarządzanie ryzykiem - PRZED wprowadzeniem zmiany! Powinna zostać określona potrzeba i zakres rekwalifikacji i / lub rewalidacji, Powinna być pisemna procedura kontroli zmian. 33
Kontrola zmian dla systemów skomputeryzowanych jest to formalny proces, obejmujący zmiany: sprzętu, oprogramowania, konfiguracji infrastruktury IT. Dotyczy etapu użytkowania, czyli zmian w zwalidowanym systemie. Kontrolę zmian należy prowadzić również w fazie rozwoju systemu w celu uniknięcia nieplanowanych i niekontrolowanych inwestycji. 34
Źródła zmian: Uszkodzenie oprogramowania Modernizacja - nowa wersja systemu operacyjnego, oprogramowania, aplikacji Uszkodzenie elementów konstrukcyjnych np. dysku, pamięci, zasilania itd. Aktualizacja sprzętu - dodanie sprzętu, nowych komponentów Nowy personel, procedury, popełniane błędy Nowy dostawca sprzętu, oprogramowania 35
36
Ocena okresowa systemu skomputeryzowanego powinna być prowadzona w ramach kontroli wewnętrznych. Częstotliwość przeglądu powinna być określona w systemie zapewniania jakości (od 1 roku do 3 lat) i uzasadniona za pomocą oceny ryzyka. Cele przeglądu: Zapewnienie, że system jest zgodny z obowiązującymi przepisami i że pozostaje w stanie zwalidowanym od ostatniego przeglądu. System jest poddawany bieżącym kontrolom i funkcjonuje poprawnie. Pozostaje w stanie zwalidowanym, a prowadzone kontrole są wystarczające, aby utrzymać status walidacji. Wskazanie obszarów, które nie funkcjonują poprawnie, aby można było je poprawić, a tym samym wyeliminować zidentyfikowane słabe strony systemu. 37
Zabezpieczenia systemów skomputeryzowanych 38
Zapewnienie bezpieczeństwa przechowywania i archiwizacji danych: Regularne wykonywanie kopii zapasowych. Dostępność, poprawność i możliwość odczytu tych kopii. Zabezpieczenie danych i kopii zapasowych przed uszkodzeniem fizycznym i elektronicznym: Dodatkowe serwery w innej lokalizacji, Przechowywanie kopii w innej lokalizacji niż serwer Szyfrowane kanały przesyłania danych, ograniczenie dostępu do Internetu, Walidacja i okresowy monitoring spójności i rzetelności kopii zapasowych oraz możliwość przywrócenia danych oraz odzyskania danych z nośników stosowanych do ich przechowywania i archiwizacji. 39
Sposoby i zakres zabezpieczeń: Zabezpieczenia fizyczne i / lub logiczne: klucze, karty dostępu, osobiste kody z hasłami, dane biometryczne, ograniczony dostęp do sprzętu komputerowego i miejsc przechowywania danych. Rejestracja przez system tożsamości osób wprowadzających, potwierdzających i usuwających dane oraz dokonujących w nich zmian. Regularne, wymuszane przez system zmiany haseł. Wylogowanie po określonym czasie niekorzystania z systemu. Blokowanie dostępu po określonej ilości nieprawidłowych (błędnych) logowań. Przywracanie dostępu przez właściciela systemu lub np. właściciela procesu. 40
Dziękujemy za uwagę! 41