IVDR e software IVD: come qualificare e classificare correttamente il vostro software

Dall'entrata in vigore del Regolamento (UE) 2017/746 (IVDR) nel maggio 2022, il mondo della diagnostica in vitro (IVD) è cambiato radicalmente. Uno dei cambiamenti più importanti? Il ruolo ormai cruciale degli organismi notificati: Si stima che quasi l'80% dei prodotti IVD debba essere valutato da un organismo notificato per ottenere l'etichettatura CE

In questo contesto, il software utilizzato negli IVD solleva molte domande:

• Tutti i software sono interessati?
• Quando il software deve essere considerato un dispositivo medico IVD?
• Quali sono gli errori da evitare per evitare un blocco della valutazione?

Questo articolo riassume queste domande sulla base del documento di posizione pubblicato da Team-NB, l'associazione europea degli organismi notificati, il 17 giugno 2025.

1. Informazioni legali importanti

Uno sguardo al passato: prima della IVDR, la Direttiva 98/79/CE prevedeva un coinvolgimento relativamente limitato degli organismi notificati. Il nuovo regolamento, invece, basa la classificazione dei dispositivi sui rischi associati all'uso previsto, e il software è al centro di questo processo.

Nel 2019, l'MDCG (Medical Device Coordination Group) ha pubblicato un documento di orientamento(MDCG 2019-11) che chiarisce la qualificazione e la classificazione del software ai sensi sia dell'MDR che dell'IVDR. Tuttavia, molti produttori hanno ancora difficoltà ad applicare questi testi ai loro casi. Ecco perché il documento di posizione del Team NB è così utile: chiarisce cosa si aspettano gli organismi notificati.

2. Che cos'è il software IVD ai sensi della IVDR?

Per MDSW, o software per dispositivi medici, si intende qualsiasi software destinato a uno scopo medico, come definito nella IVDR:

• Indipendente (ad esempio, un'applicazione di analisi NGS autonoma).
• Integrato in un sistema (ad esempio il firmware dell'analizzatore).
• Come modulo o accessorio.

Punto chiave: alcuni software combinano moduli con uno scopo medico e altri senza (ad esempio, gestione dell'inventario, archiviazione pura). Ogni modulo deve essere chiaramente delineato e documentato.

3. 3 scenari per qualificare il vostro software

Il documento di sintesi fornisce un chiaro diagramma del flusso decisionale per aiutarvi a prendere la decisione giusta. Ecco una versione semplificata.

➊ Software che controlla o influenza un dispositivo

Ad esempio, firmware, modulo di controllo del motore. In questo caso, il software viene valutato come parte integrante del sistema IVD. Nessuna classificazione separata.

➋ Software autonomo per IVD

Ad esempio, applicazione NGS, software di analisi delle immagini per lo screening del cancro. In questo caso, il software è un IVD autonomo. Deve essere classificato in base all'uso previsto e deve avere una propria documentazione tecnica.

➌ Software accessorio

Ad esempio, middleware, convertitore di formato di immagine per l'analisi AI. In questo caso il software non ha uno scopo medico diretto, ma supporta un dispositivo IVD. È classificato come accessorio ed è comunque soggetto ai requisiti IVDR.

Nota: l'uso previsto è il filo conduttore

4. Esempi pratici: Come si presenta nella vita reale?

Esempio 1

Software di analisi delle sequenze NGS per l'individuazione di anomalie genetiche ereditarie. Fornisce direttamente un risultato diagnostico → IVD-MDSW indipendente.

Esempio 2

Un'applicazione mobile che elabora i dati sulla glicemia per generare avvisi e regolare le dosi di insulina. Scopo diagnostico o terapeutico → IVD MDSW.

Esempio 3

Un modulo middleware che converte le immagini dei vetrini bioptici per l'elaborazione AI. Non ha uno scopo medico proprio, ma abilita il processo → Accessori.

5. Errori concettuali da evitare

• L'ipotesi che un software cloud o un modulo di visualizzazione siano sempre fuori dal campo di applicazione: Tutto dipende dall'uso previsto.
• Mescolare moduli medici e non medici senza chiari confini: Documentate la separazione.
• Dimenticare che la classificazione dell'intero sistema è decisiva: un modulo integrato deve seguire la classificazione del sistema.

6. FAQ - le domande più frequenti

Che cos'è il software non-IVD?

Ad esempio LIMS, ERP, gestione del magazzino: nessuna elaborazione dei dati a fini diagnostici → fuori dal campo di applicazione dell'IVDR.

Un LIMS rientra nell'ambito dell'IVDR?

No, a meno che una parte del sistema non venga utilizzata per la valutazione diagnostica. Allora questo modulo deve essere qualificato come IVD-MDSW.

Che dire del software basato su cloud?

Il luogo non conta (cloud, PC, mobile): conta solo l'uso previsto.

Il mio software è venduto separatamente: cosa devo fare?

Verificare se è destinato all'uso IVD stand-alone o come parte di un sistema. Questo determina la procedura di valutazione.

Posso qualificare un modulo come "non medico"?

Sì, ma è necessario dimostrare che non ha un'interazione diretta con i dati diagnostici. I confini e le interfacce devono essere chiari.

7. Conclusione: la chiave è lo scopo previsto

Per evitare ostacoli nella revisione da parte dell'organismo notificato, dovreste sempre chiedervi: "Qual è l'effettivo uso previsto?". Formulatelo chiaramente, giustificate le vostre decisioni e documentate i vostri moduli. E in caso di dubbio: non correre rischi inutili.

Se non siete sicuri di come qualificare o classificare il vostro software, CSDmed può aiutarvi a rendere sicuro il vostro percorso IVDR e a evitare sorprese dell'ultimo minuto durante la valutazione CE.

Contattateci per discutere i vostri progetti.

Potrebbe interessarvi anche questo articolo: Nuova linea guida MDCG 2025-4: requisiti per le applicazioni software per dispositivi medici su piattaforme online