Walidacja systemu produkcyjnego w przemyśle farmaceutycznym - walidacja systemu EBR/MES

Walidacja systemu w przemyśle farmaceutycznym jest kluczowym procesem zapewniającym, że skomputeryzowane systemy są odpowiednie do ich zamierzonego zastosowania i spełniają aktualne wymogi prawne. Jest to obowiązkowy wymóg cGMP (aktualnych Dobrych Praktyk Wytwarzania) i ma zasadnicze znaczenie dla zarządzania jakością wytwarzanych produktów. Każdy skomputeryzowany system, który może mieć wpływ na bezpieczeństwo pacjenta, jakość produktu i integralność danych, musi zostać odpowiednio zweryfikowany.

Przeczytaj więcej lub posłuchaj naszego podcastu na temat sztucznej inteligencji:

Walidacja ma na celu wykorzystanie istniejących dobrych praktyk branżowych w wydajny i skuteczny sposób. Obejmuje ona wykazanie poprzez udokumentowane dowody że każdy skomputeryzowany system konsekwentnie generuje oczekiwane wyniki. Kluczowe wymogi regulacyjne i wytyczne dotyczące walidacji w tej branży obejmują przepisy GxP (Dobrej Praktyki), EudraLex Volume 4, załącznik 11 dotyczący systemów skomputeryzowanych, US FDA's 21 CFR Part 11 w sprawie dokumentacji elektronicznej i podpisów elektronicznych oraz przewodnik ISPE GAMP: A Risk-Based Approach to Complaint GxP Computerized Systems (GAMP 5). GAMP 5, na przykład, dostarcza praktycznych wskazówek, ustanawia wspólny język i promuje podejście do cyklu życia systemu oparte na dobrych praktykach.

Skomputeryzowany system w tym kontekście, taki jak systemy MES lub EBR firmy Accevo, to zestaw komponentów programowych i sprzętowych, które razem spełniają określone funkcje. Oprogramowanie aplikacyjne powinno być zweryfikowane, a podstawowa infrastruktura IT powinna być kwalifikowana. Jeśli skomputeryzowany system zastępuje operację ręczną, nie powinien obniżać jakości produktu, kontroli procesu lub zapewnienia jakości, ani zwiększać ogólnego ryzyka procesu.

Model V w walidacji systemu

Ogólne podejście do walidacji skomputeryzowanego systemu, takiego jak MES lub EBR, integruje działania walidacyjne z wdrożeniem systemu, zazwyczaj zgodnie z następującą procedurą Cykl życia systemu. Ten cykl życia często obejmuje fazy takie jak planowanie i specyfikacja, projektowanie i rozwój, weryfikacja, obsługa i wycofanie. Poziom wysiłku włożonego w walidację jest współmierny do złożoności systemu (kategoryzacja) i ryzyka związanego z jego określonym przeznaczeniem (krytyczność cGxP). Proces walidacji jest często przedstawiany za pomocą schematu Model V.

Typowe działania walidacyjne i związana z nimi dokumentacja obejmują:

