La norma ISO 13485 richiede che l’organizzazione documenti le procedure per la validazione dell’applicazione di software di computer utilizzati nel sistema di gestione per la qualità. Queste applicazioni software, specifica la norma, devono essere validate prima dell’utilizzo iniziale e, come appropriato, dopo le modifiche a questo software o alla sua applicazione.
Validare un software significa definire l’insieme di tutte le attività che consentono di stabilire con un buon margine di certezza che il software è appropriato per l’uso previsto e che è affidabile. Le attività scelte, qualsiasi esse siano, devono garantire che il software soddisfi i requisiti e il suo scopo inteso.
La norma ISO 13485 non specifica come validare il software, ma si limita a indicare che l’approccio specifico da adottare e le attività associate alla validazione del software e alla rivalidazione debbano essere proporzionate al rischio associato all’utilizzo del software.
Come soddisfare questo requisito?
In aiuto dei fabbricanti sopraggiunge la norma ISO/TR 80002-2 che si applica a qualsiasi software utilizzato per la progettazione, il collaudo, l’accettazione dei componenti, la produzione, l’etichettatura, l’imballaggio, la distribuzione e la gestione dei reclami dei dispositivi o per automatizzare qualsiasi altro aspetto del sistema di qualità dei dispositivi medici descritto nella norma ISO 13485.
Quali software del sistema qualità dei dispositivi medici è necessario validare?
Per rispondere a questa domanda, la norma ISO/TR 80002-2 suggerisce di porsi le seguenti domande.
- Il fallimento o i difetti latenti del software potrebbero influire sulla sicurezza o sulla qualità dei dispositivi medici?
- Il software automatizza o esegue un’attività richiesta dai requisiti normativi (in particolare, dai requisiti dei sistemi di gestione della qualità dei dispositivi medici)? Alcuni esempi possono essere l’acquisizione di firme e/o registrazioni elettroniche, il mantenimento della tracciabilità del prodotto, l’esecuzione e l’acquisizione di risultati di test, il mantenimento di registri di dati quali CAPA, non conformità, reclami, calibrazioni, ecc.
Una risposta affermativa anche a una sola di queste domande dà un’unica risposta: il software che deve essere convalidato secondo la ISO 13485 e rientra nell’ambito di applicazione della ISO/TR 80002-2.
L’approccio basato sul rischio: il “critical thinking”
È necessario premettere che per validare adeguatamente un software è indispensabile valutarne i rischi, le principali parti interessate, le loro esigenze e l’ambiente in cui verrà utilizzato per identificare l’insieme più significativo di attività su cui concentrarsi durante la convalida. Le soluzioni di convalida, infatti, possono variare notevolmente da un software all’altro ma anche all’interno di uno stesso software tra task differenti che esso gestisce. Durante l’intero ciclo di vita del software per i sistemi di qualità dei dispositivi medici è necessario effettuare controlli adeguati a garantire che il software funzioni come previsto. L’incorporazione del “critical thinking” e l’applicazione di attività selezionate di rafforzamento della fiducia (confidence-building) portano a stabilire e mantenere uno stato convalidato del software.
Le fasi della validazione del software
La convalida del software è suddivisa dalla norma ISO/TR 80002-2 in tre macro-fasi.
- Sviluppo, che include le sottofasi: definizione, implementazione, test e distribuzione;
- Manutenzione;
- Dismissione.
Definizione
Questa fase prevede che venga stabilito l’ambito di applicazione del software, il suo uso previsto e i requisiti d’uso del software all’interno del sistema di gestione per la qualità. È in questa fase che viene condotta anche un’analisi dei rischi a livello di processo, ossia dei processi in cui viene utilizzato lo strumento software del SGQ. Da questi presupposti viene messo a punto il piano di convalida.
Implementazione
Questa fase assume due flussi diversi a seconda che il software sia stato creato su misura per l’organizzazione oppure sia un “software off-the-shelf”.
Implementazione di un software su misura
In questo caso l’implementazione consiste nella progettazione del software, nella sua codifica e nei test di basso livello (anche se lo sviluppo del software fosse stato esternalizzato). Durante questo step viene condotta anche la valutazione dei rischi del software: un team dedicato definisce quali sono i possibili guasti che il software può subire, quali azioni di mitigazione possono essere adottate e con quale metodo viene mantenuta la tracciabilità tra rischi, requisiti del software e test del software.
Implementazione di un software “off the shelf”
Nel caso l’organizzazione si sia dotata di un software off-the-shelf, la progettazione e la codifica sono generalmente sostituite dall’audit del fornitore. La valutazione del rischio è comunque uno step da attuare allo scopo di identificare i possibili guasti che il software può subire e le loro potenziali conseguenze; le azioni di mitigazione, tuttavia, dovranno essere pensate tenendo conto di cosa è fattibile attuare nel software acquistato.
Test
Questa fase costituisce la verifica del software: test di sviluppo, test unitari, test di integrazione, test utente, test di carico, test operativi etc. sono diversi metodi che, in base al tipo di software, vengono adottati allo scopo di definire se il software soddisfa l’uso previsto e se i rischi che si intendeva mitigare sono stati effettivamente diminuiti. Una volta completate un numero sufficiente di attività di confidence-building atte a garantire che il software funzioni come previsto, le attività e i risultati ottenuti devono essere citati in un rapporto di convalida finale. La revisione formale e l’approvazione del rapporto forniscono una sintesi dei riferimenti a tutte le prove oggettive documentate che supportano la conclusione che il software è stato convalidato per l’uso previsto.
Distribuzione
Questa fase consiste nell’installazione del software nella piattaforma di destinazione e nella sua messa in funzione. I controlli eseguiti in questa fase devono garantire e confermare che il software messo in uso corrisponde a quello valutato attraverso le attività di confidence-building citate nel rapporto di convalida.
Mantenimento
La fase di manutenzione del software inizia dopo che il software viene rilasciato per essere utilizzato. Le attività della fase di manutenzione consistono nell’assicurare che il software rimanga in uno stato convalidato, accogliendo, gestendo e controllando vari tipi di modifiche. Idealmente, la pianificazione della manutenzione inizia durante le fasi precedenti di sviluppo.
Si deve capire bene come le modifiche influiranno sulla convalida del software, esaminare l’effetto delle modifiche sul rischio e pianificare le attività adeguate a mantenere la convalida. Un software complesso e di grandi dimensioni potrebbe dover essere sottoposto ad attività di manutenzione quotidiana e di messa a punto delle prestazioni, senza che ciò influisca sulla capacità del software di funzionare come previsto. La pianificazione della manutenzione durante la fase di sviluppo può definire quali attività operative possono essere svolte senza influire sulla convalida e quali interventi richiedono una riconvalida. Prima che il software arrivi alla fase di manutenzione, è necessario pianificare e discutere i metodi per determinare quando eseguire ulteriori attività di convalida sul software, ossia quali sono le modifiche del software che potrebbero far venire meno, del tutto o in parte, la convalida. È utile addestrare gli addetti al dipartimento IT a riconoscere tali confini e a riconoscere la differenza tra le normali attività operative e le modifiche che richiedono la convalida.
Dismissione
Questa fase corrisponde alla dismissione del software del SGQ, ad esempio perché viene sostituito da un altro software. L’aspetto più importate da trattare in questa fase è la definizione di opportuni metodi di accesso ai documenti elettronici associati al software che verrà ritirato, per tutti i periodi di conservazione dei documenti richiesti.
