GAMP 5 e V-Model sono il binomio che da quasi vent'anni guida la convalida dei sistemi computerizzati in ambito farmaceutico. Con la Seconda Edizione di GAMP 5 (ISPE, luglio 2022), il modello non è stato abbandonato: è stato reso più flessibile, integrato con il critical thinking, gli approcci Agile e il Computer Software Assurance (CSA) della FDA. In questa guida pratica vediamo come applicare il V-Model a un progetto CSV reale — dal Validation Plan al rilascio — senza produrre documentazione inutile e arrivando in audit con evidenze difendibili.
GAMP 5 e V-Model: cosa sono e perché restano lo standard
GAMP 5 ("A Risk-Based Approach to Compliant GxP Computerized Systems") è la linea guida ISPE di riferimento per la convalida dei sistemi computerizzati GxP. Non è una norma di legge, ma è il framework che ispettori EMA, FDA e PIC/S si aspettano di ritrovare nella pratica aziendale, in coerenza con l'Annex 11 EU GMP e il 21 CFR Part 11.
Il V-Model è la rappresentazione grafica del suo principio cardine: ogni specifica deve avere una verifica corrispondente. Il lato sinistro della "V" scende attraverso le specifiche (requisiti utente, specifiche funzionali, specifiche di configurazione o design); il lato destro risale attraverso le verifiche (IQ, OQ, PQ o i loro equivalenti risk-based). Il vertice è la realizzazione del sistema. Se un requisito non è verificato da alcun test, o un test non è riconducibile ad alcun requisito, la "V" è rotta — ed è esattamente ciò che una Traceability Matrix deve far emergere prima che lo faccia un ispettore.
Le categorie software GAMP 5: calibrare lo sforzo
Il V-Model non si applica con la stessa profondità a tutti i sistemi. GAMP 5 classifica il software in categorie, e la categoria — insieme al risk assessment — determina quanto è "larga" la V: quali specifiche servono davvero e quanta verifica documentata è proporzionata.
| Categoria GAMP 5 | Descrizione | Approccio tipico di convalida |
|---|---|---|
| Categoria 1 — Infrastruttura | Sistemi operativi, database, middleware | Qualifica dell'infrastruttura e controllo versioni |
| Categoria 3 — Prodotti non configurati | Software commerciale usato "as is" | URS, verifica dell'installazione e test sui requisiti d'uso |
| Categoria 4 — Prodotti configurati | LIMS, MES, EDMS, ERP configurati sul processo | V-Model completo focalizzato sulla configurazione e sui workflow critici |
| Categoria 5 — Applicazioni custom | Codice sviluppato su misura (incluse macro e fogli di calcolo complessi) | V-Model completo esteso a design e verifica del codice |
La Seconda Edizione invita a usare le categorie come punto di partenza del ragionamento, non come etichetta burocratica: un sistema di Categoria 3 con impatto diretto sul rilascio del lotto può meritare più attenzione di una Categoria 4 a basso rischio.
Se lavori in QA, IT o Validation e vuoi una dose settimanale di approcci pragmatici alla compliance GxP — dal CSV alla data integrity — iscriviti a The Pragmatic GMP, la newsletter gratuita di GuideGxP: ogni settimana un tema operativo, zero teoria fine a sé stessa.
Il lato sinistro della V: pianificazione e specifiche
Tutto parte dal Validation Plan, che definisce perimetro, ruoli (Business/Process Owner, IT, QA, fornitore) e strategia. Prima ancora, due valutazioni determinano la rotta:
- GxP Assessment: il sistema impatta su qualità del prodotto, sicurezza del paziente o integrità dei dati? Solo se la risposta è sì il sistema entra nel perimetro di convalida.
- Risk Assessment: identifica le funzioni critiche (calcoli, firme elettroniche, audit trail, interfacce) su cui concentrare specifiche dettagliate e test rigorosi, lasciando alle funzioni a basso rischio verifiche più leggere, anche non scripted.
Seguono le specifiche, proporzionate alla categoria del sistema:
- URS (User Requirements Specification): requisiti specifici, misurabili e verificabili. Includi sempre i requisiti di data integrity (audit trail, backup e restore, sincronizzazione dell'ora) e di sicurezza (gestione accessi, password policy): sono i primi che un ispettore cerca in matrice.
- Specifiche funzionali e di configurazione: descrivono come il sistema soddisfa i requisiti. Per i prodotti commerciali configurati, la specifica di configurazione documenta le scelte fatte sul processo; la documentazione del fornitore, se valutata con un supplier assessment, può essere riusata invece di essere riscritta.
Il lato destro della V: verifica con IQ, OQ e PQ
Qui la V risale: ogni livello di verifica risponde a un livello di specifica.
- IQ (Installation Qualification): il sistema è installato come specificato? Versioni, componenti, ambienti separati (sviluppo, test, produzione), protezione fisica e logica dell'infrastruttura.
- OQ (Operational Qualification): le funzioni operano come da specifica? È il momento dei test sulle funzioni critiche, dei test negativi (input errati, interruzioni di rete, tentativi di accesso non autorizzati) e della verifica dell'audit trail.
- PQ (Performance Qualification): il sistema regge il processo reale? Utenti addestrati, dati rappresentativi, flussi end-to-end: è qui che la convalida incontra la vita operativa, spesso nella forma di User Acceptance Test.
GAMP 5 Seconda Edizione legittima esplicitamente strategie di test miste: test scripted per le funzioni ad alto rischio, test unscripted ed esplorativi documentati in forma sintetica per il resto. L'obiettivo è l'evidenza dell'idoneità all'uso, non il faldone.
Traceability Matrix e deviazioni di test
La Traceability Matrix collega requisito → specifica → test case → risultato. È lo strumento che in ispezione dimostra la copertura: senza, non puoi provare di aver testato tutto ciò che hai dichiarato critico. Mantienila viva a ogni change control, non solo alla convalida iniziale.
Quando un test fallisce, la tentazione è correggere e rieseguire in silenzio: errore. Apri una deviazione di test, indaga la causa (difetto del sistema, errore dello script, errore dell'esecutore), correggi e riesegui documentando tutto. Le deviazioni gestite bene sono una prova di controllo del processo, non una debolezza.
Critical thinking, CSA e dove va il V-Model
Il contesto regolatorio si muove nella stessa direzione di GAMP 5. La FDA ha finalizzato nel settembre 2025 la guidance Computer Software Assurance for Production and Quality System Software, che promuove un approccio risk-based alle attività di assurance, con test proporzionati al rischio e meno enfasi sulla documentazione fine a sé stessa. In Europa, la revisione dell'Annex 11 EU GMP — in bozza dal 2025 — rafforza i requisiti su data integrity, accessi e controllo dei fornitori. Il V-Model resta la spina dorsale: cambia la quantità di carta, non la logica specifica-verifica.
Errori comuni e come evitarli
- Testare solo lo happy path: inserisci sempre test negativi e casi limite sulle funzioni critiche.
- URS scritte dopo la configurazione: requisiti "fotocopia" del sistema già installato rendono la convalida un esercizio circolare. Scrivi le URS prima, anche in forma snella.
- Riscrivere ciò che il fornitore ha già testato: con un supplier assessment positivo, sfrutta la documentazione del fornitore e concentra i tuoi test sulla configurazione e sul processo.
- Convalidare e dimenticare: senza periodic review e change control, lo stato validato si erode a ogni aggiornamento.
Raccomandazione GuideGxP
Disegna la tua V su misura del rischio: un Validation Plan di poche pagine ma onesto sul perimetro, URS con i requisiti di data integrity espliciti, test rigorosi dove il rischio è alto e sintetici dove è basso, Traceability Matrix sempre aggiornata e un Validation Report che dichiari chiaramente l'idoneità all'uso. In audit vince chi sa spiegare perché ha testato ciò che ha testato — e perché no il resto.
Per partire da una base già strutturata, la Guida Operativa alla Computer System Validation (CSV) in Ambito GxP di GuideGxP include 175 pagine operative e i template Excel e Word di Validation Plan, URS, Risk Assessment, protocolli IQ/OQ/PQ e Traceability Matrix, già allineati a GAMP 5 Seconda Edizione e al nuovo scenario Annex 11/CSA.
