Walidacja systemów komputerowych w badaniach klinicznych - zaufanie oparte na dowodach

Wstęp: cyfryzacja wymusza nowe podejście do jakości

Rozwój technologii całkowicie zmienił krajobraz badań klinicznych. Systemy takie jak EDC (Electronic Data Capture) wraz z elektronicznymi kartami obserwacji pacjenta (eCRF), formularzami oceny klinicznej (eCOA), formularzami samooceny pacjenta (ePRO), platformami chmurowymi, aplikacjami mobilnymi czy rozwiązaniami wspieranymi przez sztuczną inteligencję są dziś powszechnie stosowane, a skala ich wykorzystania systematycznie rośnie.

Postępująca cyfryzacja wspomaga realizację badań klinicznych, zwiększając ich jakość i efektywność. Jednocześnie ekosystemy technologiczne stają się coraz bardziej złożone, a źródła danych - rozproszone. W konsekwencji rosną wymagania regulacyjne wobec organizacji prowadzących badania. Dotyczy to także systemów wykorzystujących komponenty AI/ML, gdzie walidacja musi uwzględniać m.in. kontrolę zmian modelu i zarządzanie ryzykiem związanym z zastosowanym algorytmem.

W takim środowisku kluczowe staje się nie tylko pytanie o wiarygodność samych danych, ale również o zaufanie do procesów i systemów, które te dane generują i przetwarzają. Istotnym elementem odpowiedzi na te wyzwania jest walidacja systemów komputerowych - jeden z fundamentów zapewnienia jakości i budowania zaufania w nowoczesnych badaniach klinicznych. Walidacja, choć nie rozwiązuje wszystkich problemów jakościowych, stanowi narzędzie potwierdzające, że system wspierający badanie działa zgodnie z przeznaczeniem i pozostaje pod kontrolą.

Czym jest walidacja systemów komputerowych?

Walidacja systemów komputerowych (CSV - Computer System Validation) to udokumentowany proces, którego celem jest potwierdzenie, że system:

• działa zgodnie z przeznaczeniem (fit for intended use),
• spełnia wymagania użytkownika i regulatorów,
• zapewnia integralność, bezpieczeństwo i dostępność danych.

Walidacja nie ogranicza się tylko do testowania samego oprogramowania. Obejmuje cały cykl życia systemu wspierającego badanie kliniczne - od fazy planowania i definiowania wymagań, poprzez wdrożenie, użytkowanie i zarządzanie zmianami, aż po kontrolowane wycofanie systemu z użycia.

W środowiskach regulowanych, czyli tam, gdzie obowiązują szczególne wymagania prawne lub branżowe dotyczące bezpieczeństwa, jakości czy integralności danych (np. badania kliniczne, produkcja farmaceutyczna), istotne jest rozróżnienie trzech pojęć:

Weryfikacja zazwyczaj poprzedza kwalifikację; kwalifikacja stanowi zaś istotny element procesu walidacji.

Z punktu widzenia organu regulacyjnego, zastosowanie systemu, który nie został odpowiednio zwalidowany i utrzymany w stanie kontrolowanym (validated state), może oznaczać brak możliwości obrony wiarygodności i integralności danych zebranych z jego użyciem w rozumieniu GCP.

Dlaczego walidacja ma znaczenie w badaniu klinicznym?

Walidacja wspiera integralność i jakość danych (ALCOA++)

Zgodnie z zasadami ALCOA++ (zob. też ALCOA++ w praktyce - nowy wymiar jakości danych ), przedstawionych m.in. w ICH E6(R3) GCP oraz wytycznych EMA (omówionych poniżej) - dane powinny być identyfikowalne, dokładne, kompletne oraz możliwe do prześledzenia w całym swoim cyklu życia, tak aby możliwe było ich odtworzenie. W środowisku cyfrowym osiągnięcie tych założeń wymaga odpowiednio zaprojektowanych i zweryfikowanych systemów przetwarzania.

System musi zapewniać m.in. ścieżkę audytu (audit trail), kontrolę dostępu użytkowników, zarządzanie zmianą, właściwe zarządzanie podpisami elektronicznymi (zgodnie z FDA 21 CFR Part 11) oraz utrzymanie spójności danych. Kluczowe jest jednak nie samo istnienie tych mechanizmów, lecz potwierdzenie w ramach procesu walidacji, że działają one poprawnie i zgodnie z wymaganiami w kontekście konkretnego badania.