• Główny plan walidacji (VMP): Podstawowy dokument, który zawiera przegląd planowanych działań w zakresie walidacji i kwalifikacji, definiując zakres, ramy, standardy systemu jakości, role i obowiązki, podejście i wyniki walidacji.
• Plan walidacji (VP): Opisuje konkretne działania i rezultaty wymagane do wdrożenia i obsługi systemu, zapewniając szczegółowe planowanie, definiując obowiązki i wymieniając niezbędną dokumentację. Dostarcza dowodów na to, że działania walidacyjne będą systematyczne i kontrolowane.
• Specyfikacja wymagań użytkownika (URS): Dokumentuje potrzeby biznesowe i wymagania dotyczące procesów kontrolowanych przez system. Określa, co system musi wykonywać. URS obejmuje wymagania ogólne, wymagania regulacyjne (takie jak te dotyczące integralności danych, ścieżki audytu i bezpieczeństwa) oraz wymagania funkcjonalne/procesowe. Powinien zawierać listę lokalizacji, w których wykorzystywane są zapisy i podpisy elektroniczne i które mają wpływ na regulacje prawne. Wymagania są jednoznacznie identyfikowalne.
• Analiza ryzyka (RA): Systematyczny proces, często wykorzystujący metody takie jak uproszczona analiza FMEA (Failure Mode and Effects Analysis) oparta na zaleceniach GAMP 5, służąca do oceny, kontroli, komunikacji i przeglądu ryzyka w całym cyklu życia systemu. Ocenia znaczenie systemu dla GxP, integralność danych i wpływ na procesy jakości, w tym definiowanie działań naprawczych. Działania walidacyjne są często oparte na wnioskach z analizy ryzyka.
• Specyfikacja funkcjonalna (FS) i specyfikacja projektu oprogramowania/sprzętu (DS): FS opisuje funkcje i moduły systemu wykorzystywane do spełnienia wymagań zdefiniowanych w URS. DS dokumentuje sposób budowy systemu, w tym strukturę, algorytmy, logikę, formaty danych i opisy interfejsów. DS zawiera również konfigurację i specyfikacje projektowe HW/SW. FS jest tworzony na podstawie URS i wszelkich dokumentów propozycji i stanowi podstawę testów funkcjonalności. Kwalifikacja projektu (DQ) obejmuje ocenę dokumentacji projektu w celu oceny, czy system został zaprojektowany zgodnie z zasadami GMP/GAMP.
• Kwalifikacja dostawców (SQ): Ocenia, czy dostawca jest w stanie dostarczyć produkt lub usługę wysokiej jakości, spełnić wymogi prawne, posiadać odpowiednie procedury jakości oraz zarządzać wdrażaniem, wsparciem i aktualizacjami.
• Kwalifikacja instalacji (IQ): Weryfikuje udokumentowaną instalację i konfigurację wszystkich komponentów systemu, zarówno sprzętu, jak i oprogramowania, zgodnie ze specyfikacjami. Obejmuje to weryfikację poprawności instalacji i konfiguracji.
• Kwalifikacja operacyjna (OQ): Potwierdza, że system działa zgodnie ze specyfikacją funkcjonalną. OQ testuje najbardziej krytyczne funkcje systemu, zwłaszcza te zarządzające krytycznymi danymi, i obejmuje pozytywne i negatywne wyniki testów. Powinna ona obejmować testowanie wymogów prawnych dotyczących elektronicznych rejestrów i podpisów. OQ jest zazwyczaj przeprowadzane w środowisku walidacyjnym.
• Kwalifikacja wydajności (PQ): Weryfikuje i dokumentuje spełnienie wymagań użytkownika. PQ testuje ogólny proces zarządzany przez system zdefiniowany w URS. Testy PQ są często przeprowadzane w środowisku produkcyjnym przy użyciu rzeczywistych danych.
• Matryca identyfikowalności (TM): Mapuje wszystkie wymagania techniczne z URS do odpowiednich sekcji dokumentacji projektowej i procedur testowych (IQ/OQ/PQ). Jego celem jest sprawdzenie, czy wszystkie wymagania zdefiniowane w URS są spełnione przez system. Pokazuje związek między wymaganiami użytkownika a pomyślnie wykonanymi testami.
• Raport podsumowujący walidację (VSR): Dokument wydawany na koniec procesu walidacji podsumowujący wszystkie zaplanowane działania i wyniki. Analizuje zebrane dane, raportuje wyniki testów (w tym niezgodności), potwierdza, że działania zostały wykonane zgodnie z planem, ocenia wyniki testów pod kątem kryteriów akceptacji i zawiera jasne oświadczenie, że system został zweryfikowany i dopuszczony do użytku operacyjnego. Matryca identyfikowalności jest zwykle dołączana jako załącznik.

Kto zatwierdza?

Walidacja jest przeprowadzana przez różne role, w tym Właściciel procesu (odpowiedzialny za proces firmy, przegląd dokumentów walidacyjnych, zarządzanie zmianami), Właściciel systemu (odpowiedzialny za kwestie techniczne, infrastrukturę, zatwierdzanie etapów), Jednostka jakości (odpowiedzialny za kwestie jakości, przeglądanie/zatwierdzanie określonych produktów, zapewnianie zgodności), Kierownik projektu (ogólna odpowiedzialność za dostarczenie rozwiązania, przegląd wyników) oraz Dostawca (zapewnia wdrożenie systemu, usługi konsultingowe, testowanie).

