Una delle novità più importanti presentata dalla nuova versione della ISO 13485:2016 riguarda l’introduzione di un requisito, quello riportato al punto 4.1.6., che si riferisce alla richiesta che ogni applicazione software, che abbia influenza sul Sistema di gestione, sia soggetta ad un processo di Validazione.
Questo requisito si va ad aggiungere a quanto era già stato stabilito nelle precedenti edizioni della norma e che riguardava le applicazioni software direttamente coinvolte sia nel processo di produzione dei dispositivi elettromedicali (7.5.6) sia nelle attività di monitoraggio e controllo (7.6),
La novità dunque consiste nel fatto che in questa nuova versione, la ricerca di affidabilità delle applicazioni software, non si limita a quelle che permettono la produzione ed il controllo dei dispositivi commercializzati, ma riguarda anche tutte quelle applicazioni che vengono utilizzate come strumenti informatici del sistema di Gestione della ISO 13485.
Questa nuova richiesta avvicina la ISO 13485 ad altri standard quali ad esempio la 21 CFR Part 820, che è la norma, riconosciuta dalla FDA, che attualmente permette di commercializzare i dispositivi medici negli Stati Uniti ed in altri paesi del mondo.
1. COS’È LA VALIDAZIONE DEL SOFTWARE
Per Validazione o Convalida del software si intende quel processo di controllo di una determinata applicazione per valutare se essa risulta essere conforme agli usi previsti ed in particolare alle esigenze dell’utente, agli aspetti di sicurezza ed a quelli normativi applicabili.
Molto spesso il termine validazione è associato a quello di verifica del software che invece serve a stabilire che il software rispetti i requisiti e le specifiche, quindi ad esempio che non ci siano requisiti mancanti
In pratica, mentre la Verifica assicura che sia stata costruita un’applicazione in modo corretto, la Validazione assicura che sia stata realizzata un’applicazione corretta per le attività previste
Questo significa che paradossalmente, se ci si limitasse solamente alla sola fase di Verifica (senza effettuare quella di Validazione) si potrebbe costruire un’applicazione software perfettamente funzionante ma che serve poco o a nulla per gli scopi prefissati.
2. REQUISITI DI VALIDAZIONE DEL SOFTWARE NELLA ISO 13485
Il capitolo 4.1.6 della ISO 13485:2016 richiede dunque che qualsiasi applicazione utilizzata per supportare lo sviluppo o la manutenzione di un dispositivo medico, sia soggetta ad un’attività di Convalida.
Il livello di convalida del software richiesto dovrebbe essere determinato adottando un approccio basato sul rischio: maggiore e più critico é l’impatto e l’effetto del software, più intensa è la convalida richiesta.
Ad esempio sistemi complessi come la Pianificazione delle risorse aziendali (ERP), i Sistemi Elettronici di gestione della qualità (eQMS) e i Sistemi di Gestione delle informazioni di laboratorio (LIMS) dovrebbero richiedere un ampio approccio di convalida: altri che intervengono su specifiche fasi dei processi di gestione potrebbero essere convalidati attraverso attività più ridotte.
In pratica la nuova ISO 13485 richiede, in relazione a questo requisito,:
- che siano sviluppate procedure per convalidare il software del Sistema di Gestione per verificare la sua conformità all’uso previsto;
- che l’approccio di tale validazione sia proporzionato al rischio assunto;
- che tale software sia nuovamente convalidato (ri-validazione) ogni volta che ne venga modificato l’uso previsto.
- che le attività di validazione e ri-validazione siano opportunamente registrate
3. LE APPLICAZIONI SOFTWARE DA CONVALIDARE
Il primo aspetto su cui focalizzare il processo di convalida riguarda la necessità di individuare quali applicazioni del software, fra quelle utilizzate, siano coinvolte in modo significativo nel Sistema per la Qualità ISO 13485.
Per ciascuna di queste applicazioni è necessario valutare il rischio, in termini di malfunzionamenti, di safety e di security, al quale si può essere esposti nell’utilizzare tale applicazione.
Questa valutazione può includere applicazioni che riguardano ad esempio:
- sistemi CRM sistemi PLM, sistemi ERP per le parti che interessano la progettazione, realizzazione e consegna dei dispositivi medici;
- sistemi di gestione dei database
- file CAM/ CAD per attività di progettazione
- programmi software di distribuzione
ma anche
- software di tracciabilità di problemi e di gestione dei reclami
- fogli di calcolo Excel soprattutto se al loro interno sono implementati specifici algoritmi per la gestione di attività critiche collegate a Dispositivi Medici
Il processo di valutazione dovrebbe essere documentato indicando motivazioni e criteri delle modalità di convalida utilizzate
4. TIPOLOGIE DI VALIDAZIONE
La Validazione dei Sistemi Software si compone di diverse tipologie di processi di qualifica che possono essere applicate, del tutto o in parte sulla base delle necessità di convalida ( come descritto nel capitolo successivo).
Tali processi sono generalmente realizzati sia dal Produttore dell’Applicazione Software, sia dall’Acquirente / utilizzatore .
I processi di qualifica che generalmente sono effettuati dal produttore sono:
Design Qualification (DQ) che serve a verificare che durante l’intero ciclo di progettazione, sviluppo e test, l’Applicazione Software risulti costantemente adatta allo scopo previsto.
Component qualification (CQ) che serve a verificare che parti di software acquistate o realizzate in outsourcing siano coerenti con i requisiti stabiliti con il fornitore, prima che tali componenti siano integrati nella Applicazione software.
Maintenance Qualification (MQ ) che serve a valutare l’adeguatezza dei processi di manutenzione in atto per garantire la sistematica affidabilità della Applicazione Software nel tempo
I processi di qualifica che generalmente sono invece effettuati dall’Acquirente e che sono quelli che ovrebbero soddisfare il punto 4.1.6 della ISO 13485 risultano essere:
Installation qualification (IQ) che serve a verificare che l’applicazione sia stata installata correttamente e che tutta la documentazione necessaria (ad esempio manuali utente, istruzioni di lavoro, procedure di backup, ecc.) sia corretta e disponibile per gli utilizzatori
Operational qualification (OQ) che serve a verificare che le funzionalità / operazioni offerte in fase di acquisto siano conformi alle aspettative dell’acquirente sia in termini di operatività, sia in termini di altri fattori quali ad esempio l’usabilità: inoltre viene valutata la coerenza con la documentazione d’uso rilasciata.
Performance qualification (PQ) che serve a verificare che il sistema software si comporti, in termini prestazionali, come previsto.
5. PROCESSO DI VALIDAZIONE
Ogni tipologia di validazione, sia effettuata dal produttore sia dall’acquirente, dovrebbe essere realizzata attraverso un processo che dovrebbe essere regolamentata attraverso una procedura di qualità o SOP , che contenga le varie fasi e attività del Processo di validazione.
Come tutti i processi anche quello che regolamenta le Validazioni dovrebbe essere strutturato sulla base della classica architettura Plan, Do, Check, Act
Plan : che consiste nell’effettuare una fase di analisi per determinare il campo di applicazione e di fattibilità delle applicazioni software e la realizzazione di un Piano di Validazione che rappresenti la cornice all’interno della quale effettuare la Convalida
Do : che consiste nella attività vera e propria di validazione che sarà declinata sulla base delle tipologie di qualifiche interessate. Qualunque tipologia venga scelta è comunque necessario che essa sia guidata da protocolli che determinino su cosa e come effettuare le analisi di convalida e che al termine sia emesso un Report di Validazione che riassuma i risultati della convalida
Check : che consiste nel verificare la necessità di rivalidazione ogni qualvolta vi sia un upgrade e una nuova release delle applicazioni convalidate
Act : che consiste nel determinare le attività necessarie per rivalidare tali applicazioni che dovranno essere inserite in un nuovo eventuale piano
Linee guida per gestire in modo efficace tale processo di convalida possono essere desunte utilizzando, per quanto riguarda il settore dei dispositivi medici, dalla EN 62304 “medical device software – software life cycle processes” e dalla ISO/TR 80002/2 “Medical Device Software part 2: Validation of Software for Medical Device Quality System ”
Mentre una metodologia più completa e dedicata specificatamente alla validazione può essere reperita dalle “Gamp 5” la linea guida rilasciata dall’ISPE (International Society for Pharmaceutical Engineering)
6. CONCLUSIONI
La convalida del software, oltre a soddisfare quanto richiesto dalla ISO 13485, aiuta a ridurre i rischi e la responsabilità legale, oltre a fornire la prova che il sistema informatico è adatto allo scopo.
La convalida serve a verificare che i sistemi installati sul computer “svolgano i compiti che noi vogliamo che facciano” e ci impediscano di fare “cose che non dovremmo essere in grado di fare”
La convalida del software ha anche molti vantaggi commerciali. Sulla base di quanto afferma la Food and Drug Administration (FDA) degli Stati Uniti, essa può aumentare l’usabilità e l’affidabilità, con conseguente riduzione dei tassi di fallimento, meno richiami di prodotto e azioni correttive, minori rischi per i pazienti e gli utenti e ridotta responsabilità a carico dei produttori
La convalida però può essere difficile e dispendiosa in termini di tempo e quindi di costi.
Molte aziende trovano il processo di validazione di un sistema software notevolmente più complicato rispetto all’implementazione del sistema stesso. Per questo in relazione alla necessità di essere conformi a quanto richiesto dalla ISO 13485:2016 è importante una profonda fase di analisi al fine di ridurre gli impatti che tale processo di validazione può avere sull’azienda coinvolta
Commenti recenti