Walidacja wynika z oczekiwań agencji regulacyjnych

Walidacja nie jest jedynie dobrą praktyką lecz bezpośrednio wynika z oczekiwań regulacyjnych wobec systemów używanych w badaniu klinicznym.

Podstawową ramą regulacyjną są wytyczne ICH E6(R3) GCP, które wymagają, aby systemy komputerowe były właściwe do zamierzonego zastosowania (fit for purpose) - m.in. poprzez zastosowanie walidacji opartej na ryzyku, proporcjonalnej do wpływu na bezpieczeństwo uczestników i wiarygodność danych. Wytyczne wzmacniają zarządzanie ryzykiem, czynniki krytyczne dla jakości (critical to quality) oraz nadzór nad danymi i systemami w całym cyklu życia badania.

W Unii Europejskiej oczekiwania wobec systemów IT i danych elektronicznych w badaniach klinicznych uszczegóławia wytyczna EMA Guideline on Computerised Systems and Electronic Data in Clinical Trials . W USA kluczowe znaczenie mają 21 CFR Part 11 oraz wytyczne FDA dotyczące integralności danych i systemów elektronicznych w badaniach klinicznych (zob. też Technologie godne zaufania - jak zapewnić wiarygodność badań klinicznych w erze cyfryzacji? ).

Przy wdrażaniu tych oczekiwań organizacje często korzystają z uznanych dobrych praktyk branżowych, takich jak GAMP 5. Nie są one przepisem prawa, lecz pomagają dobrać zakres i dokumentację walidacji proporcjonalnie do ryzyka.

Oczekiwania regulacyjne dotyczą dziś nie tylko klasycznych systemów EDC, lecz także aplikacji mobilnych, narzędzi wspierających rekrutację, platform CTMS czy modułów analitycznych. Praktycznie każdy element cyfrowego ekosystemu badania może wymagać oceny pod kątem walidacji - proporcjonalnie do jego wpływu na dane i proces badawczy.

Walidacja wspiera bezpieczeństwo danych i pacjentów

Dane kliniczne należą do najbardziej wrażliwych kategorii informacji - obejmują dane osobowe, szczegółowe informacje zdrowotne, a czasem także dane genetyczne. Systemy wykorzystywane w badaniach muszą zapewniać odpowiedni poziom bezpieczeństwa: kontrolę dostępu, szyfrowanie, ciągłość działania oraz odporność na zagrożenia cybernetyczne.

Standardy takie jak ISO/IEC 27001 dostarczają ram dla systemu zarządzania bezpieczeństwem informacji w organizacji. Certyfikacja ISO 27001 potwierdza ogólne kompetencje organizacji w obszarze bezpieczeństwa, lecz nie zastępuje walidacji konkretnego systemu używanego w badaniu. To walidacja - w powiązaniu z oceną ryzyka - pozwala potwierdzić, że wdrożone mechanizmy rzeczywiście funkcjonują skutecznie w środowisku operacyjnym danego badania (zob. też ISO/IEC 27001:2022 w badaniach klinicznych: Od bezpieczeństwa danych do standardu jakości ).

Walidacja jest narzędziem zarządzania ryzykiem

Walidacja oparta na analizie ryzyka umożliwia proporcjonalne dopasowanie zakresu działań do wpływu systemu na jakość danych, bezpieczeństwo pacjentów i zgodność z wymaganiami regulacyjnymi. Dzięki temu organizacja może skupić wysiłek na elementach o realnym znaczeniu, zamiast generować dokumentację oderwaną od rzeczywistego ryzyka.

Zakres walidacji w badaniach klinicznych

Zakres walidacji wykracza daleko poza potwierdzenie, że system „działa”. Obejmuje on ocenę tego, w jaki sposób dany system wpływa na:

• jakość i integralność danych klinicznych,
• bezpieczeństwo informacji,
• zgodność z wymaganiami regulacyjnymi, w tym specyficznymi wymaganiami sponsora,
• krytyczne procesy badawcze i bezpieczeństwo pacjentów.

