Software POCT: il confine tra semplice trasmissione del dato e dispositivo medico
Una sentenza della Corte di giustizia del 2 luglio 2026 riporta al centro la destinazione d’uso e la funzione oggettiva dei prodotti sanitari. Nel mondo dei POCT la conseguenza è concreta: archiviare e stampare un risultato non equivale a interpretarlo, ma basta aggiungere un algoritmo, un allarme o un comando remoto perché il perimetro regolatorio possa cambiare.
Tra un analizzatore e un referto, molto spesso, c’è un cavo.
Dentro quel cavo passa un numero. Ma attorno a quel numero si muovono software, server, interfacce, archivi, soglie, grafici, allarmi e, sempre più spesso, algoritmi di interpretazione.
È qui che nasce una delle domande più sottovalutate della diagnostica di prossimità: quel programma è davvero soltanto un middleware oppure è diventato un software medicale o un IVD?
La risposta non dipende dal nome scelto nel contratto, nella brochure o sulla schermata iniziale. Dipende dalla destinazione d’uso dichiarata, dalle funzioni effettive e dal modo in cui il software interviene sul dispositivo e sull’informazione clinica.
Chiamarlo “piattaforma”, “gestionale”, “LIS”, “middleware” o “semplice collegamento” non risolve la qualificazione. Esattamente come chiamarlo “medicale” non basta, da solo, a trasformarlo in un dispositivo.
La sentenza europea che cambia il modo di porre la domanda
Il 2 luglio 2026 la Corte di giustizia dell’Unione europea ha pronunciato la sentenza nella causa C-427/24, Zentrale contro Diagramm Halbach.
Il caso non riguardava un software né un POCT, ma braccialetti identificativi per pazienti consegnati senza stampa e privi di marcatura CE come dispositivi medici. Il fabbricante li presentava come strumenti capaci di migliorare la sicurezza del paziente e ridurre gli errori di identificazione.
La Corte ha stabilito che quei braccialetti non erano dispositivi medici. Ha però chiarito un principio più ampio: la destinazione d’uso formulata dal fabbricante è un elemento fondamentale, ma non è l’unico. Occorre anche verificare se il prodotto sia oggettivamente capace di svolgere una delle funzioni mediche previste dal regolamento.
In altre parole, non basta il racconto commerciale. Conta ciò che il prodotto fa realmente.
La sentenza riguarda il MDR e non decide direttamente la qualificazione di un software IVD. Applicarla automaticamente ai middleware POCT sarebbe scorretto. Tuttavia, il suo ragionamento offre una chiave interpretativa coerente con le indicazioni europee sul software: né il contesto sanitario né l’etichetta scelta dal produttore possono sostituire l’analisi funzionale.
Il primo equivoco: “gestisce dati sanitari, quindi è un dispositivo”
Non tutto il software utilizzato in sanità è un dispositivo medico.
La Commissione europea, nella MDCG 2019-11 rev.1 del giugno 2025, distingue le funzioni che si limitano a:
- memorizzare;
- archiviare;
- comunicare o trasferire dati;
- eseguire una ricerca semplice;
- effettuare una compressione senza perdita.
Se il software si limita realmente a ricevere un risultato già completo e comprensibile dall’analizzatore, associarlo al paziente, conservarlo e riprodurlo senza modificarne il significato clinico, può non qualificarsi come Medical Device Software.
Un LIS o un Work Area Manager non è quindi automaticamente un dispositivo medico. Può essere un’infrastruttura amministrativa e informativa che organizza dati prodotti altrove.
Ma la stessa guida europea aggiunge immediatamente una precisazione: all’interno di un sistema non medicale possono esistere moduli che, considerati singolarmente, svolgono una funzione medica e devono essere qualificati autonomamente.
È il primo punto decisivo: non si classifica soltanto il contenitore; si analizzano anche i suoi moduli e le singole funzioni.
Quando il software oltrepassa il confine
Il confine può essere superato quando il programma elabora, analizza, interpreta, calcola, crea o modifica informazioni mediche per una finalità diagnostica, prognostica, di monitoraggio o di supporto alla decisione.
Nel mondo POCT questo può accadere, per esempio, quando il software:
- combina più risultati dello stesso paziente per produrre uno score clinico;
- applica un algoritmo interpretativo e propone una possibile condizione patologica;
- genera raccomandazioni, priorità o azioni sulla base del risultato;
- emette un allarme clinico progettato dal fabbricante e destinato a influenzare la gestione del paziente;
- modifica la rappresentazione del dato allo scopo di evidenziare un reperto diagnostico;
- interpreta dati grezzi provenienti dall’analizzatore, come densità ottiche, curve o segnali, trasformandoli in un risultato clinicamente utilizzabile;
- confronta automaticamente dati diversi e produce nuova informazione riferita al singolo paziente.
L’elemento determinante non è che il software “faccia diagnosi da solo”. Anche fornire informazioni destinate a sostenere una decisione diagnostica può essere sufficiente a farlo rientrare nel perimetro medicale.
Esiste tuttavia una zona intermedia. La MDCG osserva che operazioni elementari, come conversioni di unità, calcolo di una media, visualizzazione nel tempo o confronto con limiti impostati dall’utente, non rendono necessariamente il programma un IVD quando il risultato originario rimane leggibile e comprensibile senza il suo intervento.
La valutazione cambia se le soglie sono definite dal fabbricante con una finalità clinica, se il sistema combina informazioni, genera nuovi significati o induce una scelta assistenziale. Non è quindi il simbolo rosso sullo schermo a decidere la qualificazione: conta il motivo per cui è stato progettato e l’azione che è destinato a provocare.
Il secondo confine: controllare o influenzare l’analizzatore
Un software può non avere una finalità diagnostica autonoma e, ciò nonostante, rientrare nel quadro MDR o IVDR perché controlla, aziona o influenza un dispositivo.
È il caso di programmi destinati a:
- avviare o interrompere l’analisi;
- modificare parametri operativi dell’analizzatore;
- gestire calibrazioni o procedure di controllo elettronico;
- cambiare lo stato del dispositivo;
- trasferire comandi che influenzano la prestazione;
- fornire informazioni determinanti sul funzionamento dell’hardware.
La MDCG cita espressamente il software utilizzato per comandare un analizzatore di chimica clinica e quello dotato di controlli elettronici per le procedure di qualità dell’IVD.
L’allegato VIII dell’IVDR, Regolamento (UE) 2017/746, stabilisce inoltre che il software che guida o influenza l’uso di un dispositivo ricade nella stessa classe del dispositivo; se è indipendente, deve essere classificato autonomamente.
Questo rende particolarmente delicati gli aggiornamenti da remoto. Un programma che si limita a installare un pacchetto firmato e validato potrebbe avere un ruolo tecnico circoscritto. Se invece seleziona parametri, interviene sulla calibrazione, modifica algoritmi o cambia il comportamento dell’analizzatore, la sua qualificazione e la ripartizione delle responsabilità devono essere rivalutate.
“Classe A” non significa sempre la stessa cosa
Nel settore software circola una confusione pericolosa: quella tra classe A IVDR e software safety class A secondo IEC 62304.
Non sono la stessa cosa.
Le classi A, B, C e D dell’IVDR rappresentano la classificazione regolatoria degli IVD in funzione del rischio e della destinazione d’uso. Le classi di sicurezza software della IEC 62304 riguardano invece la severità del possibile danno associato a un guasto del software e determinano la profondità dei processi documentali del ciclo di vita.
La IEC 62304 definisce infatti processi, attività e compiti per sviluppo e manutenzione del software medicale. Non decide però, da sola, se un prodotto sia o non sia un dispositivo e non sostituisce la qualificazione ai sensi di MDR o IVDR.
Scrivere “software di classe A” senza indicare il sistema di riferimento genera quindi ambiguità. Peggio ancora, attribuire una classe A IVDR soltanto perché il programma non formula una diagnosi esplicita può condurre a una classificazione errata.
La sequenza corretta è diversa:
- descrivere tutte le funzioni e la destinazione d’uso;
- stabilire se il software sia non medicale, accessorio, parte del dispositivo oppure MDSW autonomo;
- individuare se ricada sotto MDR o IVDR;
- applicare le regole di classificazione pertinenti;
- definire il percorso di conformità e le evidenze necessarie.
La classe non si sceglie per convenienza. È la conseguenza dell’analisi.
Sette modifiche che possono trasformare un middleware
Molti software nascono come semplici strumenti di trasmissione e, nel tempo, acquisiscono nuove funzioni. È il fenomeno del feature creep: ogni aggiornamento sembra piccolo, ma la somma degli aggiornamenti può cambiare la natura regolatoria del prodotto.
Il confine dovrebbe essere riesaminato quando vengono introdotti:
- commenti interpretativi automatici;
- intervalli decisionali o soglie cliniche definite dal produttore;
- allarmi che suggeriscono un invio urgente o una scelta terapeutica;
- score ottenuti combinando risultati e dati anamnestici;
- intelligenza artificiale per interpretazione o previsione;
- funzioni che modificano parametri, calibrazioni o algoritmi dell’analizzatore;
- priorità automatiche basate sulla criticità clinica del singolo paziente.
La funzione può essere inserita in un modulo separato, ma la separazione grafica non è sufficiente. Occorre documentare architettura, interdipendenze, flussi di dati, interfacce e impatto delle funzioni medicali su quelle non medicali.
La domanda da porre a ogni nuova release dovrebbe essere: abbiamo migliorato soltanto l’organizzazione del dato oppure abbiamo iniziato a produrre nuova informazione clinica?
Se non è un dispositivo, non significa che sia senza regole
Un middleware che non ricade sotto MDR o IVDR non entra per questo in una zona franca.
Se tratta risultati associati a persone identificabili, tratta dati relativi alla salute. Il Regolamento generale sulla protezione dei dati impone di definire ruoli, basi giuridiche, finalità, tempi di conservazione, accessi e responsabilità. L’articolo 32 richiede misure tecniche e organizzative adeguate al rischio, comprese riservatezza, integrità, disponibilità, resilienza, ripristino e verifica periodica dell’efficacia delle misure.
Restano inoltre necessari:
- validazione delle interfacce e dei protocolli;
- gestione degli errori di associazione paziente-risultato;
- audit trail e controllo degli accessi;
- cifratura e gestione delle credenziali;
- backup verificati e procedure di ripristino;
- tracciamento delle versioni;
- gestione documentata degli aggiornamenti;
- verifica della corrispondenza tra risultato originario e documento stampato;
- contratti coerenti tra sviluppatore, fornitore, titolare e responsabile del trattamento.
La sicurezza del paziente può essere compromessa anche da un software non medicale: basta associare il risultato alla persona sbagliata, perdere un decimale, cambiare unità di misura o non rendere disponibile un dato critico. Il rischio clinico non determina da solo la qualificazione regolatoria, ma deve comunque essere governato.
Il contratto non può correggere l’architettura
Definire contrattualmente un programma “semplice middleware” è utile soltanto se la descrizione coincide con ciò che il software fa davvero.
Il contratto dovrebbe individuare con precisione:
- funzioni incluse ed escluse;
- titolarità del codice e licenza d’uso;
- soggetto che autorizza e valida gli aggiornamenti;
- responsabilità per configurazione, manutenzione e assistenza remota;
- gestione degli incidenti e delle vulnerabilità;
- tempi di conservazione e localizzazione dei dati;
- ruoli privacy;
- continuità operativa e restituzione dei dati;
- procedura di change control regolatorio.
La consegna del codice sorgente non trasferisce automaticamente la qualità del processo di sviluppo. La proprietà del server non attribuisce, da sola, tutti i ruoli privacy. E la denominazione inserita in una clausola non modifica la funzione oggettiva di un algoritmo.
La vera verifica per una rete POCT
In una farmacia, in uno studio medico o in una rete territoriale il software dovrebbe essere analizzato come parte del processo diagnostico complessivo.
Occorre seguire il dato dalla sua origine alla sua destinazione:
analizzatore → interfaccia → identificazione del paziente → elaborazione → visualizzazione → stampa → archivio → eventuale LIS/FSE → decisione e follow-up.
Per ogni passaggio bisogna chiedere:
- il valore viene modificato?
- l’unità viene convertita?
- una soglia viene applicata?
- nasce un nuovo significato clinico?
- il software invia comandi all’analizzatore?
- un errore viene registrato e reso visibile?
- chi può correggere il dato e con quale traccia?
- l’operatore vede ancora il risultato originario?
Soltanto dopo questa mappatura è possibile sostenere seriamente che il programma sia un middleware non medicale, un accessorio, una componente del dispositivo o un software medicale autonomo.
La riga di codice più rischiosa
Per anni il dibattito sui POCT si è concentrato sull’analizzatore: accuratezza, campione, controlli, manutenzione e destinazione d’uso.
Ora una parte crescente del rischio si sta spostando nel software. Non perché ogni piattaforma debba essere medicalizzata, ma perché la digitalizzazione tende ad aggiungere interpretazione, automazione e decisione a strumenti nati per trasferire dati.
La riga di codice più rischiosa non è necessariamente quella che contiene un errore. Può essere quella perfettamente funzionante che introduce una nuova finalità clinica senza che nessuno riapra la valutazione regolatoria.
Un software non diventa sicuro perché viene chiamato middleware. E non diventa medicale perché compare la parola “sanitario” nella brochure.
Diventa ciò che è progettato e oggettivamente capace di fare.
Quante piattaforme oggi utilizzate nelle reti POCT sono state valutate funzione per funzione — e quante, invece, continuano a vivere sotto una definizione scelta anni fa, prima dell’ultimo aggiornamento?