Profilo DEC

Il profilo DEC [51]-[54] descrive il meccanismo che consente di comunicare i dati dei PCD ai sistemi informativi sanitari, come la cartella clinica elettronica, mappando i dati da una sintassi e semantica proprietarie a una singola rappresentazione standard utilizzando il formato HL7, e garantendo quindi l'interoperabilità tra i sistemi in gioco.

Questo profilo consente di implementare, in modo opzionale, il meccanismo publish-and-subscribe (DEC-SPD) che verrà preso in considerazione in questo progetto.

Attori del profilo DEC:

DOR (Device Observation Reporter) → riceve i dati dai PCD e li mappa su transazioni HL7 per comunicarli al DOF, se si utilizza l'opzione del profilo, o direttamente al DOC

DOF (Device Observation Filter) → riceve i dati dal DOC e fornisce servizi di filtraggio basati sul meccanismo publish-and-subscribe in base alle richieste del DOC

DOC (Device Observation Consumer)→ riceve i dati dal DOF dopo avergli inviato la richiesta di sottoscrizione, se si utilizza l'opzione del profilo, altrimenti li riceve direttamente dal DOR

Gli attori DOR e DOF possono essere riferiti a due sistemi diversi (come per il Caso 2 presentato in seguito) oppure essere raggruppati in un unico sistema (come per il Caso 1, la centrale di telemonitoraggio che ha il compito di gestire i dati dei dispositivi è il sistema giusto per incorporare i due attori, mentre per esempio in un ospedale, che assolve compiti totalmente

diversi e distinti e non solo la gestione di dati, i due attori andrebbero considerati divisi in due entità). Nel momento in cui sono raggruppati non è più necessario che comunichino in formato standard HL7 ma possono bensì scambiarsi le informazioni con il protocollo interno del sistema. Transazioni del profilo DEC:

PCD-01 → utilizzata per trasmettere i dati tramite messaggi HL7, in modo non sollecitato. DOF e DOC utilizzano un messaggio HL7 ACK per confermare al DOR l'avvenuta ricezione dei dati. PCD-02 → utilizzata affinché il DOC faccia richieste di sottoscrizione al DOF tramite messaggi HL7

Gli attori sono interconnessi attraverso le transazioni come rappresentato il Figura 5.11.

Figura 5.11 – Diagramma attori/transazioni DEC Eventi attesi:

• il DOC comunica le regole di sottoscrizione al DOF (PCD-02); • il DOF riceve i dati dal DOR (PCD-01);

• il DOF invia i dati al DOC in base alle regole di sottoscrizione.

Effetti del meccanismo publish-and-subscribe

A causa dell'asincronismo tra DOR e DOC, dovuto all'utilizzo del publish-and-subscribe, non è possibile, come già osservato, che il medico dall'EHR cominci la comunicazione con il dispositivo, non c'è la possibilità dello scambio di informazioni real time, al momento, perché non c'è una transazione che parte dal DOC e arriva al DOR. Si ha solo il reperimento passivo dei dati dai dispositivi e, al più, il DOC può richiedere un filtraggio dei dati avvalendosi del DOF (meccanismo store-and-forward). Quindi, il DOR riporta i dati al DOF indipendentemente dalla richiesta del DOC e solo il DOF invia i dati in dipendenza del DOC.

Facendo riferimento ai dispositivi presentati sopra, la Stazione Base per Telemetria è un concentratore ed è in grado di inviare i dati alla Centrale ma non di ricevere informazioni da essa, mentre la Stazione base per braccialetti è in grado di essere teleprogrammata dalla centrale e di avere una comunicazione bidirezionale con essa. Quindi, con i profili PCD, il medico (DOC) non può richiedere dati direttamente ai dispositivi cominciando lui la comunicazione ma, per

Device Observation Consumer DOC

Device Observation Filter DOF

Device Observation Reporter DOR Dispositivi Biomedici

→

←

←

→ ←

esempio, può fare una richiesta alla centrale di ricevere i dati del braccialetto tramite transazione PCD-02; la centrale (DOF) teleprogramma il bracciale in modo che gli invii i dati in quel momento, tramite formato proprietario, e, una volta ricevuti, li trasmette al medico tramite transazione PCD-01. Non è comunque una trasmissione propriamente real-time ma è un escamotage applicabile in situazioni particolari, per esempio di emergenza.

