System SaaS może wspierać proces jakościowy, badania laboratoryjne, produkcję, dystrybucję albo badania kliniczne bez utrzymywania aplikacji we własnym centrum danych. Model chmurowy nie usuwa jednak odpowiedzialności regulowanej firmy za sposób wykorzystania systemu. Jeżeli aplikacja przetwarza dane GxP, wpływa na jakość produktu, bezpieczeństwo pacjenta lub decyzje regulowane, organizacja musi wykazać, że rozwiązanie jest odpowiednie do zamierzonego zastosowania i pozostaje pod kontrolą przez cały cykl życia.

Walidacja systemów SaaS w farmacji różni się od klasycznego projektu wdrożeniowego. Dostawca odpowiada za część platformy, publikuje aktualizacje według własnego harmonogramu i może korzystać z podwykonawców. Klient konfiguruje procesy, role, dane, integracje i sposób użycia. Zakres odpowiedzialności jest więc podzielony, ale odpowiedzialność regulacyjna za proces GxP pozostaje po stronie organizacji korzystającej z systemu.

W artykule wyjaśniamy, kiedy system SaaS wymaga walidacji, jak zbudować strategię opartą na ryzyku, jakich dowodów oczekiwać od dostawcy i jak utrzymać stan zwalidowany przy częstych wydaniach oprogramowania. Materiał dotyczy przede wszystkim środowiska GMP, ale wiele opisanych zasad można zastosować także w obszarach GLP, GCP, GDP i farmakowigilancji po uwzględnieniu właściwych przepisów oraz procedur organizacji.

1. Czym jest walidacja systemu SaaS w środowisku GxP

Walidacja systemu skomputeryzowanego dostarcza udokumentowanych dowodów, że system spełnia zatwierdzone wymagania użytkownika, działa zgodnie z zamierzonym zastosowaniem i jest kontrolowany w sposób proporcjonalny do ryzyka. W modelu SaaS przedmiotem oceny nie jest sam produkt dostawcy w oderwaniu od organizacji. Walidowany jest konkretny sposób wykorzystania aplikacji, obejmujący konfigurację, procesy, dane, interfejsy, role użytkowników i procedury operacyjne.

Ten sam system może mieć odmienny status w dwóch firmach. W pierwszej służy wyłącznie do organizacji spotkań, a w drugiej zatwierdza specyfikacje, przechowuje wyniki badań lub generuje zapis wykorzystywany przy zwolnieniu serii. Nazwa produktu i deklaracje producenta nie przesądzają więc o zakresie walidacji. Decydują zamierzone zastosowanie, znaczenie danych i wpływ funkcji na regulowany proces.

W praktyce walidacja powinna odpowiedzieć na cztery pytania:

• czy wymagania biznesowe i regulacyjne zostały jednoznacznie określone;
• czy ryzyka dla pacjenta, produktu i integralności danych są rozpoznane i kontrolowane;
• czy konfiguracja oraz krytyczne procesy zostały skutecznie przetestowane;
• czy organizacja potrafi utrzymać kontrolę po uruchomieniu systemu.

Walidacja nie jest certyfikatem nadawanym aplikacji raz na zawsze. Jest stanem opartym na dowodach dotyczących konkretnej wersji, konfiguracji i sposobu użycia, a następnie podtrzymywanym przez zarządzanie zmianami, incydentami, dostępem i okresowe przeglądy.

2. Kiedy system SaaS podlega wymaganiom GxP

Pierwszym krokiem nie powinno być zamówienie pełnego pakietu testów, lecz klasyfikacja systemu i jego funkcji. Należy ustalić, czy rozwiązanie tworzy, zmienia, przechowuje, przesyła lub raportuje dane wykorzystywane w działalności regulowanej. Istotne jest również to, czy awaria, błędna konfiguracja albo nieautoryzowana zmiana może wpłynąć na jakość produktu, bezpieczeństwo pacjenta, wiarygodność danych lub zgodność procesu.

Przykładowe systemy SaaS o potencjalnym znaczeniu GxP obejmują:

