LA MARCATURA MDR PER I DISPOSITIVI MEDICI SOFTWARE

Negli ultimi tempi sono state sviluppate e commercializzate tantissime Applicazioni Software che, pur non essendo incorporate in nessun dispositivo medico, presentano funzionalità che le fanno rientrare a pieno titolo come Dispositivi Medici.

Sono quelle tipologie di applicazioni software, classificate come SaMD (Software as Medical Device), come ad esempio moltissime APP, che, pur vivendo di vita propria e non essendo collegate ad alcun dispositivo, possono essere considerate a pieno titolo strumenti per effettuare Diagnosi, Terapie e Monitoraggi di determinate malattie o per una certa categoria di pazienti

Per tale motivo, come per le altre tipologie di Dispositivi Medici, prima di essere commercializzate, tali applicazioni debbono essere marcate CE sulla base del Regolamento Europeo 2017/745/UE più conosciuto come MDR (Medical Device Regulation).

È quindi compito del Fabbricante adoperarsi per ottenere la conformità al Regolamento MDR. Il regolamento richiede però in modo esplicito che tale conformità sia sistematicamente garantita nel tempo dal Fabbricante attraverso uno specifico  Sistema di Gestione per la qualità . Naturalmente, sarebbe auspicabile, che tale specifico Sistema di Gestione fosse pienamente integrato ad altri Sistemi di gestione per la qualità, eventualmente già adottati dall’Organizzazione del fabbricante,  come la ISO 13485:2016 o la ISO 9001:2015

1. ANALISI DEL DISPOSITIVO

Prima di affrontare il percorso di Marcatura di una Applicazione Software è necessario stabilire se tale Applicazione  è effettivamente un SaMD (Software as Medical Device) come riportato nel mio precedente articolo LE APPLICAZIONI SOFTWARE COME DISPOSITIVI MEDICI

Infatti non tutte le Applicazioni Software che operano a vario titolo nel campo medicale possono essere considerate a tutti gli effetti un DM. Ad esempio una applicazione che permette di archiviare elettronicamente le cartelle cliniche non può essere qualificata come dispositivo medico in quanto sostituisce semplicemente la cartella clinica cartacea dei  pazienti e quindi non soddisfa la definizione di dispositivo medico.

Inoltre a volte un Sistema Software complesso può essere formato da diversi moduli dove  alcuni hanno uno scopo medico e altri no. Quindi é obbligo del fabbricante effettuare un’analisi preventiva per stabilire quali tra essi siano effettivamente qualificabili come DM e quindi necessitino della marcatura CE grazie alla loro conformità all’ MDR

C’è anche da tener presente che con l’introduzione di tale nuovo Regolamento MDR, molte applicazioni software sono diventate MD e molte altre sono state classificate in classi superiori : questa evoluzione spesso è dovuta anche a fronte di modifiche o aggiunte di funzionalità che hanno trasformato in senso medicale un prodotto che prima non lo era.

2. CLASSE DEL DISPOSITIVO

Una volta stabilito che l’ applicazione rientra in un Dispositivo Medico, è necessario determinare  quale sia la sua classe di appartenenza fra quelle individuate dal Regolamento MDR e cioè le classi I,IIa,IIb, III : sulla base di tale scelta si impongono percorsi di raggiungimento della conformità al Regolamento che possono essere fra loro diversi.

Il regolamento MDR nell’allegato VIII stabilisce i principali criteri grazie ai quali è possibile classificare una Applicazione SaMD

• Il software destinato a fornire informazioni utilizzate per prendere decisioni a fini diagnostici o terapeutici rientra nella classe IIa a meno che tali decisioni abbiano effetti tali da poter causare:
  • il decesso o un deterioramento irreversibile delle condizioni di salute di una persona, nel qual caso rientra nella classe III
  • un grave deterioramento delle condizioni di salute di una persona o un intervento chirurgico, nel qual caso rientra nella classe IIb