In conclusione, il meccanismo publish-and-subscribe ha il vantaggio di rendere il DOR e il DOC indipendenti, nel senso che non serve che siano attivi contemporaneamente nella comunicazione; ha lo svantaggio di non consentire di avere informazioni in tempo reale per il DOC.

Il ruolo degli standard

La necessità di rappresentare le osservazioni dei dispositivi biomedici in un formato che possa essere utilizzabile dalle applicazioni cliniche ha trovato soluzione con IHE che provvede alla fornitura di specifiche per la mappatura dei dati da ISO/IEEE 11073 a uno specifico standard di messaggi, HL7.

Per raggiungere l'interoperabilità semantica, ogni classe di dispositivo deve utilizzare la stessa terminologia e organizzazione o modellazione dei dati. La semantica che è utilizzata nel dominio PCD è basata su ISO /IEEE 11073 Nomenclatura e DIM (Domain Information Model). La semantica viene poi mappata nello standard HL7 per la comunicazione dei dati tra applicazioni. Il DOR e il DOF dovrebbero essere basati sulla semantica ISO/IEEE 11073 per le transazioni IHE-PCD in HL7, perché il TF specifica le convenzioni utilizzate per rappresentare il modello di informazione dei dispositivi biomedici ISO/IEEE 11073 DIM all'interno di convenzioni sintattiche e semantiche di HL7. In altre parole il TF fornisce le regole per mappare la semantica del dispositivo IEEE 11073 in messaggi HL7.

Schematicamente:

ISO/IEEE 11073 → semantica dispositivi PCD → archiviazione e gestione dati a livello degli attori DOR e DOF

HL7 → sintassi dei dati dei PCD → comunicazione dei dati tra attori (transazioni)

NB. Chi invia i dati dei dispositivi sono DOR e DOF, non DOC che al più invia richieste di sottoscrizione. È per questo che la mappatura tra i due standard si ha solo a livello del DOR e del DOF e non a livello del DOC, perché sono i dati dei dispositivi, strutturati con ISO/IEEE 11073, a dover essere trasformati in messaggi HL7. La mappatura da ISO a HL7 si ha a livello di dati del dispositivo, non di altri tipi di dati. Quindi anche se la transazione PCD-02 utilizza HL7 non si ha a monte una mappatura da ISO a HL7 a livello del DOC perché questi non invia dati del dispositivo ma solo richieste di sottoscrizione.

Sincronizzazione

Il TF esprime chiaramente la dipendenza del profilo DEC dal profilo ITI-CT: ogni attore del DEC deve implementare l'attore Time Client del profilo ITI-CT [62], utilizzato con lo scopo di coordinare il tempo tra sistemi in rete assicurando che gli orologi dei sistemi e data/ora dei computer siano ben sincronizzati. È richiesto per ottenere dati compatibili temporalmente nei vari sistemi. Ogni attore implementato nel DEC è raggruppato con l'attore Time Client. Il Time Client comunica con un Time Server (per esempio localizzato a livello della Centrale) per sincronizzarsi a quest'ultimo tramite la transazione ITI-01 Maintain Time (Figura 5.12). Questa transazione utilizza lo standard NTP (Network Time Protocol) e prevede la modalità domanda-risposta: il Time Client domanda la sincronizzazione (NTP Time Query) al Time Server e riceve

una risposta (NTP Time Response).

Figura 5.12 – Diagramma di sequenza Consistent Time

È importante il riferimento temporale nei messaggi trasmessi all'utente finale e già i dispositivi prevedono di inviare data e ora assieme agli altri dati fisiologici; è anche importante che i sistemi in gioco siano sincronizzati tra di loro. Si ipotizza qui che in corrispondenza della centrale ci sia l'”orologio principale” (Time Server) a cui sono sincronizzati tutti i sistemi in gioco.

Sicurezza delle informazioni

Nei casi qui presentati, in cui la comunicazione dei dati è remota, IHE raccomanda di raggruppare gli attori DOR e DOF con l'attore Secure Node del profilo ATNA per comunicazioni sicure dei dati, nel momento in cui vengano trasmessi su reti non sicure (per approfondimenti si rimanda al Capitolo 4, paragrafo 4.3.3).