Jedną z coraz bardziej popularnych form wykorzystania chmury obliczeniowej stają się tak zwane usługi SaaS, czyli Software as a Service (oprogramowanie jako usługa). Aplikacje i bazy danych są zainstalowane na serwerach dostawcy, a dostęp do nich jest zapewniany najczęściej poprzez stronę internetową. Zaletą jest to, że klient uzyskuje dostęp do rozwiązań o określonej funkcjonalności, bez inwestowania w infrastrukturę informatyczną.

Rozwiązania chmurowe stają się coraz bardziej popularnym narzędziem również w  firmach farmaceutycznych, także w  obszarach ocenianych jako krytyczne w zakresie dobrych praktyk wytwarzania (GMP – Good Manufacturing Practice). W przypadku gdy mówimy o oprogramowaniu wspomagającym krytyczny obszar GMP, oczywiście musimy pamiętać o  tym, że tego typu rozwiązanie będzie wymagać walidacji. Jak prawidłowo przeprowadzić taką walidację? Gdzie znajduje się potencjalne ryzyko? Jakiej współpracy oczekiwać na linii: firma farmaceutyczna <-> dostawca? Na te pytania postaram się odpowiedzieć poniżej.

Określenie wymagań

Jak w  każdym innym przypadku, powinniśmy zacząć od przygotowania Specyfikacji Wymagań Użytkownika (URS – User Requirement Specification). Decydując się na rozwiązanie SaaS, należy jednak pamiętać, że obok wymagań funkcjonalnych, opisujących działanie systemu czy też wymagań jakościowych, obejmujących aspekty GMP, należy szczególnie za-stanowić się nad tematem zarządzania danymi oraz integralnością danych.

Musimy sobie przede wszystkim uświadomić, że z tego samego rozwiązania już korzystają lub mogą korzystać w przyszłości inne firmy, w tym nasza konkurencja. Jest to ważne, ponieważ dane przechowywane będą na zewnętrznych serwerach, którymi zarządza firma zewnętrzna. Jeżeli dodatkowo system będzie przetwarzał dane personalne, wejdziemy w  obszar przepisów o  ochronie danych osobowych. Dlatego tak ważne będzie wyszczególnienie wymagań w tym obszarze, zgodnie z wewnętrzną polityką bezpieczeństwa i zarządzania danymi. W związku z powyższym, tworząc URS-a  powinniśmy przynajmniej zwrócić uwagę na kilka poniższych kwestii:

•  lokalizację serwerów,

•  dedykowany serwer,

•  archiwizację i backup,

•  zarządzanie dostępem,

•  aktualizacje, poprawki systemu,

•  testowanie.

Powyższe zagadnienia nie wyczerpują oczywiście całego wachlarza pytań oraz wymagań, jakie można postawić przed systemem SaaS, natomiast powinny pomóc wskazać kierunek przy pisaniu URS-a.

Audyt dostawcy

Zgodnie z wymaganiami Aneksu 11 GMP, dostaw-

ca systemów IT musi być audytowany. W przypadku rozwiązań chmurowych jest to szczególnie ważne, ponieważ dostawcy powierzamy realizację procesu biznesowego, system i opiekę nad nim oraz dane i ich zabezpieczenie. Może być to również jedna z nielicznych okazji pozwalających na szczegółową analizę systemu jakościowego dostawcy.

Zadowalające odpowiedzi dostawcy na wymagania zdefiniowane w URS muszą być na tym etapie zweryfikowane i  potwierdzone. W  tym celu należy zweryfikować czy dostawca posiada odpowiednie procedury, czy procedury te są wdrożone i stosowane w  praktyce oraz czy personel jest odpowiednio przeszkolony. Z perspektywy klienta – firmy farmaceutycznej – jednym z kluczowych punktów audytu powinna być weryfikacja dokumentacji walidacyjnej, a jeżeli dostawca usługi takowej nie posiada, to weryfikacja dokumentacji technicznej i testowej. Innym kluczowym punktem audytu powinny być aspekty związane z bezpieczeństwem systemu, zaczynając od weryfikacji architektury systemu, przez szyfrowane protokoły komunikacji, a  kończąc na weryfikacji testów penetracyjnych.

Należy pamiętać, że zgodnie z przepisami GMP, zawsze końcową odpowiedzialność za realizację procesu biznesowego ponosi firma farmaceutyczna, nawet kiedy proces ten został przekazany do realizacji do dostawcy w ramach rozwiązania Software as a Service. Biorąc to pod uwagę, audyt dostawcy jest krytycznym elementem procesu walidacji takiego rozwiązania.