W praktyce oznacza to analizę całego okresu użytkowania systemu - od planowania walidacji i definiowania wymagań, przez konfigurację i integracje z innymi narzędziami, użytkowanie w środowisku operacyjnym, aż po kontrolowane wycofanie systemu z użycia. Istotna jest również ocena przepływu danych między systemami: ich kompletności, spójności oraz odporności na błędy i utratę informacji.

W przypadku rozwiązań od dostawców zewnętrznych, zakres oceny obejmuje także model współdzielonej odpowiedzialności z dostawcą, kwalifikację dostawcy (vendor qualification), środowiska (np. test vs produkcja), lokalizację danych oraz mechanizmy ciągłości usługi.

Zakres walidacji obejmuje weryfikację mechanizmów kontroli dostępu, zarządzania uprawnieniami, rejestrowania zmian (audit trail) oraz zabezpieczeń przed nieautoryzowaną ingerencją. Im większy wpływ systemu na dane kliniczne lub decyzje podejmowane w badaniu, tym bardziej szczegółowa i rygorystyczna powinna być jego walidacja.

Cykl życia systemu a proces walidacji

Jednym z częstych błędów w opisie walidacji jest pomieszanie cyklu życia systemu z procesem walidacji. To dwa odrębne, choć ściśle powiązane obszary.

Cykl życia opisuje kolejne etapy istnienia systemu - od planowania po wycofanie. Proces walidacji nie zastępuje tego cyklu: to równoległy zestaw działań i dokumentacji, który towarzyszy systemowi wtedy, gdy jest on wykorzystywany w badaniu klinicznym. Dzięki temu na każdym istotnym etapie życia systemu można wykazać, że pozostaje on pod kontrolą i spełnia wymagania.

Etapy walidacji w cyklu życia systemu

W poprzedniej sekcji rozróżniliśmy cykl życia systemu i proces walidacji. W praktyce opisuje się je często łącznie: jako kolejne etapy, przez które przechodzi system używany w badaniu klinicznym wraz z towarzyszącymi mu działaniami walidacyjnymi. Poniższy przegląd właśnie tak łączy oba obszary - bez utożsamiania ich ze sobą.

Zgodnie z podejściem GAMP 5 system nie jest „zwalidowany raz na zawsze”. Przechodzi przez kolejne etapy, a po każdej istotnej zmianie wymaga ponownej oceny - a w uzasadnionych przypadkach ponownej kwalifikacji lub rewalidacji.

1. Planowanie walidacji i definiowanie wymagań

Proces rozpoczyna się od planu walidacji (VP - Validation Plan), który określa strategię, zakres, role, odpowiedzialności, podejście oparte na ryzyku oraz przewidywane produkty procesu walidacji. Plan walidacji powinien powstać zanim rozpocznie się szczegółowa kwalifikacja systemu.

Na tym etapie powstaje również specyfikacja wymagań użytkownika (URS - User Requirements Specification), która precyzuje:

• jakie funkcje system ma realizować w danym badaniu,
• jakie wymagania regulacyjne i organizacyjne musi spełniać,
• jakie są krytyczne procesy i przepływy danych.

URS stanowi punkt odniesienia dla całego procesu walidacji i bazę dla macierzy śledzenia wymagań (requirements traceability matrix), łączącej wymagania ze specyfikacją, przypadkami testowymi i wynikami.

2. Wybór, rozwój i konfiguracja rozwiązania

Wymagania użytkownika są przekładane na konkretne rozwiązanie technologiczne. W zależności od dokonanego wyboru, dla wybranego rozwiązania przypisuje się odpowiednią kategorię zgodnie z GAMP 5. Podczas wyboru systemu kierujemy sie wieloma zróżnicowanymi kryteriami, np:

• wybór gotowego rozwiązania lub wytworzenie systemu rozwijanego na zamówienie,
• rozwój lub implementacja funkcjonalności (dla systemów dedykowanych),
• konfiguracja, parametryzacja i integracje z innymi narzędziami,
• dostosowanie do specyfiki danego badania klinicznego.

W praktyce kategoria systemu determinuje zakres walidacji:

Na tym etapie - szczególnie dla systemów kategorii 5 - prowadzi się weryfikację w trakcie produkcji (np. przegląd kodu, testy jednostkowe, testy integracyjne). Wykorzystanie sprawdzonych rozwiązań dostawców (kategoria 4) może ograniczyć ryzyko i zakres walidacji, ale nie zwalnia organizacji używającej systemu z odpowiedzialności za jego kwalifikację w kontekście badania.

