GAMP 5 Kategoria 4 dla probabilistycznych silników decyzyjnych — dlaczego "konfigurowalna" to właściwa klasyfikacja

1. Streszczenie wykonawcze

GAMP 5 — Good Automated Manufacturing Practice wersja 5, opublikowany przez ISPE — jest de facto branżowym standardem walidacji systemów komputerowych (CSV) w regulowanych środowiskach farmaceutycznych. Jego ramy kategoryzacji (od 1 do 5) wyznaczają głębokość i zakres działań walidacyjnych. Probabilistyczne silniki decyzyjne dla operacji farmaceutycznych to nowa klasa oprogramowania, która niezręcznie mieści się w istniejących kategoriach: nie są to ani proste narzędzia parametryzowane (Cat 3), ani w pełni dedykowane opracowania (Cat 5).

Niniejszy dokument argumentuje, że Kategoria 4 — oprogramowanie konfigurowalne — jest właściwą klasyfikacją dla silników takich jak GRIP firmy Synlogica, gdzie deterministyczna warstwa reguł (SOP, bramki GxP) oraz probabilistyczne parametry modelu (współczynniki Arrhenius, priory Bayesian, rozkłady Monte Carlo) są konfigurowalne na poziomie tenanta, natomiast bazowy silnik — matematyka probabilistyczna, graf wykonania reguł, format pakietu decyzyjnego — jest kwalifikowany raz przez dostawcę i używany bez zmian przez każdego klienta.

Klasyfikacja ma znaczenie, ponieważ wyznacza nakład pracy walidacyjnej. Klasyfikacja Cat 5 (niestandardowa) wymagałaby od klienta walidacji wewnętrznych elementów silnika względem jego specyficznych wymagań (zazwyczaj 200–400 osobodni nakładu). Prawidłowa klasyfikacja Cat 4 ogranicza walidację po stronie klienta do warstwy konfiguracji (zazwyczaj 40–80 osobodni) i akceptuje kwalifikację samego silnika przeprowadzoną przez dostawcę.

2. Kategorie GAMP 5 — przypomnienie w 90 sekund

GAMP 5 wydanie drugie (2022) opisuje pięć kategorii systemów skomputeryzowanych, z których każda ma zalecane podejście walidacyjne:

(Kategoria 2 została usunięta w wydaniu drugim; numeracja 1, 3, 4, 5 jest zachowana dla zgodności wstecznej.) Ramy te są oparte na ryzyku: nakład walidacyjny powinien odpowiadać wpływowi systemu na GxP, jego złożoności i nowatorskości.

Kategoria 4 zasługuje na podkreślenie, ponieważ jest najważniejsza operacyjnie: obejmuje systemy, których zespoły farmaceutyczne faktycznie używają na co dzień (ERP, LIMS, MES), a obecnie coraz częściej także systemy decyzyjne, które działają nad nimi.

3. Wyzwanie klasyfikacyjne dla silników probabilistycznych

Probabilistyczne silniki decyzyjne zaburzają standardową rozmowę o Cat 3 vs Cat 4 vs Cat 5 na trzy sposoby:

3.1 Silnik jest taki sam; parametry nie są

Każdy klient Synlogica Terminus używa tej samej wersji silnika GRIP — sampler Monte Carlo, logika aktualizacji Bayesian, integrator Arrhenius są bit-identyczne we wszystkich tenantach. Tym, co się różni, jest konfiguracja: parametry Arrhenius dla portfela API w danym tenancie, priory Bayesian dla elastyczności dostawcy w danym tenancie, rozkłady wejściowe Monte Carlo dla ryzyka tras w danym tenancie. To podręcznikowy wzorzec Cat 4.

3.2 Wyniki probabilistyczne nie są bit-identyczne między uruchomieniami (z założenia)

