• Non ci sono risultati.

Capitolo 4. IHE-PCD: linee guida sull'utilizzo degli standard per l'interoperabilità nei

4.2 Il dominio IHE-PCD

4.3.1 Device Enterprise Communication (DEC)

4.3.1.2 PCD-02 Subscribe to PCD Data

Questa transazione è utilizzata dal DOC per sottoscrivere (abbonarsi a) dati PCD dal DOF, cioè il DOC seleziona i dati che vuole ricevere dal DOF che quindi filtra quelli inviati dal DOR in base alle richieste del DOC.

Ruoli (Figura 4.12): ➢ Attore: DOF

Ruolo: riceve la richiesta di sottoscrizione dal DOC e configura il filtraggio cosicché solo quei messaggi PCD-01 che soddisfano i predicati del filtro sono comunicati al DOC. Nell'assenza di qualsiasi predicato esplicito a proposito dell'inizio e dell'arresto del filtraggio, il DOF partirà non appena la configurazione dei predicati sui filtri è completata e continuerà fino a quando non sarà ricevuta una transazione di arresto esplicita. Ogni DOF è capace del supporto di uno o più abbonamenti da un DOC.

➢ Attore: DOC

Ruolo: sottoscrive i dati del PCD

Figura 4.12 - Diagramma degli attori coinvolti nella transazione Standard di riferimento:

HL7- Health Level 7 Version 2.5 Ch5 Query e Ch7 Observation ReportingISO/IEEE 11073-10201 Domain Information Model

ISO/IEEE 11073-10101 Nomenclature Diagramma di interazione: vedere la Figura 4.11.

Come già visto, il meccanismo con cui il DOR, il DOF e il DOC interagiscono è il publish-and-subscribe che rende asincrona la comunicazione fra il DOR e il DOC: il DOR (publisher) pubblica i dati ricevuti dai dispositivi biomedici periodicamente sul DOF (intermediario), tramite

Device Observation Consumer DOC

Device Observation Filter DOF

Subscribe to PCD data

transazione PCD-01. Il DOC (subscriber) fa una richiesta di sottoscrizione ai dati dei dispositivi secondo predicati stabiliti runtime e la invia al DOF tramite PCD-02. Il DOC è l'iniziatore della sottoscrizione e della connessione con il DOF. Il DOF in base alla richiesta del DOC filtra i dati e invia tramite PCD-01 i dati richiesti al DOC.

Nell'assenza di qualsiasi predicato esplicito a proposito dell'inizio e della fine del filtraggio, il DOF partirà non appena la configurazione dei predicati sui filtri è completata e continuerà finché non sarà ricevuta una transazione di arresto esplicita, come indicato nel TF.

Una volta ricevuto il report sia il DOF che il DOC inviano un messaggio di conferma: è il messaggio HL7 di acknowledgement (Messaggio ACK). La transazione PCD-01 è quindi sincrona perché si aspetta un messaggio di ritorno.

Il DOF esegue una funzione store-and-forward per inviare i messaggi dal DOR al DOC, cioè fa da intermediario tra i due: il sistema DOC riceve le informazioni che desidera dal DOF quando invia la richiesta di sottoscrizione, ma il DOC e il DOR non partecipano contemporaneamente: la comunicazione tra i due è asincrona.

Definizione statica del messaggio HL7

Il modello Query HL7 richiede la definizione di un dichiarazione di conformità (Tabella 4.4).

Publication ID (Query ID=Z02): Z02 Type: Publish

Publication Name: IHEPCD-02SubscribeToPCDData Query Trigger (= MSH-9): QSB^Z02^QSB_Q16

Query Mode: Immediate

Response Trigger (= MSH-9): ORU^R01^ORU_R01 (PCD-01)

Query Characteristics: Returns PCD data as defined by the query characteristics

Purpose: Communicate PCD data using the PCD-01 transaction, either

filtered or unfiltered, as specified in the input parameters.

Response Characteristics:

PCD-01 ORU messages are returned corresponding to the constraints expressed in the input parameters.

The input parameters are ANDed when selecting data to be returned. That is, all input parameters that are specified must be satisfied in order for a result report to be sent.

Parameters that are left empty are ignored in satisfying the filter criteria

Based on Segment Pattern: R01

Tabella 4.4 – Dichiarazione di conformità

Definizione statica del messaggio HL7 (Tabella 4.5): QSB^Z02^QSB_Q16

QSB^Z02^QSB_Q16 Query Grammar: QSB Message Usage Card. Section Ref.