Proces walidacji rozwiązania software as a service

Co do zasady, proces walidacji rozwiązania SaaS nie powinien się mocno różnić od walidacji innych systemów komputerowych będących własnością firmy farmaceutycznej. Wobec tego, jeżeli firma ma zdefiniowane procedury walidacji w tym obszarze, to należałoby je zastosować. Poniżej przedstawiony jest przykład jednego z możliwych podejść.

Przykładowy proces walidacji przedstawiony jest na rys. 1

Analiza Ryzyka – proces analizy ryzyka powinien rozpocząć się wraz z rozpoczęciem procesu walidacji, a wszystkie następne działania (kwalifikacja i jej zakres, zakres testów, wymagana dokumentacja, itp.) powinny być planowane i wykonywane w oparciu o „risk-based approach”. Do analizy ryzyka można stosować różne narzędzia, jednymi z  najpopularniejszych są FMEA oraz Ocena Ekspercka.

Plan Walidacji – w  oparciu o  przeprowadzoną analizę ryzyka oraz wyniki audytu dostawcy należy opracować plan walidacji, który powinien uwzględniać wszystkie kluczowe etapy procesu, z uwzględnieniem specyfiki rozwiązania SaaS. Wspominam o wyniku audytu dostawcy nie przez przypadek, bowiem wnioski z audytu będą bardzo mocno wpływały na to, jakie działania należy zaplanować do realizacji we własnym zakresie, jakie działania przekazać dostawcy do zrealizowania, a które działania można pominąć, bo już są zrealizowane przez dostawcę.

Opracowanie dokumentacji – firma farmaceutyczna odpowiada za opracowanie Specyfikacji Wymagań Użytkownika, natomiast pozostała dokumentacja techniczna (Specyfikacje Funkcjonalne, Specyfikacje Techniczne, opis architektury systemu, opis konfiguracji, interfejsów i  inne) powinny być opracowane i dostarczone przez dostawcę oprogramowania. W celu zweryfikowania czy dokumentacja dostawcy pokrywa właściwie URS-a, można już na tym etapie przystąpić do przygotowywania Matrycy Śledzenia. Matryca Śledzenia stanowi część dokumentacji walidacyjnej firmy farmaceutycznej, a  jej zadaniem jest wykazanie, że wymagania użytkownika zostały zaimplementowane w systemie (powiązanie między URS-em a odpowiadającą mu Specyfikacją Funkcjonalną) oraz że zostały właściwie przetestowane (powiązanie między URS-em, a odpowiadającymi mu testami).

Kwalifikacja infrastruktury – testy walidacyjne muszą być prowadzone na skwalifikowanej infrastrukturze. Dostawca oprogramowania powinien na tym etapie przedstawić dokumentację kwalifikacyjną dla serwerów (przynajmniej serwera testowego i produkcyjnego). Bez potwierdzenia statusu skwalifikowania infrastruktury, nie należy rozpoczynać testów walidacyjnych.

Wykonanie testów walidacyjnych – zakres testów, podejście do testowania, zasady raportowania i kryteria ocena błędów oraz sposób dokumentacji powinny być opisane w planie testów. Testy możemy podzielić na dwie grupy: Test IT (Testy Jednostkowe, Przegląd Kodu Źródłowego, Testy Systemowe, Testy Integracyjne, Testy Bezpieczeństwa) oraz Testy Biznesowe (Testy Akceptacyjne Użytkownika, Testy End-to-End). Za część techniczną systemu odpowiada dostawca, dla-tego, jeżeli wyniki audytu w obszarze testowania były pozytywne, wówczas w przypadku Testów IT można powołać się na testy wykonywane przez dostawcę. Istotne będzie zweryfikowanie dostępnej dokumentacji testowej oraz zakresu testowania. Takie podejście znacząco zmniejsza ilość testowania po stronie firmy farmaceutycznej, ponieważ do wykonania zostaną jedynie Testy Biznesowe. Po zakończeniu testów należy uzupełnić Matrycę Śledzenia w celu wykazania, że każ-de z wymagań zostało odpowiednio przetestowane. Na koniec należy opracować Raport z Testów podsumowujący wyniki. Weryfikacji powinny zostać poddane wszystkie zgłoszone w trakcie testowania błędy oraz ich aktualny status. Błędy ocenione jako krytyczne i ważne powinny być rozwiązane przed zamknięciem Raportu z Testów.