• elektroniczne systemy zarządzania jakością eQMS;
• systemy zarządzania dokumentacją EDMS i szkoleniami;
• laboratoryjne systemy LIMS, ELN i platformy zarządzania danymi analitycznymi;
• systemy wspierające badania kliniczne, bezpieczeństwo leków i nadzór nad przypadkami;
• aplikacje do zarządzania zmianami, odchyleniami, CAPA i reklamacjami;
• systemy ERP, planowania i gospodarki magazynowej, jeżeli ich dane wpływają na operacje GxP;
• platformy do elektronicznych zapisów i podpisów stosowanych w procesach regulowanych.

Nie każda funkcja takiego rozwiązania musi być równie krytyczna. Moduł obsługujący zatwierdzenie dokumentu może wymagać bardziej rygorystycznych kontroli niż moduł prezentujący pomocniczy pulpit. Podejście oparte na ryzyku pozwala skupić testy i dokumentację na funkcjach, które rzeczywiście wpływają na chronione dane i decyzje.

2.1 Ocena wpływu GxP

Ocena wpływu powinna identyfikować regulowany proces, właściciela biznesowego, rodzaje zapisów, decyzje podejmowane na podstawie danych oraz możliwe skutki błędu. Samo oznaczenie aplikacji jako „GxP” albo „non GxP” jest zbyt ogólne, jeżeli system obsługuje wiele procesów. Lepszym rozwiązaniem jest analiza funkcji i przepływów danych.

Wysoki wpływ mogą mieć funkcje, które:

• sterują krytycznym etapem procesu lub dostarczają dane do jego zwolnienia;
• generują, obliczają albo zatwierdzają wynik mający znaczenie dla jakości produktu;
• utrzymują oryginalne dane, metadane i ścieżkę audytową;
• zarządzają elektronicznymi podpisami lub zatwierdzeniami;
• przesyłają dane między systemami bez niezależnej kontroli ich kompletności.

Wynik oceny powinien wskazywać, które wymagania są krytyczne, jaki poziom dowodów jest potrzebny i które zmiany będą wymagały ponownej oceny albo testów regresji.

3. Podstawa regulacyjna walidacji SaaS

W Polsce wymagania Dobrej Praktyki Wytwarzania wynikają z rozporządzenia Ministra Zdrowia w sprawie wymagań Dobrej Praktyki Wytwarzania wraz z późniejszymi zmianami. Aneks 11 obejmuje systemy skomputeryzowane stosowane w działalności GMP i wymaga, aby aplikacje były walidowane, a infrastruktura IT kwalifikowana. Zakres walidacji oraz kontroli integralności danych powinien wynikać z uzasadnionej i udokumentowanej oceny ryzyka.

Na poziomie europejskim podstawowym punktem odniesienia pozostaje EudraLex Volume 4 i EU GMP Annex 11. Aneks nie ustanawia osobnej kategorii prawnej dla SaaS. Model dostarczania nie zwalnia z obowiązków dotyczących walidacji, kwalifikacji dostawcy, bezpieczeństwa, ścieżek audytowych, ciągłości działania, archiwizacji i okresowej oceny.

Wytyczne EMA dotyczące GMP i integralności danych odnoszą cykl życia danych również do aplikacji i pamięci masowej w chmurze. Organizacja powinna rozumieć, gdzie powstają dane i metadane, jak są przetwarzane, przenoszone, przechowywane, odzyskiwane i usuwane oraz jakie podmioty mają do nich dostęp.

Skalowanie działań walidacyjnych powinno odpowiadać ryzyku. ICH Q9(R1) dotyczący zarządzania ryzykiem jakości wskazuje, że poziom formalności, wysiłku i dokumentacji powinien być współmierny do poziomu ryzyka. Nie oznacza to ograniczania wymaganych kontroli z powodów budżetowych. Oznacza natomiast, że dowody należy dobierać do krytyczności funkcji, złożoności systemu i niepewności.

Jeżeli rozwiązanie jest wykorzystywane w procesach podlegających regulacjom amerykańskim, trzeba przeanalizować także zakres 21 CFR Part 11 oraz odpowiednich przepisów bazowych. Wytyczne FDA dotyczące elektronicznych zapisów i podpisów wyjaśniają, że Part 11 dotyczy określonych zapisów elektronicznych utrzymywanych lub przekazywanych na podstawie wymagań FDA. Nie każda funkcja elektroniczna automatycznie podlega Part 11, a sformułowanie „Part 11 compliant” nie zastępuje analizy konkretnego procesu i konfiguracji.