3. Kwalifikacja systemu

To etap potwierdzający, że system działa zgodnie ze specyfikacją i spełnia wymagania regulacyjne. Kwalifikacja przeprowadzana jest poprzez udokumentowane testy, których zakres wynika z analizy ryzyka. Każde krytyczne wymaganie z URS powinno być możliwe do prześledzenia z odniesieniem do odpowiedniego przypadku testowego i wyniku testów.

Najczęściej wyróżnia się:

• DQ (Design Qualification) - potwierdzenie, że projekt systemu odpowiada wymaganiom użytkownika (szczególnie istotne dla systemów rozwijanych na zamówienie, kategoria 5),
• IQ (Installation Qualification) - potwierdzenie poprawnej instalacji systemu (środowisko, konfiguracja, komponenty),
• OQ (Operational Qualification) - potwierdzenie, że system działa zgodnie ze specyfikacją funkcjonalną w kontrolowanych warunkach,
• PQ (Performance Qualification) - potwierdzenie prawidłowego działania systemu w rzeczywistym środowisku użytkowym, w tym w kontekście konkretnego protokołu badania (często obejmuje testy akceptacyjne użytkownika - UAT).

Nie każdy system wymaga pełnego zestawu DQ/IQ/OQ/PQ - zakres wynika z analizy ryzyka i kategorii GAMP 5. Po pomyślnej kwalifikacji następuje formalne zatwierdzenie do użycia przez upoważnioną osobę, wraz ze szkoleniem użytkowników.

W trakcie kwalifikacji powstaje dokumentacja walidacyjna - plany, protokoły testowe, raporty, rejestr odchyleń i uzasadnienia decyzji. Dokumentowanie nie jest osobnym „etapem” cyklu życia; jest integralną częścią każdego z powyższych kroków i zapewnia pełną ścieżkę audytu.

4. Utrzymanie, monitorowanie i zarządzanie zmianą

Walidacja nie kończy się na wdrożeniu. Równie istotne jest bieżące utrzymanie, monitorowanie, przeglądy okresowe oraz formalne zarządzanie zmianą.

Przegląd okresowy - zgodnie z GAMP 5 - polega na regularnej ocenie, czy system nadal spełnia wymagania i pozostaje “fit for intended use” (np. coroczny przegląd, audyt wewnętrzny, weryfikacja aktualności dokumentacji).

Każda modyfikacja - aktualizacja oprogramowania, zmiana konfiguracji, nowa integracja - może wpływać na zgodność systemu z wymaganiami walidacyjnymi. Dlatego wymaga oceny wpływu, a po przeprowadzonej analizie ryzyka - w uzasadnionych przypadkach także:

• ponownej kwalifikacji - ograniczonego zakresu testów potwierdzających wpływ konkretnej zmiany,
• rewalidacji - szerszego, ponownego procesu walidacji, gdy zmiana ma istotny wpływ na system.

Ten etap obejmuje również zarządzanie incydentami (np. awarie, naruszenia bezpieczeństwa) oraz zapewnienie, że użytkownicy posiadają aktualne szkolenia do wprowadzanych zmian.

Czynności wykonywane w ramach tego etapu mają charakter cykliczny: system pozostaje w stanie kontrolowanym tylko wtedy, gdy zmiany są identyfikowane, oceniane i odpowiednio dokumentowane.

5. Wycofanie systemu z użycia (retirement)

Ostatnim etapem cyklu życia jest kontrolowane wycofanie systemu. Proces ten powinien być zaplanowany i udokumentowany, tak aby zapewnić:

• ciągłość dostępu do danych klinicznych,
• integralność i czytelność danych w okresie retencji,
• migrację danych do archiwum lub innego systemu, jeśli wymagane,
• możliwość odtworzenia danych w przyszłości (np. na potrzeby audytu lub inspekcji),
• bezpieczne wyłączenie systemu bez ryzyka utraty lub naruszenia danych,
• formalne zamknięcie walidacji z podsumowaniem historii systemu.

Dane kliniczne muszą być przechowywane przez wymagany okres - zgodnie z przepisami, zasadami GCP oraz specyficznymi wymaganiami sponsora badania.

Podział odpowiedzialności

Odpowiedzialność za walidację i utrzymanie systemu w stanie kontrolowanym spoczywa na organizacji, która wykorzystuje go w badaniu klinicznym - niezależnie od tego, czy jest sponsorem, CRO czy ośrodkiem badawczym. Ostateczna odpowiedzialność za zgodność badania z wymaganiami regulacyjnymi spoczywa na sponsorze.

W praktyce podział obowiązków walidacyjnych między sponsora, CRO, dostawców i ośrodki powinien być jawnie opisany w umowie jakościowej lub planie jakości badania - np. kto waliduje EDC, kto CTMS, kto lokalne integracje na poziomie ośrodka.

Dostawca systemu może dostarczyć dokumentację walidacyjną, certyfikaty lub raporty z testów, jednak organizacja używająca rozwiązania w badaniu musi samodzielnie ocenić, czy produkt lub usługa spełnia wymagania w kontekście konkretnego protokołu i środowiska operacyjnego. Bezkrytyczne poleganie na deklaracjach dostawcy - zamiast na własnej kwalifikacji - stanowi poważne ryzyko regulacyjne.

Najczęstsze błędy w procesie walidacji

Traktowanie walidacji jako projektu jednorazowego

Walidacja przeprowadzona wyłącznie na etapie wdrożenia, bez mechanizmów utrzymania stanu zwalidowanego, nie chroni systemu przed skutkami późniejszych zmian. Aktualizacje, integracje i modyfikacje konfiguracji wymagają bieżącej kontroli - zgodnie z opisanymi powyżej etapami walidacji w cyklu życia systemu.

Brak przeglądu okresowego

Organizacje często prowadzą kontrolę zmian, lecz pomijają przeglądy okresowe - formalną, cykliczną ocenę, czy system nadal jest w postaci odpowiedniej dla zamierzonego użytkowania. W efekcie stopniowe, drobne i niezamierzone zmiany w konfiguracji i procesie mogą pozostać niewykryte aż do momentu audytu.

Brak podejścia opartego na analizie ryzyka

Jednolite, szablonowe podejście do wszystkich systemów prowadzi do dwóch skrajności: nadmiernej dokumentacji, która obciąża zespoły kosztem realnej kontroli jakości, albo - co bardziej ryzykowne - pomijania testów krytycznych dla integralności danych, bez udokumentowanego uzasadnienia takiej decyzji.

Nieskuteczne zarządzanie zmianą

Wprowadzanie modyfikacji bez formalnej oceny wpływu na zgodność systemu z wymaganiami walidacyjnymi może prowadzić do utraty kontroli nad systemem i jego zgodności z wymaganiami regulacyjnymi.

Nadmierne poleganie na deklaracjach dostawcy

Korzystanie z gotowych, zweryfikowanych rozwiązań jest zgodne z podejściem GAMP 5, lecz deklaracja dostawcy, że system jest „zwalidowany”, nie zastępuje kwalifikacji produktu w kontekście konkretnego badania. Organizacja musi samodzielnie potwierdzić, że rozwiązanie spełnia wymagania w planowanym środowisku użytkowania.

Skutki tych błędów

Efektem opisanych błędów może być utrata kontroli nad systemem wspierającym badanie, co w konsekwencji prowadzi do podważenia wiarygodności danych i - w skrajnych przypadkach - wyników całego badania. Może to skutkować opóźnieniami w procesach rejestracyjnych lub koniecznością powtórzenia części działań badawczych.

Podsumowanie: walidacja jako dowód zaufania

W erze cyfrowej walidacja systemów komputerowych:

• jest narzędziem zarządzania ryzykiem w obszarze systemów wspierających badanie kliniczne,
• wspiera zapewnienie integralności i jakości danych zgodnie z zasadami ALCOA++,
• pomaga utrzymać zgodność z wymaganiami regulacyjnymi,
• buduje audytowalne zaufanie do procesów i systemów generujących i przetwarzających dane kliniczne.

Walidacja nie polega na deklaracji zaufania do systemu - lecz na zbudowaniu zaufania opartego na udokumentowanych dowodach. Organizacja musi być w stanie wykazać, poprzez odpowiednie działania i dokumentację, że system przez cały okres użytkowania w badaniu pozostaje pod kontrolą i spełnia wymagania jakościowe oraz regulacyjne.