La Validazione di software medicali sviluppati con l’Intelligenza Artificiale

L’Intelligenza Artificiale sta modificando profondamente il modo in cui il software viene progettato e sviluppato.

Fino a pochi anni fa, parlare di AI nello sviluppo software significava principalmente parlare di strumenti di supporto alla programmazione. Oggi, invece, sistemi basati sull’AI possono contribuire alla definizione dei requisiti, alla progettazione dell’architettura, alla generazione del codice, alla produzione dei casi di test, alla redazione della documentazione e, naturalmente, alla realizzazione del modello di AI destinato a essere incorporato nel prodotto finale.

Questa evoluzione pone una domanda particolarmente importante soprattutto quando il software è destinato a diventare un dispositivo medico o a essere incorporato in un dispositivo medico:

è sufficiente validare il software finale oppure occorre verificare anche la qualità del processo attraverso il quale quel software è stato prodotto?

Il problema riguarda quindi un insieme molto ampio di applicazioni: software autonomi che svolgono direttamente una funzione medicale e sono utilizzati come dispositivo medico, ma anche software e firmware che operano all’interno di dispositivi medici e ne determinano, in tutto o in parte, il funzionamento.

Nel software tradizionale, la qualità del prodotto finale può essere verificata attraverso requisiti, test, verifiche e validazione. Quando però nel processo intervengono sistemi di AI, modelli addestrati su dati, componenti di terze parti, librerie, servizi cloud o strumenti generativi capaci di produrre autonomamente applicazioni software, diventa più difficile considerare il prodotto finale come l’unico elemento da sottoporre a controllo.

La qualità del risultato dipende infatti anche dalla qualità del processo che lo ha generato.

Da questa considerazione nasce una possibile evoluzione dell’approccio tradizionale: affiancare alla validazione del prodotto una qualificazione sistematica del processo di sviluppo.

L’obiettivo non è introdurre un nuovo standard né sostituire i processi già previsti dalla normativa applicabile. Si tratta piuttosto di utilizzare una metodologia che consenta di organizzare e documentare, in modo strutturato e proporzionato al rischio, la qualificazione del processo di sviluppo di un software medicale realizzato anche con l’impiego dell’AI

Due modi molto diversi di utilizzare l’AI

Prima di affrontare il problema della qualificazione è necessario distinguere due situazioni che, pur potendo coesistere, presentano problematiche differenti.

La prima è quella nella quale l’AI viene utilizzata come strumento durante lo sviluppo del software. Un sistema generativo può, per esempio:

• proporre requisiti;
• generare porzioni di codice;
• suggerire architetture;
• generare casi di test;
• produrre documentazione;
• analizzare codice;
• individuare possibili vulnerabilità;
• trasformare o classificare dati;
• assistere gli sviluppatori nella risoluzione di problemi.

In questo caso l’AI non entra necessariamente nel prodotto finale. Il controllo riguarda quindi soprattutto risultati ottenuti con l’ausilio dell’AI e il modo con il quale tali risultati vengono verificati e approvati.

La seconda situazione è quella nella quale un modello o un algoritmo di AI, costituisce una parte del software finale.

In questo caso la complessità aumenta: oltre al normale ciclo di sviluppo, devono essere considerati dati, dataset, procedure di preparazione, addestramento, parametri, prestazioni del modello, gestione dei bias, robustezza, riproducibilità e modalità di aggiornamento

Le due situazioni possono naturalmente essere presenti contemporaneamente. Un software medicale, sia esso un’applicazione SaMD oppure software/firmware incorporato in un dispositivo medico, potrebbe, ad esempio, contenere un modello di Machine Learning e, allo stesso tempo, essere stato sviluppato utilizzando strumenti di AI generativa. In entrambi i casi emerge una stessa esigenza:

Dimostrare che il processo attraverso il quale il software è stato realizzato è sotto controllo.

Dalla validazione del prodotto alla qualificazione del processo

Il concetto di validazione del software è tradizionalmente associato alla dimostrazione che il prodotto realizzato soddisfa i requisiti stabilti e che è idoneo all’uso previsto: questo principio rimane fondamentale e non viene messo in discussione dall’introduzione dell’AI.