GAMP 5 jest powszechnie stosowanym przewodnikiem branżowym pomagającym przełożyć wymagania na cykl życia systemu i podejście oparte na ryzyku. Nie jest jednak przepisem prawa ani certyfikatem produktu. Organizacja powinna określić własną strategię walidacji na podstawie mających zastosowanie regulacji, zamierzonego zastosowania systemu oraz swojego systemu jakości.

4. Odpowiedzialność firmy i dostawcy SaaS

W tradycyjnym wdrożeniu organizacja może kontrolować serwery, bazę danych, harmonogram aktualizacji i wiele czynności administracyjnych. W SaaS część tych działań wykonuje dostawca lub jego podwykonawcy. Zmienia to źródło dowodów i mechanizmy nadzoru, ale nie przenosi odpowiedzialności za regulowany proces.

Podział odpowiedzialności powinien być zapisany w umowie, umowie jakościowej albo innym kontrolowanym dokumencie. Ogólny regulamin usługi zwykle nie opisuje wszystkich kwestii potrzebnych w środowisku GxP.

Macierz nie powinna pozostawiać luk ani dublować odpowiedzialności bez wskazania właściciela. Szczególnie ważne są sytuacje, w których dostawca zakłada, że klient testuje daną kontrolę, a klient uważa ją za część standardowej usługi.

5. Walidacja systemów SaaS w farmacji krok po kroku

5.1 Określenie zamierzonego zastosowania

Zamierzone zastosowanie opisuje, po co organizacja wdraża system, jakie procesy będzie wspierał, kto będzie z niego korzystał i jakie decyzje będą podejmowane na podstawie danych. Opis powinien być konkretny. Stwierdzenie „system do zarządzania jakością” nie wyjaśnia, czy aplikacja obsługuje dokumenty, CAPA, szkolenia, audyty, podpisy czy wszystkie te funkcje.

Na tym etapie należy również określić granice systemu, interfejsy, źródła danych, rekordy GxP i funkcje pozostające poza zakresem. Dobrze zdefiniowana granica ogranicza późniejsze spory dotyczące testów i odpowiedzialności.

5.2 Mapowanie procesu i cyklu życia danych

Mapa procesu pokazuje, gdzie dane są tworzone, sprawdzane, zatwierdzane, raportowane i archiwizowane. Dla SaaS trzeba uwzględnić również transfery między usługami, integracje API, warstwy raportowe, kopie zapasowe, eksporty oraz narzędzia administracyjne dostawcy.

Analiza powinna obejmować dane oraz metadane potrzebne do odtworzenia zdarzenia. Sama możliwość wyeksportowania pliku PDF nie zawsze wystarczy, jeżeli nie zachowuje historii zmian, podpisów, znaczników czasu, relacji lub kontekstu rekordu.

5.3 Kwalifikacja dostawcy i usługi

Kwalifikacja dostawcy powinna być proporcjonalna do krytyczności rozwiązania i stopnia zależności od zewnętrznego podmiotu. Certyfikaty ISO 27001, raporty SOC i wyniki testów bezpieczeństwa mogą stanowić ważne dowody, ale nie potwierdzają automatycznie zgodności konkretnego procesu GxP.

Ocena może obejmować:

• system zarządzania jakością i odpowiedzialności w organizacji dostawcy;
• cykl rozwoju oprogramowania, testy, przeglądy kodu i obsługę defektów;
• zarządzanie wersjami, zmianami i komunikacją release notes;
• bezpieczeństwo, zarządzanie podatnościami i reakcję na incydenty;
• ciągłość działania, kopie zapasowe i testowanie odtwarzania;
• nadzór nad podwykonawcami oraz lokalizacje przetwarzania danych;
• dostępność dokumentacji, wsparcia audytowego i danych po rozwiązaniu umowy.

Forma oceny może obejmować kwestionariusz, przegląd dokumentów, zdalny audyt lub audyt na miejscu. Decyzja powinna wynikać z ryzyka, a nie z jednej stałej procedury dla wszystkich dostawców.

