SaMD vs SiMD: Software come dispositivo medico secondo FDA ed EU MDR

TL;DR

Il Software as a Medical Device (SaMD) è un software che persegue una finalità medica senza fare parte di un dispositivo medico hardware. Il Software in a Medical Device (SiMD) è un software che aziona o è incorporato in un dispositivo hardware. La definizione internazionale proviene dall'International Medical Device Regulators Forum (IMDRF). Quest'ultimo definisce il SaMD come "software destinato a essere utilizzato per una o più finalità mediche che persegue tali finalità senza fare parte di un dispositivo medico hardware". ¹

Tale distinzione determina il modo in cui il software viene classificato e sottomesso. Nell'UE, il SaMD è classificato a sé stante, per lo più in base alla Regola 11 dell'MDR. Il software che aziona un dispositivo appartiene alla stessa classe di tale dispositivo. Negli Stati Uniti, FDA autorizza le funzioni software di dispositivo tramite 510(k), De Novo o PMA. L'elenco dei dispositivi dotati di IA di FDA mostra questo andamento. Dei 1.614 dispositivi presenti nell'elenco, il 96,2% ha raggiunto il mercato tramite 510(k). Il numero di dispositivi autorizzati all'anno è cresciuto da 18 nel 2016 a 335 nel 2025. ²

Il 2026 ha introdotto diversi cambiamenti. FDA ha revisionato le sue linee guida sul supporto alle decisioni cliniche e sul benessere generale a gennaio e la sua linea guida sulla cybersecurity a febbraio. L'UE ha posticipato gli obblighi per i sistemi ad alto rischio dell'AI Act relativi ai dispositivi medici dotati di IA al 2 agosto 2028. Questa guida illustra le definizioni, come determinare se un software sia o meno un dispositivo medico, in che modo FDA e l'UE lo classificano, cosa comprende una sottomissione e come viene trattato da altri mercati principali.

SaMD, SiMD e MDSW: il significato di ciascun termine

Il SaMD è un termine definito. Il SiMD è un'etichetta descrittiva priva di una definizione legale vincolante. L'UE impiega un terzo termine, MDSW, che comprende entrambi.

L'IMDRF è esplicito riguardo a tale confine: "Un software non soddisfa la definizione di SaMD se la sua destinazione d'uso è azionare un dispositivo medico hardware". Afferma inoltre che "le app mobili che soddisfano la definizione sopra indicata sono considerate SaMD". La policy di FDA del 2022 sulle funzioni software di dispositivo stabilisce che esse "possono includere 'Software as a Medical Device (SaMD)' e 'Software in a Medical Device (SiMD)'". ³

Nell'UE, la MDCG 2019-11 Rev.1 sostituisce "standalone software" con MDSW e segnala che la vecchia espressione "non è più utilizzata nel contesto dei regolamenti sui dispositivi medici". La regola di attuazione 3.3 dell'MDR stabilisce le conseguenze per la classificazione: "Il software che aziona un dispositivo o ne influenza l'uso appartiene alla stessa classe del dispositivo. Se il software è indipendente da qualsiasi altro dispositivo, esso è classificato a sé stante". ^{4 5}

La TGA australiana descrive il SiMD nei termini più pratici. Tale software viene "solitamente fornito preinstallato con il dispositivo hardware" e "il SiMD è regolamentato come parte del dispositivo in cui è installato". ⁶

Prima domanda: il software è effettivamente un dispositivo medico?

Gran parte dei software sanitari non è un dispositivo medico. A determinarlo sono la destinazione d'uso e, negli Stati Uniti, cinque esclusioni previste dalla legge.

Negli Stati Uniti, la sezione 520(o) dell'FD&C Act, aggiunta dal 21st Century Cures Act, esclude cinque tipi di funzioni software dalla definizione di dispositivo:

• supporto amministrativo;
• mantenimento o incoraggiamento di uno stile di vita sano, non correlato a malattie;
• cartelle cliniche elettroniche dei pazienti, a meno che la funzione non le interpreti o le analizzi;
• trasferimento, memorizzazione, conversione o visualizzazione di dati, a meno che non interpreti o analizzi tali dati;
• determinati supporti alle decisioni cliniche (CDS). ⁷

L'esclusione per i CDS si applica unicamente quando il software non analizza immagini o segnali medici. Esso deve visualizzare o analizzare informazioni mediche, supportare la raccomandazione di un operatore sanitario e consentire a tale professionista di esaminare in modo indipendente la base su cui poggia tale raccomandazione.

FDA ha revisionato due policy fondamentali a gennaio 2026:

• Supporto alle decisioni cliniche. La linea guida è stata ripubblicata il 6 gennaio 2026 e corretta il 29 gennaio 2026. Il software che fornisce una specifica direttiva diagnostica o terapeutica non soddisfa il terzo criterio. Qualora una sola opzione sia clinicamente appropriata e per il resto il software soddisfi i criteri, FDA intende esercitare la propria discrezionalità applicativa. Il software che fornisce raccomandazioni a pazienti o caregiver, anziché a operatori sanitari, rimane un dispositivo medico. ⁸
• Benessere generale. La policy revisionata del 6 gennaio 2026 afferma che FDA "può considerare determinati prodotti che utilizzano il rilevamento non invasivo" per stimare parametri fisiologici, quali pressione arteriosa, saturazione di ossigeno o glucosio, come prodotti per il benessere generale. Ciò si applica solo a determinate condizioni. Il prodotto deve essere non invasivo, non deve sostituire un dispositivo autorizzato da FDA e non deve fornire output che inducano un'azione clinica specifica. ⁹

Nell'UE, la MDCG 2019-11 Rev.1 definisce un percorso decisionale. Il software destinato a "fini generali, anche se utilizzato nel contesto dell'assistenza sanitaria", o a "fini legati allo stile di vita e al benessere" non è un dispositivo ai sensi del considerando 19 dell'MDR. Il software che crea o modifica informazioni mediche per un singolo paziente di norma lo è. La revisione di giugno 2025 pone maggiore enfasi su una destinazione d'uso redatta con chiarezza e sul software modulare, in cui solo alcuni moduli si qualificano come dispositivo medico.

Come viene classificato il SaMD in base al rischio

Il framework dell'IMDRF costituisce il linguaggio comune. Ciascuna autorità regolatoria lo converte poi nelle proprie classi legali.

Il framework dell'IMDRF nel documento N12 suddivide il SaMD in categorie in base a due fattori. Il primo è lo stato della situazione sanitaria: critica, grave o non grave. Il secondo è l'importanza delle informazioni per la decisione sanitaria: trattare o diagnosticare, guidare la gestione clinica o informare la gestione clinica. ¹⁰

L'IMDRF avverte che questa "non è una classificazione regolatoria". Nel gennaio 2025 ha pubblicato il documento N81, che integra N12 con considerazioni di rischio specifiche per il software per tutti i software per dispositivi medici, compreso il software che fa parte dell'hardware. ¹¹

La Regola 11 dell'EU MDR trasforma la stessa logica in legge:

"Il software destinato a fornire informazioni utilizzate per prendere decisioni a fini diagnostici o terapeutici è classificato nella classe IIa, a meno che tali decisioni non abbiano un impatto che possa causare: — il decesso o un deterioramento irreversibile dello stato di salute di una persona, nel qual caso è nella classe III; o — un grave deterioramento dello stato di salute di una persona o un intervento chirurgico, nel qual caso è classificato nella classe IIb. Il software destinato a monitorare i processi fisiologici è classificato nella classe IIa, a meno che non sia destinato al monitoraggio di parametri fisiologici vitali, laddove la natura delle variazioni di tali parametri sia tale da poter determinare un pericolo immediato per il paziente, nel qual caso è classificato nella classe IIb. Tutti gli altri software sono classificati nella classe I."

Il documento MDCG 2019-11 Rev.1 include una tabella illustrativa che mappa le categorie IMDRF sulle classi MDR. Escludendo la Classe I, le situazioni critiche corrispondono alla Classe III (trattare o diagnosticare), IIb (guidare) e IIa (informare). Le situazioni gravi corrispondono a IIb, IIa e IIa, e quelle non gravi a IIa in tutti i casi. A causa della Regola 11, la maggior parte dei SaMD di supporto alle decisioni nell'UE necessita di un organismo notificato. La proposta della Commissione europea di dicembre 2025 volta a rivedere l'MDR e l'IVDR riscriverebbe la Regola 11 attorno alla matrice IMDRF. Tale proposta è ancora pendente, pertanto si applica l'attuale Regola 11. ¹² Per il quadro completo delle classi UE, consultare la nostra guida alla classificazione EU MDR.

Negli Stati Uniti, il software è classificato come qualsiasi altro dispositivo: in base al codice prodotto e al regolamento di classificazione. La maggior parte dei SaMD rientra nella Classe II. I software di elaborazione di immagini radiologiche (codice prodotto QIH, 21 CFR 892.2050) e i software radiologici di triage e notifica assistiti da computer (QAS, 21 CFR 892.2080) costituiscono esempi tipici. La nostra guida alla classificazione FDA spiega come individuare il codice corretto.