Utrzymanie walidacji przez cały cykl życia systemu

Walidacja to nie tylko jednorazowa czynność podczas wdrażania. Utrzymanie zatwierdzony stan w okresie eksploatacji systemu i w fazie jego wycofania z użytku. Działania w tych fazach obejmują przekazanie, zarządzanie wsparciem, monitorowanie wydajności, zarządzanie incydentami, CAPA, zarządzanie zmianami, naprawy, okresowe przeglądy, tworzenie kopii zapasowych i przywracanie, ciągłość działania, zarządzanie bezpieczeństwem, administrację systemem, migrację danych oraz wycofanie/usunięcie systemu.

System komputerowy w tym kontekście to zestaw komponentów oprogramowania i sprzętu, które razem spełniają określone funkcje. Oprogramowanie aplikacji powinno zostać zatwierdzone, a infrastruktura IT powinna zostać zakwalifikowana. Jeśli skomputeryzowany system zastępuje operację ręczną, nie powinien obniżać jakości produktu, kontroli procesu lub zapewnienia jakości, ani zwiększać ogólnego ryzyka procesu.

Ogólne podejście do walidacji skomputeryzowanego systemu integruje działania walidacyjne z wdrożeniem systemu, zazwyczaj zgodnie z cyklem życia systemu. Ten cykl życia często obejmuje fazy takie jak planowanie i specyfikacja, projektowanie i rozwój, weryfikacja, obsługa i wycofanie. Poziom wysiłku włożonego w walidację jest współmierny do złożoności systemu (kategoryzacja) i ryzyka związanego z jego określonym przeznaczeniem (krytyczność cGxP). Proces walidacji jest często przedstawiany za pomocą modelu V.

Typowe działania walidacyjne i związana z nimi dokumentacja obejmują:

• Główny plan walidacji (VMP): Podstawowy dokument, który zawiera przegląd planowanych działań w zakresie walidacji i kwalifikacji, definiując zakres, ramy, standardy systemu jakości, role i obowiązki, podejście i wyniki walidacji.
• Plan walidacji (VP): Opisuje konkretne działania i rezultaty wymagane do wdrożenia i obsługi systemu, zapewniając szczegółowe planowanie, definiując obowiązki i wymieniając niezbędną dokumentację. Dostarcza dowodów na to, że działania walidacyjne będą systematyczne i kontrolowane.
• Specyfikacja wymagań użytkownika (URS): Dokumentuje potrzeby biznesowe i wymagania dotyczące procesów kontrolowanych przez system. Określa, co system musi wykonywać. URS obejmuje wymagania ogólne, wymagania regulacyjne (takie jak te dotyczące integralności danych, ścieżki audytu i bezpieczeństwa) oraz wymagania funkcjonalne/procesowe. Powinien zawierać listę lokalizacji, w których wykorzystywane są zapisy i podpisy elektroniczne i które mają wpływ na regulacje prawne. Wymagania są jednoznacznie identyfikowalne.
• Analiza ryzyka (RA): Systematyczny proces, często wykorzystujący metody takie jak uproszczona analiza FMEA (Failure Mode and Effects Analysis) oparta na zaleceniach GAMP 5, służąca do oceny, kontroli, komunikacji i przeglądu ryzyka w całym cyklu życia systemu. Ocenia znaczenie systemu dla GxP, integralność danych i wpływ na procesy jakości, w tym definiowanie działań naprawczych. Działania walidacyjne są często oparte na wnioskach z analizy ryzyka.
• Specyfikacja funkcjonalna (FS) i specyfikacja projektu oprogramowania/sprzętu (DS): FS opisuje funkcje i moduły systemu wykorzystywane do spełnienia wymagań zdefiniowanych w URS. DS dokumentuje sposób budowy systemu, w tym strukturę, algorytmy, logikę, formaty danych i opisy interfejsów. DS zawiera również konfigurację i specyfikacje projektowe HW/SW. FS jest tworzony na podstawie URS i wszelkich dokumentów propozycji i stanowi podstawę testów funkcjonalności. Kwalifikacja projektu (DQ) obejmuje ocenę dokumentacji projektu w celu oceny, czy system został zaprojektowany zgodnie z zasadami GMP/GAMP.
• Kwalifikacja dostawców (SQ): Ocenia, czy dostawca jest w stanie dostarczyć produkt lub usługę wysokiej jakości, spełnić wymogi prawne, posiadać odpowiednie procedury jakości oraz zarządzać wdrażaniem, wsparciem i aktualizacjami.
• Kwalifikacja instalacji (IQ): Weryfikuje udokumentowaną instalację i konfigurację wszystkich komponentów systemu, zarówno sprzętu, jak i oprogramowania, zgodnie ze specyfikacjami. Obejmuje to weryfikację poprawności instalacji i konfiguracji.
• Kwalifikacja operacyjna (OQ): Potwierdza, że system działa zgodnie ze specyfikacją funkcjonalną. OQ testuje najbardziej krytyczne funkcje systemu, zwłaszcza te zarządzające krytycznymi danymi, i obejmuje pozytywne i negatywne wyniki testów. Powinna ona obejmować testowanie wymogów prawnych dotyczących elektronicznych rejestrów i podpisów. OQ jest zazwyczaj przeprowadzane w środowisku walidacyjnym.
• Kwalifikacja wydajności (PQ): Weryfikuje i dokumentuje spełnienie wymagań użytkownika. PQ testuje ogólny proces zarządzany przez system zdefiniowany w URS. Testy PQ są często przeprowadzane w środowisku produkcyjnym przy użyciu rzeczywistych danych.
• Matryca identyfikowalności (TM): Mapuje wszystkie wymagania techniczne z URS do odpowiednich sekcji dokumentacji projektowej i procedur testowych (IQ/OQ/PQ). Jego celem jest sprawdzenie, czy wszystkie wymagania zdefiniowane w URS są spełnione przez system. Pokazuje związek między wymaganiami użytkownika a pomyślnie wykonanymi testami.
• Raport podsumowujący walidację (VSR): Dokument wydawany na koniec procesu walidacji podsumowujący wszystkie zaplanowane działania i wyniki. Analizuje zebrane dane, raportuje wyniki testów (w tym niezgodności), potwierdza, że działania zostały wykonane zgodnie z planem, ocenia wyniki testów pod kątem kryteriów akceptacji i zawiera jasne oświadczenie, że system został zweryfikowany i dopuszczony do użytku operacyjnego. Matryca identyfikowalności jest zwykle dołączana jako załącznik.

