Ricerca e sviluppo
Software come dispositivo medico.
Dalla classificazione allo sviluppo conforme alla norma IEC 62304, fino alla presentazione alla FDA: seguiamo i vostri progetti SaMD dall'architettura fino all'autorizzazione all'immissione in commercio.
Perché i progetti SaMD falliscono in fase di autorizzazione?
Il software, in quanto dispositivo medico, è soggetto agli stessi requisiti normativi dell'hardware, ma viene spesso trattato come un progetto informatico:
- Classificazione mancante: la norma MDR 11 e il regolamento FDA 21 CFR Parte 820 vengono presi in considerazione troppo tardi nel ciclo di sviluppo. La classe di rischio determina l'intero percorso normativo – e quindi l'impegno richiesto, i tempi e i costi.
- IEC 62304 non integrata: il ciclo di vita del software non è strutturato fin dall'inizio secondo la norma IEC 62304. Nella documentazione mancano l'architettura del software, la modularizzazione e la gestione delle modifiche.
- Casi particolari di IA/ML: gli algoritmi adattivi richiedono piani di controllo delle modifiche predeterminati (PCCP) secondo il quadro normativo della FDA in materia di IA/ML. Senza tale piano, è impossibile ottenere l'autorizzazione all'immissione in commercio per i sistemi di apprendimento.
- La sicurezza informatica come elemento secondario: le linee guida della FDA sulla sicurezza informatica pre-commercializzazione (2023) e l'MDCG 2019-16 dell'UE richiedono la modellizzazione delle minacce e l'SBOM fin dall'inizio, non come fase finale della verifica.
La vostra architettura software è documentata in modo tale che un revisore della FDA possa comprendere il livello di classificazione di sicurezza di ogni unità software?
I nostri servizi SaMD.
Portiamo la precisione normativa nello sviluppo agile di software, senza rallentare il vostro processo di sviluppo.
Classificazione SaMD e strategia normativa
Classificazione secondo la regola 11 del MDR, il quadro normativo SaMD dell'IMDRF e le procedure De Novo / 510(k) / PMA della FDA. Definiamo il percorso di autorizzazione più efficiente ed elaboriamo la strategia normativa, compresa l'analisi del dispositivo di riferimento.
IEC 62304: Ciclo di vita del software
Implementazione di un processo di sviluppo conforme alla norma IEC 62304: piano di sviluppo del software, progettazione dell'architettura, test unitari, di integrazione e di sistema. Perfetta integrazione nei framework agili (Scrum, SAFe) con tracciabilità completa.
Quadro normativo in materia di IA/ML
Elaborazione di piani di controllo delle modifiche predeterminati (PCCP) in conformità con il piano d'azione della FDA in materia di IA/ML. Documentazione relativa all'addestramento e alla convalida degli algoritmi, all'analisi dei bias e ai protocolli di apprendimento continuo per algoritmi adattivi.
Cybersecurity e SBOM
Modellizzazione delle minacce (STRIDE/DREAD), Software Bill of Materials (SBOM) e divulgazione delle vulnerabilità secondo le linee guida della FDA sulla sicurezza informatica pre-commercializzazione e la MDCG 2019-16. Test di penetrazione e valutazione dei rischi di sicurezza.
Domande frequenti sul Software as a Medical Device.
Quando un software è considerato un dispositivo medico?
Un software è considerato un dispositivo medico (SaMD) se, di per sé, soddisfa una finalità medica, ad esempio il supporto diagnostico, la formulazione di raccomandazioni terapeutiche o il monitoraggio del paziente. Ciò che conta è la finalità prevista, non la piattaforma. Un'app su uno smartphone può essere un dispositivo medico di classe IIb.
Qual è la differenza tra SaMD e SiMD?
Il SaMD (Software as a Medical Device) è un software autonomo destinato a scopi medici. Il SiMD (Software in a Medical Device) è un software integrato in un dispositivo medico fisico. Entrambi sono soggetti alla norma IEC 62304, ma il SaMD è soggetto a regole di classificazione specifiche (Regola 11 dell'MDR, IMDRF).
È possibile seguire un approccio agile allo sviluppo e rimanere comunque conformi alla norma IEC 62304?
Sì. La norma IEC 62304 non impone l'uso del metodo a cascata. Lo sviluppo agile è pienamente compatibile, a condizione che gli artefatti degli sprint siano correttamente mappati ai documenti richiesti dal ciclo di vita: user story → requisiti software, sprint review → revisioni di progettazione, definizione di "completato" → verifica.
Quali sono i requisiti della FDA per i dispositivi medici basati sull'intelligenza artificiale e sull'apprendimento automatico?
La FDA richiede un piano di controllo delle modifiche prestabilito (PCCP) che descriva in che modo l'algoritmo potrà essere modificato dopo l'immissione sul mercato. Inoltre: buone pratiche di machine learning (GMLP), documentazione dei dati di addestramento, mitigazione dei bias e monitoraggio delle prestazioni nel mondo reale.
Argomenti correlati di ingegneria.
Competenza
Cybersecurity per i dispositivi medici
Linee guida pre-commercializzazione della FDA, modellizzazione delle minacce e obbligo di SBOM.
CompetenzaControlli di progettazione
DHF, tracciabilità e V&V secondo le norme ISO 13485 e 21 CFR 820.
CompetenzaVerifica e convalida
Metodologia formale di verifica e convalida per software e hardware.
Un software che convince le autorità.
Descrivete il vostro progetto SaMD: i nostri esperti vi indicheranno il percorso di autorizzazione più efficiente.