Cosa mostrano i dati del mercato statunitense

Il software basato sull'IA rappresenta la quota in più rapida crescita tra le autorizzazioni di dispositivi di FDA, e quasi la totalità passa attraverso 510(k).

L'elenco dei dispositivi medici abilitati all'IA di FDA conteneva 1.614 voci nell'aggiornamento di settembre 2026, con decisioni definitive fino al 29 giugno 2026. 1.553 (96,2%) erano clearance 510(k), 40 erano concessioni De Novo e 21 erano approvazioni PMA. La radiologia è stata il panel di revisione principale per 1.230 di essi (76,2%), seguita da cardiovascolare (154) e neurologia (73). FDA segnala che l'elenco "non è una risorsa esaustiva di dispositivi medici abilitati all'IA".

Una seconda misurazione proviene dall'analisi condotta da Pure Global sull'export 510(k) di openFDA. Le clearance relative a codici prodotto la cui denominazione del dispositivo per FDA include "software" sono aumentate da 7 nel 2016 a 187 nel 2025, passando dallo 0,2% al 5,8% di tutte le clearance 510(k). Nel 2025, 94 di quei 187 erano software automatizzati per l'elaborazione di immagini radiologiche (QIH). ¹³ Questo dato sottostima i SaMD, perché molti dispositivi software rientrano in codici prodotto che non recano "software" nel nome. Resta comunque una linea di tendenza coerente.

Cosa si attende FDA in una sottomissione SaMD

L'iter è lo stesso previsto per l'hardware. La documentazione è specifica per il software ed è definita da quattro linee guida.

1. Livello di documentazione del software. La linea guida di FDA di giugno 2023 ha sostituito il vecchio "level of concern" con due livelli di documentazione. L'Enhanced Documentation si applica "qualora un guasto o un difetto di qualsiasi funzione software del dispositivo possa presentare una situazione pericolosa con un probabile rischio di morte o lesioni gravi". La valutazione viene effettuata prima dell'applicazione delle misure di controllo del rischio. In caso contrario, si applica la Basic Documentation. ¹⁴
2. Cybersicurezza. La Sezione 524B del FD&C Act, in vigore dal 29 marzo 2023, si applica ai "cyber device". Si tratta di dispositivi che includono software, possono connettersi a Internet e potrebbero essere vulnerabili a minacce di cybersicurezza. Le sottomissioni devono includere un piano di monitoraggio delle vulnerabilità, processi di aggiornamento e patching e una software bill of materials. ¹⁵ La linea guida sulla cybersicurezza di FDA è stata revisionata l'ultima volta il 3 febbraio 2026 per allinearsi al QMSR. ¹⁶
3. Piani di controllo delle modifiche prestabiliti (PCCP). La Sezione 515C consente a FDA di autorizzare in anticipo modifiche future pianificate, in modo tale che le modifiche apportate nell'ambito del piano non richiedano una nuova sottomissione. La linea guida PCCP di FDA per le funzioni software dei dispositivi abilitati all'IA è stata finalizzata il 4 dicembre 2024 e revisionata il 18 agosto 2025. Essa copre 510(k), De Novo e PMA. ¹⁷ Una linea guida PCCP generale per tutti i dispositivi è ancora in bozza da agosto 2024. ¹⁸
4. Ciclo di vita dell'IA. La bozza di linea guida di FDA del 7 gennaio 2025 sulle funzioni software dei dispositivi abilitati all'IA definisce raccomandazioni relative al ciclo di vita e alla sottomissione per l'immissione in commercio. Queste riguardano la gestione dei dati, la descrizione del modello, la validazione delle prestazioni, i bias, la trasparenza e il monitoraggio post-market. A ottobre 2026 era ancora in forma di bozza. ¹⁹ FDA ha inoltre richiesto commenti entro il 19 ottobre 2026 su un documento di discussione sull'IA generativa. ²⁰

Ai sensi del QMSR, la progettazione e sviluppo (clausola 7.3 di ISO 13485) si applica a ogni dispositivo di Classe II e III e ai dispositivi di Classe I automatizzati mediante software. La convalida del software si colloca pertanto all'interno del sistema qualità oltre che nella sottomissione. Consultare la nostra tabella di corrispondenza da 21 CFR 820 a ISO 13485.

Requisiti UE oltre la Regola 11

