Walidacja systemów IT w branży farmaceutycznej

Walidacja systemów IT w branży farmaceutycznej
Data publikacji
9 Czerwiec 2017
Napisany przez
Karolina Jagusiak
Pojęcie walidacji jest nierozerwalnie związane z wdrożeniami złożonych systemów informatycznych w branży farmaceutycznej. To niezwykle ważny proces, który nie kończy się na etapie wdrożenia ale trwa aż po wycofanie systemu z użytkowania. W niniejszym artykule poruszamy temat walidacji systemów skomputeryzowanych w projekcie wdrożeniowym, opisując 6 najważniejszych kroków.

Walidacja systemów skomputeryzowanych jest zbiorem działań mającym na celu dostarczenie udokumentowanego dowodu który zapewni nas, że system rzeczywiście prowadzi do zaplanowanych wyników i działa zgodnie z wcześniejszymi założeniami. Jak to zrobić?

Oto 6 kroków przez które musimy przejść:

1. Jakie wymagania stawiane są przed systemem?

Implementacja systemu IT ma na celu wsparcie, automatyzację bądź optymalizację realizacji procesu biznesowego.  Zwykle więc organizacja wie jaki proces chce wspierać i ma na to jakiś podgląd. Pierwszym krokiem jest więc spisanie listy wymagań. Wymagania użytkownika (User Requirements) zawierają zarówno wymagania funkcjonalne bezpośrednio związane ze wspieranym procesem biznesowym jak i niefunkcjonalne, odnoszące się między innymi do bezpieczeństwa, wydajności czy interfejsu systemu. Tworząc listę wymagań dla systemów wspierających branżę farmaceutyczną należy również pamiętać o wymaganiach prawnych.

2. Walidować? Jak?

Gdy wiemy już co system ma wspierać, należy zastanowić się nad jego krytycznością. Na tym etapie powinniśmy móc ocenić czy system jest krytyczny z punktu widzenia GxP i czy należy go walidować. O co tutaj chodzi? Kluczem jest ocena czy system wspiera elementy procesu biznesowego mogące mieć wpływ na:

  • Zdrowie pacjenta
  • Jakość produktu leczniczego
  • Integralność danych

Jeśli widzimy korelację, odpowiedź jest prosta – trzeba walidować!

3. Jak system ma działać?

Poszczególne funkcje systemu lub elementy konfiguracji wspierają odpowiednie wymagania. W kolejnym etapie należy wypisać funkcje, elementy konfiguracji systemu i rozszerzenia oraz połączyć je z odpowiadającymi im wymaganiami. Celem jest dostarczenie systemu, który spełnia wymagania użytkownika, wobec tego musimy jednoznacznie móc określić, które funkcje odpowiadają poszczególnym wymaganiom oraz zapewnić, że wszystkie wymagania zostaną pokryte i zrealizowane w systemie.

Oczywiście poza typową specyfikacją funkcjonalności systemu należy przygotować specyfikację techniczną.

4. Ryzyko? Jak mu przeciwdziałać?

Z poszczególnymi funkcjami systemu wiążą się ryzyka. Należy je zidentyfikować i ocenić. Każde ryzyko oceniamy pod kątem jego wpływu na: zdrowie pacjenta, jakość produktu leczniczego, integralność danych, prawdopodobieństwa wystąpienia oraz możliwości detekcji. Następnie należy ocenić, które ryzyka możemy zaakceptować a które wymagają od nas działań ograniczających. Metod analizy ryzyka jest wiele i często dojrzałe organizacje mają swoje wypracowane i sprawdzone schematy. Wśród najpopularniejszych możemy wymienić metodę analizy ryzyka zaprezentowaną przez GAMP 5 oraz metodę FMEA.

Wśród działań ograniczających najczęściej spotykane to: dodatkowe testy, procedury, instrukcje użytkownika, szkolenia oraz tzw. przebudowanie funkcji – czasem „zabezpieczenia” możemy „wbudować” w daną funkcję systemu.

Pamiętajmy, żeby po przeprowadzeniu działań ograniczających powtórnie zweryfikować analizę ryzyka!

5. Testy!

Gdy system jest już gotowy, należy sprawdzić czy rzeczywiście działa on tak jak powinien. Na samym początku przeprowadzamy testy na poziomie kodu, np. testy integracyjne czy code review. Następnie sprawdzamy czy wszystkie komponenty są poprawnie zainstalowane „IQ”, czy system działa tak jak powinien „OQ” (według wymagań funkcjonalnych). Jeśli te testy przejdą poprawnie, pora na testy ostateczne „PQ” realizowane zwykle przez użytkowników końcowych, którzy sprawdzą czy system wspiera realizowany proces biznesowy i potwierdzą, że zamierzony cel został osiągnięty – system spełnia zamierzony cel (ang. Intended use). Jeśli na którymś etapie zidentyfikowane zostaną błędy działania systemu, analizujemy je, poprawiamy oraz powtarzamy testy (te dotknięte błędem lub te, na które błąd mógł wpłynąć).

Oczywiście wszystkie testy przeprowadzamy w sposób formalny odpowiednio je dokumentując i pamiętając o dowodach na to, że testy przebiegły pomyślnie. W końcu musimy udowodnić że system działa poprawnie.

6. Podsumowanie

Gdy system jest już gotowy, należy przeszkolić użytkowników oraz przygotować dla nich instrukcje stanowiskowe jeszcze przed oficjalnym startem. Spełnienie powyższych założeń i prawidłowa instalacja systemu w środowisku produkcyjnym pozwala na podsumowanie całości działań i zwolnienie systemu do użytku.

Z formalnego punktu widzenia tworzymy raport walidacji zawierający podsumowanie wszystkich działań, które przeprowadziliśmy. Raport powinien zawierać wszelkie odstępstwa od planu pierwotnego wraz z krótkim uzasadnieniem. Jeśli zidentyfikowane zostały akcje, które nie zostały zrealizowane w terminie ale nie są krytyczne z punktu widzenia walidacji systemu, należy je wymienić oraz opisać w jaki sposób ich realizacja będzie śledzona.

Oczywiście w fazie operacyjnej cały czas pamiętamy, że należy utrzymać zwalidowany status systemu i w odpowiedni sposób realizować i kontrolować takie aspekty jak: zarządzanie zmianą, zarządzanie incydentami i problemami, zarządzanie użytkownikami i dostępami, procedurę backup, procedurę odzyskiwania danych i wiele innych. Ale to o tym w kolejnej części.

Karolina Jagusiak
Validation Consultant, Hicron

Ta strona używa plików cookie. Kontynuując korzystanie z tej witryny, zgadzasz się z naszą Polityką Prywatności.

Wyrażam zgodę