Come portare il vostro software medicale sul mercato come SaMD in conformità regolatoria e senza iterazioni di approvazione?
Affianchiamo i dispositivi medici basati su software dalla classificazione attraverso lo sviluppo strutturato secondo IEC 62304 e la gestione del rischio secondo ISO 14971 fino alla valutazione della conformità ai sensi della Medical Device Regulation (EU) 2017/745 o alla FDA submission. La leva decisiva non è nel codice, ma nella classificazione di sicurezza del software: se viene stabilita troppo tardi, manca la documentazione del ciclo di vita che per questa classe difficilmente può essere ricostruita correttamente in un secondo momento.
- MedTech
- IVD
Panoramica
Cosa rende il software un dispositivo medico e quali requisiti ne derivano?
Supporto di progetti SaMD lungo il ciclo di vita · IEC 62304, ISO 14971, IEC 62366-1, MDR (EU 2017/745)
Ultimo aggiornamento: 2026-06-13
Il software è un dispositivo medico non appena svolge una destinazione d'uso medica autonoma, cioè non si limita a memorizzare o trasmettere dati, ma contribuisce alla diagnosi, alla terapia o al supporto decisionale. Da quel punto si applicano gli stessi requisiti generali dei prodotti fisici, integrati da norme specifiche per il software. Le leve in cui i progetti SaMD si bloccano più frequentemente:
- Classificazione: ai sensi di MDR (EU) 2017/745, la Regola 11 dell'Allegato VIII classifica il software medico autonomo in base alla gravità della decisione supportata; la maggior parte dei SaMD si colloca al di sopra dell'autocertificazione e necessita di un Organismo Notificato. Il software di tipo diagnostico può invece rientrare nella IVDR (EU) 2017/746, le cui regole di classificazione nell'Allegato VIII decidono tra le classi di rischio da A a D.
- Classificazione di sicurezza del software secondo IEC 62304: la classe A, B o C determina l'estensione delle attività e della documentazione del ciclo di vita richieste. Deriva dalla valutazione del rischio e non può essere corretta a posteriori verso il basso senza modificare l'analisi del rischio.
- Gestione del rischio secondo ISO 14971 come collegamento unificante: i pericoli relativi al software devono confluire nella stessa atto di rischio da cui derivano classificazione e profondità di verifica. Gestire i rischi software separatamente dal rischio del prodotto crea lacune.
- Usabilità secondo IEC 62366-1: gli errori operativi sono per il software una fonte di pericolo centrale; l'atto di usabilità deve documentare le fasi operative critiche per la sicurezza e la loro validazione.
- Cybersecurity per tutto il ciclo di vita: per il software in rete, gli Organismi Notificati e la FDA si aspettano un Secure Development Lifecycle documentato che includa SBOM, gestione delle vulnerabilità e strategia di aggiornamento oltre la fase di mercato.
Servizi
Come la supportiamo
Classificazione e delimitazione
Valutazione della destinazione d'uso, delimitazione dispositivo medico versus non-dispositivo medico e classificazione ai sensi di MDR (EU 2017/745) o IVDR (EU 2017/746). Deliverable: motivazione della classificazione documentata e percorso di valutazione della conformità stabilito.
Ciclo di vita del software secondo IEC 62304
Costruzione dei processi del ciclo di vita richiesti da IEC 62304 adeguati alla classe di sicurezza del software A, B o C, dall'analisi dei requisiti e dall'architettura fino all'implementazione e alla verifica. Deliverable: piano di sviluppo software e atto del ciclo di vita verificabile.
Gestione del rischio e usabilità
Integrazione dei pericoli software nella gestione del rischio secondo ISO 14971 e costruzione dell'atto di usabilità secondo IEC 62366-1. Deliverable: atto di rischio consolidata e Usability Engineering File con fasi operative critiche per la sicurezza validate.
Cybersecurity e SBOM
Definizione di un Secure Development Lifecycle secondo IEC 81001-5-1 con Software Bill of Materials, gestione delle vulnerabilità e degli aggiornamenti. Deliverable: documentazione di cybersecurity per la documentazione tecnica e l'esercizio in mercato.
AI/ML Governance per sistemi adattativi
Definizione di un framework per software con componenti AI o machine learning: data management, controllo delle versioni dei modelli e change control per gli aggiornamenti dei modelli. Deliverable: framework documentato di ciclo di vita e change per la componente ML.
Scopri di più →Documentazione tecnica e submission
Aggregazione degli atti software nella documentazione tecnica per la valutazione della conformità MDR o preparazione come FDA submission. Deliverable: pacchetto documentale pronto per la presentazione incluse le evidenze di verifica e validazione.
Come collaboriamo
Cosa conta davvero
Per il SaMD raramente è il codice a decidere il successo dell'approvazione, ma la sequenza delle determinazioni regolatorie. All'inizio vi è la destinazione d'uso: essa determina se il software è effettivamente un dispositivo medico e sotto quale regolamento rientra: la MDR (EU) 2017/745 o, per l'elaborazione a fini diagnostici, la IVDR (EU) 2017/746. Dalla destinazione d'uso e dalla valutazione del rischio secondo ISO 14971 deriva la classe di sicurezza del software secondo IEC 62304, e questa classe stabilisce con quale profondità devono essere documentati architettura, progettazione di dettaglio e verifica. Chi chiude questa catena troppo tardi costruisce software senza le evidenze richieste esattamente per la sua classe.
Il collo di bottiglia è quindi quasi sempre la ricostruzione a posteriori: una classe di sicurezza superiore riconosciuta troppo tardi o una destinazione d'uso vaga obbliga a costruire retroattivamente documentazione del ciclo di vita, atto di rischio ed evidenze di usabilità secondo IEC 62366-1, e precisamente in un momento in cui le decisioni di sviluppo sono già state prese. Per questo interveniamo prima dell'implementazione: classificazione, classe di sicurezza e strategia di cybersecurity secondo IEC 81001-5-1 vengono stabilite anticipatamente e integrate con il sistema QM secondo ISO 13485:2016, in modo che la documentazione tecnica alla fine documenti ogni requisito con un'evidenza software solida invece che con un ricordo.
Il nostro approccio
Il nostro approccio
Fase
Risultato
Classificazione e strategia
Destinazione d'uso documentata, classe di prodotto confermata ai sensi di MDR o IVDR e classe di sicurezza del software stabilita secondo IEC 62304.
Setup del ciclo di vita
Piano di sviluppo software secondo IEC 62304 con attività definite adeguate alla classe di sicurezza, collegato al sistema QM secondo ISO 13485:2016.
Rischio e usabilità
Atto di rischio consolidata secondo ISO 14971 e atto di usabilità secondo IEC 62366-1, costantemente riferite ai requisiti software.
Verifica e cybersecurity
Evidenze di verifica e validazione e documentazione di cybersecurity secondo IEC 81001-5-1 inclusa SBOM.
Documentazione tecnica
Documentazione tecnica aggregata in cui ogni requisito generale è documentato con un'evidenza software.
Submission e esercizio in mercato
Richiesta presentata all'Organismo Notificato o alla FDA e una gestione continuativa degli aggiornamenti e delle vulnerabilità per la fase di mercato.
Errori tipici
Perché i progetti spesso falliscono
La classificazione di sicurezza del software secondo IEC 62304 viene stabilita troppo tardi.
Se viene riconosciuto solo dopo il completamento dello sviluppo che si applica una classe superiore, mancano le attività e le evidenze del ciclo di vita richieste per questa classe; non possono essere ricostruite retroattivamente in modo verificabile.
La destinazione d'uso è formulata in modo troppo vago.
Una descrizione generica rende la classificazione ai sensi di MDR (EU 2017/745) contestabile e porta in sede di audit a discussioni sul fatto che si tratti effettivamente di un dispositivo medico e sotto quale regola rientri.
I rischi software vengono gestiti separatamente dalla gestione del rischio del prodotto.
Se i pericoli relativi al software non confluiscono nell'atto di rischio secondo ISO 14971, manca il collegamento tra rischio, classe di sicurezza e profondità di verifica, cosa che gli Organismi Notificati contestano regolarmente.
I componenti di terze parti e open-source utilizzati (SOUP) non vengono rilevati sistematicamente.
Senza Bill of Materials e valutazione delle vulnerabilità manca la base per la documentazione di cybersecurity e la gestione degli aggiornamenti durante la fase di mercato.
Le componenti AI o ML vengono gestite senza change control per gli aggiornamenti dei modelli.
Chi modifica i modelli dopo l'approvazione senza valutare la portata della modifica rispetto alla destinazione d'uso approvata rischia una modifica sostanziale che innesca una nuova valutazione della conformità.
FAQ
Domande frequenti
Fonti
- Regolamento (UE) 2017/745 (MDR), Testo primario, regole di classificazione per il software
- Regolamento (UE) 2017/746 (IVDR), Testo primario
- IEC 62304, Processi del ciclo di vita del software per dispositivi medici
- ISO 14971, Applicazione della gestione del rischio ai dispositivi medici
- IEC 62366-1, Applicazione dell'usabilità ai dispositivi medici
- IEC 81001-5-1, Cybersecurity nel ciclo di vita del software
- https://theentourage.de/clinical-medical-affairs/software-development-samd/ (contenuto pagina esistente, rielaborato)
Life Science Journal
Aggiornamenti regolatori, direttamente nella Sua casella di posta.
Nuovi requisiti, decisioni delle autorità e indicazioni pratiche. Una volta al mese, cancellazione possibile in qualsiasi momento.
Case Study
Come si presenta nella pratica
Insights correlati
Tutti gli insights →Normative e standard considerati
- EU 2017/745 (MDR)
- EU 2017/746 (IVDR)
- IEC 62304 (Ciclo di vita del software per dispositivi medici)
- ISO 14971 (Gestione del rischio)
- IEC 62366-1 (Usabilità / Usability Engineering)
- ISO 13485:2016 (Sistema QM)
- IEC 81001-5-1 (Cybersecurity nel ciclo di vita del software)
- ISO/IEC 27001 (Sistema di gestione della sicurezza delle informazioni)
Argomenti correlati
EU AI Act →
Quadro regolatorio per componenti AI e ML nei dispositivi medici
Cybersecurity per i Dispositivi Medici →
Secure Development Lifecycle e gestione delle vulnerabilità per software in rete
conformità MDR →
Valutazione della conformità del software ai sensi di MDR (EU 2017/745)
Verifica e Validazione →
Evidenze di verifica e validazione come nucleo dell'atto software
Un progetto concreto in merito?
Ci descriva brevemente la sua situazione di partenza. Ci facciamo vivi con una prima valutazione, di norma entro un giorno lavorativo.
Preferisce il contatto diretto? +49 89 4161170-0
info@theentourage.de
- Risposta di norma entro un giorno lavorativo
- 4 sedi: DE · CH · IT · US
- 100% Life Sciences