Valutazione Clinica dei Dispositivi Medici Software: Dall'Articolo 61 alla Real World Evidence

L’avvento del Regolamento (UE) 2017/745 (MDR) ha segnato un cambio di paradigma per il mondo dei Dispositivi Medici, inclusi quelli software, ridefinendo radicalmente il concetto di ‘valutazione clinica‘.

Se in passato, sotto la precedente Direttiva 93/42/CEE (MDD), la conformità tecnica e una solida verifica del codice venivano spesso considerate sufficienti, oggi il baricentro si è spostato sulla Clinical Evaluation. Sotto l’MDD, infatti, era frequente ricorrere a ‘scorciatoie’ basate sull’equivalenza con prodotti esistenti o su una semplice revisione della letteratura per confermare lo stato dell’arte. L’MDR ha drasticamente ridotto questi spazi, specialmente per i dispositivi ad alto rischio, esigendo che l’evidenza clinica sia specifica, solida e intrinseca al dispositivo.

Non è più sufficiente dimostrare che ‘la tecnologia è nota’; è necessario provare che il proprio software, operando nel suo specifico contesto d’uso, generi un beneficio clinico misurabile. Che si tratti di un SaMD (Software as a Medical Device, es. un’app di telemedicina) o di un SiMD (Software in a Medical Device, es. il firmware di un ventilatore polmonare), l’obbligo di dimostrare sicurezza e prestazione clinica attraverso dati rigorosi rappresenta oggi il cuore pulsante dell’Articolo 61.

Oltre il codice: il Triangolo della Conformità

Per un software medico, la dimostrazione della conformità clinica non è un blocco monolitico, ma si poggia su tre pilastri fondamentali definiti dalla linea guida MDCG 2020-1:

Validità Scientifica: Esiste un’associazione clinica valida tra l’output del software e la condizione clinica target? Es. l’analisi della variabilità della frequenza cardiaca può essere considerato un indicatore valido per lo stress?.
Prestazione Analitica: Il software elabora i dati correttamente? È accurato, ripetibile e riproducibile? Qui parliamo di bug-free e performance tecniche.
Prestazione Clinica: Il software produce un beneficio clinico per il paziente in condizioni d’uso normali? Nel SaMD la prestazione clinica è spesso legata all’algoritmo di elaborazione dati, nel SiMD ,invece,essa è indissociabile dal dispositivo fisico che il firmware gestisce

Mentre i primi due punti possono spesso essere risolti tramite analisi o validazioni effettuati anche solo tramite simulazione al computer o dataset storici, è sulla Prestazione Clinica che il ‘mondo reale’ smette di essere opzionale e diventa protagonista, richiedendo al fabbricante di dimostrare il valore aggiunto del dispositivo nel contesto clinico effettivo

Real World Evidence e l’Articolo 61

L’Articolo 61, comma 4, specifica che per i dispositivi di classe III e gli impiantabili è generalmente richiesta un’indagine clinica, pur prevedendo deroghe nel caso di dispositivi sostanzialmente equivalenti a dispositivi dello stesso fabbricante già commercializzati .

Invece per i Dispositivi medici software che tipicamente ricadono all’interno delle altre classi (I, IIa o IIb), la sfida regolatoria è fornire evidenza clinica sufficiente senza dover necessariamente ricorrere alla complessità di un’indagine clinica ai sensi dell’Articolo 62. In questo scenario, la Real World Evidence (RWE) diventa lo strumento strategico per eccellenza.

Se il fabbricante è in grado di dimostrare, attraverso dati raccolti nel mondo reale (RWD) su versioni precedenti del software (appartenenti ad esempio ad applicazioni legacy certificate MDD) o su propri dispositivi equivalenti, che i risultati clinici sono consistenti e sicuri, tale documentazione può essere presentata come evidenza clinica sufficiente ai fini dell’Articolo 61. Questo approccio permette di sostenere la conformità basandosi su flussi di dati generati dall’uso effettivo, rendendo talvolta superflua l’esecuzione di un’indagine clinica pre-market strutturata, spesso poco compatibile con i rapidi cicli di rilascio del software.

Questi flussi di dati, essenziali per la valutazione clinica, si declinano in modo differente sulla base della tipologia di dispositivo e, la quantità di dati reali necessari, dipende strettamente dal profilo di rischio e dal grado di novità del software:

Rappresentatività vs Quantità: Non serve raccogliere “tutto” il mondo reale, ma è cruciale assicurare la rappresentatività del campione. Un dataset di 10.000 pazienti raccolti in un solo centro può essere meno significativo di 500 pazienti eterogenei distribuiti su 10 infrastrutture IT diverse.
SaMD (Software as a Medical Device): L’attenzione è rivolta alla variabilità dei dati in ingresso (es. immagini diagnostiche, dati vitali, ecc.). Qui il “mondo reale” serve a mitigare il rischio di bias algoritmici, garantendo che il software mantenga l’accuratezza su popolazioni diverse da quelle di addestramento.
SiMD (Software in a Medical Device): Il focus si sposta sull’affidabilità nel tempo. Poiché il firmware interagisce con componenti fisiche soggette a usura, i dati reali (es. log di telemetria sulla deriva di un sensore) permettono di dimostrare, ad esempio, che il sistema compensa correttamente il degrado hardware, fornendo una prova di sicurezza clinica continua per l’intero ciclo di vita del dispositivo.

