di
Giorgio Civaroli per
ICF – Rivista dell’Industria Chimica e Farmaceutica – giugno/luglio 2020
Le DTx (Digital Therapeutics) rappresentano un settore fortemente innovativo, che deve tenere conto sia delle criticità tipiche del ciclo di vita di un prodotto informatico sia delle buone pratiche e delle normative stringenti di industria farmaceutica e life sciences.
A tutela della salute del paziente.
Con un
articolo di
Teresa Minero, nello scorso numero di ICF abbiamo descritto come, con le Terapie Digitali (Digital Therapeutics – DTx), in realtà il futuro sia già qui, nel presente.
Con questo secondo articolo vogliamo entrare nello specifico di come una DTx possa diventare tale e cosa si debba tenere in considerazione mentre la si realizza, seguendo le buone pratiche in uso nel settore farmaceutico, dove è d’obbligo avere la certezza che il software realizzato rispetti una serie di regole per garantire le adeguate sicurezze al paziente.
Un vero strumento terapeutico
La terapia digitale, che è software e “principio attivo” allo stesso tempo, vero oggetto terapeutico, deve perciò funzionare in modo affidabile, come condizione necessaria e preliminare a ogni analisi e approvazione terapeutica. Esso è soggetto a tutti i rischi tipici che caratterizzano il ciclo di vita di un prodotto software:
• Errori (od omissioni) in fase di concezione e progettazione;
• Errori di realizzazione;
• Inadeguata gestione del processo evolutivo nel tempo.
In aggiunta agli standard internazionali emessi per i Medical Device, che sono il riferimento più affine per una corretta gestione dello sviluppo, cosa potrebbe imparare il neonato settore delle DTx dalla storia vissuta dall’industria farmaceutica relativamente all’utilizzo dei software?
Approfondiamo allora alcune riflessioni, che nascono dalle esperienze vissute nel mondo farmaceutico negli ultimi quattro decenni circa; esperienze relative all’uso di automazione ed informatizzazione a supporto dei processi critici.
Partiamo con una premessa. Nel mondo moderno siamo abituati a fidarci di quello che leggiamo sullo schermo del nostro computer, del cellulare o del tablet. È un atto consapevole o inconsapevole?
Spesso rischia di essere un atto di fiducia inconsapevole perché, indubbiamente, il computer (nelle sue diverse accezioni) ha migliorato il nostro modo di vivere: l’informazione è sempre più facilmente reperibile, fruibile, archiviabile e l’automazione ci ha tolto alcune parti della fatica fisica.
Nel settore della farmaceutica però, molto di più che in altri, c’è di mezzo la salute delle persone, se non addirittura la vita stessa.
Pertanto, la fiducia riposta nei computer non può essere un atto inconsapevole, deve essere l’esito di una “ragionevole certezza”; certezza che va costruita con metodologie chiare e ripetibili.
La validazione dei sistemi computerizzati e la nascita delle GAMP
Alcuni tragici eventi avvenuti già negli anni ‘70 e ‘80 nel farmaceutico hanno chiaramente stimolato, nel settore specifico, un processo di consapevolezza sull’uso sicuro dei sistemi computerizzati. Consapevolezza che è diventata presto richiesta normativa da parte degli enti di Salute pubblica, primo tra tutti, in ordine di tempo, la
Food & Drug Administration statunitense. E questa consapevolezza ha avuto e continua ad avere un processo di maturazione, passando da richieste di correttezza funzionale (in primis) ad una successiva maggiore attenzione al concetto di “dato”.
Da dove arrivano i dati di input?
E quelli di output: se sono corretti al tempo zero, dove vanno? Quanto devono vivere? Sono disponibili sempre? Sono affidabili sempre durante la loro vita? Se no, quali rischi possono insorgere?
La storia dell’evoluzione delle richieste regolatorie va di pari passo con le risposte metodologiche che l’industria farmaceutica (e più in generale il Life Science) ha trovato negli anni, al fine di rispondere a tali richieste e costruire la ragionevole certezza di operare con sistemi computerizzati sotto pieno controllo.
A partire dalle metodologie ingegneristiche per la validazione dei sistemi meccanici l’industria farmaceutica ha sviluppato la propria strada per la validazione di impianti, processi e sistemi computerizzati, partendo da quelli di automazione utilizzati per il controllo degli impianti stessi, per poi allargare l’ambito ai sistemi informativi, attingendo ad altri standard industriali, di ingegneria del software (le famose IEEE) e rielaborandoli per il proprio fine.
Nasce così, tra la fine degli anni ‘80 e l’inizio dei ‘90, la disciplina della
Computerized Systems Validation (CSV).
Qual è il compito della CSV? In accordo con le richieste di FDA, essa può essere definita tuttora come:
“Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled”.
In particolare, nascono in Europa (e in parte anche in Italia) le linee guida ormai universalmente diffuse come il punto di riferimento metodologico per la CSV: le
GAMP (Good Automated Manufacturing Practices – Norme di Buona Fabbricazione di Sistemi Automatici).
Perché possiamo dire che sono nate anche in Italia?
Perché nello sviluppo della metodologia di risposta giocano un ruolo fondamentale due ispezioni fatte in Europa da FDA, nel 1991, in Inghilterra e proprio in Italia, presso due stabilimenti di importanti multinazionali. Ispezioni importantissime perché pietre miliari per le non conformità rilevate sulla gestione dei sistemi computerizzati.
Come conseguenza, nutriti gruppi di lavoro delle due aziende hanno lavorato per qualche anno alla risoluzione delle non conformità ed alle azioni di rimedio. L’autore di questo articolo ha avuto la fortuna di trovarsi, da giovane neolaureato, nel gruppo di lavoro italiano. Una volta superate positivamente le ispezioni di riverifica da parte di FDA, i due gruppi di lavoro si sono ritrovati in Inghilterra e hanno trascritto
in un documento le metodologie identificate. Sono la prima versione delle GAMP. Era il 1994. Molti anni sono passati e la metodologia (ormai alla sua quinta versione) è stata migliorata ed è evoluta da un focus iniziale sui sistemi di controllo di impianto, ad una forma più generale, includente anche i sistemi informativi, e andando oltre la produzione verso i processi distributivi, la ricerca clinica, i processi regolatori.
Non ultimo, elaborando un approccio più flessibile per potersi adattare all’elevata dinamicità delle nuove tecnologie.
GAMP, dapprima piccolo gruppo di lavoro indipendente, si è poi unita a
ISPE (International Society of Pharmaceutical Engineering), la più grande comunità no profit al mondo di professionisti dell’industria farmaceutica.
Grazie a questo passaggio, la metodologia GAMP ha potuto solcare l’oceano ed arrivare negli Usa, e da lì nel resto del mondo, fino ad essere riconosciuta da FDA stessa, che la cita espressamente come una delle strade per rispondere alle richieste di adeguatezza dei software in uso nel settore.
Il principio base comunque è rimasto sempre lo stesso: supportare la buona gestione dell’intero ciclo di vita di un sistema (software e hardware), progettando, documentando e testando il tutto in maniera formale e dimostrabile. In modo tale da verificare l’aderenza tra il funzionamento finale del sistema e gli obiettivi predefiniti (Intended use), con particolare attenzione alle funzionalità critiche. Quindi, in ultima analisi, per garantire l’obiettivo che più interessa: poter ridurre i rischi derivanti per la salute del paziente.
Le potenzialità delle DTx e la necessità di linee guida
Per tornare alle DTx: la Terapia Digitale è di fatto un software. E come tale è soggetto a tutti i rischi tipici già citati. Una delle caratteristiche principali di queste terapie innovative è il poter essere erogate ai pazienti attraverso i terminali mobili (cellulari e tablet), ormai alla portata di tutti. Questo punto, indubbiamente positivo, porta con sé ulteriori rischi da gestire in aggiunta, appunto, a quelli tipici di un prodotto software tradizionale.
Alcuni esempi:
• necessità di funzionamento su piattaforme multiple (Android, iOS) e su diverse tipologie di hardware dalle più svariate capacità prestazionali;
• discrezionalità degli utenti nell’aggiornamento dei sistemi operativi e delle app;
• corretta gestione delle installazioni sui dispositivi: corretta configurazione, identificazione e profilazione dell’utente;
• impossibilità di certezza sulla disponibilità di connessione.
Cosa si potrebbe quindi imparare dal farmaceutico per la nuova realtà delle DTX?
Sicuramente mutuare la consapevolezza dei rischi legati allo sviluppo del software per il farmaceutico, che nell’ambito delle DTx, poiché appena nate, deve ancora crescere. Inoltre, attingere alle metodologie esistenti lavorando per adattarle alle proprie peculiarità. Infine, considerare che un supporto fondamentale alla realizzazione di un corretto ciclo di vita di questi software ci può essere fornito, come per le altre tipologie di software GxP critici, dalla linea guida ISPE GAMP. In particolare, per quest’argomento, da uno dei suoi approfondimenti tematici (ISPE GAMP Good Practice Guides): GAMP GPG “A Risk-Based Approach to Regulated Mobile Applications”, che fornisce indicazioni su come gestire “in compliance” le applicazioni per i dispositivi mobili che si configurano come Medical Device (Mobile Medical App).
In sintesi, appare utile che nell’attuale processo di ideazione, progettazione, realizzazione e manutenzione delle DTx, che certamente presenta potenzialità notevoli, si aggiungano agli standard di riferimento attuali metodologie ispirate all’esperienza delle linee guida GAMP.
La proposta per un tavolo di confronto
In conclusione, a nome di LifeBee e della comunità che da sempre si occupa delle tematiche di progettazione e qualità dei software nel Life Science, chi scrive esprime il desiderio di aprire un dibattito aperto con chi a vario titolo si occupa di progettazione, test e manutenzione di DTx. Si propone cioè un tavolo di confronto finalizzato allo sviluppo di metodologie che, a partire dalle esperienze consolidate in ambito CSV nel Life Science, definiscano una evoluzione adeguata alle esigenze specifiche delle DTx.