5.4 Ustalenie wymagań i kryteriów akceptacji

Specyfikacja wymagań użytkownika powinna opisywać potrzebny rezultat i kryteria akceptacji. Wymagania muszą być testowalne i możliwe do prześledzenia. Oprócz funkcji biznesowych warto ująć wymagania dotyczące integralności danych, bezpieczeństwa, audytu, podpisów elektronicznych, retencji, eksportu, wydajności, dostępności i obsługi awarii.

Przykładowe wymaganie „system posiada audit trail” jest zbyt ogólne. Należy określić, jakie zdarzenia mają być zapisywane, czy zapis zawiera użytkownika, datę, czas, wartość poprzednią i nową, powód zmiany oraz kto może przeglądać i eksportować historię.

5.5 Ocena ryzyka funkcjonalnego i integralności danych

Ocena ryzyka łączy wymagania z możliwymi błędami oraz kontrolami. Dla każdej funkcji warto ustalić, co może pójść źle, jaki będzie skutek, jak błąd może zostać wykryty i które zabezpieczenie ogranicza ryzyko. Krytyczne wymagania powinny otrzymać odpowiednio silne dowody z testów lub innych wiarygodnych źródeł.

Nie należy sprowadzać oceny wyłącznie do mechanicznego iloczynu punktów. Uzasadnienie, wiedza procesowa i jakość danych wejściowych są ważniejsze niż pozorna precyzja liczby. Ryzyko trzeba ponownie oceniać po zmianie konfiguracji, procesu, interfejsu albo dostawcy.

5.6 Projekt konfiguracji i kontroli

Standardowa konfiguracja SaaS często ogranicza potrzebę tworzenia niestandardowego kodu, ale konfiguracja nadal może decydować o zachowaniu procesu. Statusy, ścieżki zatwierdzeń, reguły eskalacji, role, słowniki, formularze i reguły retencji powinny zostać opisane, przejrzane i kontrolowane.

Rozszerzenia, skrypty, automatyzacje i integracje zwiększają zakres odpowiedzialności klienta. Trzeba ustalić ich właścicieli, repozytoria, sposób wdrażania i testowania. Wysoki poziom personalizacji może utrudniać korzystanie ze standardowych dowodów dostawcy.

5.7 Walidacja migracji i interfejsów

Migracja danych wymaga potwierdzenia kompletności, dokładności i zachowania znaczenia zapisów. Strategia powinna opisywać reguły mapowania, transformacje, rekordy odrzucone, uzgodnienie liczby obiektów i sposób zatwierdzania wyjątków. Próbkowanie może być właściwe, jeżeli jego zakres wynika z ryzyka i struktury danych.

Interfejsy należy testować w obu kierunkach, jeżeli dwukierunkowy przepływ ma znaczenie dla procesu. Testy powinny obejmować poprawne dane, błędy transmisji, duplikaty, ponowienie komunikatu, synchronizację czasu oraz zachowanie systemu po częściowym niepowodzeniu.

5.8 Testowanie krytycznych procesów

Testy powinny wykazać spełnienie wymagań i skuteczność kontroli. W SaaS można wykorzystać część dowodów dostawcy, jeżeli organizacja rozumie ich zakres, wersję, środowisko i sposób zatwierdzenia. Nie ma potrzeby bezrefleksyjnie powtarzać każdego testu producenta. Trzeba natomiast samodzielnie potwierdzić własną konfigurację, procesy, role, dane i integracje.

Pakiet testów może obejmować:

• testy pozytywne krytycznych przepływów biznesowych;
• testy negatywne oraz obsługę wyjątków;
• testy ról i rozdziału obowiązków;
• sprawdzenie audit trail i elektronicznych podpisów;
• testy integralności transferu i migracji danych;
• testy raportów, obliczeń i eksportów;
• scenariusze awarii, odzyskiwania i ciągłości procesu;
• testy akceptacyjne wykonywane przez reprezentatywnych użytkowników.

Nazwy IQ, OQ i PQ mogą być używane zgodnie z procedurami organizacji, ale nie powinny zastępować logicznego powiązania wymagań, ryzyk i dowodów. Dla typowego SaaS klasyczna kwalifikacja instalacyjna może w dużej mierze opierać się na dowodach dostawcy, natomiast konfiguracja i zamierzone zastosowanie wymagają oceny po stronie klienta.

