Convalida dell’eQMS: un approccio basato sul rischio per i piccoli team Qualità

Avete acquistato, o state per acquistare, un sistema elettronico di gestione della qualità e qualcuno vi ha chiesto il piano di convalida. Il team Qualità è composto da tre persone. L’ultima convalida di un sistema informatico vista da qualcuno qui consisteva in un raccoglitore ad anelli di schermate relative a uno strumento di laboratorio, e nessuno vuole ripetere l’esperienza per un sistema che conterrà tutte le SOP, le CAPA e i registri di formazione di cui disponete. Questo articolo illustra un approccio proporzionato alla convalida dell’eQMS: cosa richiedono davvero l’EU GMP Annex 11 e la norma ISO 13485, in che modo GAMP 5 seconda edizione e i principi della computer software assurance riducono il lavoro, quanto ci si può affidare ai test eseguiti dal fornitore, quali differenze comportano configurazione e personalizzazione, cosa testare in autonomia e come mantenere il sistema convalidato una volta operativo.

Cosa richiedono davvero le norme

Per i fabbricanti di dispositivi medici, la clausola 4.1.6 della ISO 13485:2016 richiede procedure documentate per convalidare l’applicazione dei software informatici utilizzati nel sistema di gestione della qualità. La convalida avviene prima del primo utilizzo e, ove appropriato, dopo modifiche al software o alla sua applicazione. L’approccio deve essere proporzionato al rischio associato all’uso del software e occorre conservare la documentazione delle attività svolte. Il rapporto tecnico ISO/TR 80002-2:2017 fornisce indicazioni specifiche sulla convalida dei software utilizzati nei sistemi di qualità dei dispositivi medici ed è utile per disporre di un quadro pratico di riferimento.

Per i medicinali, l’EU GMP Annex 11 si applica a ogni sistema computerizzato utilizzato nelle attività regolamentate dalle GMP. La sezione 1 richiede la gestione del rischio durante l’intero ciclo di vita del sistema, con un’estensione della convalida basata su una valutazione del rischio giustificata e documentata. La sezione 4 riguarda la convalida: requisiti utente basati sul rischio e sull’impatto GMP, tracciabili durante tutto il ciclo di vita (4.4); valutazione del fornitore (4.5); prove di metodi e scenari di test adeguati (4.7). La sezione 3 riguarda gli accordi formali con i fornitori e la sezione 11 la valutazione periodica. Nel 2025 è stata avviata una consultazione pubblica su una revisione dell’Annex 11; al momento della stesura, il testo del 2011 è ancora la versione pubblicata nella pagina EudraLex della Commissione. Pianificate quindi sulla base di questa versione e monitorate la pubblicazione di quella nuova.

Nessuno dei due testi vi chiede di testare ogni pulsante. Entrambi chiedono di capire cosa fa il sistema nel vostro processo, decidere cosa potrebbe non funzionare e concentrare lì gli sforzi. ICH Q9(R1) esprime lo stesso principio in termini generali: l’impegno, il livello di formalità e la documentazione della gestione del rischio per la qualità devono essere commisurati al livello di rischio.

GAMP 5 seconda edizione e computer software assurance nella pratica

ISPE ha pubblicato la seconda edizione di GAMP 5 nel luglio 2022. Le categorie software sono ancora utili: la maggior parte dei prodotti eQMS è costituita da software configurabile (categoria 4), mentre qualsiasi software scritto appositamente per voi rientra nella categoria personalizzata (categoria 5). Le modifiche più utili riguardano l’impostazione. La seconda edizione sollecita il pensiero critico da parte di persone che conoscono il processo, si aspetta che le aziende regolamentate sfruttino appieno le conoscenze, i test e la documentazione dei fornitori e supporta lo sviluppo iterativo e i servizi cloud.

