GAMP 5 Categoria 4 per i motori decisionali probabilistici — perché "configurabile" è la classificazione corretta

1. Sintesi esecutiva

GAMP 5 — Good Automated Manufacturing Practice versione 5, pubblicato da ISPE — è lo standard di settore di fatto per la convalida dei sistemi computerizzati (CSV) negli ambienti farmaceutici regolamentati. Il suo schema di categorie (da 1 a 5) determina la profondità e l'ampiezza dell'attività di convalida. I motori decisionali probabilistici per le operazioni farmaceutiche sono una nuova classe di software che si colloca in modo scomodo nelle categorie esistenti: non sono né semplici strumenti parametrizzati (Cat 3) né sviluppi interamente su misura (Cat 5).

Questo documento sostiene che la Categoria 4 — software configurabile — è la classificazione corretta per motori come GRIP di Synlogica, dove il livello deterministico delle regole (SOP, gate GxP) e i parametri del modello probabilistico (coefficienti Arrhenius, prior Bayesian, distribuzioni Monte Carlo) sono configurabili per tenant, ma il motore sottostante — la matematica probabilistica, il grafo di esecuzione delle regole, il formato del decision-package — è qualificato una sola volta dal fornitore e utilizzato senza modifiche da ogni cliente.

La classificazione conta perché definisce l'ambito dello sforzo di convalida. Una classificazione Cat 5 (custom) richiederebbe al cliente di convalidare gli interni del motore rispetto ai propri requisiti specifici (tipicamente 200–400 giorni-persona di sforzo). Una corretta classificazione Cat 4 confina la convalida lato cliente al livello di configurazione (tipicamente 40–80 giorni-persona) e accetta la qualifica del motore eseguita dal fornitore.

2. Le categorie GAMP 5 — un ripasso in 90 secondi

GAMP 5 Second Edition (2022) descrive cinque categorie di sistemi computerizzati, ciascuna con un approccio di convalida raccomandato:

(La Categoria 2 è stata rimossa nella Second Edition; la numerazione 1, 3, 4, 5 è mantenuta per riferimento retrospettivo.) Lo schema è basato sul rischio: lo sforzo di convalida dovrebbe essere proporzionato all'impatto GxP, alla complessità e alla novità del sistema.

La Categoria 4 merita enfasi perché è la più rilevante dal punto di vista operativo: copre i sistemi che i team farmaceutici usano effettivamente ogni giorno (ERP, LIMS, MES) e, sempre più, i sistemi decisionali che vi si appoggiano sopra.

3. La sfida di classificazione per i motori probabilistici

I motori decisionali probabilistici complicano la consueta discussione Cat 3 vs Cat 4 vs Cat 5 in tre modi:

3.1 Il motore è lo stesso; i parametri no

Ogni cliente di Synlogica Terminus utilizza la stessa versione del motore GRIP — il sampler Monte Carlo, la logica di aggiornamento Bayesian, l'integratore Arrhenius sono identici a livello di bit tra i tenant. Ciò che differisce è la configurazione: parametri Arrhenius per tenant per il portafoglio di API, prior Bayesian per tenant per l'elasticità dei fornitori, distribuzioni di input Monte Carlo per tenant per il rischio di lane. Questo è il pattern Cat 4 da manuale.

3.2 Gli output probabilistici non sono identici a livello di bit tra le esecuzioni (per progetto)

Una simulazione Monte Carlo inizializzata con uno stato iniziale casuale produce output statisticamente equivalenti ma non identici a livello di bit da un'esecuzione all'altra. Gli ispettori formati sul software deterministico talvolta segnalano questo come mancanza di riproducibilità, il che costituirebbe una preoccupazione Part 11. La risposta corretta: il motore inizializza la simulazione in modo deterministico per ciascuna decisione (usando ad esempio SHA-256 del lineage dei dati di input), così qualsiasi decisione può essere ripetuta bit per bit anche se due esecuzioni non correlate differirebbero.

3.3 Il livello della decision policy è configurazione della tolleranza al rischio, non codice custom

"Raccomanda il rilascio se la probabilità di superare la soglia è inferiore al 5% AND il lotto è non sterile AND la classe di prodotto è classe B" sembra logica custom ma è la configurazione di un DSL di policy generico. Finché il DSL stesso è qualificato e la configurazione è convalidata come qualsiasi configurazione Cat 4, questo non è Cat 5.