5.9 Raport i decyzja o uruchomieniu

Raport podsumowujący powinien przedstawiać zakres, wersję i konfigurację systemu, wykonane działania, wyniki testów, odchylenia, pozostałe ryzyka oraz warunki dopuszczenia do użycia. Nierozwiązane odchylenie nie musi automatycznie blokować uruchomienia, ale decyzja o akceptacji ryzyka powinna być jawna, uzasadniona i zatwierdzona przez właściwe role.

Przed uruchomieniem należy potwierdzić gotowość procedur, wsparcia, szkoleń, zarządzania dostępem, kopii zapasowych, monitorowania i obsługi incydentów. Walidacja techniczna bez gotowości operacyjnej nie zapewnia kontroli nad systemem.

6. Dokumentacja walidacyjna systemu SaaS

Pakiet dokumentacji powinien umożliwiać prześledzenie drogi od zamierzonego zastosowania i wymagań do ryzyk, kontroli, testów i decyzji o dopuszczeniu. Nazwy dokumentów mogą różnić się między organizacjami. Ważniejsze od liczby szablonów jest to, czy dowody są kompletne, zatwierdzone, aktualne i możliwe do odtworzenia podczas inspekcji.

Dokumentacja dostawcy powinna być przyjmowana świadomie. Raport z testów producenta ma wartość tylko wtedy, gdy wiadomo, której wersji dotyczy, jaki był zakres testu, jakie kryteria zastosowano i czy wynik odnosi się do funkcji wykorzystywanych przez klienta.

7. Integralność danych i zasady ALCOA

System SaaS powinien wspierać zachowanie danych, które można przypisać do osoby, odczytać, powiązać z czasem wykonania, zachować w formie oryginalnej lub zweryfikowanej kopii oraz uznać za dokładne. Rozszerzone zasady ALCOA+ obejmują także kompletność, spójność, trwałość i dostępność danych.

Ocena integralności danych powinna objąć:

• unikalne konta i odpowiedzialność za działania użytkownika;
• synchronizację czasu i znaczenie stref czasowych;
• ochronę oryginalnych danych oraz powiązanych metadanych;
• kontrolę zmian i możliwość przeglądu ścieżki audytowej;
• kompletność eksportów, raportów i zweryfikowanych kopii;
• zabezpieczenie danych podczas integracji i migracji;
• retencję, archiwizację, wyszukiwanie i odczyt przez wymagany okres;
• możliwość odzyskania danych po awarii oraz potwierdzenie skuteczności odtworzenia.

Nie wystarczy sprawdzić, czy funkcja audit trail istnieje. Organizacja powinna ustalić, czy jest zawsze aktywna dla krytycznych zdarzeń, kto może zmienić jej ustawienia, jak prezentuje zmiany i jak będzie regularnie przeglądana. Jeżeli dostawca ma uprzywilejowany dostęp administracyjny, jego działania również powinny podlegać odpowiednim mechanizmom nadzoru.

8. Aktualizacje i utrzymanie stanu zwalidowanego

Największym wyzwaniem w SaaS bywa nie pierwsza walidacja, lecz rytm późniejszych zmian. Dostawca może publikować wiele wydań w roku, a część funkcji może być aktywowana automatycznie. Organizacja potrzebuje procesu, który szybko odróżnia zmianę nieistotną od zmiany wpływającej na proces GxP.

Proces obsługi wydania powinien obejmować:

1. Pozyskanie release notes i informacji o planowanym terminie.
2. Identyfikację zmienionych funkcji, interfejsów, danych i wymagań.
3. Ocenę wpływu na konfigurację, ryzyka oraz dokumentację.
4. Decyzję o zakresie testów regresji i potrzebnych działaniach.
5. Wykonanie oraz zatwierdzenie testów przed użyciem zmiany w procesie GxP, jeżeli jest to możliwe.
6. Aktualizację dokumentacji, materiałów szkoleniowych i macierzy śledzenia.
7. Udokumentowane dopuszczenie wydania lub zastosowanie uzgodnionego działania ograniczającego ryzyko.