• Il software destinato a monitorare i processi fisiologici rientra nella classe IIa, a meno che sia destinato a monitorare i parametri fisiologici vitali, ove la natura delle variazioni di detti parametri sia tale da poter creare un pericolo immediato per il paziente, nel qual caso rientra nella classe IIb
• Ogni altra applicazione SaMD rientra nella classe I

In questo articolo affrontiamo le principali fasi del percorso della Marcatura CE MDR per le Applicazioni software della classe IIa che è la classe più comune per i software SaMD.

3. RESPONSABILITÀ

Il primo passo da affrontare è quello della nomina di una persona responsabile del rispetto della normativa.

Tale persona deve avere, come richiede in modo esplicito l’MDR, una adeguata formazione, competenza  ed esperienza nel settore dei dispositivi medici : in particolare, nel caso specifico delle Applicazioni SaMD tali caratteristiche dovrebbero estendersi, per quanto possibile, anche agli  aspetti software.

Il ruolo di tale persona potrebbe essere assimilabile a quello tipico del Responsabile della Qualità per lo specifico Sistema che permette la gestione dei processi per la marcatura : naturalmente tale responsabile può coincidere, come quasi sempre accade nelle piccole realtà, con il Responsabile della Qualità del più generale Sistema di gestione, ove presente e se soddisfa ai requisiti richiesti dall’ MDR.

4. PROCEDURE DI VALUTAZIONE DELLA CONFORMITÀ

Il secondo passo è quello di scegliere quale procedura utilizzare per ottenere la conformità necessaria per raggiungere la marcatura CE dell’Applicazione SaMD

Si tenga comunque sempre presente che nel caso di Dispositivi di classe IIa, incluse quindi molte delle Applicazioni software SaMD, è sempre necessario l’intervento di un Ente di Notifica

Per questa classe di dispositivi il Regolamento MDR prevede tre modalità alternative fra di loro equipollenti : vediamo come potranno essere applicate nello specifico caso di Applicazioni Software SaMD.

MODALITÀ A :   valutazione della conformità basata su un  Sistema di Gestione per la Qualità  e sulla documentazione tecnica

In questa modalità:

1. All’interno dell’azienda del Fabbricante deve essere implementato  un Sistema di Gestione per la Qualità (meglio se conforme alla normativa di settore ISO 13485), anche se non formalmente certificato, che abbia nel proprio campo di applicazione anche la progettazione e sviluppo di prodotti software in ambito medicale
2. Deve essere realizzata, per la specifica Applicazione SaMD la  Documentazione Tecnica (Fascicolo Tecnico) contenente gli argomenti di cui allegati II,III del Regolamento oltre a descrivere le modalità di rispetto delle  Garanzie Generali richieste dall’allegato I con particolare riguardo alla Gestione dei Rischi

Per questo tipo di modalità  l’Organismo Notificato effettua:

1. gli audit necessari al Sistema di Gestione per la Qualità con particolare riguardo alla sua applicazione al Software SaMD in questione.
2. la valutazione della documentazione tecnica relativa all’applicazione software per verificarne la conformità ai requisiti dell’ MDR

MODALITÀ B :  valutazione della conformità basata sulla Garanzia di Qualità della Produzione  

Nel caso in cui l’organizzazione non disponga di un Sistema di gestione completo per la Qualità per la realizzazione di Applicazioni  Software medicali il Regolamento MDR richiede che :

1. analogamente alla modalità precedente la disponibilità della Documentazione Tecnica (Fascicolo Tecnico) relativa all’Applicazione SaMD
2. l’esistenza di un Sistema di Garanzia di qualità dei processi di produzione

Ora, poiché nel caso di applicazioni software non esiste una netta distinzione fra le fasi di progettazione e quelle di produzione (come invece accade nella maggior parte dei manufatti) ma tutto è considerato progettazione tranne la duplicazione del codice, questo implica che l’organizzazione deve dotarsi di un sistema di procedure che descrivano le fasi pertinenti ed appropriate del Ciclo di Vita del Software utilizzato e delle attività di supporto e che siano conformi ad esempio ai capitoli 7.3 della ISO 13485 :2016 oppure 8.3 della ISO 9001:2015