La computer software assurance (CSA) va nella stessa direzione. È stata illustrata nelle linee guida della US FDA finalizzate nel settembre 2025 e aggiornate nel febbraio 2026 e, sebbene sia un documento statunitense, i suoi quattro passaggi costituiscono una valida struttura per qualsiasi team di piccole dimensioni. Individuate l’uso previsto di ciascuna funzionalità. Stabilite se un guasto di quella funzionalità comporterebbe un rischio elevato per il processo. Scegliete le attività di assurance di conseguenza: test scriptati con passaggi dettagliati e risultati attesi quando il rischio è elevato, e metodi non scriptati, come test esplorativi o basati sulla ricerca degli errori, quando non lo è. Conservate una documentazione sufficiente a dimostrare che il lavoro è stato svolto, senza eccedere.

Nel loro insieme, questi approcci vi consentono di smettere di produrre evidenze che nessuno usa. Non vi autorizzano a smettere di riflettere.

Partite dall’uso previsto

Scrivete una pagina che descriva lo scopo dell’eQMS presso la vostra sede. Quali processi gestisce (controllo dei documenti, formazione, deviazioni, CAPA, audit interni) e quali no (rilascio dei lotti, segnalazione dei reclami alle autorità, per esempio)? Chi lo utilizza e quali registrazioni al suo interno sono registrazioni GMP o ISO 13485? Aggiungete il sistema al vostro inventario dei sistemi computerizzati, che l’Annex 11 4.3 richiede di mantenere aggiornato.

Definite quindi i requisiti utente in base ai vostri processi, con parole vostre. «Una revisione di una SOP diventa effettiva alla relativa data di entrata in vigore e la revisione precedente viene ritirata dall’uso nella stessa data» è un requisito verificabile. «Il sistema deve supportare il controllo dei documenti» non lo è. Per una piccola azienda, in genere bastano alcune decine di requisiti per coprire un eQMS. Classificate ciascuno in base al rischio: un malfunzionamento potrebbe incidere sulla qualità del prodotto, sulla sicurezza del paziente o sull’integrità di una registrazione GMP? La maggior parte sarà a basso rischio. I requisiti che non lo sono, come il passaggio alla data di entrata in vigore, le firme elettroniche, l’audit trail, le autorizzazioni dei ruoli e l’assegnazione della formazione in seguito a una revisione, sono quelli da testare in autonomia.

Valutazione del fornitore e affidamento sui suoi test

L’Annex 11 stabilisce che la competenza e l’affidabilità del fornitore sono fattori fondamentali, che la necessità di un audit deve essere determinata in base al rischio (3.2) e che le informazioni sul sistema di qualità e sugli audit dei fornitori devono essere disponibili agli ispettori su richiesta (3.4). Per la maggior parte delle piccole aziende che acquistano un sistema cloud configurabile, è proporzionata una valutazione a distanza basata su un questionario e sulla documentazione; un audit in loco è opportuno quando le risposte sollevano dubbi.

Richiedete una descrizione del ciclo di sviluppo e del sistema qualità del fornitore, del processo di rilascio e notifica delle modifiche, una sintesi dei test eseguiti sulle funzioni principali, informazioni sul funzionamento dell’audit trail e delle firme elettroniche, sul luogo di hosting dei dati, sulle modalità di verifica dei backup e dei ripristini e sul processo di uscita ed esportazione. La nostra checklist per l’acquisto di un eQMS contiene l’elenco completo delle domande.

Ecco il limite. Le linee guida MHRA sull’integrità dei dati GxP (sezione 6.19) affermano che non è accettabile accettare dati di convalida forniti dal fornitore senza considerarli insieme alla configurazione del sistema e all’uso previsto dall’utente, perché i test del fornitore al di fuori del vostro processo si limitano probabilmente a una verifica funzionale. I test del fornitore possono coprire il prodotto di base: il motore di audit trail registra le modifiche, le firme sono associate alle registrazioni e le autorizzazioni vengono applicate secondo la configurazione. I vostri test riguardano la configurazione all’interno del vostro processo. Riportate questa ripartizione in una breve dichiarazione sull’affidamento, indicando i documenti del fornitore esaminati e le conclusioni raggiunte.

Configurazione e personalizzazione

Configurazione significa impostare il prodotto con gli strumenti che mette a disposizione: flussi di lavoro, percorsi di approvazione, ruoli, schemi di numerazione, campi dei moduli, regole di formazione. Personalizzazione significa scrivere o modificare codice per voi. La differenza ha un impatto considerevole sull’impegno di convalida.