Umowa z dostawcą powinna zapewniać wystarczający czas na ocenę zmian, dostęp do środowiska testowego i czytelne informacje o wpływie wydania. Jeżeli klient nie może odroczyć aktualizacji, proces musi uwzględniać krótkie okno oceny, priorytetowe scenariusze regresji oraz plan reakcji na nieakceptowalny wynik.

Stan zwalidowany utrzymują także codzienne procesy operacyjne: przeglądy dostępów, zarządzanie incydentami, CAPA, monitorowanie interfejsów, okresowa ocena, szkolenia, przegląd audit trail, testowanie odtworzenia i kontrolowane wycofanie systemu.

9. Najczęstsze błędy w walidacji SaaS

9.1 Poleganie wyłącznie na certyfikatach dostawcy

ISO 27001 lub raport SOC może wspierać kwalifikację bezpieczeństwa i kontroli organizacyjnych. Nie potwierdza jednak, że konkretna konfiguracja, workflow, raport i rola użytkownika spełniają wymagania procesu GxP.

9.2 Kopiowanie klasycznego modelu CSV bez uwzględnienia SaaS

Powielanie dokumentów i testów przeznaczonych dla systemu instalowanego lokalnie może tworzyć duży nakład pracy bez pokrycia najważniejszych ryzyk SaaS. Strategia powinna wykorzystywać dowody dostawcy i koncentrować działania klienta na konfiguracji, danych, integracjach oraz sposobie użycia.

9.3 Brak jasnego podziału odpowiedzialności

Nieprecyzyjna umowa utrudnia dostęp do dowodów, analizę incydentów i ocenę aktualizacji. Podział obowiązków powinien obejmować również podwykonawców, wsparcie administracyjne, kopie danych i zakończenie usługi.

9.4 Testowanie tylko scenariusza prawidłowego

Proces może działać poprawnie przy typowych danych, a zawodzić przy błędzie integracji, duplikacie, cofnięciu zatwierdzenia albo utracie połączenia. Testy negatywne i obsługa wyjątków są szczególnie ważne dla krytycznych przepływów.

9.5 Jednorazowa walidacja bez procesu zmian

Dokumentacja szybko traci aktualność, jeżeli organizacja nie ocenia kolejnych wydań. W SaaS plan utrzymania stanu zwalidowanego powinien powstać przed uruchomieniem, a nie dopiero przy pierwszej dużej aktualizacji.

9.6 Mylenie dostępności z możliwością odtworzenia procesu

Wysoki poziom dostępności usługi nie gwarantuje, że firma odzyska kompletne dane i wznowi regulowany proces w wymaganym czasie. Trzeba odrębnie ocenić kopie, retencję, parametry odtworzenia, eksport danych oraz procedurę pracy awaryjnej.

10. Checklista walidacji systemu SaaS zgodnego z GxP

[ ] Zdefiniowaliśmy zamierzone zastosowanie, granice systemu i właściciela procesu.

[ ] Oceniliśmy wpływ poszczególnych funkcji na pacjenta, produkt i integralność danych.

[ ] Zidentyfikowaliśmy przepisy GxP i rodzaje zapisów elektronicznych mające zastosowanie.

[ ] Udokumentowaliśmy przepływy danych, metadanych, integracji, eksportów i archiwów.

[ ] Przeprowadziliśmy kwalifikację dostawcy oraz ocenę jego systemu jakości i SDLC.

[ ] Zweryfikowaliśmy dostawców infrastruktury, podwykonawców i lokalizacje przetwarzania danych.

[ ] Ustaliliśmy podział odpowiedzialności w umowie i uzgodnieniu jakościowym.

[ ] Przygotowaliśmy testowalne wymagania użytkownika oraz kryteria akceptacji.

[ ] Przeprowadziliśmy udokumentowaną ocenę ryzyka funkcji, danych i interfejsów.

[ ] Zatwierdziliśmy konfigurację, role, workflow, reguły retencji i rozszerzenia.

[ ] Zweryfikowaliśmy migrację danych oraz kompletność interfejsów.

[ ] Przetestowaliśmy krytyczne procesy, wyjątki, uprawnienia, audit trail i podpisy.

[ ] Powiązaliśmy wymagania i ryzyka z dowodami w macierzy śledzenia.

