MDCG 2019-11 rev.1: Cosa cambia con la nuova versione per il software medico e IVD

Dal 2019, la guida MDCG 2019-11 è un riferimento per i produttori di software per dispositivi medici (MDSW) e di software diagnostico in vitro (IVD MDSW). In pratica, però, la prima versione lasciava molte zone d'ombra: casi limite irrisolti, mancanza di chiarezza riguardo ai moduli software e interpretazioni diverse della regola 11.

La versione rivista, pubblicata il 17 giugno 2025, va ben oltre gli aggiornamenti estetici. Apporta sostanziali chiarimenti concettuali e operativi, con una forte attenzione al concetto di scopo previsto, alle strutture software modulari e alle interazioni con altri regolamenti come l'EHDS.

Questo articolo analizza i principali cambiamenti, delinea le implicazioni concrete per i produttori e offre scenari pratici per aiutarvi ad adattare i vostri prodotti e la vostra documentazione tecnica.

1. Promemoria: di cosa tratta l'MDCG 2019-11?

La guida si concentra su due concetti fondamentali:

• Qualificazione: determinare se un prodotto software rientra nella MDR o nella IVDR e si qualifica come dispositivo medico o accessorio.
• Classificazione: assegnazione della classe di rischio appropriata al software in base alla sua destinazione d'uso (in particolare ai sensi della regola 11 della MDR).

Si occupa anche di casi speciali:

• software che guida o influenza un dispositivo medico,
• differenziazione tra MDSW e moduli non medici,
• software distribuito nel cloud, su dispositivi mobili o incorporato nell'hardware.

Lo scopo previsto è centrale: determina la qualificazione, la classificazione e i requisiti normativi applicabili.

2. Cosa cambia con la Revisione 1 (giugno 2025)

2.1 Chiarimenti introdotti

• Estensione del campo di applicazione per includere il software di cui all'Allegato XVI (prodotti senza finalità mediche, ad esempio dispositivi estetici).
• Scopo previsto: la guida sottolinea la necessità di una dichiarazione di scopo chiara, precisa e inequivocabile: ogni funzione con scopo medico deve essere giustificata clinicamente.
• Approccio modulare: Il documento riconosce che il software può essere suddiviso in moduli. Alcuni moduli possono essere MDSW, altri no. Il produttore deve:
• definire chiaramente i confini funzionali;
• documentare le interazioni;
• dimostrare che i moduli non medici non compromettono la sicurezza o le prestazioni dei moduli medici.
• Interoperabilità con i sistemi EHR: La guida incorpora i nuovi requisiti dello Spazio europeo dei dati sanitari (EHDS). La dichiarazione di interoperabilità comporta ulteriori obblighi.

2.2 Nuovi esempi

• Casi di software destinati alla cura (in particolare per la salute mentale, la riabilitazione, i disturbi alimentari).
• Software terapeutico che utilizza la realtà virtuale o giochi interattivi.
• Esempi in cui i moduli non medici sono essenziali per il funzionamento, ma non rientrano nella MDR/IVDR, purché i confini siano ben documentati.
• Un raro esempio di software di Classe I (applicazione di comunicazione assistita per pazienti affetti da autismo o paralisi cerebrale).

2.3 Classificazione e regola 11

Il documento chiarisce le tre sottoregole:

• 11a: software che fornisce informazioni utilizzate per decisioni diagnostiche o terapeutiche,
• 11b: software per il monitoraggio di processi fisiologici,
• 11c: tutti gli altri software

Include inoltre una matrice utile basata sulla gravità della situazione clinica e sull'impatto del software sulle decisioni mediche, in linea con il quadro IMDRF.

3. Scenari pratici: Cosa significa per voi

Caso 1 - Software di riabilitazione modulare

Uno sviluppatore costruisce una piattaforma di riabilitazione che comprende:

• un modulo terapeutico di realtà virtuale (MDSW),
• un modulo di monitoraggio amministrativo (non MDSW),
• un modulo per tracciare il coinvolgimento del paziente.

Cosa dice la Revisione 1

• Ogni modulo deve essere valutato separatamente.
• Il modulo terapeutico è classificato sotto la regola 11.
• I moduli non medici devono essere documentati e la loro interazione analizzata nella documentazione tecnica.

Caso 2 - Software collegato a un EHR

Uno strumento di supporto alle decisioni è integrato con un sistema EHR certificato.

Cosa dice la Revisione 1

• Se il produttore dichiara l'interoperabilità, è richiesta anche la conformità all'EHDS (specifiche di interoperabilità, documentazione, cybersicurezza)
• La sola qualificazione MDR non è più sufficiente: il quadro normativo diventa duplice.

4. Domande frequenti (FAQ)

1. Il mio software rimane di Classe IIa se non ho modificato l'algoritmo?

Non necessariamente. Ciò che conta è l'impatto sulle decisioni mediche. Anche senza modifiche tecniche, la vostra posizione normativa potrebbe evolvere in base alle nuove linee guida.

2. Posso dichiarare i moduli non medici come "fuori campo"?

Sì, ma solo se si può giustificare che non hanno alcun impatto sulla sicurezza o sulle prestazioni del MDSW.

3. Il cloud hosting influisce sulla classificazione del mio software?

No. La classificazione dipende dallo scopo previsto, non dall'implementazione tecnica. Tuttavia, possono essere applicati ulteriori requisiti (cybersecurity, tracciabilità, disponibilità). Vedere anche: Nuova guida MDCG 2025-4: Requisiti per le applicazioni di software per dispositivi medici su piattaforme online.

4. Cosa succede se voglio collegare il mio software a un EHR?

Dovrete essere conformi sia all'EHDS che all'MDR/IVDR. È richiesto uno specifico dossier di interoperabilità.

5. Il mio software era precedentemente considerato non MDSW. Devo riqualificarlo?

È possibile. I casi limite sono ora affrontati più chiaramente e possono essere considerati MDSW.

5. Cosa devono fare ora i produttori

• Rivalutare lo scopo previsto con l'allineamento clinico.
• Mappare l'architettura del software: moduli, flussi di dati, interfacce.
• Riqualificare i moduli borderline alla luce dei nuovi esempi.
• Aggiornare la documentazione tecnica: giustificazione della classificazione, analisi dell'interfaccia, conformità EHDS, se applicabile.
• Rivalutare le strategie di valutazione clinica e delle prestazioni per ciascun modulo.

6. Conclusione

Questo non è solo un aggiornamento minore: consolida il quadro interpretativo e risolve finalmente alcune ambiguità di lunga data (indicazioni di trattamento, logica modulare, interoperabilità), rafforzando al contempo la richiesta di una solida giustificazione.

Questo richiederà un lavoro da parte dei produttori, ma offre anche un'opportunità: costruire architetture software e fascicoli tecnici più solidi, chiari e difendibili.

Avete bisogno di un supporto strategico?

Noi di CSDmed aiutiamo i produttori a:

• strutturare lo scopo e l'architettura del software,
• classificare il software secondo la logica MDR/IVDR,
• ed allinearsi ai requisiti MDR, IVDR, AIA e EHDS senza complicare eccessivamente lo sviluppo.

Sviluppare un prodotto software per la salute? Iniziate con le basi giuste. Parliamone.