Presentazione pre-commercializzazione delle funzioni del software dei dispositivi – Analisi della bozza di linee guidaFDA US

Con l'evoluzione della tecnologia, il settore sanitario ha iniziato a puntare sull'integrazione di software e dispositivi medici per automatizzare e rendere più precise la previsione, la diagnosi, la prevenzione, il trattamento e la gestione delle condizioni di salute. LaFDA US FDA da tempo riconosciuto il ruolo che il software può svolgere a vantaggio del funzionamento dei dispositivi medici, ma non ha ancora elaborato linee guida o norme concrete che possano aiutare i ricercatori del settore a compiere progressi nel campo della sanità digitale.

Il 4 novembre 2021, laFDA US FDA una bozza di linee guidasul"contenuto delle richieste di autorizzazione alla commercializzazione per le funzioni del software dei dispositivi", fornendo indicazioni precise agli sponsor responsabili della preparazione del documento e delle informazioni da includere. Le informazioni fornite dagli sponsor sono importanti per FDA alla FDA valutare il software del dispositivo che esegue una o più funzioni e di garantirne la sicurezza e l'efficacia durante tutto il suo ciclo di vita. La nuova guida è una raccomandazione e una bozza sulle funzioni del software dei dispositivi medici che la FDA impegnata a pubblicare in sostituzione del documento guida "Guida al contenuto delle richieste di autorizzazione alla commercializzazione per il software contenuto nei dispositivi medici" pubblicato nel maggio 2005 e risalente a 15 anni fa. È stata mantenuta la finestra per i feedback e qualsiasi discussione in merito è aperta fino al 2 febbraio 2022.

In questa nuova versione, la FDA la modalità di associazione del software con un dispositivo medico e li ha ulteriormente differenziati in SaMD Software as a medical device SiMD - Software in un dispositivo medico, come suddivisioni delle funzioni del software del dispositivo. Software as a medical device SaMD un software che svolge di per sé il compito di un dispositivo medico secondo la definizione di dispositivo medico di cui alla Sezione 201 (h) del FD&C Act, ma non è parte integrante del dispositivo. D'altra parte, il software in SiMD, 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 della FDA preparazione dei documenti richiesti per la presentazione pre-commercializzazione delle funzioni del software dei dispositivi. È stata fornita una chiara comprensione di ciò che ci si aspetta di vedere nei documenti che stabiliscono in modo rigoroso le specifiche dei requisiti software (SRS) e le specifiche di progettazione del software o del sistema (SDS). La FDA un approccio basato sul rischio nella documentazione per la presentazione pre-commercializzazione delle funzioni software dei dispositivi. In base al livello di preoccupazione o al rischio associato all'uso previsto del dispositivo, anche il livello di documentazione dovrebbe variare tra documentazione di base e documentazione avanzata. I punti chiave che ogni livello di documentazione deve evidenziare per identificare il livello di preoccupazione 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).
• Gli sponsor che presentano una documentazione avanzata devono fornire le specifiche di progettazione del software o del sistema (SDS) che coprono le informazioni relative al software fin dalla fase di progettazione. Mentre le SRS descrivono la funzione prevista del software, le SDS forniscono informazioni approfondite sulla metodologia di implementazione dei requisiti menzionati nelle SRS. Le SDS devono includere dettagli tecnici completi sulla progettazione con informazioni adeguate sull'utilità, sul funzionamento che fa riferimento alle SRS, sulla necessità o meno di assistenza per l'utilizzo del software o se si tratta di un sistema CAD addestrato basato suML
• Il rispetto degli standard consensuali volontari riconosciuti dal settore per le richieste di autorizzazione diventerebbe più semplice e più in linea con le attuali tendenze, pratiche e innovazioni del mercato della sanità digitale, secondo questa nuova bozza di linea guida. I dispositivi che richiedono una documentazione di base e avanzata devono entrambi essere conformi alla versione FDA della norma 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 più approfonditi sullo sviluppo del progetto e sul piano di manutenzione nel ciclo di vita del software, per una maggiore chiarezza durante la revisione.
• Sulla base dell'analisi dei rischi secondo i requisiti delle normative sul sistema di qualità (21 CFR 820), devono essere incluse anche le 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 di funzionamento, nonché qualsiasi valore di base o soglia necessario al funzionamento del software. Deve essere menzionata la presenza di qualsiasi sistema di vigilanza per tracciare i dati registrati utilizzando la memoria del dispositivo o il 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.

In base agli impegni assunti nell'ambito dell'MDUFA IV, l'Agenzia dovrebbe pubblicare la versione definitiva delle linee guida entro 12 mesi dalla fine del periodo di consultazione sulla bozza. La FDA annunciato che il 16 dicembre 2021 terrà un webinar rivolto ai produttori di dispositivi medici, ai ricercatori del settore della sanità digitale e ai professionisti del settore per discutere la bozza delle linee guida.

Per ulteriori informazioni sulla presentazione pre-commercializzazione delle funzioni del software dei dispositivi, reach esperto regionale in materia di normative come Freyr. Rimanete informati. Rimanete conformi.