Symulacja Monte Carlo zainicjowana losowym stanem początkowym daje statystycznie równoważne, ale nie bit-identyczne wyniki w kolejnych uruchomieniach. Inspektorzy przeszkoleni na oprogramowaniu deterministycznym czasami sygnalizują to jako brak odtwarzalności, co byłoby problemem z punktu widzenia Part 11. Prawidłowa odpowiedź: silnik inicjuje symulację deterministycznie dla każdej decyzji (używając np. SHA-256 śladu pochodzenia danych wejściowych), więc każda decyzja może zostać odtworzona bit po bicie, mimo że dwa niepowiązane uruchomienia różniłyby się.

3.3 Warstwa polityki decyzyjnej to konfiguracja tolerancji ryzyka, a nie kod niestandardowy

„Rekomenduj zwolnienie, jeśli prawdopodobieństwo przekroczenia progu jest poniżej 5% ORAZ partia jest niejałowa ORAZ klasa produktu to klasa B” wygląda jak logika niestandardowa, ale jest konfiguracją ogólnego DSL polityk. Dopóki sam DSL jest kwalifikowany, a konfiguracja jest walidowana jak każda konfiguracja Cat 4, nie jest to Cat 5.

Ryzyko błędnej klasyfikacji jest symetryczne: niedoszacowanie (np. Cat 3) i inspektor poprosi o brakujące dowody walidacyjne; przeszacowanie (Cat 5) i zespół spędzi osobolata, walidując to, co dostawca już zakwalifikował.

4. Dlaczego Kategoria 4 (konfigurowalna) jest właściwym wyborem

Dopasowanie do Kategorii 4 opiera się na trzech obserwacjach:

4.1 Produkt istnieje niezależnie od jakiegokolwiek pojedynczego klienta

GRIP jest opracowywany i kwalifikowany przez Synlogica jako produkt. Każdy klient otrzymuje ten sam plik binarny silnika, te same implementacje algorytmów, ten sam format pakietu decyzyjnego. To definicyjny test rozróżnienia między Kategorią 4 a Kategorią 5: system Cat 5 jest budowany dla jednego klienta; produkt Cat 4 jest budowany raz i używany przez wielu.

4.2 Powierzchnia konfiguracji jest ustrukturyzowana, a nie dowolna

Klienci konfigurują GRIP poprzez zdefiniowaną powierzchnię: zestawy reguł (zadeklarowane w ustrukturyzowanym DSL), parametry modelu (typowane dane wejściowe z regułami walidacji), konfiguracje polityk (wybierane z udokumentowanego zestawu szablonów polityk z parametrami tolerancji ryzyka), punkty końcowe integracji danych (mapowane przez warstwę konektorów). Nie piszą kodu do GRIP. Nie modyfikują wewnętrznych elementów silnika.

4.3 Pakiety kwalifikacyjne dostawcy istnieją i są audytowalne

Dostawca (Synlogica) utrzymuje dokumentację kwalifikacyjną GAMP 5 Kategoria 4 dla GRIP — kwalifikację projektu, zapisy przeglądu kodu, raporty z testów jednostkowych i integracyjnych, protokoły kwalifikacyjne, informacje o wydaniu dla każdej wersji. Są one udostępniane klientom w ramach DPA jako część pakietu zaufania. Nakład walidacyjny klienta bazuje na tych dowodach, zamiast je powielać.

To połączenie — oprogramowanie klasy produktowej, ustrukturyzowana powierzchnia konfiguracji, dowody kwalifikacji dostawcy — jest dokładnie tym wzorcem, dla którego zdefiniowano Kategorię 4.

5. Co się zmienia względem Kategorii 5 (niestandardowej)

Praktyczne różnice między poziomami nakładu Cat 4 i Cat 5 są znaczące:

Podejście Cat 4 nie jest „mniej rygorystyczne”; jest to „rygor podzielony między dostawcę a klienta”. Rygor klienta skupia się na walidacji konfiguracji (której dostawca nie może wykonać za niego), a rygor dostawcy skupia się na kwalifikacji silnika (której powielanie dla każdego klienta byłoby marnotrawstwem).

