Salute Digitale

Aver adottato per il software clinico la stessa norma dei dispositivi medici è stato, a mio giudizio, una forzatura che crea false aspettative.

Il concetto di Software As a Medical Device e le procedure previste per la sua certificazione secondo la MDR dovrebbero, in teoria, garantire la qualità delle soluzioni cliniche così normate. A differenza però di un dispositivo medico, per i quali la normativa MDR è stata concepita, il software clinico è molto più complesso e articolato. Aver adottato la stessa norma per il software clinico è stato, a mio giudizio, una forzatura che crea false aspettative. Vediamo di capire perché.

Una pila impossibile da governare

Una moderna soluzione software è composta da un’ampia serie di “strati software” che partono dal sistema operativo, a sua volta un mondo di elevata complessità e articolazione, per poi includere le componenti per la persistenza dei dati, quelle della virtualizzazione e della distribuzione, la sicurezza, le librerie e le API per varie funzioni (firma elettronica, grafica, creazione documenti, etc..), sino ad arrivare al livello della presentazione, con tutte le differenze tra i diversi browser.

Tutte queste componenti sono oggetto di un ciclo di cambiamento molto frequente, sia per la risoluzione di errori e malfunzionamenti, sia per motivi di sicurezza, sia ancora per la loro evoluzione tecnica e funzionale. Ci sono infinite combinazioni della pila tecnologica che un software clinico richiede e che spesso ha componenti condivise con altri software in uso. La sua gestione, a carico dei servizi informativi delle aziende sanitarie, viene spesso eseguita tenendo conto dei vincoli tra più software e della effettiva disponibilità degli aggiornamenti.

Malfunzionamenti ed errori possono verificarsi in uno qualsiasi degli strati tecnologici o anche dalla loro interazione. È pressoché impossibile controllare in modo pro-attivo tutte queste componenti che spesso sono, per gli sviluppatori del software clinico, delle specie di black-box.

L’architettura a micro-servizi, oggi in voga, amplifica questo rischio specie per quelli che sono gestiti da terzi, fuori dal dominio e controllo dell’azienda che sviluppa il software clinico.

Quando la configurabilità è nemica della affidabilità

I principali software clinici, per garantire il massimo grado di adattamento alle richieste dei clienti, possiedono dei moduli software con cui è possibile disegnare delle form, impostare dei controlli e delle logiche di business. Talvolta sono anche presenti dei workflow manager con cui è possibile impostare dei percorsi e flussi di lavoro basati su stati, eventi e regole.

Moduli di questo genere, anche se certificati, non possono assicurare la correttezza e l’affidabilità delle configurazioni / personalizzazioni che possono essere realizzate senza modificare il codice sorgente. Nulla impedisce di creare una form che elabori e visualizzi in modo errato dei parametri clinici o che fornisca indicazioni non corrette dal punto di vista medico.

Il mosaico della certificazione

Un altro aspetto rilevante è la modalità con cui i produttori certificano il software clinico. La soluzione oggi più adottata è di suddividere la certificazione per moduli, per classi diverse in funzione delle caratteristiche e delle funzioni che questi svolgono. Per quelli che svolgono mera funzione di data entry e visualizzazione la scelta è di perseguire la classe 1, impiegando quelle maggiori per visualizzatori evoluti, moduli per la gestione della terapia farmacologica e così via. Ma cosa viene esattamente certificato? Quali micro-servizi? Un banale calcolo del BMI comporta una certificazione di classe II? Sono solo alcune delle domande che si pone chi, con coscienza, intraprende il percorso della certificazione e per le quali non ci sono spesso risposte univoche ma interpretazioni che variano in funzione del consulente o dell’ente di certificazione.

Staticità versus dinamicità

I dispositivi medici non hanno bisogno di cambiamenti nel corso della loro vita. Nascono per uno scopo ben preciso, sono auto-consistenti, ossia includono hardware e software, vengono utilizzati dagli utenti per le funzioni native che possiedono. Ben diverso è il caso dei software. Una cartella clinica elettronica è uno strumento generico in grado di trattare specialità e casi d’uso diversi. Oltre l’aspetto clinico c’è poi quello organizzativo che varia da struttura a struttura, da reparto a reparto. Quanto è applicabile il modello dispositivo medico al software clinico? In realtà molto poco.

C’è poi da considerare l’abitudine dei clienti di richiedere “software su misura” ma certificato MDR, un paradosso di cui ho parlato in un precedente articolo che potete leggere qui. Applicare con rigore la normativa MDR determinerebbe una forte “ingessatura” per i produttori e per le aziende sanitarie. Il rischio è di un’applicazione formale della MDR a cui segua una gestione reale senza i vincoli che la normativa prevede, con tutti i rischi che ne derivano.

La mia personale conclusione è che il software non è né può essere un dispositivo medico. Se si vuole normarlo serve una normativa ad hoc che non prescinda dalla realtà delle cose e che introduca dei criteri compatibili con la natura del software e le dinamiche del mercato.