Fino a poco tempo fa, anche in America, il confine tra un semplice software informativo e un Dispositivo Medico (SaMD – Software as a Medical Device) era una linea sottile e spesso punitiva per l’innovazione. Sviluppare un algoritmo di supporto clinico significava quasi certamente entrare nel tunnel delle certificazioni di prodotto.
Tuttavia, l’aggiornamento della FDA (Food and Drug Administration) di inizio 2026 ha segnato una svolta interpretativa senza precedenti. Mentre l’Europa prosegue sulla strada del rigore con l’MDR (Medical Device Regulation), gli Stati Uniti hanno deciso di puntare sulla trasparenza del software piuttosto che sulla sua classificazione forzata.
In questo articolo esploreremo la fine del “dogma delle raccomandazioni multiple” e perché oggi un software negli USA può fare molto di più senza essere regolamentato come un dispositivo medico, a differenza di quanto accade nel nostro continente.
Una nuova era per il Digital Health : La novità FDA 2026
Il cuore del cambiamento risiede nell’interpretazione dei Clinical Decision Support (CDS).
Clinical Decision Support (CDS). sono una soluzione di tecnologia informatica sanitaria che rappresenta un insieme di sistemi di supporto alle decisioni cliniche , che analizzano i dati provenienti dalle cartelle cliniche elettroniche , dalle linee guida cliniche e dalle basi di conoscenza medica. per fornire agli operatori sanitari informazioni, avvisi e raccomandazioni basate sull’evidenza in tempo reale e immediatamente utilizzabili.
Questi sistemi utilizzano regole, protocolli o intelligenza artificiale per fornire supporto diagnostico, raccomandazioni sul dosaggio dei farmaci, avvisi sulle interazioni farmacologiche e promemoria per la cura preventiva
i moderni CDS sono in genere integrati direttamente nelle cartelle cliniche elettroniche o nei sistemi di inserimento computerizzato degli ordini medici, offrendo informazioni al momento giusto
I principali vantaggi di questi Sistemi sono:
- Migliore sicurezza del paziente : riduzione degli errori di somministrazione dei farmaci e migliore gestione delle malattie croniche
- Maggiore efficienza: semplificazione dei flussi di lavoro e riduzione del tempo necessario per recuperare informazioni specifiche sui pazienti
- Migliori risultati clinici: maggiore aderenza alle linee guida sulle migliori pratiche e standardizzazione delle cure ha portato, ad esempio, alla riduzione dei tassi di mortalità in terapia intensiva
- Medicina personalizzata: utilizzo di big data e IA per personalizzare le terapie per i singoli pazienti
FDA, attraverso linee guida quali la Clinical Decision Support Software : Guidance for Industry and Food and Drug Administration Staff ha cercato di regolamentare l’utilizzo delle CDS sulla base delle indicazioni fornite da una legge approvata dal Congresso USA, la 21st Century Cures Act, che aveva lo scopo di accelerare l’innovazione medica e dove si stabiliva chiaramente che alcuni tipi di software (tra cui molti CDS) non sono più da considerarsi dispositivi medici.
Cosa accadde nel 2022
Sulla base delle indicazioni di tale legge, FDA fece uscire fra il 2017 e il 2019 alcune bozze della linea guida che erano impostate in linea a quanto indicava la 21st Century Cures Act e quindi molto aperta e favorevole all’industria: si concentrava quasi esclusivamente sul fatto che il software dovesse essere trasparente. Se uno sviluppatore forniva le fonti scientifiche, la FDA era disposta a considerare il software “fuori” dalla regolamentazione, quasi indipendentemente dalla criticità della malattia
Nella versione finale del Settembre 2022 é arrivata una “stretta” improvvisa dovuta al timore che i medici si fidassero troppo dei software e quindi ha portato ad inserire regole che sostenevano che, per non essere considerato un dispositivo medico, un software non dovesse “decidere” al posto del medico.
Questo veniva tradotto in una regola pratica: il software doveva offrire una lista di opzioni. Se l’algoritmo suggeriva un’unica strada (es. “Somministra il farmaco X”), veniva considerato un dispositivo medico perché “sostituiva” il giudizio umano.
La svolta del 2026
Con l’aggiornamento della Linea guida del gennaio 2026, la FDA ha cercato di inserire una sintesi equilibrata che si basa sul fatto che la medicina basata sull’evidenza spesso porta ad una sola scelta corretta. Per cui un software può anche fornire una raccomandazione singola , purché la trasparenza sia reale e non solo formale
Cioè una raccomandazione singola e specifica può far considerare un software comunque come un “Non-Device” (quindi libero da trafile quali la 510k), a patto che rispetti il criterio della trasparenza verificabile. Cioé non conta quante opzioni offri, ma quanto il medico è in grado di capire perché gli stai dando quel suggerimento. Se il medico può verificare la fonte (linee guida, studi) in tempo reale, la sua indipendenza è preservata
In sostanza per capire se un applicazione software NON sia da considerarsi un Dispositivo Medico sulla base della Linea Guida FDA, é necessario veificare queste quattro condizioni:
- Input di basso rischio: Il software non deve analizzare immagini mediche (TAC, MRI) o segnali biologici (ECG in tempo reale). Deve lavorare su dati testuali o numerici (es. valori di laboratorio)
- Supporto, non sostituzione: La funzione deve essere di supporto al professionista sanitario, non di sostituzione totale
- Indipendenza del clinico: Il medico deve rimanere l’arbitro finale
- Trasparenza (Criterio d’oro): Il software deve mostrare le basi logiche. Se l’utente clicca su “perché?”, il sistema deve citare la letteratura scientifica di riferimento
L’impostazione europea; il regolamento MDR
L’approccio europeo, cristallizzato nel Regolamento (UE) 2017/745 (MDR), è profondamente diverso da quello statunitense. Se la FDA si sta muovendo verso una “de-regolamentazione selettiva” basata sulla trasparenza, l’Europa ha costruito una fortezza normativa basata sul rischio potenziale
Secondo l’Articolo 2 dell’MDR, un software è un dispositivo medico MDSW (Medical Device Software) se ha una finalità medica specifica, come:
- Diagnosi, prevenzione, monitoraggio, previsione o prognosi di una malattia
- Trattamento o attenuazione di una malattia, ferita o handicap
- Controllo del concepimento
All’interno di tali finalità mediche é fondamentale che Il software elabori i dati per creare una nuova informazione medica. In pratica :
- Se un software si limita a memorizzare, trasmettere o visualizzare (es. una cartella clinica elettronica che mostra solo i PDF dei referti), non è un dispositivo medico
- Se il software analizza quei dati (es. calcola il rischio cardiovascolare incrociando i valori), allora lo è
La Classificazione e lo scoglio della “Regola 11”
Una volta stabilito che è un dispositivo medico, bisogna assegnargli una classe (I, IIa, IIb, III). Qui entra in gioco la famigerata Regola 11 dell’Allegato VIII, il vero “spauracchio” degli sviluppatori europei. Tale Regola recita (sintetizzando):
- I software destinati a fornire informazioni utilizzate per prendere decisioni a fini diagnostici o terapeutici sono in Classe IIa
- Tuttavia, se tali decisioni possono causare la morte o un deterioramento irreversibile della salute, salgono in Classe III.
- Se possono causare un grave deterioramento della salute o un intervento chirurgico, sono in Classe IIb.
- Tutti gli altri software sono in Classe I.
Sotto la vecchia direttiva (MDD), moltissimi software erano in Classe I (autocertificati). Con l’MDR e la Regola 11, la situazione è drasticamente cambiata : infatti la Regola 11 dice che se il software fornisce informazioni per decisioni diagnostiche o terapeutiche, parte già dalla IIa
Considerando quindi che quasi ogni software medico “serio” serve a supportare una diagnosi o una terapia, la Classe I rimane confinata a casi marginali, come:
- Software che non forniscono decisioni terapeutiche dirette, ma solo supporto amministrativo o di “lifestyle” con un vago nesso medico (es. un diario della fertilità che non dà indicazioni contraccettive)
- App che non analizzano dati in modo critico per una patologia specifica
Per cui la comunità regolatoria sta arrivando a una conclusione pragmatica: un software medico in Classe I è oggi una rarità estrema Infatti, l’interpretazione prevalente è che se un software è abbastanza utile da essere considerato un “Medical Device”, allora l’informazione che fornisce ha un peso tale che un suo errore comporterebbe almeno un rischio moderato per il paziente. Di conseguenza, il “salto” automatico in Classe almeno IIa è quasi inevitabile
Questa considerazione porta quindi l’ “aggravante” che per tutti i software medicali che sono considerati come Dispositivi Medici non basta l’autocertificazione, ma é necessario l’intervento di un Ente di Notifica con tutti i problemi di tempi e costi che questa scelta comporta
FDA vs. MDR: Trasparenza Vs. Sicurezza
In conclusione :
L’FDA scommette sulla cultura del medico: “Se ti do gli strumenti per capire, sei tu il responsabile della decisione”
L’MDR parte dal concetto che: “Il software deve essere certificato perché l’errore informatico è un rischio clinico inaccettabile, indipendentemente dalla trasparenza“.
Questa divergenza crea una discrepanza competitiva: una startup americana può lanciare un Software Medicale “trasparente” senza autorizzazioni pesanti, basandosi sulla responsabilità del medico. La stessa startup, per lanciare lo stesso software in Europa, deve affrontare costi di certificazione elevati e tempi lunghi (12-18 mesi) per ottenere la marcatura CE da un Organismo Notificato, perché l’MDR non si fida della sola “trasparenza“, ma pretende una validazione clinica certificata da terzi
Ad esempio oggi è sicuramente più facile e veloce lanciare un nuovo software di supporto clinico basato su IA negli Stati Uniti piuttosto che in Italia o in Germania. Consigli per chi sviluppa software medicale IA oggi:
- PCCP (Predetermined Change Control Plan): Se punti agli USA, sfrutta i PCCP per l’IA. Ti permettono di aggiornare l’algoritmo senza chiedere nuovi permessi ogni volta
- Modularità: Se il tuo software ha una parte “CDS” e una parte “diagnostica”, separale. Potresti scoprire che metà del tuo prodotto non necessita di certificazione negli USA, riducendo i costi
- Non dare per scontata l’armonizzazione: Ciò che la FDA approva come “semplice tool”, per il Ministero della Salute italiano rimane un dispositivo medico che richiede marcatura CE
La tendenza interpretativa della FDA del 2026 ci lancia un messaggio chiaro: l’intelligenza artificiale e il software non devono essere temuti se sono “aperti”. La fine del dogma delle opzioni multiple è un atto di fiducia verso la classe medica e un acceleratore per la sanità digitale.
L’Europa seguirà questa strada o rimarrà ancorata al rigore burocratico dell’MDR? Per ora, chi vuole innovare velocemente guarda (purtroppo) oltreoceano.
Commenti recenti