Określenie zasad utrzymania systemu – po zakończeniu całości testów i przed sfinalizowaniem Raportu z  Walidacji należy ustalić i  opisać zasady utrzymywania systemu w  stanie zwalidowanym. Jeżeli jest taka potrzeba, należy opracować stosowne procedury i instrukcje oraz przeprowadzić szkolenia. Działania te powinny być również podsumowane w Raporcie z Walidacji, a szczegółowe zasady dotyczące utrzymywania systemu opisane w odrębnej umowie serwisowej – Service Level Agreement.

Opracowanie Raportu z Walidacji – na zakończenie procesu walidacji należy opracować Raport z Walidacji z podsumowaniem całego przeprowadzonego procesu. Jeżeli w trakcie trwania walidacji wystąpiły jakieś niezgodności czy odchylenia, należy je również opisać i ocenić. Jeżeli jakieś niezgodności nie zostały rozwiązane na tym etapie, powinny być przedstawione wdrożone działania obniżające ryzyko oraz wyznaczony termin na rozwiązanie otwartych niezgodności. Raport z  Walidacji powinien zawierać stwierdzenie o dopuszczeniu przedmiotu walidacji do używania na produkcji. Całość dokumentacji, która powstaje w  ramach procesu walidacji musi być opracowana i zatwierdzona przed podpisaniem Raportu z Walida-cji. Dotyczy to również materiałów szkoleniowych, procedur, instrukcji, itp.

Utrzymanie systemu – Service Level Agreement

Zwalidowany system pracujący w ramach rozwiązania SaaS, podobnie jak każdy inny, wymaga utrzymania zarówno od strony technicznej, jak i od strony walidacyjnej. Przez utrzymanie systemu rozumiemy tutaj szereg aktywności realizowanych przez dostawcę w  celu zapewnienia poprawności oraz ciągłości działania systemu. Do tych aktywności zaliczamy: monitorowanie działania systemu, wprowadzanie zmian, poprawek i  aktualizacji, testowanie, zarządzanie uprawnieniami i dostępami, archiwizacja i backup, zarządzanie incydentami, zapewnienie linii wsparcia (helpdesk, druga i trzecia linia wsparcia) i inne.

Z punktu widzenia firmy farmaceutycznej, kluczowe będzie ciągłe utrzymanie stanu zwalidowanego, realizowane w procesie kontroli zmian, który powinien łączyć w sobie aspekty związane z:

• zarządzaniem incydentami i zgłoszeniami,

• oceną ryzyka,

• zarządzaniem dokumentacją,

• testowaniem,

• szkoleniami.

Proces ten, najprościej mówiąc, powinien być zgodny z wymaganiami GMP, czyli:

• powinny być dostępne formalne wnioski o wprowadzenie zmiany – dotyczy to zarówno poprawek błędów, kiedy takim wnioskiem może być zgłoszony incydent, jak i aktualizacji,

• każdy wniosek powinien być oceniony przynajmniej pod kątem wpływu na system, dokumentację oraz testowanie; na tej podstawie powinien powstać plan wdrożenia wraz z wykazem niezbędnych czynności do wykonania,

• realizacja wdrożenia powinna być na bieżąco monitorowana pod kątem poprawności zarówno merytorycznej, jak i jakościowej,

• na koniec zmiana powinna być oceniona, czy została wdrożona poprawnie.

Ponieważ system utrzymywany jest przez dostawcę i  to dostawca odpowiada za realizację procesów, takich jak np. na przykład kontrola zmian, dlatego kluczowe jest, żeby istniała formalna umowa serwisowa – Service Level Agreement – między firmą farmaceutyczną a dostawcą, która będzie precyzowała powyższe zagadnienia, zarówno co do merytorycznej strony tych procesów, jak i samych zasad współpracy (kanały komunikacji, czasy reakcji, dostęp do dokumentacji, itp.).

Podsumowanie

Rozwiązania chmurowe SaaS (Software as a Service), ze względu na swoje rozliczne zalety, są coraz bardziej popularne wśród firm farmaceutycznych, również w obszarach GMP krytycznych. I choć walidacja wymagana w tych przypadkach, może stanowić wyzwanie, wydaje się, że kluczowym aspektem całego procesu jest wybór dostawcy, poprzedzony szczegółowym audytem. Taki wniosek nie powinien jednak nikogo dziwić. Jakość systemu i jego bezpieczeństwo zależy w takim przypadku przede wszystkim od dostawcy, jego świadomości wymagań GMP oraz odpowiednio wdrożonych procesów jakościowych. Należy jednak pamiętać, że firma farmaceutyczna decydując się na dane rozwiązanie, jest odpowiedzialna za cały proces walidacji i  powinna wiedzieć, w jaki sposób chce taką walidację przeprowadzić, zanim zdecyduje się na takie rozwiązanie.