Najważniejsze informacje

Walidacja jest przeprowadzana przez różne role, w tym właściciela procesu (odpowiedzialnego za proces firmy, przeglądanie dokumentów walidacyjnych, zarządzanie zmianami), właściciela systemu (odpowiedzialnego za kwestie techniczne, infrastrukturę, zatwierdzanie etapów), jednostkę ds. jakości (odpowiedzialną za kwestie jakości, przeglądanie/zatwierdzanie określonych wyników, zapewnienie zgodności), kierownika projektu (ogólną odpowiedzialność za dostarczenie rozwiązania, przeglądanie wyników) oraz dostawcę (zapewnia wdrożenie systemu, usługi konsultingowe, testowanie).

Walidacja to nie tylko jednorazowa czynność przy wdrożeniu. Kluczowe znaczenie ma również utrzymanie zwalidowanego stanu w okresie eksploatacji systemu i w fazie jego wycofania. Działania w tych fazach obejmują przekazanie, zarządzanie wsparciem, monitorowanie wydajności, zarządzanie incydentami, CAPA, zarządzanie zmianami, naprawy, okresowe przeglądy, tworzenie kopii zapasowych i przywracanie, ciągłość działania, zarządzanie bezpieczeństwem, administrację systemem, migrację danych oraz wycofanie/usunięcie systemu.

Warto wiedzieć! Istnieje możliwość wdrożenia skomputeryzowanego systemu, takiego jak OEE, w przemyśle farmaceutycznym bez walidacji w celu wsparcia lokalnego systemu niekrytycznego, przeczytaj więcej tutaj: Jak wdrożyć system monitorowania OEE bez walidacji w 3 miesiące? - Studium przypadku.

Sprawdź również:

MES Pharma. Oprogramowanie dla produkcji farmaceutycznej.

Oprogramowanie Electronic Batch Records (EBR)