MSH Message Header Segment R [1..1] 2.15.9

[{SFT}] Software Segment X [0..0] 2.15.12

QPD Query Parameter Definition R [1..1] 5.5.4

RCP Response Control Parameter R [1..1] 5.5.6

[ DSC ] Continuation Pointer CE [0..1] 02.15.04

Il PCD TF supporta il filtraggio basato sui parametri definiti nella Tabella 4.6 QPD (segmento HL7) Input Parameter Specification, e descritti nella Tabella 4.7 QPD Input Parameter Field Descripion and Commentary.

Field Seq (Query ID=Z02)

ColName LEN DT Opt RP/# TBL # Segment Field Name Element Name 1 MessageQueryNam e 250 CWE R [1..1] Message Query Name

2 QueryTag 32 ST R [1..1] Query Tag

3 MRN CX O [0..20] PID.3

4 ActionCode ID O [0..1] 0323

5 PatientLocation PL O [0..20] PV1.3

6 DeviceClass CWE O [0..6] OBX.3

7 ParameterClass CWE O [0..6] OBX.3

8 StartDateTime DTM O [0..1] TQ1-7

9 EndDateTime DTM O [0..1] TQ1-8

10 Interval in seconds CQ O [0..1] TQ1-5

Tabella 4.6 – QPD Input Parameter Specification

Input Parameter (Query

ID=ZXX) DT Description

MessageQueryName CWE Must be valued Z02^PCD-02-Subscription. QueryTag ST Unique to each query message instance.

MRN CX

One or more patient identifiers may be sent. When a list is provided, results will be sent if any parameter matches any ID known for a patient. Sending no value matches all patients

ActionCode ID If the subscription is being modified, the desired action e.g., Add or Delete is carried in this field. Must be ‘A’, ‘D’, or null.

PatientLocation PL When a list is provided, results will be sent if any parameter matches PV1.3 for any result. Sending no value matches all results. DeviceClass IS When a list is provided, results will be sent if any parameter matches OBX.3 for any result. Sending no value matches all results. ParameterClass CWE When a list is provided, results will be sent if any parameter matches OBX.3 for any result. Sending no value matches all results. StartDateTime DTM The date/time at which the subscription is to start. If null, subscription

starts immediately.

EndDateTime DTM The date/time at which the subscription is to end. If null, subscription continues indefinitely.

Interval in seconds CQ The interval between observation reports.

Tabella 4.7 – QPD Input Parameter Field Descripion and Commentary

Il PCD TF supporta i parametri di controllo di risposta RCP (Response Control Parameters) descritti in Tabella 4.8 e utilizzati per restringere l'ammontare dei dati che potrebbero essere mandati di ritorno in risposta alla query.

SEQ LEN DT Usage Card TBL# ITEM# ELEMENT NAME

1 1 ID R 0091 00027 Query Priority

2 10 CQ X 0126 00031 Quantity Limited Request

3 250 CNE R 0394 01440 Response Modality

4 24 DTM X 01441 Execution and Delivery Time

5 1 ID X 0395 01443 Modify Indicator

6 512 SRT X Y 01624 Sort-by Field

7 256 ID X Y 01594 Segment group inclusion

Tabella 4.8 – Tabella attributi HL7 RCP

Eventi di trigger

Il messaggio QSB^Z02^QSB_Q16 è definito da IHE PCD basandosi sulle regole nel capitolo 5.7 di HL7 v2.6 per Publish and Subscribe messages. Il QSB^Z02^QSB_Q16 è spedito da un DOC a un DOF al fine di creare un nuovo abbonamento o modificare un abbonamento esistente. L'autorizzazione perché un DOC invii il QSB ^ Z02 ^ QSB_Q16 a un DOF è definita al tempo di implementazione.

Semantiche del messaggio

QSB^Z02^QSB_Q16 definisce i parametri che definiscono il filtro applicato a un flusso di messaggi di osservazione del dispositivo. La versione corrente dello IHE PCD TF fornisce le funzioni per la selezione di messaggi basate sulle regole di sottoscrizione, per il caso in esame, possono riguardare:

Medical Record Number;

• inizio e fine della sottoscrizione;

• lista di uno o più parametri dei dispositivi; • lista di parametri dei PCD più recenti;

• invio dati a una frequenza diversa da quella del DOR; • lista di dati di un paziente specifico;

• lista di dati di pazienti provenienti da luoghi specifici.