La configurazione viene testata rispetto ai vostri requisiti. Se il percorso di approvazione delle SOP prevede due revisori e un approvatore QA, testate quel percorso, compreso cosa succede quando un revisore respinge il documento. La personalizzazione introduce la categoria 5, con le attività di progettazione, revisione del codice e test che comporta, e deve essere nuovamente testata a ogni nuovo rilascio del fornitore. Per un piccolo team, la strategia di convalida meno costosa consiste nel configurare il sistema in base al processo e modificare il processo quando è in conflitto con il prodotto. Giustificate per iscritto ogni richiesta di personalizzazione.

Tenete sotto controllo anche la configurazione. La sezione 10 dell’Annex 11 richiede che le modifiche alla configurazione seguano una procedura definita. Registrate quindi la configurazione di riferimento al momento dell’avvio e sottoponete le modifiche successive al controllo delle modifiche con una valutazione dell’impatto.

Cosa testare in autonomia

Concentrate i test scriptati sulle funzioni il cui malfunzionamento potrebbe danneggiare le registrazioni o consentire che il documento sbagliato arrivi sul luogo di lavoro. Una tipica ripartizione per un eQMS è la seguente:

Anche i test esplorativi richiedono una registrazione: chi ha testato, quando, quale area, cosa ha provato e cosa ha rilevato. È sufficiente mezza pagina per sessione. La migrazione dei dati richiede una verifica specifica, poiché l’Annex 11 4.8 richiede che i dati migrati non vengano alterati nel valore o nel significato.

Concludete con un rapporto riepilogativo di convalida che elenchi i requisiti, le evidenze per ciascuno (i vostri test, le evidenze del fornitore o entrambi), le deviazioni individuate durante i test e la loro risoluzione (Annex 11 4.2), oltre a una dichiarazione chiara che confermi l’idoneità del sistema all’uso previsto.

Mantenere il sistema convalidato

Un eQMS cloud viene aggiornato più volte all’anno. Redigete una breve procedura per i rilasci: come venite informati, chi legge le note di rilascio, come si valuta l’impatto rispetto ai requisiti e quando una modifica richiede nuovi test. Una modifica alla logica delle firme o delle approvazioni richiede un nuovo test mirato. Una nuova disposizione grafica di un report no.

La sezione 11 dell’Annex 11 prevede una valutazione periodica per confermare che il sistema mantenga uno stato convalidato, considerando funzionalità, deviazioni, incidenti, cronologia degli aggiornamenti, prestazioni, sicurezza e stato della convalida. Per una piccola azienda è sufficiente una revisione annuale di una o due pagine: cosa è cambiato, cosa non ha funzionato, se gli accessi degli utenti sono ancora appropriati, se è stato verificato un ripristino da backup e se il pacchetto di convalida rispecchia ancora l’uso del sistema. Nel corso della revisione, includete anche un esame dell’audit trail su un campione di registrazioni.

Mantenere la proporzionalità

Per un piccolo fabbricante, un pacchetto di convalida dell’eQMS difendibile può stare in un’unica cartella: uso previsto, requisiti valutati in base al rischio, valutazione del fornitore e dichiarazione sull’affidamento, configurazione di riferimento, script di test e registrazioni dei test esplorativi, rapporto riepilogativo e procedura per i rilasci e le revisioni periodiche. Un ispettore potrà esaminarlo in un’ora. Se il vostro è molto più corposo, chiedetevi quali parti siano state effettivamente utilizzate per prendere una decisione.

In sintesi

Convalidate la configurazione realizzata per il processo che svolgete, fate affidamento sul fornitore per il prodotto di base dopo averne verificato le evidenze e mantenete il sistema convalidato attraverso la valutazione dei rilasci e una revisione annuale.

Se state definendo ora l’ambito di questo lavoro, la pagina della piattaforma InnoQualis descrive i moduli di controllo dei documenti, formazione, deviazioni, CAPA e audit che dovrete convalidare, con firme elettroniche progettate per supportare il 21 CFR Part 11 e l’EU GMP Annex 11 e un audit trail a sola aggiunta.