Per questo tipo di modalità  l’Organismo Notificato effettua, :

1. Una verifica del  prodotto software nella release corrente per valutarne la conformità con  il corrispondente Fascicolo tecnico
2. Una valutazione del Sistema di garanzia per la Qualità

MODALITÀ C :  valutazione della conformità sulla verifica di ogni singolo  prodotto 

Nel caso infine in cui l’organizzazione non disponga per la realizzazione di applicazioni SaMD, né di un Sistema di gestione completo né di un Sistema ridotto alla sola fabbricazione, il Regolamento MDR richiede  la disponibilità della Documentazione Tecnica (Fascicolo Tecnico) relativa all’Applicazione SaMD

L’ Organismo notificato effettua una valutazione  di ogni prodotto software prima del suo rilascio attraverso il confronto con la  documentazione tecnica

Teniamo inoltre comunque presente che:

1. Per ogni modifica significativa della Applicazione SaMD ( che ad esempio coinvolga la sicurezza dei pazienti/utilizzatori o intervenga su determinate prestazioni funzionali) il fabbricante deve comunque interpellare l’ente di notifica il quale potrebbe decidere anche di effettuare una verifica supplettiva
2. Indipendentemente dalla modalità prescelta l’organismo notificato oltre al ciclo ordinario di verifiche di sorveglianza, compie, almeno una volta ogni cinque anni, un audit senza preavviso negli stabilimenti del fabbricante e, se del caso, dei suoi fornitori e/o subfornitori come potrebbero essere, ad esempio, coloro che sviluppano il prodotto, del tutto o in parte, in outsourcing  o che eseguono alcune fasi del ciclo di vita come ad esempio Test Funzionali indipendenti

5. REGISTRAZIONE DEI DISPOSITIVI SOFTWARE

Ogni fabbricante di Applicazione SaMD, nella veste di operatore economico, dovrà registrare la propria organizzazione  e successivamente Registrare ogni  applicazione software che intende immettere sul mercato come DM in una banca dati europea denominata  EUDAMED

Questo comporta che, come ogni Dispositivo Medico, anche un’ Applicazione SaMD, deve essere identificata in modo univoco attraverso un Sistema Unificato di Codifica che viene opportunamente assegnato da un ente autorizzato.

Tale identificativo, detto UDI, è una modalità che è conforme agli standard riconosciuti  a livello internazionale  e serve ad assicurare la tracciabilità e la rintracciabilità dei dispositivi medici nel caso ad esempio di una  evenienza avversa. Tale identificazione è formata da due componenti:

1. UDI-DI che è un codice numerico o alfanumerico unico, specifico di un modello di dispositivo ed è anche usato come “chiave di accesso” alle informazioni memorizzate nella banca dati Europea.
2. UDI-PI che è un codice numerico o alfanumerico che identifica la specifica unità di produzione del dispositivo (es. il numero di serie, il numero del lotto/della partita, la fabbricazione ecc.)

Nel caso delle applicazioni SaMD la loro identificazione è soggetta alle seguenti regole:

1. Ad ogni nuova versione del SaMD deve essere associato un nuovo identificativo UDI.
2. Ogni volta che vi sia stata una modifica significativa (revisione di tipo maggiore) siamo in presenza di un prodotto nuovo e quindi deve essere identificato con un nuovo UDI-DI. Per modifiche significative si intendono quelle che riguardano
   1. le prestazioni e l’efficacia originali
   2. la sicurezza per il paziente e l’utilizzatore oppure l’uso previsto del SaMD

Queste modifiche possono includere algoritmi nuovi o modificati, strutture di database, la piattaforma operativa,        l’architettura, nuove interfacce utente o nuovi canali per l’interoperabilità ecc.