Il rischio di una classificazione errata è simmetrico: sotto-classificare (ad esempio Cat 3) e l'ispettore chiederà le evidenze di convalida mancanti; sovra-classificare (Cat 5) e il team spenderà anni-persona a convalidare ciò che il fornitore ha già qualificato.

4. Perché la Categoria 4 (configurabile) è la scelta corretta

L'adeguatezza della Categoria 4 si fonda su tre osservazioni:

4.1 Il prodotto esiste indipendentemente da qualsiasi singolo cliente

GRIP è sviluppato e qualificato da Synlogica come prodotto. Ogni cliente riceve lo stesso binario del motore, le stesse implementazioni degli algoritmi, lo stesso formato del decision-package. Questo è il test definitorio per la Categoria 4 rispetto alla Categoria 5: un sistema Cat 5 è costruito per un singolo cliente; un prodotto Cat 4 è costruito una volta e utilizzato da molti.

4.2 La superficie di configurazione è strutturata, non arbitraria

I clienti configurano GRIP attraverso una superficie definita: set di regole (dichiarate in un DSL strutturato), parametri del modello (input tipizzati con regole di validazione), configurazioni di policy (selezionate da un insieme documentato di template di policy con parametri di tolleranza al rischio), endpoint di integrazione dati (mappati attraverso un livello di connettori). Non scrivono codice all'interno di GRIP. Non modificano gli interni del motore.

4.3 I pacchetti di qualifica del fornitore esistono e sono verificabili

Il fornitore (Synlogica) mantiene la documentazione di qualifica GAMP 5 Categoria 4 per GRIP — design qualification, registrazioni delle revisioni del codice, report dei test unitari e di integrazione, protocolli di qualifica, release notes per versione. Questi sono messi a disposizione dei clienti in base al DPA come parte del trust pack. Lo sforzo di convalida del cliente si basa su queste evidenze anziché duplicarle.

La combinazione — software di classe prodotto, superficie di configurazione strutturata, evidenze di qualifica del fornitore — è esattamente il pattern per cui la Categoria 4 è stata definita.

5. Cosa cambia rispetto alla Categoria 5 (custom)

Le differenze pratiche tra i livelli di sforzo Cat 4 e Cat 5 sono sostanziali:

L'approccio Cat 4 non è "meno rigoroso"; è "rigore ripartito tra fornitore e cliente". Il rigore del cliente è concentrato sulla convalida della configurazione (che il fornitore non può fare al posto suo), e il rigore del fornitore è concentrato sulla qualifica del motore (che sarebbe dispendioso duplicare per ogni cliente).

6. I deliverable di convalida che un cliente dovrebbe aspettarsi

Dal fornitore (come parte del trust pack):

• Dossier di audit del fornitore — incluso lo stato ISO 9001 / ISO 27001, la documentazione del ciclo di vita di sviluppo, le registrazioni di revisione del codice e di change control.
• Protocollo e report di qualifica di GRIP — design qualification, copertura dei test unitari, copertura dei test di integrazione, performance qualification.
• Release notes per versione — cosa è cambiato nel motore, cosa è cambiato nel DSL delle regole, cosa è cambiato nel DSL delle policy, cosa è cambiato nel formato del decision-package. Versionate con semver.
• Matrice di tracciabilità — requisito → design → codice → test, mantenuta per ogni release.
• Valutazione del rischio per gli output probabilistici — che copre il meccanismo di determinismo con seeding e le garanzie di convergenza per gli aggiornamenti Monte Carlo / Bayesian.

Dal cliente (assemblati con il supporto del fornitore):

• User Requirements Specification (URS) — definita in funzione dell'uso previsto: quali decisioni di business Terminus sarà usato per prendere.
• Valutazione del rischio funzionale — impatto GxP per classe di decisione, controlli per livello di impatto.
• Specifica di configurazione — le regole, i parametri e le policy specifici del cliente, con relativa motivazione.
• Script IQ / OQ — focalizzati sul livello di configurazione e sull'integrazione con i sistemi esistenti (eQMS, ERP, TMS).
• PQ (Performance Qualification) — scenari end-to-end che confermano che il sistema configurato supporta le decisioni di business previste.
• Report di sintesi della convalida — che chiude il ciclo di vita della convalida e autorizza l'uso in produzione.

7. Convalidare la logica probabilistica — le sfide specifiche

7.1 "Stesso input, stesso output" — il test di riproducibilità

I sistemi probabilistici possono essere convalidati per la riproducibilità bit per bit inizializzando in modo deterministico il sampler casuale. Il test: un decision package ripetuto rispetto alla stessa versione del motore con gli stessi input deve produrre lo stesso output. GRIP ottiene questo attraverso un seeding derivato da SHA-256. L'evidenza di convalida è un protocollo di riproducibilità che ripete N decisioni di produzione e conferma output identici.

