Software e dispositivi medici: cosa deve sapere chi sviluppa tecnologia per la salute

Immaginiamo uno scenario sempre più comune: un'azienda tecnologica o un gruppo di ricerca universitaria sviluppa un'applicazione che supporta i medici nella diagnosi di una malattia o uno strumento digitale per la riabilitazione post ictus o, ancora, il software integrato in un esoscheletro che seleziona gli esercizi più adatti al paziente. Siamo nel 2026 e questi prodotti non sono più fantascienza: esistono, si diffondono e devono fare i conti con un quadro normativo europeo preciso e vincolante.

La domanda che molti produttori e ricercatori si pongono è legittima: posso sviluppare questo software senza preoccuparmi di obblighi normativi particolari? La risposta tipica del diritto è: dipende. Dipende da cosa fa concretamente il software e da quale uso ne ha previsto il fabbricante.

Il quadro normativo

Dal 26 maggio 2021 è pienamente operativo in tutta l'Unione Europea il Regolamento UE n. 745 del 2017 sui dispositivi medici, che ha sostituito le previgenti direttive europee in materia. A esso si affianca il Regolamento UE n. 746 del 2017 sui dispositivi medico-diagnostici in vitro. In Italia, il Decreto legislativo n. 137 del 2022 completa il quadro nazionale.

La novità fondamentale del Regolamento 745/2017 riguarda proprio il software: per la prima volta, la normativa include espressamente il software nella definizione di dispositivo medico, superando ogni ambiguità interpretativa precedente.

Quando il software diventa dispositivo medico

Non tutti i software in ambito sanitario rientrano nella categoria dei dispositivi medici. Il criterio decisivo è la destinazione d'uso dichiarata dal fabbricante — in inglese, intended use — ossia lo scopo per il quale il prodotto è stato progettato e commercializzato.

Il Regolamento definisce dispositivo medico “qualunque […] software […] destinato dal fabbricante a essere impiegato sull'uomo, […] per una o più delle seguenti destinazioni d'uso mediche specifiche:

— diagnosi, prevenzione, monitoraggio, previsione, prognosi, trattamento o attenuazione di malattie;

— diagnosi, monitoraggio, trattamento, attenuazione o compensazione di una lesione o di una disabilità;

— studio, sostituzione o modifica dell'anatomia oppure di un processo o stato fisiologico o patologico;

— fornire informazioni attraverso l'esame in vitro di campioni provenienti dal corpo umano, inclusi sangue e tessuti donati”.

Restano invece esclusi i software a finalità generale, anche se usati in contesti sanitari, e quelli destinati al benessere e allo stile di vita. Un esempio concreto: uno smartwatch che misura il battito cardiaco con scopo fitness non è un dispositivo medico. Lo diventa se lo stesso produttore lo commercializza come strumento di monitoraggio clinico funzionale a decisioni terapeutiche. Anche le cartelle cliniche elettroniche e i software di sola archiviazione dati restano fuori dal perimetro, poiché non svolgono funzioni diagnostiche o terapeutiche dirette.

Il confine non dipende dalla tecnologia in sé, ma dall'intenzione dichiarata dal fabbricante. Questo rende la fase di definizione degli obiettivi del prodotto un momento cruciale sotto il profilo giuridico.

Classi di rischio e obblighi

Stabilire se un software è un dispositivo medico non è un esercizio teorico: determina obblighi concreti, la cui violazione è sanzionata con importi a cinque cifre come previsto dal Decreto legislativo 137/2022.

Il Regolamento classifica i dispositivi medici — software incluso — in quattro classi di rischio crescente: I, IIa, IIb e III. Per il software dispositivo medico (SWMD), la Regola n. 11 dell'Allegato VIII prevede che ricada in classe I, salvo eccezioni: classe IIa per software che monitorano processi fisiologici o supportano decisioni diagnostiche; classe IIb per quelli con rischi seri per la salute o usati in ambito chirurgico; classe III per quelli che possono determinare rischi di morte o danni irreversibili.

A classi più alte corrispondono obblighi più stringenti: sistema di gestione della qualità conforme agli standard internazionali, gestione del rischio e documentazione tecnica da sottoporre agli organi competenti. Questi adempimenti valgono anche per i prototipi usati in indagini cliniche, non solo per i prodotti già sul mercato.

L'ulteriore variabile: l'Intelligenza Artificiale

Quando un software dispositivo medico incorpora algoritmi di intelligenza artificiale, il fabbricante deve dimostrare la conformità sia al Regolamento sui dispositivi medici sia al Regolamento UE n. 1689 del 2024 sull'Intelligenza Artificiale (AI Act). Anche quest'ultimo adotta un approccio basato sul rischio, imponendo sistemi di gestione della qualità analoghi a quelli già previsti per i dispositivi medici.

Conclusioni

Lo sviluppo di software in ambito clinico richiede una consapevolezza giuridica che va ben oltre la competenza tecnica. Gli obblighi normativi non nascono al momento dell'immissione sul mercato: accompagnano il prodotto dall'ideazione allo sviluppo, dalla fase prototipale all'utilizzo clinico. Ignorare queste norme significa esporsi a sanzioni significative e al rischio di dover bloccare prodotti già avviati. La strada corretta è quella di un approccio multidisciplinare: legali, tecnici e clinici che collaborino fin dall'inizio per garantire la conformità del prodotto al quadro normativo di riferimento.