3. Ogni volta invece che viene effettuata una modifica minore la nuova revisione dovrebbe essere identificata               attraverso un nuovo UDI-PI.

Queste modifiche possono riguardare correzioni di errori, miglioramenti dell’usabilità non collegati però alla               sicurezza fisica, interventi sulla sicurezza delle informazioni, miglioramenti dell’efficienza ecc.

E’ quindi molto importante che il fabbricante definisca una chiara Politica per la Manutenzione del software ed un relativo Piano di Manutenzione che permettano, ad esempio, di stabilire i criteri per i quali una modifica sia considerata di tipo maggiore o minore relativamente alla specifica Applicazione software SaMD.

La banca dati europea EUDAMED  è in via di completamento e si prevede sia completamente operativa nel 2023. Pertanto nel frattempo si dovranno applicare, per la registrazione, quanto previsto dalle precedenti direttive come  la 90/385/CEE e la 93/42/CEE.

6. DICHIARAZIONE DI CONFORMITÀ E MARCATURA

Una volta appurata la conformità ai requisiti del Regolamento MDR per ogni applicazione software SaMD rilasciata è necessario associare una Dichiarazione di Conformità e il relativo marchio CE sulla base delle indicazioni fornite dal Regolamento stesso negli allegati IV e V. Tale dichiarazione di conformità dovrà essere rilasciata al cliente e sul Dispositivo Medico dovrà essere applicata la marcatura  CE.

Tutte le recenti  Applicazioni Software non vengono però generalmente rilasciate in una custodia tipo CD-ROM sulla quale applicare il marchio, ma con modalità elettronica (es. download di una App da uno store) .Pertanto il modo migliore è che tali informazioni compaiano ad esempio  all’attivazione della applicazione e siano comunque  presenti in una opportuna pagina facilmente raggiungibile da ogni punto dell’applicazione stessa. Tali elementi informativi dovranno essere riportati anche all’interno dei manuali d’uso cartacei e/o on-line.

7. LA VALUTAZIONE CLINICA

Il regolamento MDR richiede che la dimostrazione della Conformità ai Requisiti generali di Sicurezza e prestazione del DM debba comprendere una Valutazione Clinica.

Per Valutazione Clinica si intende un processo sistematico e programmato atto a produrre, raccogliere, analizzare e valutare in maniera continuativa i dati clinici relativi a un dispositivo allo scopo di verificarne la sicurezza, le prestazioni e i benefici clinici quando è utilizzato come previsto dal fabbricante.

Per quanto riguarda tale argomento FDA ha emesso una specifica linea guida che fornisce indicazioni per la gestione delle attività allorquando si sta trattando di una  Applicazioni Software SaMD : tali indicazioni sono molto utili anche per ottenere la conformità al Regolamento MDR.

Sulla base di tale linea guida gli aspetti da considerare per una corretta gestione di tale processo sono :

1. La verifica di una corretta Associazione Clinica  : in cui si deve accertare che esista una corretta associazione tra i dati prodotti dalla applicazione  SaMD e la situazione clinica all’interno della quale opera  l’applicazione software. Si valuta in pratica la confidenza sulla validità dei dati prodotti dalla Applicazione SaMD nella situazione sanitaria e nelle condizioni cliniche previste. Tale valutazione comprende :

• • Lo stato ambientale : che riguarda alcuni fattori quali quello Logistico (ad esempio il posizionamento delle postazioni di lavoro dove è attivo il SaMD), Funzionale (che riguarda la capacità dell’Applicazione di intercettare il corretto flusso di lavoro), di Conoscenza (che valuta la capacità di utilizzo da parte degli operatori) e di Comunicazione. Teniamo presente che una situazione ambientale  inadeguata potrebbe indurre diagnosi e trattamenti errati da parte degli operatori / utenti dell’applicazione software

