4 minuti di lettura
Con l’evoluzione della tecnologia, il settore sanitario ha iniziato a puntare sull’integrazione del software con i dispositivi medici per garantire automazione e precisione nella previsione, nella diagnosi, nella prevenzione, nel trattamento e nella gestione delle patologie. La Commissione per la sicurezza dei dispositivi medici ( US )FDA aveva da tempo riconosciuto il ruolo che il software può svolgere a vantaggio del funzionamento dei dispositivi medici, ma non aveva ancora elaborato linee guida o norme concrete che potessero aiutare i ricercatori del settore a compiere progressi verso la sanità digitale.
Il 4 novembre 2021, l’ US FDA ha pubblicato una bozza di linee guida sul“contenuto delle richieste di autorizzazione pre-commercializzazione relative alle funzioni del software dei dispositivi”, fornendo indicazioni chiare ai richiedenti incaricati di redigere il documento e sulle informazioni da includere. Tali informazioni fornite dai richiedenti sono fondamentali affinché l’ FDA possa valutare il software del dispositivo che esegue una o più funzioni e garantire la sicurezza e l’efficacia per tutto il suo ciclo di vita. La nuova guida è una raccomandazione e una bozza relativa alle funzioni del software dei dispositivi medici che l’ FDA e si è impegnata a pubblicare in sostituzione del documento di orientamento risalente a 15 anni fa, intitolato «Linee guida sul contenuto delle domande di autorizzazione all’immissione in commercio relative al software contenuto nei dispositivi medici», pubblicato nel maggio 2005. È stato mantenuto il periodo dedicato ai commenti e qualsiasi discussione in merito rimarrà aperta fino al 2 febbraio 2022.
In questa nuova versione, l’ FDA e ha riconosciuto la modalità di associazione del software a 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 del software del dispositivo. Il “Software as a medical device” ( SaMD ) è un software che svolge autonomamente la funzione di un dispositivo medico secondo la definizione di dispositivo medico di cui alla Sezione 201 (h) del FD&C Act, ma non costituisce una parte integrante del dispositivo stesso. D’altra parte, il software SiMD, come suggerisce il nome, è parte integrante 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 (FDA) riguardo alla preparazione della documentazione richiesta per le richieste di autorizzazione all’immissione in commercio relative alle funzioni del software dei dispositivi medici. L’agenzia ha fornito una chiara definizione di ciò che si aspetta di trovare nei documenti che definiscono in modo solido le Specifiche dei Requisiti del Software (SRS) e le Specifiche di Progettazione del Software o del Sistema (SDS). La bozza “ FDA ” (Linee guida per la documentazione delle specifiche di progettazione del software per dispositivi medici) sottolinea l’importanza di un approccio basato sul rischio nella documentazione relativa alle richieste di autorizzazione all’immissione in commercio delle funzioni software dei dispositivi. In base al livello di rischio associato all’uso previsto del dispositivo, il livello di documentazione dovrebbe variare tra 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:
- Panoramica del software che offre un'idea degli input e degli output
- Specifiche dei requisiti software (SRS), che includono i dettagli relativi all'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'eventuale utilizzo di software shell e qualsiasi dettaglio relativo all'interfaccia utente (UI) e all'esperienza utente (UX)
- Per i committenti che presentano una documentazione approfondita è richiesta una Specifica di Progettazione del Software o del Sistema (SDS) che copra le informazioni relative al software fin dalla fase di progettazione. Mentre l’SRS descrive la funzionalità prevista del software, l’SDS fornisce informazioni approfondite sulla metodologia di implementazione dei requisiti menzionati nell’SRS. L’SDS deve includere una descrizione tecnica dettagliata e completa, con informazioni adeguate sull’utilità e sul funzionamento, che facciano riferimento all’SRS, indicando se è necessaria assistenza per utilizzare il software o se si tratta di un sistema CAD avanzato basato su modelli di intelligenza artificiale (AI) o di apprendimento automatico (ML ).
- Secondo questa nuova bozza di linea guida, il rispetto degli standard consensuali volontari riconosciuti dal settore per le presentazioni alle autorità regolatorie diventerebbe più semplice e più in linea con le attuali tendenze, pratiche e innovazioni del mercato della sanità digitale. Sia i dispositivi che richiedono una documentazione di base sia quelli che richiedono una documentazione avanzata devono conformarsi alla versione della norma ANSI/AAMI IEC 62304 “Software per dispositivi medici – Processo del ciclo di vita del software” riconosciuta dall’ FDA. La documentazione avanzata richiede 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, al fine di garantire una maggiore chiarezza durante la revisione.
- Sulla base dell’analisi dei rischi, conformemente ai requisiti del regolamento 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 l’esistenza di un sistema di vigilanza per il monitoraggio dei 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 fondamentali e si ottengono mediante il collaudo dei componenti del software a livello di sistema o di integrazione. Ciò è obbligatorio ai fini di una documentazione più completa. Inoltre, occorre anche esaminare la descrizione dei protocolli di collaudo, insieme ai risultati attesi o osservati, al fine di stabilire se il sistema abbia superato o meno i test.
- Qualsiasi presenza di anomalie irrisolte, quali bug o difetti che possano influire sulle prestazioni del software, deve essere identificata e classificata in base alla tassonomia dei difetti, secondo la “Classificazione dei difetti nel software sanitario” prevista dalla norma ANSI/AAMI SW91.
È necessario presentare una documentazione approfondita per i dispositivi che siano prodotti combinati o classificati come dispositivi di Classe III ad alto rischio, oppure per le funzioni software destinate all’uso in applicazioni di donazione e trasfusione di sangue che effettuano la valutazione della compatibilità tra donatore e ricevente. I dispositivi che richiedono una documentazione speciale devono attenersi ai requisiti di documentazione approfondita. La documentazione di base deve includere relazioni sintetiche sull’analisi dei pericoli, sulla mitigazione dei pericoli e sulla giustificazione dei rischi.
In base agli impegni previsti dall’MDUFA IV, l’Agenzia è tenuta a pubblicare la versione definitiva delle linee guida entro 12 mesi dalla chiusura del periodo di consultazione sulla bozza. L’ FDA ha annunciato che il 16 dicembre 2021 terrà un webinar rivolto agli produttori i del settore dei dispositivi medici, ai ricercatori e ai professionisti del settore della sanità digitale per discutere questa bozza di linee guida.
Per saperne di più sulla presentazione pre-commercializzazione delle funzioni software dei dispositivi, reach aun esperto in materia di normative a livello regionale come Freyr. Rimani informato. Rimani conforme.