[ ] Zamknęliśmy odchylenia albo formalnie zaakceptowaliśmy ryzyko rezydualne.

[ ] Zatwierdziliśmy raport walidacyjny i gotowość operacyjną przed uruchomieniem.

[ ] Mamy proces oceny release notes, zmian i testów regresji.

[ ] Prowadzimy okresowe przeglądy dostawcy, systemu, dostępów i stanu walidacji.

[ ] Przetestowaliśmy kopie zapasowe, odtworzenie, ciągłość działania i eksport danych.

[ ] Określiliśmy zasady archiwizacji, retencji i kontrolowanego zakończenia usługi.

[ ] Personel został przeszkolony odpowiednio do roli i odpowiedzialności.

11. Jak wybrać partnera do walidacji systemu SaaS

Partner powinien rozumieć zarówno wymagania jakościowe, jak i techniczną architekturę rozwiązania. Sama znajomość szablonów CSV nie wystarczy do oceny integracji, modelu tożsamości, mechanizmów chmurowych, automatycznych wydań i dowodów dostawcy.

Przed rozpoczęciem współpracy warto sprawdzić, czy partner potrafi:

• przełożyć zamierzone zastosowanie na zakres GxP i strategię opartą na ryzyku;
• ocenić dostawcę SaaS, dokumentację produktu i podział odpowiedzialności;
• przygotować URS, analizę ryzyka, plan, testy, macierz śledzenia i raport;
• połączyć wymagania jakościowe z bezpieczeństwem, architekturą i integracją danych;
• zaprojektować proces utrzymania stanu zwalidowanego po częstych aktualizacjach;
• wspierać zespół QA, IT i właścicieli biznesowych bez przejmowania ich decyzji regulacyjnych.

Zakres usług powinien być dostosowany do dojrzałości organizacji. Jedna firma potrzebuje niezależnego przeglądu strategii, inna pełnego prowadzenia dokumentacji i testów, a jeszcze inna stałego wsparcia przy kolejnych wydaniach SaaS.

12. Dlaczego TTMS

Walidacja systemów SaaS w farmacji wymaga współpracy QA, właścicieli procesów, IT, bezpieczeństwa i zespołów wdrożeniowych. TTMS łączy kompetencje w zakresie walidacji systemów skomputeryzowanych z doświadczeniem w rozwoju, integracji, testowaniu i utrzymaniu oprogramowania dla branż regulowanych.

Zakres współpracy może obejmować ocenę wpływu GxP, kwalifikację dostawcy, opracowanie strategii i dokumentacji walidacyjnej, przegląd architektury oraz konfiguracji, przygotowanie testów, wsparcie migracji danych i utrzymanie stanu zwalidowanego. Model pracy można dopasować do nowego wdrożenia, systemu już używanego operacyjnie albo programu obejmującego wiele aplikacji chmurowych.

Praktyczne wsparcie TTMS może obejmować:

• Inwentaryzację systemów, funkcji i przepływów danych objętych GxP.
• Ocenę luk w dokumentacji, kontroli i podziale odpowiedzialności.
• Przygotowanie roadmapy działań według ryzyka i krytyczności procesów.
• Opracowanie oraz wykonanie uzgodnionych działań walidacyjnych.
• Wsparcie przy aktualizacjach, testach regresji i okresowych przeglądach.

Celem współpracy jest zbudowanie dowodów, które odpowiadają rzeczywistemu sposobowi użycia systemu i mogą być utrzymywane po jego uruchomieniu. Ostateczne decyzje dotyczące zakresu GxP, akceptacji ryzyka i dopuszczenia systemu pozostają częścią systemu jakości klienta.

13. Rozmowa o walidacji SaaS

Jeżeli Twoja organizacja planuje wdrożenie systemu chmurowego albo chce uporządkować walidację już używanej aplikacji, warto rozpocząć od oceny zamierzonego zastosowania, dostawcy i cyklu wydawniczego. Pozwala to określić zakres prac przed przygotowaniem dokumentacji i testów.

Skontaktuj się z TTMS, aby omówić strategię walidacji, ocenę dostawcy SaaS lub utrzymanie stanu zwalidowanego w środowisku GxP.

FAQ