Il problema è che, in presenza di sistemi AI, la sola verifica del prodotto finale potrebbe non fornire una rappresentazione sufficientemente completa del livello di controllo esercitato sul processo di sviluppo.

Si consideri, per esempio, un sistema nel quale una parte significativa del codice sia stata generata da un modello di AI. Il fatto che il software superi i test previsti dimostra che, nella configurazione sottoposta a verifica, il prodotto ha raggiunto determinati risultati. Non dimostra però necessariamente che il processo attraverso il quale tale risultato è stato ottenuto sia adeguatamente sotto controllo e tracciabile. In particolare, occorre poter ricostruire, secondo modalità proporzionate al rischio:

• quali strumenti e modelli di AI siano stati utilizzati per la generazione del codice;
• quali istruzioni o condizioni abbiano guidato la generazione;
• quale versione del modello sia stata utilizzata;
• quali controlli siano stati effettuati sul codice generato;
• quali parti siano state successivamente modificate o integrate dallo sviluppatore;
• quali elementi del processo siano necessari per comprenderne e, ove necessario, ripeterne o controllarne il risultato.

Lo stesso principio assume particolare rilevanza quando il prodotto contiene un modello di Machine Learning. In questo caso, infatti, la qualità del risultato finale dipende anche dalle modalità con cui sono stati selezionati, preparati e utilizzati i dati, nonché dalle modalità di addestramento, verifica e versionamento del modello. La sola verifica del comportamento del prodotto non è quindi necessariamente sufficiente a dimostrare che anche questi elementi del processo siano stati adeguatamente controllati e documentati.

La metodologia descritta in questo articolo non significa però inventare un nuovo ciclo di vita del software.

Per il software medicale esistono già riferimenti consolidati, a partire dalla IEC 62304, che definisce processi, attività e compiti relativi al ciclo di vita del software per dispositivi medici. Inoltre, quando sono presenti elementi di AI, possono assumere particolare rilevanza riferimenti specifici per l’intelligenza artificiale, come ISO/IEC 5338, dedicata ai processi del ciclo di vita dei sistemi AI.

Il punto interessante è che questi riferimenti possono essere integrati con un modello di qualificazione del processo, finalizzato a verificare non soltanto che una determinata attività sia stata eseguita, ma anche che sia stata eseguita secondo criteri di qualità definiti. Non si tratta semplicemente di chiedersi se “È stato eseguito il processo di raccolta dei dati?” ma piuttosto se “Il processo utilizzato per raccogliere i dati era appropriato, controllato, documentato, tracciabile e adeguato allo scopo?“

Questo porta a una possibile metodologia articolata in tre livelli principali:

DQ – Design Qualification

CQ – Component Qualification

MQ – Maintenance Qualification

Si tratta di una proposta metodologica e non di categorie formalmente definite in una qualche normativa. Il loro valore consiste nell’offrire una struttura organizzativa attraverso la quale rendere verificabile la qualità del ciclo di vita.

È importante evitare una possibile ambiguità terminologica. DQ, CQ e MQ non dovrebbero essere interpretate come una sostituzione delle tradizionali attività di Installation Qualification, Operational Qualification e Performance Qualification ( ma al massimo in una loro complementarietà) in quanto le due prospettive rispondono a esigenze differenti :

• La DQ/CQ/MQ riguardano principalmente il processo attraverso il quale il software viene progettato, realizzato, integrato e mantenuto
• La IQ/OQ/PQ riguardano invece la verifica del sistema nel contesto operativo nel quale sarà utilizzato

ISO/IEC 25010 e ISO/IEC 25059: dalla qualità generica alla qualità dell’AI

Per costruire questo modello è necessario disporre di un linguaggio comune per descrivere la qualità. Un riferimento particolarmente utile è ISO/IEC 25010, che definisce un modello di qualità per sistemi e prodotti software. Quando il prodotto incorpora elementi di AI, può essere affiancato da ISO/IEC 25059, che definisce un modello di qualità specificamente rivolto ai sistemi AI. Questo consente di passare da una logica puramente procedurale a una logica basata sulle caratteristiche qualitative.

