Gli aspetti di interoperabilità sintattica e semantica dei device collegati alle piattaforme di telemedicina non sono dettagli di poco contro. Conoscerli e considerarli nelle gare di prossima attivazione per acquisire servizi sarà fondamentale per un’integrazione sistemica del processo di diagnosi e cura del SSN.
Quasi sempre relegata all’ambito della mera sperimentazione o al massimo di “caso di successo”, la telemedicina non è mai davvero divenuta un supporto sistematico al lavoro degli operatori del Sistema Sanitario e ai pazienti.
Eppure, non stiamo parlando di una “intuizione” nuovissima.
Quasi un secolo fa, il medico, scrittore visionario, divulgatore di successo (a lui si deve l’invenzione dell’ “infografica”), polimatematico Fritz Kahn è stato con ogni probabilità anche il primo ad intravedere nell’integrazione della pratica clinica con le tecnologie che nel XX secolo hanno rivoluzionato le comunicazioni e trasmissioni a distanza, il futuro della medicina [1]. Le sue, quelle sì, intuizioni, di fatto anticipavano il concetto rivoluzionario di telemedicina, la trasmissione e condivisione, in tempo reale, di informazioni di carattere sanitario e scientifico tra medico e cittadino o tra gli stessi operatori sanitari, attraverso sistemi di comunicazione di tipo telematico/informatico al fine di migliorare, semplificare e integrare il percorso di cura e di diagnosi ha subìto alterne fortune.
Eppure, siamo ancora qui a discutere di cosa non è andato come avrebbe dovuto. Ma, se motivi sono noti e ampiamente analizzati, come se ne esce?
I motivi del mancato decollo della telemedicina
I motivi sono stati analizzati in una serie innumerabile di rapporti, indagini, articoli, convegni da esperti di ogni specializzazione e provenienza. La sintesi credo stia nei seguenti 4 punti:
- Tecnologia inadeguata: carenza di supporti informativi integrati e pienamente interoperabili, spesso a causa di soluzioni ancora on premise e stand alone, nonostante standard internazionali ormai consolidati e indicazioni nazionali (AgID) obblighino soprattutto le PA a modelli “cloud first” e a criteri di interoperabilità basati su servizi web based in una logica “vendor-neutral”;
- Resistenza culturale degli operatori: le tecnologie informatiche, a cui sempre più i dispositivi elettromedicali sono connessi, per il personale sanitario sono ancora fonte di diffidenza, generano un senso di “male inevitabile”, prevalentemente a causa di una carente specifica formazione;
- Connettività insufficiente: la diffusione di una rete a banda larga su tutto il territorio nazionale è ancora eterogenea, se si pensa che appena il 58% del territorio nazionale ha una connessione a 30Mbit/s, contro l’80% previsto dall’obiettivo dell’Agenda Europea [2];
- Mancata organizzazione dei percorsi tra ospedale e territorio: quasi proverbiale è ormai la percezione di una insufficiente integrazione tra le strutture del SSN, a cui si aggiunge il grande inconveniente di matrice culturale di scarsa condivisione di informazioni tra il Medico di Medicina Generale (su cui un sistema di telemedicina punta molto per l’abbattimento dei costi di gestione) e lo specialista: il paziente è spesso visto come una “proprietà privata” e l’accesso alle informazioni che lo riguardano è visto più come un privilegio da tutelare che come una risorsa da condividere nel suo interesse.
Fin qui le cause. Ma le soluzioni?
Uscire dalla “sperimentazione”: un’architettura decentrata e integrata
La caratteristica fondamentale di un servizio di telemedicina è la gestione delle informazioni sanitarie che fluiscono nell’organizzazione da fonti esterne.
L’architettura di un sistema con questa finalità prevede, lato paziente, un sistema di device e sensori medicali per l’acquisizione dei segnali di allarme e dei parametri vitali, un gateway di comunicazione, fisico o virtuale, che riceva i segnali dai sensori, effettui le opportune elaborazioni e li trasmetta al centro di ascolto mediante rete di connettività ed infine un apparato di videocomunicazione. Dal lato dell’operatore sanitario, occorre che il centro di ascolto comprenda una piattaforma di lavoro (workstation), fisica o virtuale, per la raccolta dei dati proveniente dal lato paziente, una base dati per l’archiviazione dei dati raccolti ed eventualmente un sistema ACD (Automatic Call Distribution), in grado di distribuire le chiamate entranti tra gli operatori disponibili e di gestire in automatico la schedulazione delle visite programmate. Quest’ultimo si rende indispensabile per un alto numero di pazienti da servire.
Aldilà degli aspetti organizzativi e di corretta definizione di quale sia il fabbisogno di salute da soddisfare, temi tutt’altro che banali, ma che non sono di competenza di chi scrive, che si tratti di comunicazioni audio/video, documentazione e immagini diagnostiche o parametri vitali, la grande sfida tecnologica è sempre stata capire come verranno integrate le informazioni nel record, chi ne garantirà l’integrità, come lo utilizzeranno i provider [3].
Alla base di tutto c’è l’assunto che i dispositivi e i sensori adoperati rispettino due importanti vincoli:
- il più alto livello di interoperabilità possibile tra i dispositivi e i sistemi sanitari (FSE, cartella del MMG), in modo che le misurazioni raccolte dai primi possano essere integrate nei flussi di lavoro sanitari, rendendole disponibili in qualsiasi momento per gli specialisti ospedalieri e gli operatori autorizzati.
- una sicurezza continua delle misurazioni raccolte, per impedire accessi non autorizzati, che potrebbero comportare un danno sociale e professionale per gli utenti, falsificazione, corruzione e perdita dei dati, che possono causare diagnosi errate, trattamenti inefficaci o errati risultati della ricerca.
I requisiti di interoperabilità
Cercherò di delineare priorità tecniche relative al primo punto, ovvero i requisiti di interoperabilità.
L’HIMSS (Healthcare Information and Management Systems Society) definisce quattro livelli di interoperabilità, intesa come la capacità di diversi sistemi di informazione, dispositivi o applicazioni di connettersi, in modo coordinato, all’interno e attraverso i confini dell’organizzazione per accedere, scambiare e utilizzare in modo cooperativo i dati tra le parti interessate:
- Foundational: i requisiti di inter-connettività necessari per un sistema o un’applicazione (senza elementi di interpretazione, ma solo di trasmissione);
- Structural: come livello intermedio, definisce il formato dello scambio di dati tra i sistemi, tramite standard di formato dei messaggi.
- Semantic: la capacità dei sistemi di scambiare e utilizzare dati standardizzati e codificati. Ciò consente al sistema HIT ricevente di interpretare i dati.
- Organizational: è il tentativo di raggiungere l’interoperabilità globale. Il livello aggiuntivo di “organizzazione” vuole enfatizzare la necessità fondamentale di una solida infrastruttura di interoperabilità supportata dagli aspetti organizzativi, non tecnici, che contribuiscono al successo dell’interoperabilità.
Tralasciando l’”utopia” del livello organizzativo, se al livello intermedio, di interoperabilità strutturale, negli anni numerosi passi avanti sono stati compiuti con l’utilizzo di messaggistica codificata (HL7 o la sua recente evoluzione HL7 FHIR per i dati strutturati, DICOM per le immagini radiologiche, ecc…), a livello di interoperabilità semantica e sintattica molto c’è ancora da fare.
Vediamo quali sono gli standard che possono essere adoperati per un ecosistema integrato dispositivi – piattaforme software, alla base per l’applicazione della telemedicina.
Interoperabilità come “linguaggio universale”: gli standard funzionano
X73-PHD. No, non è un refuso, né si tratta dell’ennesimo personaggio robot-umanoide della saga di “Guerre Stellari”, bensì della modalità con cui sono identificati i dispositivi medici personali (Personal Health Device – PHD) che sono coerenti con la famiglia di norme ISO/IEEE 11073 (o X-73), da cui X73-PHD.
Facciamo un passo indietro. Un dispositivo medico personale, un PHD appunto, è qualunque dispositivo dotato di uno o più sensori in grado di monitorare i parametri vitali, tenendo debitamente considerazione i segnali dall’ambiente circostante come il rumore [4]. Si tratta quindi dei pulsossimetri, dei misuratori di pressione, termometri, ECG a n derivazioni, glucometri e tutti i dispositivi, compresi quelli indossabili, in grado di acquisire parametri vitali di una persona e trasformarli in segnale elettronico, ovvero tutti quei dispositivi alla base di qualsiasi applicazione di telemedicina.
E le norme ISO/IEEE 11073? Appartengono alla famiglia di norme tecniche che garantiscono l’interoperabilità tra i PHD e ciò che definiscono come gli aggregatori, ovvero i sistemi informativi ospedalieri e/o ambulatoriali e le piattaforme software di raccolta e supporto alle decisioni cliniche. Numerosi enti regolatori internazionali, tra cui IHE (Integrating the Healthcare Enterprise), promuovono da anni l’uso coordinato di diversi standard nei sistemi sanitari (ad es. cartelle cliniche personali/elettroniche, gestori degli avvisi, sistemi di supporto alle decisioni cliniche) definendo profili destinati ai casi di uso medico.
Figura 2 Esempio di Sistema Informativo integrato con le applicazioni di Telemedicina conforme alle norme X73PHD [7]
X73PHD fornisce un solido modello sintattico e una terminologia completa, ma ad oggi, ancora pochi sono i produttori che rilasciano sul mercato dispositivi compliant con queste norme [4], obbligando all’acquisizione di soluzioni proprietarie per l’integrazione con i sistemi informativi e le piattaforme aggregatrici o, peggio, ad un utilizzo stand-alone e non in rete.
Ma un sistema codificato di comunicazione tra dispositivi e piattaforme software non basta: manca ancora un elemento, che è la transcodifica delle modalità con cui i produttori codificano i segnali che acquisiscono tramite i sensori nei PHD per renderli compatibili con lo standard X73-PHD.
Una sorte di “Stele di Rosetta” tra la modalità con cui l’acquisizione di un segnale è codificato da un vendor (solo per gli ECG, ad esempio, ci sono almeno 15 modalità diverse di acquisizione dei segnali dalle derivazioni) e quanto prescrive la famiglia di norme ISO 11073 per l’interoperabilità sintattica e semantica per quel segnale.
L’analogia con uno dei più grandi ritrovamenti dell’archeologia di tutti i tempi, senza il quale non saremmo stati in grado di comprendere la lingua e quindi la cultura egizia, è talmente calzante che il set di transcodifica dei segnali con questa finalità è stato definito proprio Rosetta Terminology Mapping!
Il RTM fornisce una mappatura armonizzata indipendente dal fornitore, in una logica quindi “vendor neutral”, per le osservazioni dei dispositivi per la cura del paziente basata sulla nomenclatura ISO/IEEE 11073.
Il Rosetta Terminology Mapping utilizza tre tabelle primarie che definiscono e vincolano il contenuto semantico dei messaggi IHE PCD. Le tre tabelle sono:
- “Rosetta”, che contiene gli identificatori di osservazione, le unità di misura e le enumerazioni che i fornitori attualmente supportano sui loro gateway e come intendono mapparli rispetto alla nomenclatura ISO/IEEE 11073-10101 e alle sue estensioni;
- “Units”, che definisce tutte le unità di misura consentite e la mappatura normativa tra le unità di misura ISO/IEEE 11073-10101 (mediante ID di riferimento e codici numerici) e i termini UCUM equivalenti.
- “Enums”, che definisce gruppi di valori enumerati (stringhe di token o come ID di riferimento IEEE e codici numerici) a cui si fa riferimento dalla tabella ‘Rosetta’ principale.
Figura 3 i livelli di interoperabilità secondo HIMSS e gli standard correlati per i device di telemedicina
Pretendere l’uso degli standard per l’interoperabilità e l’efficienza
La recente pubblicazione in Gazzetta Ufficiale delle linee guida per i servizi di telemedicina [5], è stata salutata con entusiasmo pressoché unanime. Sicuramente contribuisce a dare, dopo decenni di confinamento alla realtà di sperimentazioni locali, una dimensione di sistema e nazionale. Altrettanto vera è l’attenzione ai meccanismi di integrazione tra i servizi con modalità web service, tramite API, e l’enfasi su un’architettura a microservizi delle piattaforme software da mettere a disposizione.
Tuttavia, mi unisco alle perplessità sollevate da esperti del settore [6] proprio perché trovo anch’io che manchi il giusto dettaglio di come dovranno essere codificati i dati acquisiti dai dispostivi elettromedicali collegati alle piattaforme telemedicali coerenti con le linee guida e soprattutto di quali standard trasmissivi adottare.
Non sono solo dettagli tecnici. Considerare fondamentali gli aspetti di interoperabilità sintattica e semantica non solo per la piattaforma software, ma anche (soprattutto) per i device elettromedicali da collegare, vuol dire evitare il “lock-in” da parte dei fornitori (uno dei principi chiaramente espressi anche dal codice degli appalti); vuol dire garantire una pluralità di servizi di acquisizione dei segnali a prescindere dalle tecnologie proprietarie, e quindi dare al paziente la più ampia possibilità di presa in carico ovunque si trovi e qualunque sia la sua condizione; vuol dire uscire dalla “maledizione” del caso di successo, della singola, isolata sperimentazione, dell’isola felice, ma rendere la telemedicina un’integrazione sistemica del processo di diagnosi e cura del Sistema Sanitario Nazionale.
Per fare tutto questo, le Aziende Sanitarie del SSN hanno a disposizione le gare di prossima attivazione, nell’ambito dei finanziamenti PNRR per acquisire servizi, connessi alle Piattaforme regionali e integrati nei processi interni per televisita, teleconsulto, telerefertazione e telemonitoraggio, a partire dalle patologie cardiovascolari pneumologiche, diabetologiche, oncologiche e neurologiche. Si tratta di gare per 750 milioni di euro complessivi con cui dare un avvio ai servizi regionali in una logica integrata e di sistema.
Tuttavia, occorre saper scrivere i capitolati tenendo conto degli standard trasmissivi, consolidati oramai, ma mai davvero utilizzati, in modo da poter essere committenza intelligente, che orienta il mercato verso il reale bisogno di salute, che trova nell’adeguata e consapevole scelta della metodologia tecnologica più adatta il modo migliore per dare forma alla visione del dott. Fritz Kahn quasi un secolo fa.
Note
[1] «Fritz Kahn,» [Online]. Available: https://www.fritz-kahn.com/.
[2] «Ministero dello Sviluppo Economico, Piano Strategico BUL,» [Online]. Available: https://bandaultralarga.italia.it/.
[3] L. A. Eramo, «Personal Medical Devices: Managing Personal Data, Personally Collected,» [Online]. Available: https://library.ahima.org/doc?oid=100033#.Y24En4TMKUk.
[4] H. F. Badawi, F. Laamarti e A. E. Saddik, «ISO/IEEE 11073 Personal Health Device (X73-PHD) Standards Compliant Systems: A Systematic Literature Review,» IEEE Access, 2018.
[5] «Approvazione delle linee guida per i servizi di telemedicina – Requisiti funzionali e livelli di servizio,» DECRETO 21 settembre 2022, 2022.
[6] M. Mangia, «La telemedicina è legge: i limiti, gli errori e le omissioni,» [Online]. Available: https://salutedigitale.blog/2022/11/12/la-telemedicina-e-legge-i-limiti-gli-errori-e-le-omissioni/#more-5380.
[7] Ó. J.Rubio, J. D.Trigo, Á. Alesanco, L. Serrano e J. García, «Analysis of ISO/IEEE 11073 built-in security and its potential IHE-based extensibility,» Journal of Biomedical Informatics, vol. 60, pp. 270-285, 2016.
l’Autore: Dario Ricci Direttore f.f. SC Area ICT, Azienda Ospedaliera di Alessandria
fonte: AgendaDigitale.eu
