Vediamo le differenze tra FHIR e le classiche integrazioni basate sulla messaggistica HL7 / IHE e i vantaggi che ne derivano.
I sistemi informativi ospedalieri sono “sistemi di sistemi”, ossia degli insiemi eterogenei di applicazioni specializzate nel gestire i principali processi di una struttura sanitaria.
Normalmente questi sistemi si scambiano dati mediante messaggi HL7 versione 2 che vengono smistati da un Enterprise Service Bus. Nel caso di un’accettazione di un ricovero, il sistema ADT invia un messaggio ADT01 al Service Bus che lo recapita a tutti i sistemi che potrebbero aver bisogno di questa informazione (nella figura sottostante ad esempio all’Order Entry, al sistema di laboratorio (LIS) e alla cartella clinica elettronica.
Questi sistemi memorizzano il contenuto dei messaggi nei propri archivi affinché possano utilizzarne i dati (o aggiornarli). Per fare ad esempio un ordine a un paziente ricoverato l’Order Entry deve conoscere la lista dei pazienti ricoverati per permettere all’utente di selezionarne uno e identificarlo nel modo corretto.
Siamo quindi in presenza di una logica “push” in cui ogni sistema invia, mediante messaggi, le informazioni che gestisce (come fonte principale o master) agli altri sistemi.
Per alcune tipologie di informazioni, ad esempio l’anagrafica, esistono anche messaggi di Query che capovolgono questo approccio in cui è ad esempio l’Order Entry che chiede quando serve all’ADT i dati anagrafici del paziente. Si tratta però di casi circoscritti. In genere i sistemi si scambiano un’elevata mole di messaggi per tutti gli eventi che sono gestiti in modo digitale.
La logica FHIR è invece completamente differente. Nel caso di prima, l’accettazione di un paziente, non è l’ADT che invia un messaggio ai sistemi per informarli dell’avvenuto ricovero di un paziente ma espone queste informazioni mediante “risorse” che sono accessibili attraverso web services.
Quando un sistema ha bisogno di un’informazione la va a chiedere al o ai sistemi che la possiedono. Nel caso di prima l’ADT, semplificando, espone i dati anagrafici dei pazienti e quelli relativi al ricovero mediante le risorse Patient e Encounter rispettivamente. La logica, in questo caso, è di tipo “pull”.
L’integrazione dati mediante messaggi richiede quindi che siano noti i sistemi mittenti e destinatari. Questo scenario è fattibile all’interno di un’azienda sanitaria mentre diventa impraticabile se il contesto si amplia, ad esempio se vogliamo consentire a un’app iOS o Android di leggere i dati di un paziente, come oggi avviene in tutti i principali ospedali USA che permettono ai loro pazienti di leggere e caricare sull’app Salute di Apple i dati della propria cartella clinica (attraverso FHIR).
Uno dei motivi che hanno portato allo sviluppo di FHIR è proprio la necessità, in un contesto di connected care, di consentire l’accesso e lo scambio di informazioni sanitarie tra strutture sanitarie diverse, professionisti e pazienti, senza generare un traffico enorme di messaggi. Per questa ragione è facile ipotizzare un forte sviluppo di questo standard e la sua adozione anche in Italia.
3 – Fine.