Come capire se un software è un dispositivo medico secondo l’MDR
Nel contesto attuale della digitalizzazione della sanità, molti sviluppatori e aziende di applicazioni in ambito healthcare si chiedono se il proprio software debba essere considerato un dispositivo medico ai sensi del Regolamento (UE) 2017/745 (MDR).
La risposta a questa domanda non è sempre immediata: la normativa europea ha introdotto criteri più stringenti e nuove categorie, in particolare per i software, e molte aziende si trovano impreparati ad affrontare gli obblighi regolatori.
In questo articolo, rispondiamo alle 20 domande più frequenti che ci vengono poste da aziende, startup e sviluppatori che operano nel settore della telemedicina, della diagnostica digitale e della gestione dei dati clinici.
Le risposte sono basate sulla normativa vigente, sulle linee guida MDCG e sull’esperienza diretta maturata dal nostro studio di consulenza.
1. Il mio software è un dispositivo medico secondo l’MDR?
Un software è considerato un dispositivo medico se ha una finalità medica esplicita, come diagnosticare, prevenire, monitorare, trattare o alleviare una malattia. La classificazione non dipende dalla tecnologia in sé, ma dall’uso previsto.
2. Quali requisiti deve avere un software per essere classificato come dispositivo medico?
Non tutti i software utilizzati in ambito sanitario sono automaticamente dispositivi medici. La normativa MDR stabilisce criteri ben definiti per distinguere un semplice strumento digitale da un vero e proprio dispositivo medico.
La chiave di lettura è la finalità d’uso dichiarata dal fabbricante: se il software è progettato per finalità diagnostiche, terapeutiche o di monitoraggio clinico, allora deve essere considerato (e gestito) come dispositivo medico, con tutti gli obblighi che ne derivano.
In breve deve:
- Avere una finalità medica specifica;
- Essere destinato all’uso sugli esseri umani;
- Essere autonomo o parte di un sistema;
- Produrre effetti diretti sulla salute o supportare decisioni cliniche.
3. Un’app di monitoraggio della salute è un dispositivo medico?
Dipende: se si limita al benessere generale (es. contare i passi o monitorare il sonno), non è un DM. Ma se monitora parametri vitali per scopi clinici (es. frequenza cardiaca per identificare aritmie), potrebbe esserlo.
4. Che differenza c’è tra software medicale e software benessere (wellness)?
Il software wellness migliora lo stile di vita e non ha finalità mediche. Il software medicale ha uno scopo diagnostico o terapeutico. Il confine può sembrare sottile, ma è decisivo in sede regolatoria.
5. Cosa si intende per finalità medica di un software?
La finalità medica è l’elemento centrale che determina se un software rientra nella definizione di dispositivo medico.
Non si tratta di come il software funzioni tecnicamente, ma di perché è stato progettato e a cosa serve, secondo quanto dichiarato dal fabbricante. Definire correttamente questa finalità è fondamentale per inquadrare il prodotto nel perimetro regolatorio del MDR.
Quindi per finalità medica significa che il software è destinato a:
- Diagnosticare una condizione;
- Monitorare l’andamento di una patologia;
- Sostenere un processo terapeutico;
- Prevenire una condizione patologica.
6. Quando un software è considerato un “accessorio” e non un dispositivo medico?
Secondo il Regolamento (UE) 2017/745, un software può essere qualificato come “accessorio” quando non esercita direttamente una funzione medica, ma è progettato per supportare specificamente uno o più dispositivi medici nella loro funzionalità prevista.
In altre parole, un accessorio non ha una finalità medica autonoma, ma è indispensabile o utile per permettere a un dispositivo medico di funzionare correttamente, oppure ne ottimizza l’uso, facilita la misurazione, o supporta il processo clinico associato al dispositivo.
Facciamo alcuni esempi:
- Un software che consente di calibrare o impostare i parametri di un ventilatore meccanico: è un accessorio del ventilatore.
- Un’app che serve a controllare da remoto una pompa per infusione, senza interpretare dati clinici: anche in questo caso, può essere considerata accessorio, purché non intervenga direttamente nel processo decisionale clinico.
- Un programma che trasmette i dati raccolti da un dispositivo medico a un sistema centrale senza modificarli né interpretarli: è un accessorio, non un DM autonomo.
Se però il software elabora, interpreta o analizza dati clinici al fine di supportare diagnosi, monitoraggio o trattamento, allora diventa esso stesso un dispositivo medico, anche se è utilizzato in combinazione con altri dispositivi.
Cosa prevede il MDR per gli accessori?
Il Regolamento MDR include gli accessori nel proprio campo di applicazione (art. 1.1 e art. 2.2), il che significa che devono comunque essere conformi ai requisiti generali di sicurezza e prestazione, ma la valutazione regolatoria può seguire un percorso diverso, in funzione della classificazione e del rischio associato.
7. Il mio software è un SaMD (Software as a Medical Device)?
Sì, se funziona in modo autonomo, senza essere parte integrante di un hardware medico, e svolge una funzione clinica, rientra nella definizione di SaMD.
8. Il software che elabora dati clinici deve essere marcato CE?
Sì, se l’elaborazione ha finalità clinica (es. supporto alla diagnosi, allerta su valori anomali). Se invece si limita a raccogliere o visualizzare dati, potrebbe non esserlo.
9. Come faccio a classificare il rischio del mio software secondo l’MDR?
Il rischio si basa su:
- Gravità dell’impatto sulla salute;
- Destinazione d’uso;
- Contesto d’uso (es. ospedaliero, domiciliare);
- Conseguenze in caso di malfunzionamento. La classificazione può variare da Classe I a Classe III.
10. Quali sono gli obblighi documentali per software classificati come dispositivi medici?
Un software che rientra nella definizione di dispositivo medico secondo il Regolamento (UE) 2017/745 (MDR) deve essere accompagnato da una documentazione tecnica completa, che dimostri in modo sistematico la conformità ai requisiti essenziali di sicurezza e prestazione. Questi obblighi valgono indipendentemente dalla classe di rischio, sebbene la complessità e il livello di dettaglio varino a seconda della classificazione del dispositivo.
Di seguito, i principali documenti richiesti:
- Fascicolo tecnico
- Analisi dei rischi
- Evidenze cliniche
- Etichettatura e istruzioni per l’uso
- Sorveglianza post-commercializzazione
Fascicolo tecnico (Technical Documentation)
È il cuore della conformità regolatoria. Deve contenere tutte le informazioni che descrivono il software, il suo scopo previsto, il ciclo di vita, le funzionalità, l’architettura, i requisiti normativi applicabili e le verifiche effettuate
Analisi dei rischi (Risk Management)
L’analisi dei rischi, conforme alla norma ISO 14971, è obbligatoria per tutti i dispositivi. Deve identificare, valutare e mitigare i rischi associati all’uso del software
Evidenze cliniche (Clinical Evaluation)
Il produttore deve fornire una valutazione clinica conforme all’allegato XIV del MDR, che dimostri la validità scientifica, la prestazione analitica e la prestazione clinica del software. Può includere:
- Studi clinici o bibliografia scientifica
- Dati post-market (real world evidence)
- Confronto con soluzioni equivalenti già presenti sul mercato.
Etichettatura e istruzioni per l’uso (IFU – Instructions for Use)
Ogni software deve essere corredato da etichettatura e IFU che devono essere conformi ai requisiti indicati al capo III dell’Allegato I del MDR
Sorveglianza post-commercializzazione (PMS – Post-Market Surveillance)
Il produttore è tenuto a implementare un sistema proattivo per raccogliere e analizzare dati sull’utilizzo del software una volta immesso sul mercato. Deve includere:
- Procedure di monitoraggio delle prestazioni e della sicurezza;
- Raccolta di feedback da parte degli utenti;
- Aggiornamenti del software in risposta a eventi avversi o problemi di performance;
- Integrazione dei dati raccolti nel ciclo di miglioramento continuo e nella gestione del rischio.
Piano e report di vigilanza e follow-up clinico post-commercializzazione (PMCF)
Nei casi previsti, soprattutto per i software in Classe IIa o superiore, è richiesto anche un piano di follow-up clinico post-commercializzazione, per monitorare l’efficacia clinica del software nel tempo.
11. Il mio software ha bisogno di una certificazione da un organismo notificato?
Solo se è Classe IIa o superiore. I software Classe I possono essere autocertificati, ma con requisiti tecnici comunque molto rigorosi.
12. Quali normative europee si applicano ai software medicali?
- MDR 2017/745
- Direttive correlate (GDPR per i dati, direttiva sulla cybersecurity)
- ISO 13485 (qualità)
- IEC 62304 (ciclo di vita del software)
13. Esistono linee guida per determinare se un software è un dispositivo medico?
Sì: la MDCG 2019-11 è la guida ufficiale più completa per interpretare la definizione di software come dispositivo medico o meno.
14. Cosa dice la linea guida MDCG 2019-11 sul software?
Fornisce criteri decisionali (con diagrammi di flusso) per stabilire se un software ha una finalità medica, se è parte di un dispositivo o è autonomo, e come deve essere classificato.
15. Come cambia la classificazione dei software con il nuovo MDR rispetto alla MDD?
Il passaggio dalla Direttiva 93/42/CEE (MDD) al Regolamento (UE) 2017/745 (MDR) ha avuto un impatto significativo sulla classificazione dei software medicali. Il nuovo regolamento ha introdotto criteri più stringenti, in particolare attraverso l’introduzione della regola 11 dell’Allegato VIII, dedicata specificamente ai software.
Prima (MDD): classificazione più permissiva
Sotto la MDD, molti software venivano classificati come Classe I, spesso in modo quasi automatico, in assenza di un’interazione fisica diretta con il paziente o di funzioni considerate “critiche”. Il testo normativo non conteneva una regola specifica per i software, lasciando ampie zone grigie e spazi di interpretazione.
Dopo (MDR): nuova Regola 11 per i software
Con il MDR, la classificazione dei software è diventata molto più dettagliata e restrittiva. La regola 11 prevede che la classe di rischio non dipenda tanto dall’hardware collegato, ma piuttosto dalla funzione del software stesso e dalle conseguenze cliniche del suo utilizzo.
Ecco cosa dice, in sintesi, la Regola 11:
- Classe IIa: se il software è destinato a fornire informazioni usate per decisioni diagnostiche o terapeutiche.
- Classe IIb: se da tali decisioni può derivare un rischio grave per il paziente (es. danni irreversibili, interventi chirurgici).
- Classe III: se il software è utilizzato per decisioni che possono avere conseguenze letali o invalidanti.
- Classe I: solo se il software non ha scopo medico diretto oppure se fornisce supporto amministrativo o di gestione senza impatto sulla salute.
Molti software che sotto la MDD erano in autocertificazione (Classe I), oggi devono passare per un Organismo Notificato, con una valutazione più rigorosa.
Questo comporta nuovi obblighi documentali, verifiche cliniche più strutturate e tempi più lunghi di accesso al mercato.
Le aziende devono rivedere la propria strategia di sviluppo e validazione del software per adeguarsi alla nuova classificazione.
16. Il software usato da medici deve sempre essere certificato come DM?
Solo se ha una finalità medica diretta. Se è un semplice strumento gestionale o amministrativo, no. Ma se aiuta a diagnosticare o a decidere terapie, sì.
17. Il software che supporta decisioni cliniche è un dispositivo medico?
Sì. I CDSS (Clinical Decision Support System) sono dispositivi medici se influenzano direttamente il processo clinico.
18. Un algoritmo di intelligenza artificiale è un dispositivo medico?
Se il suo output ha influenza clinica (es. diagnosi automatica), allora sì. L’AI non è esente dalle regole del MDR, anzi richiede maggiore attenzione.
19. Posso vendere il mio software senza marcatura CE?
Solo se non è un dispositivo medico. Se lo è, la marcatura CE è obbligatoria per la commercializzazione nell’UE.
20. Qual è la differenza tra software “stand-alone” e software incorporato in un DM?
Lo stand-alone è indipendente (es. app mobile). Il software incorporato funziona solo all’interno di un dispositivo (es. firmware di una pompa infusiva). Entrambi possono essere regolati dal MDR.
Come possiamo aiutarvi?
Determinare se un software è un dispositivo medico non è solo una questione normativa, ma anche strategica e di responsabilità legale. Una classificazione errata può portare a blocchi nella commercializzazione, sanzioni o richiami di prodotto.
Il nostro studio di consulenza ha maturato una lunga esperienza nell’affiancare aziende, startup e sviluppatori del settore software e health tech nel:
- Valutare la corretta classificazione del software;
- Predisporre fascicoli tecnici, analisi dei rischi e documentazione per la marcatura CE;
- Interagire con gli organismi notificati;
- Supportare la conformità normativa anche su temi correlati come GDPR e cybersecurity.
Se hai dubbi sul tuo software o vuoi pianificare una strategia regolatoria su misura, contattaci senza impegno. Siamo qui per rendere semplice ciò che sembra complesso.
Previous Post