6. Produkty walidacyjne, których klient powinien oczekiwać

Od dostawcy (jako część pakietu zaufania):

• Dossier audytu dostawcy — w tym status ISO 9001 / ISO 27001, dokumentacja cyklu życia rozwoju, zapisy przeglądu kodu i kontroli zmian.
• Protokół i raport kwalifikacyjny GRIP — kwalifikacja projektu, pokrycie testami jednostkowymi, pokrycie testami integracyjnymi, kwalifikacja działania.
• Informacje o wydaniu dla każdej wersji — co zmieniło się w silniku, co zmieniło się w DSL reguł, co zmieniło się w DSL polityk, co zmieniło się w formacie pakietu decyzyjnego. Wersjonowane według semver.
• Macierz śledzenia — wymaganie → projekt → kod → test, utrzymywana dla każdego wydania.
• Ocena ryzyka dla wyników probabilistycznych — obejmująca mechanizm inicjowanego determinizmu oraz gwarancje zbieżności dla aktualizacji Monte Carlo / Bayesian.

Od klienta (przygotowane przy wsparciu dostawcy):

• Specyfikacja wymagań użytkownika (URS) — ograniczona do zamierzonego użycia: jakie decyzje biznesowe będą podejmowane przy użyciu Terminus.
• Funkcjonalna ocena ryzyka — wpływ na GxP dla każdej klasy decyzji, kontrole dla każdego poziomu wpływu.
• Specyfikacja konfiguracji — konkretne reguły, parametry i polityki klienta wraz z uzasadnieniem.
• Skrypty IQ / OQ — skoncentrowane na warstwie konfiguracji i integracji z istniejącymi systemami (eQMS, ERP, TMS).
• PQ (kwalifikacja działania) — scenariusze end-to-end potwierdzające, że skonfigurowany system wspiera zamierzone decyzje biznesowe.
• Raport podsumowujący walidację — zamykający cykl życia walidacji i autoryzujący użycie produkcyjne.

7. Walidacja logiki probabilistycznej — konkretne wyzwania

7.1 „Te same dane wejściowe, ten sam wynik” — test odtwarzalności

Systemy probabilistyczne można walidować pod kątem odtwarzalności bit po bicie, inicjując sampler losowy deterministycznie. Test: pakiet decyzyjny odtworzony względem tej samej wersji silnika z tymi samymi danymi wejściowymi musi dać ten sam wynik. GRIP osiąga to poprzez inicjowanie wyprowadzone z SHA-256. Dowodem walidacyjnym jest protokół odtwarzalności, który odtwarza N decyzji produkcyjnych i potwierdza identyczne wyniki.

7.2 „Co się dzieje, gdy dane wejściowe się degradują?” — test odporności

Silniki probabilistyczne wymagają jawnych testów tego, co dzieje się, gdy dane wejściowe są brakujące, zaszumione lub poza oczekiwanymi zakresami. Oczekiwanym zachowaniem jest łagodna odmowa rekomendacji, a nie rekomendacja oparta na założonych danych wejściowych. Skrypty OQ GAMP 5 dla systemów probabilistycznych powinny obejmować testy negatywne pokrywające niedostępność danych, anomalię czujnika oraz dryf parametrów.

7.3 „Skąd wiemy, że model jest prawidłowy?” — test kalibracji

Odróżniany od walidacji w sensie regulacyjnym. Kalibracja dotyczy tego, czy predykcje modelu odpowiadają rzeczywistości (np. czy przesyłki sklasyfikowane jako mające 95% prawdopodobieństwa terminowego przybycia faktycznie przybywają na czas w 95% przypadków). Jest to bieżąca kwestia monitorowania działania, odrębna od walidacji. Pytanie walidacyjne brzmi: „czy system poprawnie implementuje zamierzony model”; pytanie kalibracyjne brzmi: „czy sam zamierzony model jest dokładny dla naszych operacji”.

