Caratterizzare i rischi del software medico: cosa dobbiamo imparare dalla guida IMDRF N81 (2025)?

1. Una nuova guida per comprendere meglio i rischi del software

La rapida crescita del software medico, sia esso autonomo (SaMD) o incorporato in un dispositivo, richiede un nuovo approccio alla valutazione dei rischi. Non è più solo il dispositivo a fornire le cure, ma anche le informazioni che genera, filtra o raccomanda. E queste informazioni possono diventare esse stesse una fonte di rischio.

Per aiutare i produttori a gestire questa crescente complessità, l'IMDRF ha pubblicato una nuova guida nel gennaio 2025: IMDRF/SaMD WG/N81 FINAL:2025, sobriamente intitolata "Considerazioni sulla caratterizzazione del software dei dispositivi medici e sul rischio specifico del software".

Questa guida non si limita a ribadire l'ovvio. Fornisce un quadro di riferimento per descrivere meglio il software medico, identificare i fattori di rischio specifici del software e supportare i processi di classificazione normativa e di gestione del rischio.

2. Cosa tratta la guida N81 dell'IMDRF (e cosa non tratta)

La guida N81 si pone come complemento della guida N12 dell'IMDRF del 2014, che proponeva un quadro per la categorizzazione dei SaMD in base al loro impatto clinico. In questo caso, però, l'ambito di applicazione è ampliato: non si parla più solo di SaMD, ma di qualsiasi software che rientri nella definizione di dispositivo medico, compresi quelli incorporati nell'hardware.

Cosa offre:

• Un metodo per descrivere accuratamente il software medico (destinazione d'uso + descrizione funzionale).
• Una lista di controllo per identificare i rischi specifici legati al software, in particolare i rischi informativi.
• Un linguaggio comune per discutere la classificazione dei rischi del software tra gli enti normativi.

Cosa non è:

• Uno strumento di classificazione.
• Uno standard di gestione del rischio.
• Una lista di controllo di requisiti.

Da ricordare:

La guida N81 è uno strumento di caratterizzazione, non un riferimento normativo. Aiuta a strutturare il vostro pensiero, non a convalidare la vostra conformità.

3. Caratterizzazione del software medico: dimensioni da considerare

3.1. Uso previsto: i 7 elementi chiave

La guida propone una chiara strutturazione dell'uso/scopo previsto, articolata su 7 elementi:

1. Scopo medico (diagnosi, trattamento, monitoraggio, ecc.)

2. Malattia o condizione mirata (gravità, stadio, ecc.)

3. Popolazione target (età, vulnerabilità...)

4. Utente target (medico, paziente, caregiver...)

5. Ambiente di utilizzo (casa, ufficio, ospedale...)

6. Controindicazioni (se rilevanti)

7. Funzioni del software: input, output e il loro ruolo nel percorso di cura.

Nell'Appendice A della guida viene proposto un modello di redazione, utile per strutturare le sezioni 1 e 3 della documentazione tecnica.

3.2. Descrizione del software: i 4 assi proposti

La descrizione del software deve coprire 4 aree chiave:

• Problema medico affrontato (scopo del software, livello di gravità, popolazione interessata);
• Contesto d'uso (tipo di utente, ambiente, tempo di utilizzo nel percorso di cura);
• Funzione e utilizzo del software (tipo di output, fonte dei dati, livello di autonomia, spiegabilità, destinatario);
• Gestione del cambiamento (apprendimento, aggiornamento, infrastruttura, implementazione).

4. Caratterizzazione dei rischi del software: concetti utili

La guida N81 sottolinea un punto fondamentale: i rischi del software non sono sempre fisici. Possono essere:

• Informativi (dati errati, mancanti o male interpretati)
• Indiretti (decisioni mediche errate basate sull'output del software)
• Relativi alla riduzione dell'efficienza (distorsioni, perdita di interpretabilità, mancanza di affidabilità)

Esempio: un software che interpreta in modo eccessivo i dati dei sensori può portare a esami non necessari o addirittura a trattamenti inappropriati.

La guida sottolinea anche il legame con la norma ISO 14971: la metodologia di analisi del rischio rimane valida, ma le specificità del software devono essere integrate.

5. Casi di studio: quando la caratterizzazione cambia il livello di rischio

5.1. Esempio 1: diagnosi di pre-diabete mediante un algoritmo

Un software analizza le cartelle cliniche dei pazienti per individuare un probabile prediabete. La guida mostra che:

• Il rischio è moderato, poiché l'errore non comporta alcun pericolo immediato
• Ma l'esclusione di alcuni pazienti (non segnalati dall'algoritmo) è un punto da tenere sotto controllo
• L'autonomia dello strumento e il fatto che certe soglie non siano visibili influenzano la percezione del rischio

Un buon esempio di rischio informativo indiretto, ma reale.

5.2 Esempio 2: terapia del dolore digitale

Si confrontano due scenari:

• Scenario 1: il software viene utilizzato come complemento agli analgesici
• Scenario 2: il software è l'unica terapia possibile (pazienti intolleranti ai farmaci)

Stessa funzione, stesso scopo, ma livelli di rischio molto diversi. In caso di fallimento, il secondo scenario presenta un rischio molto più elevato per il paziente.

6. In pratica: come utilizzare questa guida come produttore

La guida N81 può aiutarvi a:

• Strutturare il vostro fascicolo tecnico fin dalle prime fasi di sviluppo
• Arricchire le analisi del rischio ISO 14971, in particolare per le funzioni algoritmiche
• Chiarire il vostro posizionamento normativo con le autorità o gli enti di controllo.

Lista di controllo da ricordare:

• Definire chiaramente l'uso previsto (utilizzando i 7 elementi)
• Completare i 4 assi di descrizione del software
• Identificare i pericoli specifici per le informazioni e il contesto d'uso
• Valutare l'impatto dell'autonomia e della spiegabilità
• Documentare la gestione delle modifiche del software (aggiornamenti, IA, personalizzazioni).

7. Mini FAQ

Questa guida sostituisce la ISO 14971?

No, la integra. Fornisce elementi specifici per il software.

È obbligatorio seguire le tabelle e le liste di controllo della guida?

No, la guida non ha valore normativo vincolante. È uno strumento di strutturazione.

Può essere utilizzata per il software incorporato?

Sì, il campo di applicazione copre tutti i software che rientrano nella definizione di dispositivo medico (DM).

E se il mio software è in continua evoluzione?

La guida comprende una sezione sulla gestione del cambiamento. Invita a caratterizzare il grado di autonomia e la portata degli aggiornamenti.

La guida tratta gli algoritmi di intelligenza artificiale?

Indirettamente, sì. In particolare attraverso le nozioni di spiegabilità, autonomia e prestazioni scalabili.

8. Conclusioni

La guida IMDRF N81 non è né uno standard né una normativa. È un prezioso strumento di strutturazione, che aiuta ad analizzare e documentare i rischi del software in modo dettagliato e contestualizzato.

Noi di CSDmed aiutiamo i produttori a integrare queste best practice fin dalle prime righe di codice, per proteggere il prodotto e facilitare gli scambi con le autorità.

Avete bisogno di aiuto per caratterizzare o documentare il vostro software medico?

Contattateci. Discuteremo dell'uso clinico, dell'architettura del software e della strategia normativa.

9. Risorse correlate

• ISO 14971 e le start-up: come iniziare l'analisi del rischio senza perdersi
• FDA vs MDR: 5 differenze che contano per un produttore di DM
• ISO 13485 per le start-up: 3 approcci realistici

• Caratterizzazione dei rischi del software medico: cosa ricordare della guida IMDRF N88 (2025)?