In altre parole, il processo non viene qualificato soltanto perché possiede una procedura documentata, ma perché quella procedura è in grado di produrre risultati adeguati rispetto alle caratteristiche qualitative richieste. Questa impostazione permette inoltre di costruire una relazione molto interessante:

Fase del ciclo di vita → caratteristica di qualità → criterio di accettazione → evidenza → risultato della qualificazione

È una struttura che può essere applicata tanto allo sviluppo tradizionale quanto allo sviluppo AI

Il problema particolare dell’AI generativa

L’impiego di strumenti come sistemi di AI generativa introduce una nuova categoria di rischio. Tradizionalmente lo sviluppatore produce direttamente un’ Applicazione e l’organizzazione ne verifica la correttezza. Con l’AI generativa, una parte dell’applicazione può essere prodotta da uno strumento il cui output deve essere considerato un risultato da verificare, e non un’evidenza automatica della correttezza del prodotto.

Se un sistema AI genera codice, requisiti o casi di test, questi sono risultati che devono essere sottoposti ai normali processi di revisione, verifica e approvazione. Il processo di qualificazione potrebbe quindi richiedere di documentare almeno:

• quale strumento AI è stato utilizzato;
• quale versione o configurazione era disponibile;
• per quale attività è stato utilizzato;
• quali dati sono stati forniti al sistema;
• quali limitazioni erano note;
• quali controlli umani sono stati applicati;
• come sono stati verificati gli output;
• come sono state gestite eventuali modifiche successive.

L’elemento fondamentale è che L’AI può partecipare al processo di sviluppo, ma non sostituisce la responsabilità del fabbricante o dello sviluppatore rispetto alla conformità del prodotto

DQ – Design Qualification

La Design Qualification rappresenta il cuore della metodologia. L’obiettivo non è semplicemente verificare che il software sia stato progettato, ma qualificare il processo attraverso il quale il progetto è stato definito e sviluppato. La DQ può quindi seguire l’intero percorso:

Requisiti → Architettura → Progettazione → Dati → Sviluppo → Addestramento → Verifica → Validazione → Rilascio

La profondità della valutazione deve essere proporzionata alla natura del software, alla sua criticità e ai rischi associati.

Per ogni fase possono essere individuate specifiche caratteristiche qualitative da verificare. Ad esempio, nella fase di raccolta dei dati si potrebbero valutare:

• Appropriatezza :     Il metodo di raccolta è adeguato alla popolazione e agli obiettivi?
• Completezza :          I dati raccolti sono sufficienti rispetto allo scopo previsto?
• Accuratezza :           I dati rappresentano correttamente ciò che devono rappresentare?
• Trasparenza :          Sono documentate origine, modalità e condizioni di raccolta?
• Tracciabilità :          È possibile ricostruire origine e trasformazioni dei dati?
• Sicurezza :                I dati sono protetti da accessi o modifiche non autorizzate?
• Rappresentatività : Il dataset rappresenta adeguatamente la popolazione prevista a partire dai risultati della analisi clinica?
• Coerenza :                 I dati derivano da fonti coerenti con la futura destinazione d’uso (es. centro specializzato vs. medicina generale)
• Riproducibilità ;      Il processo di raccolta può essere ripetuto ottenendo condizioni comparabili?

Lo stesso approccio può essere applicato alle altre fasi del ciclo di vita.

Per la progettazione dell’algoritmo potrebbero essere valutate, ad esempio, appropriatezza, coerenza, trasparenza, verificabilità e robustezza.

Per il processo di testing oltre ai normali criteri di completezza, copertura, tracciabilità e riproducibilità, possono assumere particolare rilevanza alcuni aspetti specifici dei sistemi AI, quali la verifica della sensibilità alle variazioni degli input, la stabilità delle prestazioni, la capacità di generalizzazione e, ove pertinente, la rilevazione o gestione di condizioni fuori dominio.

In questo modo la DQ non diventa una semplice verifica documentale del fatto che “la fase è stata eseguita”, ma una vera valutazione qualitativa del processo

