FDA:DALLA VALIDAZIONE ALL'ASSICURAZIONE DEI SISTEMI SOFTWARE

La trasformazione digitale, che rientra nel nuovo corso chiamato Industria 4.0 e che riguarda tutto il settore manifatturiero, non poteva non coinvolgere anche le aziende che operano nel settore dei Dispositivi Medici.

FDA ha deciso così di incoraggiare l’uso dell’automazione e della tecnologia dell’informazione in tutto il ciclo di vita collegato alla realizzazione di un Dispositivo Medico: dalla progettazione, alla produzione, al collaudo, alla consegna ed alle attività di assistenza.

Quindi in termini di compliance ai propri regolamenti FDA si pone come obiettivo quello di cercare di andare oltre a quello che per anni ha rappresentato uno dei capisaldi della affidabilità di un Sistema Computerizzato e cioè la convalida dei Sistemi Informatici collegati ad un Dispositivo Medico.

La validazione dei Sistemi automatizzati è da diversi anni uno degli elementi principali di molti regolamenti quale ad esempio il 21 CFR Part 11 la cui definizione, praticamente immutata dal 1997, come sono rimaste invariate le successive linee guida emesse dalla FDA “General Principles of Software Validation” del 2002 e Guidance on Part 11 del 2003.

Per tale motivo FDA entro la fine del 2019 pubblicherà una nuova guida “Computer Software Assurance for Manufacturing Operation and Quality System Software ” che intende favorire un atteggiamento più moderno sull’argomento e che comunque porterà a superare l’approccio di valutazione dell’affidabilità dei Sistemi Automatici oramai vecchio di almeno 17 anni. Teniamo infatti presente che in questo periodo alcuni aspetti dei Sistemi informativi si sono molto evoluti come, ad esempio, le metodologie di sviluppo e di test del software e sono stati introdotti strumenti come il cloud computing e le App.

Tale nuova guida ha anche tre ulteriori scopi:

eliminare alcuni aspetti poco chiari che hanno portato ad errate interpretazioni della CFR 21 Part 11 relative alla convalida dei Sistemi Informatici e che hanno spesso generato confusione sia nelle aziende che le hanno applicate sia in coloro che ne verificavano l’applicazione;
cercare di porre rimedio agli aspetti che a volte appaiono estremamente onerosi della attività di convalida. Infatti nell’ FDA vi è la consapevolezza che gli sforzi di convalida del sistema informatico (CSV) sono stati spesso troppo estesi e troppo costosi per essere accettati dalle aziende, inducendo molte di esse a ridurre al minimo l’adozione di automazione e tecnologia pur di non affrontare l’iter a volte alquanto impegnativo del processo di validazione. Tale processo in alcuni casi può raggiungere anche fino a due volte il costo delle applicazioni stesse .
concentrare soprattutto l’attenzione non solo sugli aspetti di conformità formale, ma soprattutto sulla qualità e reale affidabilità del Sistema Informatico. FDA vuole evitare che succeda come “quel ristorante che é pienamente conforme alle norme igieniche ed alimentari,…… ma dove si mangia malissimo”

1. DALLA CONFORMITÀ ALLE METRICHE

L’approccio insito nella Computer Quality Assurance rispetto alla Computer System Validation è quello che porta a cercar di superare la mentalità di ricerca esasperata della conformità a scapito della individuazione della reale qualità da stabilire attraverso l’uso di metriche appropriate.

L’attuale paradigma, su cui è incentrata l’attività di validazione, richiede spesso di produrre una documentazione corposa ai quali fanno seguito test e verifiche, che però non dà molto spazio a valutazioni critiche sulle applicazioni software e alle necessità di garantire la sicurezza dovuta.

In particolare le macrofasi che grantiscono l’affidabilità di un Sistema Software riguardano :