• Evidenze cliniche. Il documento MDCG 2020-1 richiede tre componenti per ogni MDSW: associazione clinica valida (validità scientifica), prestazioni tecniche o analitiche e prestazioni cliniche. Queste seguono il documento IMDRF N41. ²¹
• Requisito generale di sicurezza e prestazione 17. L'Allegato I richiede che il software sia sviluppato "conformemente allo stato dell'arte tenendo conto dei principi del ciclo di vita dello sviluppo, della gestione dei rischi, compresa la sicurezza delle informazioni, della verifica e della convalida".
• L'AI Act. Il Regolamento (UE) 2024/1689 considera ad alto rischio i sistemi di IA nei dispositivi medici che richiedono la valutazione della conformità da parte di un organismo notificato. Il Digital Omnibus, Regolamento (UE) 2026/1744, pubblicato nella Gazzetta ufficiale il 24 luglio 2026, ha posticipato tali obblighi al 2 agosto 2028. ²² Il documento MDCG 2025-6 spiega come interagiscono l'MDR e l'AI Act. In esso si afferma che l'AI Act "non influisce sulla classificazione del rischio dei dispositivi medici". Il suo riferimento a una data di agosto 2027 precede l'Omnibus. ²³

Come gli altri principali mercati trattano il SaMD

Fonti: ²⁴, ²⁵ e ²⁶. Per l'accesso al mercato specifico per l'IA in oltre 30 paesi, consultate il nostro rapporto di ricerca sull'IA come dispositivo medico.

Le norme tecniche alla base di un fascicolo SaMD

• IEC 62304:2006+A1:2015 definisce i processi del ciclo di vita del software e le classi di sicurezza del software A, B e C. L'edizione 2 è ancora una bozza di comitato e l'IEC ne prevede la pubblicazione nell'ottobre 2028. Pianificate sulla base della versione consolidata del 2015. ²⁷
• IEC 82304-1:2016 riguarda i prodotti software sanitari che funzionano su piattaforme informatiche generiche senza hardware dedicato, una condizione tipica per i SaMD. ²⁸
• IEC 81001-5-1:2021 definisce le attività di sicurezza lungo l'intero ciclo di vita del software sanitario. ²⁹
• La gestione del rischio ISO 14971 e l'ingegneria dell'usabilità IEC 62366-1 si applicano al SaMD come a qualsiasi dispositivo. La nostra guida a ISO 14971 tratta il fascicolo del rischio.

SaMD rispetto a SiMD: cosa cambia nel vostro fascicolo

Errori comuni

• Redigere la destinazione d'uso per ultima. La classificazione, l'evidenza clinica e lo stato di wellness o CDS discendono tutti da essa. Redigetela per prima e mantenete i claim di marketing al suo interno.
• Presumere che "supporto decisionale" significhi "non un dispositivo". Negli Stati Uniti devono essere soddisfatti tutti e quattro i criteri CDS. Nell'UE, la regola 11 colloca la maggior parte dei software di supporto decisionale nella classe IIa o superiore.
• Trattare un'app mobile come una categoria inferiore. Un'app che soddisfa la definizione di SaMD è un SaMD.
• Citare il vecchio "level of concern". La FDA lo ha sostituito con la Basic ed Enhanced Documentation a giugno 2023.
• Pianificare in base alla data dell'AI Act del 2027. Gli obblighi relativi all'alto rischio per i dispositivi medici abilitati all'IA si applicano ora a partire dal 2 agosto 2028.
• Rilasciare aggiornamenti dell'algoritmo senza un piano. Senza un PCCP, una modifica significativa richiede solitamente una nuova sottomissione.

Come aiuta Pure Global

Determiniamo se il software è un dispositivo e redigiamo la destinazione d'uso. Classifichiamo il software in base a FDA, alla regola 11 dell'EU MDR e ad altri sistemi, e prepariamo i fascicoli 510(k) e De Novo con documentazione Basic o Enhanced, contenuti di cybersecurity e PCCP. Il nostro team supporta inoltre le sottomissioni agli organismi notificati dell'UE e le registrazioni in oltre 30 mercati. Consultate la nostra pagina sulla regolamentazione dei SaMD o contattate il nostro team.

Come abbiamo elaborato i numeri

• Dispositivi abilitati all'IA: il nostro conteggio dell'elenco dei dispositivi medici abilitati all'IA di FDA (CSV), aggiornato a settembre 2026. Le decisioni arrivano fino al 29 giugno 2026 e il 2026 è un anno parziale. Le quote per percorso provengono dal prefisso del numero di sottomissione (K, DEN o P).
• Codici prodotto con denominazione software: i codici prodotto nel file dei codici prodotto di FDA datato 12 ottobre 2026 il cui nome del dispositivo contiene "software", abbinati all'esportazione 510(k) di openFDA datata 12 ottobre 2026. Pure Global conserva entrambi nel proprio data lake. I conteggi sono riferiti all'anno solare della decisione.