7.2 "Cosa succede quando gli input degradano?" — il test di robustezza

I motori probabilistici necessitano di test espliciti su cosa accade quando i dati di input sono mancanti, rumorosi o fuori dagli intervalli attesi. Il comportamento atteso è un rifiuto controllato a raccomandare anziché una raccomandazione basata su input presunti. Gli script OQ GAMP 5 per i sistemi probabilistici dovrebbero includere test negativi che coprono l'indisponibilità dei dati, l'anomalia dei sensori e la deriva dei parametri.

7.3 "Come sappiamo che il modello è corretto?" — il test di calibrazione

Da distinguere dalla convalida nel senso regolatorio. La calibrazione riguarda se le previsioni del modello corrispondono alla realtà (ad esempio, se le spedizioni classificate come probabili al 95% di arrivare in orario arrivano effettivamente in orario il 95% delle volte). Questa è una preoccupazione di monitoraggio continuo delle prestazioni, separata dalla convalida. La domanda della convalida è "il sistema implementa correttamente il modello previsto"; la domanda della calibrazione è "il modello previsto è esso stesso accurato per le nostre operazioni".

7.4 "Cosa cambia quando si aggiorna la versione del motore?" — il test di impatto

Quando il fornitore rilascia una nuova versione del motore, il team di convalida del cliente ha bisogno di una valutazione di impatto: il comportamento algoritmico è cambiato, la semantica del DSL delle regole è cambiata, il formato del decision-package è cambiato? Il versioning di GRIP segue semver: le versioni patch sono equivalenti a livello di bit per input validi, le versioni minor estendono senza rompere, le versioni major possono cambiare la semantica e attivare la riconvalida da parte del cliente delle configurazioni interessate.

8. Controlli continuativi e gestione delle modifiche

I sistemi Cat 4 richiedono una disciplina di convalida continuativa:

• Change control — ogni modifica di configurazione (nuova regola, parametro modificato, policy aggiornata) passa attraverso il change control con valutazione del rischio, piano di test, approvazione e verifica post-modifica.
• Revisione periodica — tipicamente annuale; conferma che la configurazione è ancora idonea allo scopo, che l'elenco degli utenti è aggiornato, che le integrazioni rimangono valide.
• Gestione degli incidenti — qualsiasi anomalia del decision-package viene registrata, indagata e analizzata fino alla causa radice. Le anomalie riconducibili alla configurazione sono lato cliente; le anomalie riconducibili al motore sono lato fornitore e attivano un'escalation di supporto.
• Notifica delle modifiche del fornitore — il fornitore notifica ogni release. Il team di convalida del cliente valuta l'impatto e decide l'ambito della riconvalida.
• Monitoraggio continuo delle prestazioni — le metriche di calibrazione (previsto vs effettivo) sono riportate periodicamente; una deriva significativa attiva una ri-taratura della configurazione.

L'errore più grande nella convalida continuativa Cat 4 è trattarla come un evento una tantum. Il sistema è qualificato al go-live; i controlli continuativi lo mantengono qualificato nel corso delle modifiche. La maturità della convalida si misura dalla disciplina di tali controlli continuativi, non dalla profondità della qualifica iniziale.

9. Punti chiave

1. GAMP 5 Categoria 4 (configurabile) è la classificazione corretta per i motori decisionali probabilistici come GRIP, dove il motore è qualificato dal fornitore e i clienti configurano regole, parametri e policy.
2. La sovra-classificazione Cat 5 (custom) aggiunge 3–5× di sforzo di convalida senza aggiungere valore di conformità per software di classe prodotto con superfici di configurazione strutturate.
3. La documentazione di qualifica lato fornitore (audit del fornitore, protocollo di qualifica, release notes, tracciabilità) deve essere disponibile in base al DPA e considerata affidabile come evidenza dai validatori lato cliente.
4. La logica probabilistica richiede pattern di convalida specifici: determinismo con seeding per la riproducibilità, test negativi per il degrado degli input, release del motore con versioning controllato e semantica semver documentata.
5. La calibrazione (accuratezza del modello in produzione) è separata dalla convalida (implementazione corretta); entrambe contano ma richiedono controlli diversi.
6. I controlli continuativi — change control, revisione periodica, gestione degli incidenti, notifica delle modifiche del fornitore — sono il luogo in cui si misura la maturità Cat 4.