CQ – Component Qualification

Un secondo elemento della metodologia è la Component Qualification.

Nello sviluppo moderno, il software finale raramente è costituito esclusivamente da codice sviluppato internamente. Possono essere utilizzati:

• librerie;
• framework;
• API;
• componenti Open Source;
• SOUP;
• servizi cloud;
• database;
• modelli AI pre-addestrati;
• dataset di terze parti;
• componenti hardware/software;
• strumenti di sviluppo;
• servizi esterni.

La CQ estende quindi il concetto tradizionale di controllo dei componenti di terze parti.

Anche in questo caso la qualificazione dovrebbe essere proporzionata alla criticità del componente: quanto più un componente esterno è importante per il comportamento del prodotto, tanto maggiore deve essere il livello di evidenza richiesto per dimostrarne l’adeguatezza.

Una possibile valutazione potrebbe considerare:

origine → versione → funzione → criticità → dipendenze → vulnerabilità → documentazione disponibile → prestazioni → manutenzione prevista → evidenze disponibili → risultato della qualificazione.

Per i componenti sviluppati o modificati, in tutto o in parte, mediante strumenti di intelligenza artificiale, la qualifica dovrebbe verificare, nella misura in cui tali informazioni siano disponibili e rilevanti in relazione al rischio, l’origine e la versione del componente e gli eventuali elementi introdotti durante il suo sviluppo.

In ogni caso, il componente deve essere identificabile e tracciabile, sottoposto a una valutazione da parte di personale competente e alle attività di verifica e testing applicabili in relazione al suo utilizzo previsto. Per i componenti di terze parti, inclusi quelli open source, la qualifica dovrebbe inoltre tenere conto delle informazioni effettivamente rese disponibili dal fornitore o dalla comunità di sviluppo e delle eventuali limitazioni alla loro disponibilità.

MQ – Maintenance Qualification

La qualità del software non termina con il rilascio. Questo principio diventa ancora più importante nei sistemi che utilizzano AI.

Per questo la Maintenance Qualification ha lo scopo di assicurare che le modifiche al sistema siano sottoposte a una valutazione proporzionata al loro impatto e che, nel tempo, siano mantenute le caratteristiche qualitative e prestazionali richieste. 

Nel caso dei sistemi basati sull’AI, la MQ dovrebbe considerare non soltanto le modifiche intenzionalmente introdotte nel software, nei dati, nei modelli o nell’infrastruttura, ma anche le informazioni provenienti dall’utilizzo del sistema in condizioni reali.

Le performance osservate sul campo, eventuali variazioni nella distribuzione dei dati, segnalazioni degli utilizzatori, anomalie o evidenze di deterioramento delle prestazioni possono infatti costituire input per una rivalutazione del sistema e, ove necessario, per l’avvio di un processo di modifica e riqualificazione.

La sequenza può pertanto essere rappresentata come:

Modifica / Monitoraggio delle prestazioni → Analisi dell’impatto → Analisi del rischio → Valutazione della qualità → Riqualificazione / Verifica di regressione → Approvazione → Rilascio → Monitoraggio post-rilascio

L’eventuale scostamento delle performance rispetto ai criteri definiti non implica automaticamente l’aggiornamento del sistema: deve innanzitutto essere valutata la causa dello scostamento e il relativo impatto sulla sicurezza, sulle prestazioni e sull’uso previsto. Solo quando tale valutazione evidenzi la necessità di un intervento, la modifica dovrà essere gestita attraverso il processo controllato di manutenzione e sottoposta alle attività di verifica e riqualificazione applicabili.

Una metodologia che può essere utile anche nel mondo GxP

Questa impostazione non è necessariamente limitata al settore dei dispositivi medici.

Un caso particolarmente interessante è rappresentato dalle Aziende Farmaceutiche che affidano lo sviluppo di applicazioni software a Software House esterne. In questo contesto, le esigenze di Supplier Assurance e Computerized System Validation richiedono spesso al cliente di poter comprendere e valutare il processo attraverso il quale il fornitore ha sviluppato il software.

