Risposta breve: quando un software ha uno scopo medico (diagnosi, prevenzione, monitoraggio, previsione, prognosi, trattamento), è un dispositivo medico ai sensi del Regolamento sui Dispositivi Medici dell'UE (MDR, 2017/745) e riceve una classe di rischio: I, IIa, IIb o III, principalmente in base alla Regola 11 dell'Allegato VIII. La classe decide se è possibile l'autocertificazione (solo classe I) o se è necessario un organismo notificato, quanto approfondita debba essere la valutazione clinica e come debba funzionare la sorveglianza post-vendita. Separatamente, lo standard di ingegneria IEC 62304 assegna al software una classe di sicurezza: A (nessun danno possibile), B (possibile danno non grave) o C (possibile morte o danno grave), che decide quanta documentazione, progettazione e test richiede il ciclo di vita. Le due classificazioni sono correlate ma indipendenti, ed entrambe sono determinate dal danno che il software potrebbe causare, non dalla sua complessità.
Fase 1: è un dispositivo?
Il software è considerato un dispositivo medico secondo il MDR UE quando il suo scopo è medico: diagnosi, prevenzione, monitoraggio, previsione, prognosi o trattamento (Articolo 2(1)). Il software che si limita a memorizzare, archiviare, comunicare, visualizzare o cercare dati non è un dispositivo; il software che crea o modifica informazioni mediche per supportare una decisione diagnostica o terapeutica lo è, secondo il MDCG 2019-11.
La definizione del MDR (Articolo 2(1)) si basa sullo scopo previsto. Il software che memorizza, archivia, comunica, visualizza o esegue semplici ricerche sui dati non è un dispositivo (MDCG 2019-11 lo specifica). Il software che crea o modifica informazioni mediche per supportare una diagnosi o una decisione terapeutica lo è. Un referto che mostra un valore di laboratorio con l'intervallo di riferimento del laboratorio non lo è; il software che indica all'utente che il valore indica una condizione, o raccomanda un dosaggio, lo è. Vedere Un'app per la salute è un dispositivo medico? per la fase di qualificazione in dettaglio.
Fase 2: la classe di rischio MDR, Regola 11
La Regola 11 del MDR classifica il software dei dispositivi medici in base al danno che una decisione errata potrebbe causare. Il software che fornisce informazioni per decisioni diagnostiche o terapeutiche è di classe IIa per impostazione predefinita, classe IIb se tali decisioni possono causare un grave peggioramento o un intervento chirurgico, e classe III se possono causare morte o un deterioramento irreversibile. Il software di monitoraggio è di classe IIa, o IIb per parametri vitali.
| Software destinato a… | Classe MDR |
|---|---|
| fornire informazioni utilizzate per prendere decisioni a fini diagnostici o terapeutici (il valore predefinito) | IIa |
| …dove tali decisioni possono causare morte o un deterioramento irreversibile della salute | III |
| …dove tali decisioni possono causare un grave deterioramento della salute o un intervento chirurgico | IIb |
| monitorare processi fisiologici (il valore predefinito) | IIa |
| …monitorare parametri fisiologici vitali dove variazioni potrebbero comportare un pericolo immediato per il paziente | IIb |
| qualsiasi altro caso (software che è un dispositivo ma nessuno dei precedenti) | I |
La Regola 11 ha fatto sì che la maggior parte del software precedentemente classificato come classe I rientrasse nella IIa o superiore, il che è il motivo principale per cui il MDR è stato percepito come un cambiamento epocale per la salute digitale. MDCG 2019-11 e il quadro di rischio IMDRF (significato delle informazioni × stato della situazione sanitaria) aiutano a posizionare i casi limite. Il software che controlla o influenza un dispositivo hardware assume la classe di tale dispositivo (Regola 3.3 delle norme di attuazione).
Conseguenze per classe: la classe I è autocertificata con un fascicolo tecnico e registrazione, senza organismo notificato (eccetto Im, Is, Ir); la IIa richiede una valutazione da parte di un organismo notificato del sistema di qualità e un campione della documentazione tecnica; la IIb lo stesso con un esame più approfondito della documentazione; la III una revisione completa della documentazione tecnica e, ove pertinente, la consultazione di un panel di esperti. Tutte le classi necessitano di un sistema di gestione della qualità, una valutazione clinica proporzionata alla classe, una persona responsabile della conformità normativa, UDI, registrazione in EUDAMED, sorveglianza post-vendita e vigilanza.
Fase 3: la classe di sicurezza del software IEC 62304
La classe di sicurezza del software IEC 62304 valuta il software dei dispositivi medici in base al danno peggiore a cui potrebbe contribuire, dopo i controlli di rischio esterni: classe A quando non è possibile alcun infortunio, classe B quando è possibile un infortunio non grave, classe C quando è possibile la morte o un infortunio grave. La classe determina quanto rigore è richiesto nella progettazione, verifica e documentazione del ciclo di vita del software.
IEC 62304 (2006, modificato nel 2015) è lo standard armonizzato per i processi del ciclo di vita del software dei dispositivi medici. La sua classe di sicurezza deriva dalla peggiore situazione di pericolo a cui il software può contribuire, dopo aver considerato le misure di controllo del rischio esterne al software:
| Classe | Situazione di pericolo potrebbe portare a… | Cosa richiede il ciclo di vita |
|---|---|---|
| A | nessun danno o danno alla salute | Piano di sviluppo del software, requisiti, rilascio; risoluzione dei problemi; gestione della configurazione |
| B | danno non grave | A: più progettazione architetturale, verifica dell'integrazione e test di sistema, verifica unitaria documentata |
| C | morte o danno grave | B: più progettazione dettagliata per ogni unità, segregazione architetturale aggiuntiva, verifica più rigorosa |
Le classi sono assegnate per sistema software e possono essere assegnate per elemento software dopo la scomposizione, in modo che solo le parti rischiose portino il rigore della classe C; lo standard spiega l'argomentazione di segregazione che ciò richiede. ISO 14971 (gestione del rischio) alimenta la classificazione; IEC 82304-1 aggiunge requisiti a livello di prodotto per il software sanitario che funziona su piattaforme generiche (telefoni, cloud).
Come interagiscono
La classe di rischio MDR e la classe di sicurezza IEC 62304 sono indipendenti: la classe MDR (da I a III) decide il percorso normativo e il coinvolgimento dell'organismo notificato, mentre la classe IEC 62304 (da A a C) decide il rigore del processo di ingegneria. Un'app di classe IIa può essere di classe 62304 B o C a seconda del danno che un output errato potrebbe causare.
La classe MDR riguarda il percorso normativo; la classe IEC 62304 riguarda il processo di ingegneria. Un'app di classe IIa secondo la Regola 11 potrebbe essere di classe B secondo IEC 62304 (informazioni errate potrebbero portare a un ritardo non grave nelle cure) o di classe C (se un suggerimento di dosaggio errato potesse uccidere). Un dispositivo di classe I è solitamente di classe A secondo IEC 62304, ma non necessariamente. Gli organismi notificati si aspettano che il fascicolo tecnico mostri la classe IEC 62304 con la sua giustificazione, i documenti del ciclo di vita a quel livello e il collegamento al fascicolo di gestione del rischio. La cybersecurity (MDCG 2019-16, IEC 81001-5-1) viene valutata insieme.
Esempio pratico
Un esempio pratico di SaMD: un'app per il monitoraggio dei sintomi che registra, visualizza e condivide i sintomi non è un dispositivo medico. L'aggiunta di una funzionalità che valuta i sintomi rispetto a una scala validata e indica all'utente quando cercare assistenza la rende un dispositivo, di classe IIa MDR per impostazione predefinita, con classe IEC 62304 B, o classe C per un caso d'uso cardiaco.
Un'app di tracciamento dei sintomi che consente agli utenti di registrare i sintomi, visualizzare le tendenze e condividerle con il proprio medico: non è un dispositivo (memorizzazione, visualizzazione, comunicazione). La stessa app aggiunge una funzione che valuta i sintomi registrati rispetto a una scala convalidata e indica all'utente quando il punteggio suggerisce che dovrebbe cercare assistenza: ora è un dispositivo, classe IIa di default secondo la Regola 11 (informazioni per una decisione diagnostica; un errato "non è necessario cercare assistenza" potrebbe ritardare il trattamento, grave ma non tipicamente irreversibile, quindi non IIb o III a meno che la condizione target non lo renda tale). IEC 62304: una falsa rassicurazione potrebbe portare a un ritardo nelle cure, da non grave a grave a seconda della condizione, quindi classe B, possibilmente C per un caso d'uso cardiaco. Percorso: QMS ISO 13485, organismo notificato, valutazione clinica della scala, ingegneria dell'usabilità (IEC 62366-1), sorveglianza post-vendita.
Gli Stati Uniti, in breve
Negli Stati Uniti, la FDA regola il software come dispositivo medico in base all'uso previsto, con classi I, II e III e i percorsi 510(k), De Novo e PMA. Il 21st Century Cures Act esclude dallo status di dispositivo il software amministrativo, i prodotti per il benessere generale, le cartelle cliniche elettroniche e alcuni sistemi di supporto decisionale clinico. La FDA riconosce la IEC 62304 come standard di consenso.
La FDA regola il software come dispositivo medico secondo la stessa logica dello scopo previsto, con classi I, II e III e percorsi 510(k), De Novo e PMA. Il 21st Century Cures Act (sezione 3060) ha rimosso diverse categorie dallo status di dispositivo: software amministrativo, benessere generale, cartelle cliniche elettroniche e supporto decisionale clinico che consente al medico di rivedere in modo indipendente la base della raccomandazione (la guida CDS 2022 della FDA la interpreta in modo restrittivo). La FDA riconosce IEC 62304 come standard di consenso e, dal 2023, richiede la documentazione sulla cybersecurity per i "dispositivi cyber". ISO 13485 è diventato la base della normativa sui sistemi di qualità statunitensi (QMSR) nel 2026.
In Anpheros
Anpheros Daily memorizza, visualizza e condivide; non valuta, interpreta o raccomanda, e il suo scopo previsto lo dichiara. Pertanto, non è un dispositivo medico secondo la Regola 11 o le esclusioni del Cures Act, e il team applica la sicurezza in stile ISO 27001 e pratiche software documentate senza il percorso del dispositivo. Se venisse mai aggiunta una funzione con uno scopo medico, verrebbe classificata secondo la Regola 11 e sviluppata secondo IEC 62304 prima del rilascio. Vedere Trasparenza sanitaria.
Questa pagina spiega la regolamentazione per i team di prodotto e ingegneria. Non costituisce consulenza legale; i testi collegati sotto Fonti fanno fede, e il tuo responsabile della protezione dei dati, organismo notificato o consulente decide per il tuo caso. Ultima revisione: Ottobre 2026.
Pagine correlate
- Un'app per la salute è un dispositivo medico? EU MDR Regola 11
- MDR vs IVDR
- CDS Hooks spiegato
- Mappa della regolamentazione dei dati sanitari
- L'AI Act dell'UE e l'IA sanitaria
Fonti
- Regolamento (UE) 2017/745 (MDR), Allegato VIII, EUR-Lex
- MDCG 2019-11: Qualificazione e classificazione del software
- IEC 62304:2006+AMD1:2015, Processi del ciclo di vita del software dei dispositivi medici
- IEC 82304-1:2016, Sicurezza dei prodotti software sanitari
- FDA: Guida sul software di supporto decisionale clinico (2022)
- FDA: Software come dispositivo medico
Domande frequenti
Il software può essere di classe I secondo il MDR?
Sì, ma raramente: solo il software con uno scopo medico che non informa decisioni diagnostiche o terapeutiche né monitora processi fisiologici. La maggior parte delle app che si qualificano come dispositivi rientra nella IIa.
Un dispositivo di classe IIa richiede studi clinici?
Richiede una valutazione clinica, che può basarsi su letteratura, equivalenza e dati di performance; un'indagine clinica è richiesta quando le prove esistenti sono insufficienti. Il software che dichiara una performance diagnostica di solito necessita di un proprio studio di performance.
IEC 62304 è obbligatorio?
È uno standard armonizzato, quindi seguirlo è la presunzione di conformità ai requisiti software del MDR (Allegato I, 17). È possibile utilizzare un approccio diverso, ma si deve poi dimostrare l'equivalenza, cosa che in pratica nessuno fa.
E le funzionalità AI?
Si applicano le stesse regole, più l'AI Act dell'UE: un dispositivo con valutazione di un organismo notificato è un sistema AI ad alto rischio secondo l'Allegato I, con requisiti su dati, logging, trasparenza e supervisione umana valutati insieme al MDR.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →