4 minuti di lettura
Con l'evoluzione della tecnologia, il settore sanitario è diventato propenso a integrare il software con i dispositivi medici per incorporare automazione e precisione nella previsione, diagnosi, prevenzione, trattamento e gestione delle condizioni di salute. La FDA statunitense ha riconosciuto da tempo il ruolo che il software può svolgere a vantaggio del funzionamento dei dispositivi medici, ma non ha ancora emanato linee guida o regole concrete che avrebbero potuto agevolare i ricercatori del settore nel compiere progressi verso la salute digitale.
Il 4 novembre 2021, l'FDA statunitense ha pubblicato una bozza di guida sul "contenuto delle richieste di autorizzazione all'immissione sul mercato per le funzioni software dei dispositivi", dando un'idea precisa agli sponsor responsabili della preparazione del documento e delle informazioni da includere. Le informazioni fornite dagli sponsor sono importanti perché l'FDA possa valutare il software del dispositivo che esegue una o più funzioni e garantire la sicurezza e l'efficacia durante il suo ciclo di vita. La nuova guida è una raccomandazione e una versione in bozza sulle funzioni del software dei dispositivi medici che l'FDA si è impegnata a pubblicare in sostituzione del documento guida di 15 anni fa "Guidance for the content of pre-market submission for the software contained in Medical device" pubblicato nel maggio 2005. L'FDA ha mantenuto aperta la finestra per i commenti e le discussioni in merito fino al 2 febbraio 2022.
In questa nuova versione, la FDA ha riconosciuto la modalità di associazione del software con un dispositivo medico e li ha ulteriormente differenziati in SaMD - Software come dispositivo medico e SiMD - Software in un dispositivo medico, come suddivisioni delle funzioni del software del dispositivo. Il software come dispositivo medico o SaMD è un software che svolge il compito di un dispositivo medico secondo la definizione di dispositivo medico di cui alla Sezione 201 (h) dell'FD&C Act, ma non è parte di un componente del dispositivo. Il software in SiMD, invece, come suggerisce il nome, fa parte del componente o dell'hardware del dispositivo medico utilizzato per registrare, controllare o visualizzare informazioni mediche o non mediche.
La bozza si concentra maggiormente sulle aspettative dell'FDA in merito alla preparazione dei documenti richiesti per la presentazione delle funzioni software dei dispositivi prima dell'immissione sul mercato. L'FDA ha definito chiaramente cosa si aspetta di vedere nei documenti che stabiliscono in modo solido le specifiche dei requisiti del software (SRS) e le specifiche di progettazione del software o del sistema (SDS). L'FDA enfatizza un approccio basato sul rischio durante la documentazione per la presentazione delle funzioni software dei dispositivi prima dell'immissione sul mercato. In base al livello di preoccupazione o al rischio associato all'uso previsto del dispositivo, il livello di documentazione deve variare in documentazione di base e documentazione avanzata. I punti chiave che ciascun livello di documentazione deve evidenziare per identificare il livello di rischio del software associato al dispositivo medico sono:
- La panoramica del software che dà un'idea degli ingressi e delle uscite
- Specifiche dei requisiti del software (SRS), che comprendono i dettagli dell'architettura del software con un diagramma schematico di tutti i moduli, le periferiche, i linguaggi di programmazione, il sistema operativo, la versione del compilatore, l'uso di qualsiasi software di shell e tutti i dettagli dell'interfaccia utente (UI/UX).
- Per gli sponsor che presentano una documentazione avanzata è necessario presentare le Specifiche di progettazione del software o del sistema (SDS), che contengono informazioni sul software fin dalla fase di progettazione. Mentre le SRS descrivono la funzione prevista del software, le SDS sono informazioni approfondite sulla metodologia di implementazione dei requisiti indicati nelle SRS. La SDS deve includere un progetto tecnico dettagliato con informazioni adeguate sull'utilità, sul funzionamento che ricalca la SRS, sulla necessità di assistenza per il funzionamento del software o sul fatto che si tratta di un sistema CAD addestrato costruito su modelli AI/ML.
- Secondo questa nuova bozza di linee guida, l'adesione agli standard di consenso volontario riconosciuti dal settore per le richieste di autorizzazione diventerà semplice e più in linea con le tendenze, le pratiche e le innovazioni del mercato della salute digitale. I dispositivi che richiedono una documentazione di base o avanzata devono essere conformi alla versione riconosciuta dalla FDA della norma ANSI/AAMI IEC 62304 Medical device software- Software lifecycle process. I documenti avanzati richiedono una descrizione aggiuntiva della configurazione completa con dettagli ancora più precisi sullo sviluppo del progetto e sul piano di manutenzione del ciclo di vita del software, per una maggiore chiarezza durante la revisione.
- In base all'analisi dei rischi secondo i requisiti della normativa sul sistema di qualità (21 CFR 820), devono essere incluse anche le informazioni relative alla sicurezza, come l'ambiente operativo, l'efficacia, l'accuratezza, il tempo di risposta, il tempo di ritardo, la coerenza, i limiti operativi e l'intervallo e qualsiasi valore di base o di soglia su cui il software deve operare. Deve essere menzionata l'esistenza di un sistema di vigilanza che tenga traccia dei dati registrati nella memoria del dispositivo o nel sistema di archiviazione.
- Nell'ambito del ciclo di vita del software, la verifica e la convalida del software sono essenziali e si ottengono testando i componenti del software a livello di sistema o di integrazione. Ciò è obbligatorio per una migliore documentazione. Inoltre, è necessario descrivere i protocolli di test e i risultati attesi o osservati per stabilire lo stato di "pass/fail" del sistema.
- Qualsiasi coinvolgimento di anomalie non risolte come bug, difetti che possono influire sulle prestazioni della funzione software deve essere identificato e classificato in base alla tassonomia dei difetti secondo la Classificazione dei difetti nel software sanitario di ANSI/AAMI SW91.
La documentazione avanzata deve essere presentata per i dispositivi che sono prodotti combinati o classificati come dispositivi di Classe III ad alto rischio o per una funzione software destinata a essere utilizzata nelle applicazioni di donazione e trasfusione di sangue che effettua la valutazione della compatibilità tra donatore e ricevente. I dispositivi che richiedono una documentazione speciale devono seguire i requisiti di documentazione avanzata. La documentazione di base deve contenere l'analisi dei rischi, la riduzione dei rischi e i rapporti di giustificazione dei rischi.
Secondo gli impegni del MDUFA IV, l'Agenzia dovrebbe pubblicare la guida finale entro 12 mesi dalla fine del periodo di commento della bozza. La FDA ha dichiarato di voler ospitare un webinar il 16 dicembre 2021 per i produttori di dispositivi medici, i ricercatori del settore della salute digitale e i professionisti per discutere la bozza di guida.
Per saperne di più sulla presentazione pre-market delle funzioni software dei dispositivi, rivolgetevi a un esperto di regolamentazione regionale come Freyr. Rimanete informati. Rimanete conformi.