Il ruolo strategico del PMCF (Post-Market Clinical Follow-up)

Ai sensi dell’Articolo 61, comma 11, la valutazione clinica non è un traguardo statico, ma un processo dinamico che deve essere aggiornato per l’intero ciclo di vita del dispositivo attraverso i dati del PMCF (Post-Market Clinical Follow-up)

Per il software, questo implica un cambio di prospettiva fondamentale: il ‘mondo reale’ non è solo il requisito d’ingresso per la marcatura CE, ma il pilastro che ne garantisce la permanenza sul mercato. Un piano di PMCF ben strutturato, capace di raccogliere dati clinici significativi, agisce di fatto come una ‘indagine clinica continua‘, permettendo di dimostrare che ogni aggiornamento del software rimane conforme ai requisiti di sicurezza e prestazione senza dover ricorrere a nuove, costose indagini cliniche per ogni singola release.

L’MDR ha trasformato il PMCF da semplice adempimento burocratico a vero e proprio strumento di validazione continua. Per un software, il PMCF rappresenta l’opportunità di capitalizzare l’uso dei cosiddetti dati clinici ‘nativi’ cioé quelli che vengo generati durante l’uso attraverso :

Telemetria e Feedback: la capacità del software di inviare automaticamente al fabbricante dati sul suo stato e sul suo utilizzo come un flusso costante di evidenze cliniche oggettive
Evoluzione Strategica: la raccolta di evidenze che dimostrano la capacità del software di fornire un supporto documentale necessario per l’estensione dell’uso previsto (Intended Use) o per l’eventuale riclassificazione del dispositivo, consentendo di evolvere il prodotto senza dover ripartire da zero ad esempio con un Indagine clinica ad hoc.

Qualità e Integrità dei dati

L’utilizzo di RWD (Real World Data) non rappresenta una scorciatoia per aggirare il rigore scientifico. Affinché la RWE possa validamente integrare o sostituire un’indagine clinica formale, il fabbricante deve dimostrare una qualità metodologica di grado elevato. Feedback aneddotici non sono generalmente accettabili : i dati devono essere raccolti secondo protocolli definiti, garantendo l’assenza di bias e la piena conformità al principio ALCOA+ (dati Attribuibili, Leggibili, Contemporanei, Originali, Accurati, più gli attributi di Completezza, Coerenza, Enduring e Disponibilità).

Ogni Piano di Valutazione Clinica (CEP) deve affrontare in modo proattivo le seguenti sfide critiche:

Qualità e Standardizzazione del dato: I dati del mondo reale sono intrinsecamente “sporchi”. Spesso presentano valori mancanti, formati eterogenei o assenza di ontologie cliniche standardizzate. Senza un solido processo di pulizia e normalizzazione, il dato è inutilizzabile per fini regolatori.
Data Integrity e Privacy (GDPR): La raccolta di RWD deve essere conforme al Regolamento UE 2016/679. La pseudonimizzazione è il requisito tecnico minimo, ma la sfida normativa risiede nella corretta gestione del consenso informato (o di una base giuridica alternativa prevista all’interno del GDPR) per l’uso dei dati clinici a fini della Valutazione Clinica.
Mitigazione dei Bias: Il rischio maggiore della RWE risiede nell’amplificazione di errori sistematici. Se i dati reali riflettono prassi cliniche consolidate ma errate, o se presentano discriminazioni in termini di etnia, genere o età (bias di campionamento), l’algoritmo — specialmente se basato su AI — rischia di perpetuare o amplificare tali distorsioni, compromettendo la sicurezza del paziente.

In sintesi, la robustezza della valutazione clinica non dipende dalla quantità di dati raccolti, ma dalla capacità del fabbricante di governare l’intero ciclo di vita del dato. È fondamentale sottolineare che nessun dataset, per quanto vasto, può essere utilizzato per scopi regolatori senza essere stato preventivamente sottoposto a un rigoroso processo di convalida. Tale convalida deve verificare l’accuratezza del dataset, la coerenza delle etichette (specialmente per sistemi AI) e la sua effettiva rappresentatività rispetto al contesto d’uso dichiarato. (cfr. articolo MODALITÀ DI VALIDAZIONE DI UN DATABASE CLINICO ) Solo dopo aver validato la fonte e la metodologia di estrazione si può procedere all’analisi che genererà la RWE, garantendo così che ogni punto informativo sia attendibile, tracciabile e privo di distorsioni cognitive o tecniche.

Conclusioni

In sintesi, l’integrazione intelligente della Real World Evidence nella strategia regolatoria permette di soddisfare i rigorosi requisiti dell’Articolo 61 MDR in modo dinamico. Utilizzando il “mondo reale” come laboratorio, il fabbricante può dimostrare la prestazione clinica in modo continuo, ottimizzando i tempi di immissione in commercio e garantendo una sorveglianza post-market che è, di fatto, la prova effettiva dell’efficacia del software.