> 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.
Eseguire l'Analisi dei Pericoli Prima di Scrivere una Sola Riga di Codice
Motivazione: IEC 62304 clausola 4.2 richiede una classificazione della sicurezza software prima che le attività di sviluppo inizino, e quella classificazione deriva dall'analisi dei pericoli. Iniziare lo sviluppo senza conoscere la classe di sicurezza significa che le attività di sviluppo potrebbero essere impostate al livello sbagliato, creando rischi di rielaborazione estremamente costosi da correggere dopo il blocco del progetto.
Da fare: Condurre un'analisi preliminare dei pericoli all'inizio del progetto. Per ogni modalità di guasto prevista, definire il peggior danno credibile, assegnare la gravità (catastrofica/critica/marginale/trascurabile) e impostare la classe di sicurezza (A/B/C). Documentare la motivazione. Rivedere e aggiornare l'analisi dei pericoli dopo ogni importante modifica al progetto.
Da non fare: Assegnare la classe di sicurezza per intuizione o affermazioni di marketing senza documentazione formale di analisi dei pericoli. Non rinviare l'analisi dei pericoli a "dopo che sappiamo cosa fa il software" - deve guidare le decisioni architetturali.
Costruire la Tracciabilità Bidirezionale Fin dal Primo Giorno
Motivazione: I controlli di progetto FDA (21 CFR 820.30) e IEC 62304 richiedono entrambi la tracciabilità tra requisiti, progetto, implementazione e test. Il tentativo di ricostruire la tracciabilità retroattivamente dopo lo sviluppo è la singola fonte più comune di risultati di controllo del progetto nelle ispezioni FDA.
Da fare: Utilizzare uno strumento di gestione dei requisiti (JIRA, Polarion, Codebeamer o anche un foglio di calcolo strutturato) che applica i link di tracciabilità. Definire lo schema di tracciabilità prima della raccolta dei requisiti: ID esigenza utente → ID requisito dispositivo → ID requisito SRS → elemento di progetto → ID caso di test. Assegnare ID a ogni artefatto al momento della creazione. Generare report di tracciabilità come output delle revisioni del progetto.
Da non fare: Utilizzare documenti non strutturati (Word, pagine Confluence) come archivio primario dei requisiti senza assegnazione di ID e collegamenti incrociati. Non collegare i casi di test alla "funzionalità" - collegare all'ID requisito specifico.
Implementare Audit Trail Immutabili a Prova di Manomissione per Tutte le Operazioni sui Dati Clinici
Motivazione: Il 21 CFR Part 11 richiede che i record elettronici includano audit trail generati dal computer con registrazioni di data/ora delle voci e azioni degli operatori che creano, modificano o eliminano record elettronici. Nei SaMD, l'integrità dei dati clinici (input del paziente, output dell'algoritmo, override dell'utente) è direttamente legata alla sicurezza del paziente.
Da fare: Registrare ogni operazione di creazione, lettura con impatto clinico, aggiornamento ed eliminazione sui dati del paziente e sugli output dell'algoritmo con: ID utente, timestamp (UTC, precisione al millisecondo), ID record, tipo di azione, valore precedente (per aggiornamenti), nuovo valore. Scrivere gli audit log in un archivio write-once, solo-append. Includere l'audit log nel DHF come specifica di sistema.
Da non fare: Consentire agli account di servizio dell'applicazione di eliminare o modificare i record di audit. Non memorizzare i record di audit nella stessa tabella mutabile dei dati clinici che proteggono. Non registrare mai i valori PHI nei campi dei record di audit accessibili al di fuori del sistema di conformità.
Controllare Versioni di Ogni Artefatto di Build e Collegare le Versioni ai Record DHR
Motivazione: Il 21 CFR 820.184 richiede che i DHR includano o facciano riferimento a ciascuna configurazione del dispositivo. Per i SaMD, ciò significa che ogni versione del software rilasciata deve essere identificata in modo univoco e il DHR per quella versione deve fare riferimento agli esatti artefatti di build, ai risultati dei test e alla documentazione delle modifiche che l'hanno prodotta.
Da fare: Implementare il versioning semantico (MAGGIORE.MINORE.PATCH) con una politica documentata sulla gravità delle modifiche (MAGGIORE = nuovo uso previsto o modifica significativa dell'algoritmo, MINORE = nuova funzionalità, PATCH = correzione di bug). Taggare ogni commit di rilascio nel controllo versioni. Memorizzare il DHR come record formale che collega: versione di rilascio, data di rilascio, hash di build, descrizione della modifica, riferimento al report di test e firme dell'approvatore.
Da non fare: Rilasciare aggiornamenti software senza aggiornare l'identificatore di versione e il DHR. Non utilizzare deployment "hotfix" che bypassano il processo DHR, nemmeno per le correzioni di bug critici.
Applicare la Difesa in Profondità per la Cybersicurezza per Tutti i SaMD Connessi in Rete
Motivazione: La Guida sulla Cybersicurezza FDA 2023 chiarisce esplicitamente che i controlli di cybersicurezza sono un requisito di sicurezza del paziente per i SaMD connessi in rete. Un dispositivo compromesso può fornire output clinici errati, essere utilizzato per accedere a PHI o diventare un punto di pivot nell'infrastruttura di rete clinica.
Da fare: Eseguire la modellazione formale delle minacce usando STRIDE a livello di sistema. Documentare gli obiettivi dell'attaccante, i punti di ingresso e le mitigazioni nel file di gestione del rischio. Implementare: TLS 1.2+ per tutti i dati in transito, AES-256 per i dati a riposo, controlli degli accessi basati sui ruoli, MFA per l'accesso amministrativo, validazione dell'input su tutti i punti di immissione dei dati e un meccanismo di aggiornamento software autenticato con integrità verificata. Includere l'SBOM nella presentazione premarket e stabilire un processo per monitorare i componenti SBOM per CVE post-market.
Da non fare: Trattare la cybersicurezza come un'attività di documentazione pre-presentazione indipendente dallo sviluppo. Non hardcodare credenziali, chiavi di crittografia o token API nel codice sorgente. Non spedire senza una politica di divulgazione delle vulnerabilità documentata.
Condurre Test di Usabilità Sommativa sul Dispositivo Finale Prima della Presentazione
Motivazione: L'ingegneria dei fattori umani (HFE) è richiesta dalla FDA (Guida HFE 2016) per i SaMD per dimostrare che gli errori d'uso che potrebbero causare o contribuire a danni al paziente sono stati identificati e mitigati. I test sommativi su un prototipo non finale non sono accettabili - la FDA può richiedere test aggiuntivi se l'interfaccia del dispositivo finale differisce dalla versione testata.
Da fare: Condurre studi di usabilità formativi nelle prime fasi del progetto per identificare le attività critiche e i potenziali errori d'uso. Condurre un test sommativo finale utilizzando utenti rappresentativi, l'UI finale e un protocollo di test validato. Documentare il test nel DHF. Per la presentazione, includere un report HFE con: analisi degli errori d'uso, attività critiche, metodo di test, dati demografici dei partecipanti, risultati e rischi residui.
Da non fare: Utilizzare il feedback alpha/beta come sostituto dei test sommativi formali. Non limitare i test di usabilità agli utenti esperti - includere gli utenti novizi rappresentativi della popolazione prevista.
Validare le Prestazioni Cliniche su Dataset Demograficamente Rappresentativi
Motivazione: La FDA si aspetta che le prestazioni dei SaMD AI/ML siano validate su dati rappresentativi della popolazione d'uso prevista. La distorsione nei dataset di addestramento o validazione (sottorappresentazione di gruppi di età, sesso, razza o gravità della malattia) può comportare prestazioni cliniche disparate, causando danni ai gruppi sottorappresentati.
Da fare: Prima di progettare lo studio di validazione clinica, definire la popolazione di pazienti prevista nella SRS. Assicurarsi che il dataset di validazione includa campioni rappresentativi tra i sottogruppi clinicamente rilevanti. Riportare metriche di performance disaggregate (sensibilità/specificità per sottogruppo) nella presentazione premarket. Stabilire soglie minime di performance dei sottogruppi come criteri pass/fail.
Da non fare: Validare su campioni di convenienza o dataset storici senza verificare la distribuzione demografica. Non riportare solo metriche di performance globali senza analisi dei sottogruppi quando le disparità dei sottogruppi sono plausibili. Non utilizzare il dataset di addestramento come dataset di validazione.
Implementare un Sistema di Sorveglianza Post-Market Prima del Lancio
Motivazione: Il 21 CFR Part 803 (MDR) e il 21 CFR 820.198 (gestione dei reclami) impongono obblighi post-market continui dal giorno in cui un dispositivo viene distribuito. Per i SaMD AI/ML con un ACP, la sorveglianza post-market deve anche validare le prestazioni dell'algoritmo entro i limiti definiti dall'ACP. Costruire sistemi PMS come ripensamento dopo il lancio significa che si potrebbe non essere conformi fin dal primo giorno.
Da fare: Prima della prima spedizione/deployment, stabilire: una procedura formale di ricezione dei reclami con un canale dedicato, un processo di triage per identificare gli eventi segnalabili MDR entro la finestra di segnalazione di 30 giorni, un processo di analisi delle tendenze per identificare eventi non segnalabili che potrebbero segnalare problemi sistemici, e per i SaMD AI/ML, monitoraggio automatizzato delle metriche di performance rispetto alle soglie definite dall'ACP.
Da non fare: Utilizzare sistemi generici di supporto clienti come unico meccanismo di ricezione dei reclami senza un passo di triage che valuti la segnalabilità MDR. Non consentire la deriva delle prestazioni del modello AI/ML senza un sistema di allarme automatizzato.
Gestire i SOUP Esplicitamente con Valutazioni del Rischio Documentate
Motivazione: La maggior parte dei SaMD moderni incorpora significative librerie open-source e commerciali di terze parti. IEC 62304 clausola 8.1 richiede la gestione esplicita dei SOUP. I SOUP non gestiti con CVE noti sono una delle principali preoccupazioni di cybersicurezza della FDA.
Da fare: Mantenere un SBOM completo per ogni versione rilasciata. Per ogni SOUP, documentare: nome, versione, fornitore, uso previsto all'interno del SaMD, impatto sulla classe di sicurezza, vulnerabilità note (risultato scansione CVE) e attività di verifica eseguite. Stabilire un processo per rivedere i CVE nei componenti SOUP con una cadenza definita (minimo mensile) e un SLA di deployment delle patch legato alla severità CVSS (Critico: 30 giorni, Alto: 60 giorni, Medio: 90 giorni).
Da non fare: Aggiungere nuove dipendenze SOUP senza una richiesta di modifica DHF e aggiornamento SBOM. Non fissare le dipendenze e smettere di monitorare - utilizzare la scansione automatizzata delle dipendenze in CI/CD (Dependabot, Snyk o equivalente).
Documentare la Decisione sul Percorso Normativo Prima di Iniziare una Presentazione 510(k)
Motivazione: Presentare al percorso normativo FDA sbagliato - o presentare senza un dispositivo predice appropriato - è l'errore normativo più costoso possibile. Una determinazione di "non sostanzialmente equivalente" (NSE) forza la classificazione Classe III e il PMA. Il PMA medio richiede una revisione di 180 giorni e dati clinici estesi.
Da fare: All'inizio del progetto, preparare un documento di strategia normativa che identifichi: classificazione del dispositivo (con prove di ricerca nel Product Classification Database), percorso normativo proposto (510(k), De Novo, PMA), dispositivo/i predice con confronto di uso previsto e caratteristiche tecnologiche, e il piano per i dati di validazione clinica. Presentare una Q-Sub alla FDA per feedback prima di finalizzare la strategia, specialmente per algoritmi nuovi o nuove affermazioni sulle malattie.
Da non fare: Iniziare a scrivere un 510(k) senza prima identificare e documentare il dispositivo predice. Non selezionare un predice senza verificare che sia attualmente commercializzato legalmente e fosse autorizzato/approvato (non solo registrato).
Stabilire un Change Control Board con Valutazione dell'Impatto Normativo
Motivazione: Le modifiche post-market ai SaMD che influiscono sulla sicurezza o sull'efficacia richiedono un nuovo 510(k). L'utilizzo di un processo di modifica informale che non include la valutazione dell'impatto normativo porta all'under-reporting (perdere le presentazioni richieste) o all'over-reporting (presentazioni inutili che rallentano lo sviluppo).
Da fare: Implementare un processo CCB per tutte le modifiche post-rilascio. Per ogni modifica proposta, completare una valutazione dell'impatto normativo utilizzando il diagramma di flusso FDA dalla guida 2017 "Deciding When to Submit a 510(k) for a Software Change." Documentare la motivazione della valutazione e la decisione CCB nel DHF. Mantenere un registro di tutte le modifiche valutate come "nessuna nuova presentazione richiesta" per dimostrare la diligenza dovuta durante le ispezioni.
Da non fare: Effettuare deployment hotfix di emergenza senza documentazione CCB retroattiva. Non classificare le modifiche come non significative senza giustificazione documentata.
Includere la Conformità ai Record Elettronici (21 CFR Part 11) nel Progetto del Sistema
Motivazione: I sistemi SaMD che creano, modificano, mantengono o trasmettono record elettronici equivalenti ai record cartacei (firme, approvazioni, record clinici) devono conformarsi al 21 CFR Part 11. La non conformità viene scoperta durante le ispezioni FDA e può risultare in Warning Letters.
Da fare: In fase di progettazione, identificare quali record del sistema sono soggetti alla Parte 11. Per quei record implementare: audit trail generati dal computer con data/ora, autenticazione dell'utente collegata a account individuali, controlli delle firme elettroniche (significato, nome stampato, data e manifestazione della firma) e protezione dei record dalla modifica. Validare il sistema di record elettronici con un approccio IQ/OQ/PQ. Documentare la validazione nel DHF.
Da non fare: Consentire account di accesso condivisi per l'accesso ai record regolamentati. Non implementare la conformità alla Parte 11 come layer su un database mutabile esistente - progettare per l'immutabilità fin dall'inizio.