> Disclaimer: Questo contenuto è destinato esclusivamente a scopi educativi e di riferimento per i costruttori di software. Non costituisce consulenza medica, legale, finanziaria o normativa. Consultare un professionista qualificato prima di prendere decisioni basate su questo contenuto.
Il mio software si qualifica come SaMD secondo le normative FDA?
La FDA determina lo stato di SaMD valutando l'uso previsto. Il software è un dispositivo medico se soddisfa la definizione di dispositivo nella sezione 201(h) del FD&C Act - inteso per diagnosticare, curare, mitigare, trattare o prevenire una malattia o condizione, o per influenzare la struttura o funzione del corpo. Il 21st Century Cures Act (Sezione 3060) ha escluso quattro categorie di software non-dispositivo: supporto amministrativo, stile di vita sano (scopo non medico), cartelle cliniche elettroniche e certi CDS in cui i medici possono verificare autonomamente la base della raccomandazione. Se il software non rientra in queste esclusioni e fa affermazioni correlate alle malattie, è probabilmente un dispositivo. Consultare un consulente normativo con la specifica dichiarazione di uso previsto prima di concludere che è fuori dal campo di applicazione.
Quale classe di sicurezza software devo assegnare secondo IEC 62304?
IEC 62304 definisce tre classi di sicurezza software basate sulla gravità del danno al paziente che potrebbe derivare da un guasto del software. Classe A: nessun danno alla salute. Classe B: danno non grave. Classe C: morte o danno grave. La classe di sicurezza determina le attività di sviluppo richieste - la Classe C richiede la documentazione, i test unitari e i requisiti di copertura del codice più rigorosi. Assegnare la classe di sicurezza eseguendo un'analisi dei pericoli: per ogni elemento software, identificare il peggior danno credibile, stimarne la gravità e assegnare la classe. Documentare la motivazione nel file di gestione del rischio. Nota: IEC 62304 è uno standard protetto da copyright - fare riferimento solo al numero di clausola nella documentazione; non riprodurre mai il testo delle clausole verbatim.
Quale percorso normativo FDA si applica al mio SaMD?
Il percorso normativo è determinato dalla classificazione del dispositivo (Classe I, II o III). Classe I: solo controlli generali; la maggior parte esente da 510(k). Classe II: controlli generali e speciali; la maggior parte richiede 510(k). Classe III: controlli generali e PMA; richiesto per i SaMD che supportano o sostengono la vita umana. Se il SaMD non ha un predice (nuova tecnologia, nuovo uso previsto), considerare il percorso De Novo. Consultare il Product Classification Database della FDA per i dispositivi simili per identificare la classificazione e i codici di prodotto applicabili.
Cosa deve essere incluso nella Software Requirements Specification (SRS) per la presentazione FDA?
La SRS per la revisione FDA deve documentare: (1) requisiti funzionali (cosa fa il software); (2) requisiti di performance (tempo di risposta, accuratezza, precisione); (3) requisiti di interfaccia (hardware, software, rete); (4) requisiti di sicurezza (derivati dall'analisi dei pericoli); (5) requisiti di cybersicurezza (controlli degli accessi, crittografia, autenticazione); e (6) requisiti di manutenibilità e affidabilità. La FDA si aspetta che ogni requisito abbia un ID univoco, sia verificabile e tracciabile bidirezionalmente - collegato in avanti agli elementi di progetto e all'indietro dai risultati dei test.
Quale documentazione di cybersicurezza richiede la FDA in una presentazione premarket?
Secondo la Guida sulla Cybersicurezza FDA 2023, le presentazioni devono includere: (1) una valutazione del rischio di cybersicurezza che copra la modellazione delle minacce (STRIDE o equivalente), l'identificazione delle vulnerabilità e i rischi residui; (2) un SBOM che elenca tutti i componenti software e le dipendenze; (3) documentazione dei controlli di sicurezza implementati (autenticazione, crittografia, meccanismo di patch); (4) un processo di aggiornamento software e deployment delle patch; e (5) una politica di divulgazione coordinata delle vulnerabilità.
Come gestisco le modifiche al software post-market - quando devo presentare un nuovo 510(k)?
La guida FDA "Deciding When to Submit a 510(k) for a Software Change to an Existing Device" (2017) e il relativo diagramma di flusso definiscono quando le modifiche richiedono una nuova presentazione premarket. Un nuovo 510(k) è generalmente richiesto quando: la modifica riguarda un dispositivo che richiede 510(k); potrebbe influire significativamente sulla sicurezza o sull'efficacia; o è una modifica importante all'uso previsto. Le modifiche che sono correzioni di bug minori, patch di sicurezza o miglioramenti delle prestazioni senza effetto sulla sicurezza possono tipicamente essere effettuate sotto l'autorizzazione esistente con appropriata documentazione delle modifiche di progetto nel DHF.
Cos'è la sostanziale equivalenza e come la stabilisco per i SaMD?
La sostanziale equivalenza (SE) richiede di dimostrare che il SaMD ha (a) lo stesso uso previsto del predice, o (b) un uso previsto diverso ma con caratteristiche tecnologiche che non sollevino nuove questioni di sicurezza ed efficacia E siano almeno altrettanto sicure ed efficaci del predice. Per i SaMD, l'argomento SE tipicamente confronta: le dichiarazioni di uso previsto, la descrizione del dispositivo e l'approccio algoritmico, e i dati di performance (sensibilità/specificità per i dispositivi diagnostici).
Cos'è una Pre-Submission (Q-Sub) e quando dovrei richiederla?
Una Pre-Submission (Q-Sub) è una richiesta formale di riunione con la FDA o una richiesta di feedback scritto effettuata prima di presentare una domanda premarket. La FDA incoraggia fortemente le Q-Sub quando: si è incerti sul percorso normativo, si hanno domande sulla progettazione degli studi clinici o sugli endpoint di performance, il dispositivo utilizza tecnologia nuova, o si vuole feedback su un algorithm change protocol AI/ML. Le riunioni Q-Sub si tengono tipicamente entro 90 giorni dall'accettazione da parte della FDA.
Cos'è l'algorithm change protocol (ACP) per i SaMD AI/ML?
L'ACP descrive i tipi di modifiche che un produttore prevede di apportare a un algoritmo AI/ML nel ciclo di vita del dispositivo e i test di performance da eseguire prima di implementare ciascuna modifica. Consente un modello di "controllo delle modifiche predeterminate" in cui certi tipi di aggiornamenti algoritmici possono essere effettuati senza un nuovo 510(k), a condizione che le modifiche rimangano entro i limiti predefiniti e il produttore segua il protocollo di test dell'ACP. (FDA AI/ML SaMD Action Plan, 2021)
Quali dati di validazione clinica si aspetta la FDA per i SaMD diagnostici?
La FDA si aspetta dati di validazione clinica che dimostrino che il SaMD funziona come previsto nella popolazione clinica e nell'ambiente. Per i SaMD diagnostici, ciò significa tipicamente: sensibilità, specificità, valore predittivo positivo (VPP), valore predittivo negativo (VPN) e area sotto la curva ROC (AUC) misurati su un dataset clinicamente rappresentativo. Il dataset deve rappresentare la popolazione di pazienti prevista (età, sesso, gravità della malattia, comorbilità).
Come gestisco i componenti software di terze parti (SOUP) nel mio SaMD?
Per ogni SOUP, il produttore deve: (1) documentare il titolo, il produttore e la versione nel DHF; (2) identificare i requisiti a cui il SOUP contribuisce; (3) identificare i requisiti di sistema e l'hardware su cui opera; (4) valutare i rischi derivanti dall'uso del SOUP; e (5) stabilire procedure di test per verificare che il SOUP soddisfi le funzionalità richieste. Per la FDA, l'SBOM fornisce l'inventario formale di tutti i SOUP.
Quali sono le soglie di segnalazione MDR per gli incidenti dei SaMD?
Ai sensi del 21 CFR Part 803, i produttori di SaMD devono segnalare alla FDA quando vengono a conoscenza che un dispositivo ha causato o potrebbe aver contribuito a: (1) un decesso - segnalare entro 30 giorni di calendario; (2) una lesione grave - segnalare entro 30 giorni; (3) un malfunzionamento che, se si ripetesse, potrebbe causare o contribuire a morte o lesione grave - segnalare entro 30 giorni. Se l'incidente richiede un'azione correttiva per prevenire un rischio irragionevole per la salute pubblica, segnalare entro 5 giorni.
Come stabilisco la tracciabilità per la conformità ai controlli di progetto FDA?
La tracciabilità nei controlli di progetto dei SaMD significa collegare ogni artefatto nel ciclo di vita dello sviluppo ad artefatti correlati. Implementare una matrice di tracciabilità a quattro livelli: (1) esigenze dell'utente → requisiti del dispositivo; (2) requisiti del dispositivo → requisiti software (SRS); (3) requisiti SRS → elementi di progetto (architettura, moduli); (4) elementi di progetto → casi di test (unità, integrazione, sistema). Per la gestione del rischio: collegare ogni pericolo identificato → requisito di controllo del rischio → test di verifica.
Cos'è la QMSR e come influenza lo sviluppo dei SaMD?
La FDA ha pubblicato il Quality Management System Regulation (QMSR) nel febbraio 2024, in vigore da febbraio 2026, armonizzando il 21 CFR Part 820 con ISO 13485:2016. Le principali modifiche rilevanti per i SaMD: (1) i requisiti di progettazione e sviluppo ISO 13485 sostituiscono la precedente struttura di controllo del progetto; (2) l'integrazione della gestione del rischio con ISO 14971 è più esplicita; (3) i requisiti di validazione del software fanno riferimento a IEC 62304 per il software dei dispositivi medici. I produttori di SaMD con 510(k) esistenti devono aggiornare la documentazione QMS entro febbraio 2026.
Come dovrei implementare un programma di divulgazione delle vulnerabilità per i SaMD?
La Guida sulla Cybersicurezza FDA 2023 richiede ai produttori di disporre di una politica e di un processo di divulgazione coordinata delle vulnerabilità (CVD). La politica CVD deve: (1) fornire un canale pubblico per i ricercatori di sicurezza per segnalare le vulnerabilità; (2) definire SLA di risposta (la FDA raccomanda il riconoscimento entro 10 giorni lavorativi e la comunicazione della timeline di rimediazione entro 90 giorni); (3) includere un safe harbor senza penalità per la ricerca sulla sicurezza in buona fede; e (4) impegnarsi a pubblicare avvisi di sicurezza. La politica CVD deve essere presentata come parte della sezione di cybersicurezza delle presentazioni premarket.