Qui la metodologia DQ/CQ/MQ può diventare uno strumento particolarmente interessante. Non dovrebbe essere presentata come “la metodologia GAMP 5“, né come un requisito imposto da GAMP 5. Piuttosto, può essere vista come un possibile modello con il quale un fornitore può strutturare e dimostrare il controllo del proprio ciclo di vita, in coerenza con i principi GAMP 5.

Il fornitore potrebbe quindi mettere a disposizione del cliente un vero e proprio Supplier Lifecycle Qualification Package, costituito dalle evidenze prodotte durante DQ, CQ e MQ. Il cliente farmaceutico potrebbe utilizzare tali evidenze nell’ambito della propria valutazione del fornitore e del proprio processo di validazione, senza confondere le responsabilità del fornitore con quelle dell’azienda regolamentata.

Questo approccio è particolarmente interessante perché consente di evitare una duplicazione inutile delle attività. Il fornitore dimostra di avere sotto controllo il proprio processo di sviluppo. Il cliente verifica che tale processo sia adeguato al proprio uso previsto e integra le evidenze del fornitore all’interno della propria strategia di validazione.

Conclusioni

L’introduzione dell’Intelligenza Artificiale nello sviluppo del software medicale non rende necessariamente obsolete le metodologie di validazione esistenti, ma ne evidenzia  la possibile evoluzione.

Quando un prodotto viene realizzato attraverso una combinazione di codice tradizionale, componenti di terze parti, dataset, modelli AI e strumenti generativi, la qualità del risultato finale dipende sempre più anche dalla qualità e dal controllo dei processi che ne hanno determinato la realizzazione.

Questo principio vale sia per il software che costituisce direttamente un dispositivo medico, come nel caso di un SaMD, sia per il software o firmware incorporato all’interno di un dispositivo medico, nel quale il comportamento del software può contribuire direttamente alle prestazioni e alla sicurezza del dispositivo nel suo complesso.

La domanda non dovrebbe quindi essere soltanto:

“Il software è stato validato?” ma anche “Il processo attraverso il quale il software è stato realizzato è stato adeguatamente qualificato e controllato?”.

In altre parole, oltre a dimostrare che il prodotto funziona, diventa sempre più importante poter dimostrare perché possiamo fidarci del processo che lo ha prodotto  possiede caratteristiche tali da rendere affidabili le evidenze ottenute sul prodotto stesso.

La metodologia DQ/CQ/MQ proposta in questo articolo non intende introdurre una nuova categoria normativa di qualificazione, ma rappresenta un possibile modello attraverso il quale integrare, in modo strutturato, i diversi riferimenti applicabili:

• la IEC 62304 che fornisce il riferimento per il ciclo di vita del software medicale;
• la ISO/IEC 5338 che fornisce un riferimento specifico per i processi del ciclo di vita dei sistemi AI;
• la ISO/IEC 25010 che fornisce un modello generale delle caratteristiche di qualità;
• la ISO/IEC 25059 che fornisce un modello di qualità specificamente rivolto ai sistemi AI,

Su questa base è possibile costruire una metodologia organizzativa nella quale:

• DQ qualifica il processo di progettazione e sviluppo verificando che metodi, criteri e controlli adottati siano adeguati alla natura del prodotto e, ove presente, ai componenti AI
• CQ qualifica i componenti esterni o preesistenti destinati a essere integrati nel prodotto, compresi, ove applicabile, componenti sviluppati o assistiti mediante strumenti di AI;
• MQ qualifica il processo di modifica e mantenimento verificando che le modifiche introdotte nel tempo siano valutate e controllate in funzione del loro impatto sul prodotto.

DQ, CQ e MQ non sostituiscono quindi la verifica e la validazione del prodotto, ma ne costituiscono un livello complementare di controllo del processo.

L’obiettivo finale non è dimostrare soltanto che “il software funziona“, ma poter fornire evidenze sufficienti per comprendere come è stato realizzato, quali processi ne hanno determinato le caratteristiche e perché le evidenze ottenute sul prodotto possono essere considerate affidabili.

GRAZIE PER L’ATTENZIONE