7.4 „Co się zmienia, gdy aktualizuje się wersja silnika?” — test wpływu

Gdy dostawca wydaje nową wersję silnika, zespół walidacyjny klienta potrzebuje oceny wpływu: czy zmieniło się zachowanie algorytmiczne, czy zmieniła się semantyka DSL reguł, czy zmienił się format pakietu decyzyjnego? Wersjonowanie GRIP stosuje semver: wersje patch są bit-równoważne dla prawidłowych danych wejściowych, wersje minor rozszerzają bez łamania, wersje major mogą zmieniać semantykę i wywoływać rewalidację dotkniętych konfiguracji po stronie klienta.

8. Bieżące kontrole i zarządzanie zmianą

Systemy Cat 4 wymagają bieżącej dyscypliny walidacyjnej:

• Kontrola zmian — każda zmiana konfiguracji (nowa reguła, zmodyfikowany parametr, zaktualizowana polityka) przechodzi przez kontrolę zmian z oceną ryzyka, planem testów, zatwierdzeniem i weryfikacją po zmianie.
• Przegląd okresowy — zazwyczaj roczny; potwierdza, że konfiguracja jest nadal odpowiednia do celu, lista użytkowników jest aktualna, integracje pozostają ważne.
• Zarządzanie incydentami — każda anomalia pakietu decyzyjnego jest rejestrowana, badana i analizowana pod kątem przyczyny źródłowej. Anomalie wynikające z konfiguracji są po stronie klienta; anomalie wynikające z silnika są po stronie dostawcy i wywołują eskalację wsparcia.
• Powiadomienie o zmianie od dostawcy — dostawca powiadamia o każdym wydaniu. Zespół walidacyjny klienta ocenia wpływ i decyduje o zakresie rewalidacji.
• Ciągłe monitorowanie działania — metryki kalibracji (przewidywane vs rzeczywiste) są raportowane okresowo; istotny dryf wywołuje ponowne dostrojenie konfiguracji.

Największym błędem w bieżącej walidacji Cat 4 jest traktowanie jej jako jednorazowego wydarzenia. System jest kwalifikowany przy uruchomieniu; bieżące kontrole utrzymują go w stanie kwalifikacji przez kolejne zmiany. Dojrzałość walidacyjna jest mierzona dyscypliną tych bieżących kontroli, a nie głębokością początkowej kwalifikacji.

9. Wnioski

1. GAMP 5 Kategoria 4 (konfigurowalna) jest właściwą klasyfikacją dla probabilistycznych silników decyzyjnych takich jak GRIP, gdzie silnik jest kwalifikowany przez dostawcę, a klienci konfigurują reguły, parametry i polityki.
2. Przeszacowanie do Cat 5 (niestandardowej) dodaje 3–5× nakładu walidacyjnego bez dodawania wartości w zakresie zgodności dla oprogramowania klasy produktowej z ustrukturyzowanymi powierzchniami konfiguracji.
3. Dokumentacja kwalifikacyjna po stronie dostawcy (audyt dostawcy, protokół kwalifikacyjny, informacje o wydaniu, śledzenie) musi być dostępna w ramach DPA i traktowana jako dowód przez walidatorów po stronie klienta.
4. Logika probabilistyczna wymaga specyficznych wzorców walidacji: inicjowanego determinizmu dla odtwarzalności, testów negatywnych dla degradacji danych wejściowych, wersjonowanych wydań silnika z udokumentowaną semantyką semver.
5. Kalibracja (dokładność modelu w produkcji) jest odrębna od walidacji (poprawnej implementacji); obie mają znaczenie, ale wymagają różnych kontroli.
6. Bieżące kontrole — kontrola zmian, przegląd okresowy, zarządzanie incydentami, powiadomienie o zmianie od dostawcy — to miejsce, w którym mierzy się dojrzałość Cat 4.