Il messaggio IHE PCD QSB ^ Z02 ^ QSB_Q16 fornisce anche parametri che definiscono: • Data e ora in cui l'abbonamento inizia, il default è immediatamente.

• Data e ora in l'abbonamento termina, il default è mai. • L'intervallo tra i rapporti periodici.

Ai sistemi DOF non è richiesto di inviare dati a qualsiasi intervallo di notifica arbitrario, dal momento che i dispositivi e i gateway pazienti possono essere capaci del supporto solo di un insieme chiuso di intervalli di segnalazione discreti. È permesso solo che il DOF segnali dati agli intervalli di segnalazione nativamente supportati da dispositivi di cura dei pazienti. Cioè, al DOF non è consentito di interpolare o in caso contrario stimare dati per punti di tempo diversi da quelli per cui sono disponibili le misure effettive inviate dal dispositivo. Se la richiesta di query non è per un intervallo di segnalazione di cui il sistema di segnalazione supporta, la richiesta sarà interpretata dal DOF come una richiesta dell'intervallo di segnalazione nativo inferiore successivo (o in altro modo, la velocità di campionamento più alta successiva). Se non c'è alcun intervallo di segnalazione nativo più basso di quello richiesto, il DOF utilizzerà il più basso intervallo nativo. Per evitare errori di mal comprensione, i DOC dovrebbero richiedere solo

intervalli di notifica che sono in effetti disponibili. I sistemi DOF sono responsabili della specifica in documentazione utente comunemente disponibile di quello che sono le velocità disponibili effettive.

Un modulo speciale di query è supportato per un singolo report di dati “one-shot” da un DOF che rappresenta i più recenti ( più vicino in tempo reale ) dati disponibili. Questo è richiesto impostando l'intervallo di segnalazione in una richiesta al valore speciale -1 (meno uno). I timestamps nell'osservazione risultante dal DOF saranno i tempi di misura effettivi per i dati inviati.

I parametri del QSB^Z02^QSB_Q16 sono combinati in base a un AND logico per definire la query generale. Per quei parametri che definiscono una lista di una o più voci gli elementi della lista sono combinati in base a un OR logico e la soddisfazione di qualsiasi membro della lista soddisfa la condizione per il relativo parametro. Se il Codice di Azione è impostato ad A, i parametri vengono aggiunti a un abbonamento esistente. Se il Codice di Azione è impostato a D, i parametri sono cancellati da un abbonamento esistente.

Azioni attese

Al momento del ricevimento di un QSB^Z02^QSB_Q16 il DOF stabilisce un abbonamento basato sui parametri definiti e comunica quei messaggi che soddisfano il predicato di abbonamento utilizzando la transazione PCD-01 per inviare i dati al sottoscrittore.

QPD successivi possono essere inviati per aggiungere “A” (o cancellare “D”) QPD individuali a (o da) una lista di QPD attivi mantenuta dal DOF che controlla il contenuto del flusso PCD-01 filtrato. Il flusso PCD-01 filtrato è l'unione (con duplicati rimossi) dei dati filtrati in uscita per ogni QPD attivo associato alla sottoscrizione.

Il DOC è l'iniziatore della sottoscrizione e della connessione e il DOF invierà i dati filtrati PCD-01 al DOC sulla stessa connessione (si presuppone una connessione punto a punto tra il client (DOC) e il server (DOF)). Il DOF sarà in grado di supportare una o più sottoscrizioni da un DOC, ognuna utilizzando una connessione indipendente.

Il DOC può annullare un abbonamento utilizzando la sequenza di messaggio QSX/ACK ‘cancel subscription/acknowledge’.

Il DOF manterrà un collegamento attivo al DOC fino a quando una o più delle seguenti condizioni non si verifica:

(1) l'abbonamento è annullato dal DOC utilizzando il messaggio QSX/ACK;

(2) il DOF non ha (e non si aspetta di avere) qualsiasi dato da inviare per un periodo prolungato di tempo; o

(3) il DOR 'stacca' la connessione senza inviare un messaggio QSX/ACK.

Se si verifica una qualunque delle precedenti condizioni, il DOF annullerà tutti gli abbonamenti e il flusso in uscita PCD-01 associato alla connessione e quindi 'staccherà' la connessione. Lo scenario (3) fornisce un metodo conveniente per consentire al DOC di richiedere dati 'di istantanea' frequenti (avendo un tempo specificato di inizio e di fine) e mantenere un attacco 'attivo' per supportare efficientemente le richieste successive.