,
4 minuti di lettura
Con l'evoluzione della tecnologia, il settore sanitario è diventato desideroso di integrare il software con i dispositivi medici per incorporare automazione e accuratezza nella previsione, diagnosi, prevenzione, trattamento e gestione delle condizioni di salute. La US FDA aveva da tempo riconosciuto il ruolo che il software può svolgere a beneficio del funzionamento dei dispositivi medici, ma doveva ancora elaborare linee guida o regole concrete che avrebbero potuto facilitare i ricercatori del settore nel fare progressi verso la salute digitale.
Il 4 novembre 2021, la US FDA ha pubblicato una bozza di guida sul ‘contenuto delle richieste di pre-commercializzazione per le funzioni software dei dispositivi’, fornendo un'idea chiara agli sponsor responsabili della preparazione del documento e delle informazioni da includere. Queste informazioni fornite dagli sponsor sono importanti affinché la FDA possa valutare il software del dispositivo che esegue una o più funzioni e garantire sicurezza ed efficacia durante tutto il suo ciclo di vita. La nuova guida è una raccomandazione e una bozza sulle funzioni software dei dispositivi medici che la FDA si è impegnata a pubblicare in sostituzione del documento di guida di 15 anni ‘Guidance for the content of pre-market submission for the software contained in Medical device’ rilasciato a maggio 2005. Hanno mantenuto aperta la finestra per i feedback e qualsiasi discussione in merito è aperta 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 sottocategorie delle funzioni software dei dispositivi. Il Software come dispositivo medico o SaMD è un software che svolge autonomamente il compito di un dispositivo medico secondo la definizione di dispositivo medico menzionata nella Sezione 201 (h) del FD&C Act, ma non fa parte di un componente del dispositivo. D'altra parte, il software in SiMD, come suggerisce il nome, fa parte del componente del dispositivo medico o dell'hardware utilizzato per registrare, controllare o visualizzare informazioni mediche o non mediche.
La bozza si concentra maggiormente sulle aspettative della FDA riguardo alla preparazione dei documenti richiesti per le presentazioni pre-commercializzazione delle funzioni software dei dispositivi. Hanno elaborato una chiara comprensione di ciò che si aspettano di vedere nei documenti che stabiliscono in modo robusto la Specificazione dei Requisiti Software (SRS) e le Specificazioni di Progettazione del Software o del Sistema (SDS). La FDA enfatizza un approccio basato sul rischio durante la documentazione per le presentazioni pre-commercializzazione delle funzioni software dei dispositivi. In base a questo livello di preoccupazione o al rischio associato all'uso previsto del dispositivo, il livello di documentazione dovrebbe variare tra documentazione di base e documentazione avanzata. I punti chiave che ogni livello di documentazione richiede di evidenziare per identificare il livello di preoccupazione del software associato al dispositivo medico sono:
- La panoramica del software che fornisce un'idea degli input e degli output
- Specifiche dei Requisiti del Software (SRS), che includono i dettagli dell'architettura del software con un diagramma schematico di tutti i moduli, periferiche, linguaggi di programmazione, sistema operativo, versione del compilatore, l'uso di qualsiasi software shell e qualsiasi dettaglio UI/UX
- Le Specifiche di Progettazione del Software o del Sistema (SDS), che coprono le informazioni sul software fin dalla fase di progettazione, sono richieste per gli sponsor che presentano documentazione migliorata. Mentre l'SRS descrive la funzione prevista del software, l'SDS fornisce informazioni approfondite sulla metodologia di implementazione dei requisiti menzionati nell'SRS. L'SDS deve includere un dettaglio completo della progettazione tecnica con informazioni adeguate sull'utilità e sul funzionamento che si ricollega all'SRS, indicando se è necessaria assistenza per operare il software o se si tratta di un sistema CAD addestrato basato su modelli di AI/ML.
- L'aderenza agli standard di consenso volontari riconosciuti dall'industria per le presentazioni normative diventerebbe facile e più in linea con le attuali tendenze, pratiche e innovazioni del mercato della salute digitale, secondo questa nuova bozza di linea guida. I dispositivi che richiedono documentazione di base e avanzata devono entrambi essere conformi alla versione riconosciuta dalla FDA di ANSI/AAMI IEC 62304 Software per dispositivi medici - Processo del ciclo di vita del software. I documenti avanzati richiedono una descrizione aggiuntiva della configurazione completa con dettagli ancora maggiori sul piano di sviluppo della progettazione e di manutenzione nel ciclo di vita del software per una maggiore chiarezza durante la revisione.
- Sulla base dell'analisi dei rischi, come previsto dai requisiti delle Normative sui Sistemi di Qualità (21 CFR 820), devono essere incluse anche informazioni relative alla sicurezza, quali l'ambiente operativo, l'efficacia, l'accuratezza, il tempo di risposta, il tempo di ritardo, la coerenza, i limiti e l'intervallo operativo, e qualsiasi valore di base o di soglia richiesto dal software per funzionare. Deve essere menzionata la previsione di un sistema di vigilanza per tracciare i dati registrati utilizzando la memoria o il sistema di archiviazione del dispositivo.
- Come parte del ciclo di vita del software, la verifica e la convalida del software sono essenziali, ottenute testando i componenti del software a livello di sistema o di integrazione. Ciò è obbligatorio per una documentazione migliorata. Inoltre, dovrebbe essere discussa anche la descrizione dei protocolli di test insieme ai risultati attesi o osservati per stabilire lo stato di superamento/fallimento del sistema.
- Qualsiasi coinvolgimento di anomalie irrisolte come bug, difetti che possono influenzare le prestazioni della funzione software dovrebbe essere identificato e classificato in base alla tassonomia dei difetti secondo la Classificazione dei difetti nel software sanitario ANSI/AAMI SW91.
Per i dispositivi che sono prodotti combinati, o classificati come dispositivi ad alto rischio di Classe III, o funzioni software destinate all'uso in applicazioni di donazione e trasfusione di sangue che eseguono la valutazione di compatibilità tra donatore e ricevente, è richiesta la presentazione di documentazione avanzata. I dispositivi che richiedono documentazione speciale devono seguire i requisiti di documentazione avanzata. La documentazione di base dovrebbe includere brevi rapporti sull'analisi dei pericoli, sulla mitigazione dei pericoli e sulla giustificazione del rischio.
Secondo gli impegni MDUFA IV, l'Agenzia dovrebbe pubblicare la guida finale entro 12 mesi dalla fine del periodo di commento della bozza. La FDA ha dichiarato che ospiterà un webinar il 16 dicembre 2021 per i produttori di dispositivi medici, i ricercatori del settore della salute digitale e i professionisti per discutere questa bozza di guida.
Per saperne di più sulla presentazione pre-commercializzazione delle funzioni software dei dispositivi, contattate un esperto normativo regionale come Freyr. Rimanete informati. Rimanete conformi.