• • Lo stato tecnologico : che riguarda l’ambiente tecnologico all’interno del quale opera l’applicazione SaMD in termini di Hardware, Software, reti, interconnessioni, Internet ecc. In particolare è importante verificare le potenziali situazioni critiche derivanti da interruzioni del servizio, manutenzione o aggiornamenti dei sistemi, guasti della piattaforma su cui è stato installato il SaMD

• • Lo stato della Sicurezza : che riguarda particolari fattori relativi alla sicurezza delle informazioni che possono influenzare l’integrità, la disponibilità o l’accessibilità delle informazioni fornite dalla SaMD necessarie per una diagnosi o un trattamento corretti. La sicurezza delle informazioni richiede l’identificazione e l’implementazione di metodi sicuri (e formalizzati) per archiviare, convertire e / o trasmettere dati

2. La Convalida Analitica :  che serve a determinare se l’Applicazione Software  SaMD elabora correttamente i dati di input per generare dati di output accurati, affidabili, precisi e riproducibili . Serve in pratica a dimostrare che l’Applicazione software SaMD é conforme alle esigenze dell’utente e agli usi previsti

Le caratteristiche evidenziate nella  Associazione Clinica e nella Convalida Clinica devono essere prese in considerazione fin dalle prime fasi progettuale evidenziandole ad esempio nelle Specifiche dei Requisiti Software della applicazione SaMD. Successivamente andranno verificate attraverso opportune sessioni di validazione DQ e, presso l’utilizzatore finale, attraverso operazioni di Validazione IQ,OQ,PQ in fase di prima installazione

Tali attività di validazione dovrebbero essere comunque opportunamente ripetute ad ogni upgrade significativo della Applicazione stessa

3.La Validazione Clinica : Deve poter misurare l’impatto positivo dell’Applicazione SaMD sulla salute di un individuo o di una popolazione.  Tale impatto può essere verificato ad esempio:

• • facendo riferimento a dati esistenti provenienti da studi condotti per lo stesso uso previsto;
  • facendo riferimento a dati esistenti provenienti da studi condotti per un uso previsto diverso, in cui l’estrapolazione di tali dati può essere giustificata;
  • attraverso la generazione di nuovi dati clinici

8. SORVEGLIANZA POST-COMMERCIALIZZAZIONE

Per ogni dispositivo i fabbricanti provvedono a pianificare, istituire, documentare, applicare, mantenere e aggiornare un sistema di sorveglianza post-commercializzazione in modo adeguato alla tipologia di dispositivo.

Tale Sistema di sorveglianza deve essere parte integrante del Sistema di gestione  che garantisce il rispetto sistematico dell’ MDR ed é  finalizzato a:

• raccogliere, registrare ed analizzare attivamente e sistematicamente i pertinenti dati sulla qualità, le prestazioni e la sicurezza di un dispositivo durante la sua intera vita;
• a trarre le necessarie conclusioni;
• a determinare, attuare e monitorare le eventuali azioni preventive e correttive.

Tale attività di sorveglianza è regolata da uno specifico PIANO DI SORVEGLIANZA, mentre periodicamente (almeno ogni 2 anni per la classe IIa) viene stilato un RAPPORTO  DI AGGIORNAMENTO SULLA SICUREZZA («PSUR») che sintetizza i risultati e le conclusioni delle analisi dei dati raccolti nell’ambito della sorveglianza post-commercializzazione unitamente a una motivazione e a una descrizione delle eventuali azioni preventive e correttive adottate.

9 . SEGNALAZIONI DI INCIDENTI 

Anche nel caso di Applicazioni SaMD, come per ogni altro dispositivo, è compito del Fabbricante , segnalare alle pertinenti autorità competenti qualsiasi incidente grave relativo a dispositivi messi a disposizione sul mercato.

Inoltre attraverso il Sistema Elettronico EUDAMED l’organizzazione  segnala ogni aumento statisticamente significativo della frequenza o della gravità di incidenti che hanno comportato o possono comportare rischi per la salute o la sicurezza di pazienti, utilizzatori o altre persone.

GRAZIE PER L’ATTENZIONE