Analisi Critica (Critical Thinking) : é la fase dove si raccolgano le informazioni utili a definire pienamente in che modo un Sistema Software debba rispondere alle necessità operative. La valutazione si effettua attraverso l’esame di tali informazioni rispetto alle quali si stabilisce criticamente il grado di validità. In particolare tale analisi deve valutare la chiarezza, l’accuratezza e la pertinenza di tali informazioni dove:

la chiarezza è fondamentale per comprendere le informazioni ricevute;
la precisione indaga i divari tra l’informazione e la realtà fattibile;
la pertinenza aiuta a garantire che l’informazione sia congrua con gli obiettivi che i Sistema vuole raggiungere

Esigenze di Sicurezza (Assurance Needs) che riguarda la confidenza che il Sistema Software che interagisce direttamente o indirettamente con gli utenti dei Dispositivi medici ed i pazienti coinvolti, non influisca sulla loro sicurezza. Per questo aspetto è molto importante che le azioni che servono a creare un livello di sicurezza adeguato siano conseguenza di una profonda analisi dei rischi che metta in luce le possibili criticità del Sistema

Documenti (Document) : che relativamente ad un sistema computerizzato comprendono sia l’insieme dei risultati che ad esempio descrivono le varie fasi del ciclo di vita progettuale di un Sistema e delle attività di supporto, sia le evidenze delle specifiche verifiche, Se il prodotto è complesso la stesura della documentazione può essere anche molto impegnativa soprattutto quando viene effettuata in modalità di reverse engineering

Attività di Test (Testing Activities): che riguarda i controlli e le prove sia di tipo statico, effettuati con modalità diverse sulla documentazione prodotta nelle varie fasi progettuali, sia di tipo dinamico sul prodotto informatico in funzione

2. LE DIFFERENZE FRA VALIDAZIONE ED ASSICURAZIONE

La Fig, 1, sintetizza, attraverso la rappresentazione di una piramide rovesciata, l’attuale impostazione delle pratiche di validazione di un Sistema computerizzato dove è preponderante l’attività di produzione della documentazione che va però a discapito di altre fasi, come l’Analisi Critica e la valutazione degli impatti sulla Sicurezza delle parti interessate: fasi che in realtà sono molto più importanti ai fini di determinare l’affidabilità di un Sistema informatico al servizio di un Dispositivo Medico.

Fig. 1

La Fig, 2, sintetizza invece, attraverso la rappresentazione di una piramide ordinaria, quale dovrebbe essere la dimensione e l’impegno necessari ad effettuare le stesse fasi però tese a dimostrare il grado di Qualità ed affidabilità di un Sistema Informatico

Fig. 2

Quindi concludendo possiamo confrontare tre definizioni a cui corrispondono altrettante attività e aspettative:

1 Verifica : garantisce che un Sistema Software sia stato progettato ed implementato in modo che risulti funzionante rispetto a quanto definito nei requisti progettuali (il prodotto è funzionante ). Questo attività viene eseguita attraverso la valutazione dei documenti progettuali , del codice e attraverso test dinamici

2 Validazione : garantisce che il Sistema Software sia stato progettato e realizzato sulla base delle aspettative del cliente / utilizzatore finale (il prodotto è quello corretto ) . Questo aspetto viene valutato attraverso la verifica di determinate caratteristiche in relazione a specifiche momenti dell’intervento del Sistema Software (IQ,OQ,PQ,MQ, CQ ecc.) a partire sempre e comunque dalle Specifiche dei requisiti utente

3 Assicurazione : garantisce che il Sistema Software sia stato progettato e realizzato sulla base delle aspettative del cliente /utilizzatore e che sia affidabile e congruente soprattutto, nel caso di dispositivi medici, per quanto riguarda la sicurezza del paziente. Questo aspetto viene valutato a partire da come è stata effettuata la fase di analisi che ha portato a concepire il prodotto e successivamente lungo tutto il ciclo di vita del software, ma può toccare anche aspetti che riguardano la sostenibilità economica, l’utilizzo di fornitori adeguati, la capacità di effettuare una valida manutenzione post vendita