SST – WSDL Busta Eventi Sanitari B98

Il presente scenario descrive le specifiche della busta di trasporto degli eventi sanitari, di seguito chiamata anche “Evento Clinico”. Descrive inoltre il formato della busta e il suo utilizzo per ogni tipo di interazione (one-way, request-response sincrona e asincrona) che realizza scenari di cooperazione per domini applicativi diversi.

busta di trasporto per gli eventi clinici, in seguito chiamata anche ”Evento Clinico”. Un Evento Clinico è composto da due elementi:

• una Intestazione che contiene le informazioni che riguardano la trasmissione e la gestione del messaggio (ad es. un identificativo della trasmissione e del mittente, la data di trasmissione, la scadenza) ed è indipendente dal particolare contesto applicativo. Come mostrato in Figura 1, l’intestazione ha un formato diverso per i messaggi di richiesta, risposta o di acknowledge;
• un Corpo in cui è inserito il contenuto applicativo del messaggio. Il Corpo è obbligatorio per i messaggi di richiesta e risposta, mentre è opzionale per i messaggi di acknowledge;

Il formato dell’evento clinico è mostrato nella figura seguente.

Si osserva che l’Evento Clinico è anche caratterizzato da un numero di versione (intero o decimale). In generale il numero di versione dovrebbe essere numero_rfc.versione_rfc.

Il formato della intestazione di un Evento Clinico utilizzato per l’invio di una Richiesta.

Intestazione del messaggio di richiesta, utilizzata sia nelle interazioni di tipo richiesta/risposta, sia nelle interazioni di tipo “one-way”.

L’intestazione è composta dalle informazioni riportate nella lista seguente. Si osserva la presenza di un elemento generico astratto (“Intestazione”) che include gli elementi comuni alle intestazioni dei messaggi di richiesta, risposta e acknowledge e un elemento concreto (“IntestazioneRichiesta”) che lo specializza includendo le informazioni specifiche per il tipo di messaggio:

• QIdMessaggio: codice identificativo univoco qualificato del messaggio. Si osserva che questo codice non deve essere mai utilizzato due volte anche in caso di ritrasmissione del messaggio. L’utilità del codice è quella di consentire ad altri messaggi (risposta o messaggi di ack) di riferirsi a questa comunicazione. L’elemento è costituito da un codice OID di dominio che identifica il mittente e un identificativo locale, come mostrato nella figura seguente:

Il codice OID del dominio identifica anche il dominio a cui il ricevente dovrà restituire l‘eventuale risposta o acknowledge. Il codice OID è strutturato in “radice” (che risponde al formato ISO-ITU OID) ed “estensione”.

Per le ASL, è opportuno (benchè non obbligatorio) che il codice OID del dominio sia valorizzato nel modo seguente:

• 2.16.840.1.113883.2.9.2.90101.4.5 per ASL 1 Massa Carrara
• 2.16.840.1.113883.2.9.2.90102.4.5 per ASL 2 Lucca
• 2.16.840.1.113883.2.9.2.90103.4.5 per ASL 3 Pistoia
• 2.16.840.1.113883.2.9.2.90104.4.5 per ASL 4 Prato
• 2.16.840.1.113883.2.9.2.90105.4.5 per ASL 5 Pisa
• 2.16.840.1.113883.2.9.2.90106.4.5 per ASL 6 Livorno
• 2.16.840.1.113883.2.9.2.90107.4.5 per ASL 7 Siena
• 2.16.840.1.113883.2.9.2.90108.4.5 per ASL 8 Arezzo
• 2.16.840.1.113883.2.9.2.90109.4.5 per ASL 9 Grosseto
• 2.16.840.1.113883.2.9.2.90110.4.5 per ASL 10 Firenze
• 2.16.840.1.113883.2.9.2.90111.4.5 per ASL 11 Empoli
• 2.16.840.1.113883.2.9.2.90112.4.5 per ASL 12 Viareggio
• 2.16.840.1.113883.2.9.2.90801.4.5 per ISPO
• 2.16.840.1.113883.2.9.2.90901.4.5 per AO Pisana
• 2.16.840.1.113883.2.9.2.90902.4.5 per AO Senese
• 2.16.840.1.113883.2.9.2.90903.4.5 per AO Careggi
• 2.16.840.1.113883.2.9.2.90904.4.5 per AO Meyer
• 2.16.840.1.113883.2.9.2.90907.4.5 per Fondazione Monasterio / IFC-CNR

• TipoComunicazione: Indica la tipologia della comunicazione. Può assumere i valori seguenti:
  • P = “Produzione”. Il messaggio è inviato da un sistema di produzione;
  • T = “Test”. Il messaggio è inviato da un sistema di pre-produzione/di staging. Se messaggi di questo tipo sono inviati da un sistema di produzione, il sistema ricevente deve scartare questi messaggi.

• Data: la data della trasmissionedel messaggio. Si osserva che questa è differente dalla data dell’evento che ha causato la produzione del messaggio che è invece riportata (se necessario) all’interno del contenuto applicativo.

• Interazione: elemento composto dal numero dell’RFC applicativo di riferimento per la comunicazione e versione RFC e numero dello scenario di riferimento all’interno dell’RFC.

• Destinatario: è un campo opzionale che individua, attraverso un codice OID, il destinatario dell’evento.

• Scadenza: data di scadenza del messaggio. Il sistema ricevente che riceve un messaggio scaduto non deve elaborarlo. Se il mittente accetta la comunicazione di un ack di errore (ModalitaAck=’E’ o ‘S’), il ricevente deve notificare un opportuno ack con Esito = “R” (reject) e CodiceAck = 007: “Messaggio non elaborato perché scaduto”. Il campo è opzionale e riservato ad usi futuri.

• Priorità: campo intero che indica la priorità dell’evento. A valore più alto corrisponde priorità maggiore. Il campo è opzionale e riservato ad usi futuri.

• Sequenza: numerodi sequenza opzionale del messaggio, di uso interno al dominio applicativo. Non utilizzato attualmente dal livello regionale.

• Modalità di Risposta: Indica la modalità di restituzione della risposta al fruitore. Possibili valori sono i seguenti¹:
  • I = “immediate” se siamo in un caso di request/response sincrona (quindi una interazione bloccante per il fruitore);
  • D = “deferred” nel caso di request/response asincrono ed è responsabilità dell’erogatore inviare la risposta al richiedente;
  • N = “none” nel caso di scenari one way (senza risposta);

Si osserva che un erogatore può supportare un numero ristretto di modalità (al limite una sola). Se la modalità richiesta non è supportata si restituisce al mittente un messaggio ‘ack’ con Esito = “R” (reject) e CodiceAck = 005: “Modalità di restituzione della risposta non supportata”.

• Modalità di Ack: indica la modalità di restituzione di un ack e può assumere i valori:
  • E = “errore” l’ack deve essere restituito al richiedente solo in caso di errore o rifiuto del messaggio;
  • S = “sempre” l’ack deve essere sempre restituito al richiedente;
  • M = “mai” l’ack non deve essere mai restituito.

Si osserva che se lo scenario è di tipo richiesta-risposta sincrona, il campo viene ignorato dal sistema che riceve la richiesta e l’ack viene sempre restituito (all’interno del messaggio di risposta).

• QIdEventoParent: riferimento opzionale ad un evento. Il campo può essere utilizzato da un’Azienda per tracciare internamente la catena di propagazione di propri eventi correlati. Non utilizzato da Regione Toscana.

• Livello: campo opzionale che il sistema aziendale può utilizzare come discriminante per decidere se se l’evento deve essere propagato a Regione Toscana o se deve rimanere internamente all’azienda. In particolare, gli eventi che riportano un Livello compreso tra 0 e 10 devono essere inviati anche a Regione Toscana. Quelli che hanno un Livello maggiore di 10 sono interni al dominio aziendale.

• Keywords: Elenco opzionale di coppie chiave/valore utili ad un’indicizzazione dell’evento.

• 1 A questi potrebbe essere aggiunta la modalità Q = “queued” nel caso di request/response asincrono in cui è responsabilità del fruitore richiedere la risposta all’erogatore (polling);

Intestazione del messaggio di risposta. Il messaggio è utilizzato nelle interazioni di tipo richiesta/risposta, siano esse sincrone o asincrone.

Rispetto alla Intestazione del messaggio di richiesta, questo include i seguenti elementi aggiuntivi (all’interno dell’elemento IntestazioneRisposta):

• RifMessaggio: identificativo qualificato del messaggio di richiesta a cui questa risposta si riferisce.

• Acknowledgement: è il dettaglio dell’acknowledge. L’elemento è mostrato in Figura 4. Esso è composto da:
  • Esito: indica complessivamente l’esito della richiesta. Può assumere uno tra i valori seguenti:
    • A = ‘Ack’: ricezione e elaborazione avvenuta con successo.
    • W = ‘Warning’: il messaggio è stato ricevuto ed elaborato ma vi sono alcuni warning (specificati nei dettagli).
    • E = ‘Error’: il messaggio è stato rifiutato per ragioni che non dipendono dal contenuto del messaggio. Il mittente può o meno tentare successivamente la ritrasmissione del messaggio in base alle regole stabilite per lo specifico dominio.
    • R = ‘Reject’: ricezione e elaborazione non conclusa con successo per ragioni che dipendono dal contenuto del messaggio. Il mittente deve verificare il contenuto del messaggio prima di procedere ad una nuova trasmissione.
  • Dettagli: una serie di codici (e descrizioni opzionali) che indicano nel dettaglio l’esito della elaborazione del messaggio. Attualmente sono previsti i seguenti codici:
    • 000: Nessun errore.
    • 001: Errore dovuto alla consistenza dei dati come specificato nella Descrizione.
    • 002: OID del mittente sconosciuto.
    • 003: OID del destinatario sconosciuto.
    • 004: Codice RFC di riferimento errato.
    • 005: Numero Scenario RFC non esistente o errato.
    • 006: Modalità di restituzione della risposta non supportata.
    • 007: Messaggio non elaborato perché scaduto.
    • 008: Versione RFC errata.

Struttura dell’elemento di acknowledge

Il messaggio di Acknowledge è utilizzato in scenari di tipo one-way o in scenari di tipo richiesta/risposta asincrona. Scopo del messaggio di Ack è restituire, ad un sistema che invia un messaggio, evidenza sull’esito della comunicazione, ricezione ed elaborazione del messaggio stesso.

L’intestazione del messaggio è simile a quella del messaggio di risposta. Rispetto a quest’ultimo vi sono le seguenti differenze:

• il Corpo del messaggio non è presente: poiché il messaggio di Ack non ha significato dal punto di vista applicativo ma è utile solo per ragioni di comunicazione, si assume che il corpo sia mancante e che tutta l’informazione sia all’interno della intestazione.
• gli elementi seguenti non sono presenti: Scadenza (si assume infatti che un messaggio di Ack non abbia scadenza dal momento che non trasferisce contenuto applicativo), Priorità e ModalitaAck.

Messaggio “Evento Clinico – Accettazione/Non Accettazione”

In questa sezione è riportata la descrizione del formato del messaggio di Accettazione/Non Accettazione che può essere ritornato al fruitore del servizio qualora non siano soddisfatte le condizioni minime necessarie per procedere all’elaborazione (ad esempio la mancanza di validità della busta o del corpo rispetto agli schema di riferimento).

Si osserva che l’Accettazione è da intendersi come una “presa in carico” (o una mancata presa in carico) dell’evento da parte di un sistema “accettante” che può o meno coincidere con l’erogatore del servizio.

In ogni caso, essa ha significato diverso rispetto al messaggio di Evento Clinico “Ack” descritto nella precedente sezione che si riferisce invece all’esito della elaborazione dell’evento da parte dell’erogatore del servizio.

Si osserva inoltre che mentre il messaggio di Ack può essere restituito al fruitore del servizio in modo sincrono o asincrono rispetto alla richiesta, il messaggio di Accettazione è sempre restituito in modo sincrono.

Come mostrato nelle precedenti figure, la struttura dei due messaggi è la stessa, fatta eccezione per l’elemento radice.

Come per messaggi di Richiesta e Risposta, anche il messaggio di Accettazione si compone di una “Intestazione” e un “Corpo” opzionale.

L’Intestazione riporta l’esito della accettazione attraverso le seguenti informazioni:

• Esito: può assumere uno tra i valori seguenti:
  • A = ‘Ack’: ricezione e elaborazione da parte del sistema accettante avvenuta con successo.
  • W = ‘Warning’: il messaggio è stato accettato ma vi sono alcune segnalazioni (riportate nell’elemento “Dettaglio Esito”).
  • R = ‘Reject’: messaggio non accettato per ragioni che dipendono dal contenuto del messaggio. Il mittente deve verificare il contenuto del messaggio prima di procedere ad una nuova trasmissione.
  • E = ‘Error’: il messaggio non è stato accettato per ragioni che non dipendono dal contenuto del messaggio. Il mittente può o meno tentare la ritrasmissione successivamente del messaggio in base alle regole stabilite per lo specifico dominio.
• Dettaglio Esito: una sequenza di codici che forniscono dettagli sull’esito del processo di accettazione. Per ogni codice è possibile fornire anche una descrizione.
  I codici attualmente previsti sono i seguenti:
  • 000: Messaggio accettato.
  • 001: Busta non valida rispetto agli schema XML di riferimento della busta ‘Evento Clinico’ (RFC 98).
  • 002: Identificativo OID del mittente sconosciuto.
  • 003: Identificativo OID del destinatario sconosciuto.
  • 004: Codice RFC di riferimento errato.
  • 005: Numero Scenario RFC non esistente o errato.
  • 006: Modalità di restituzione della risposta/ack non supportata.
  • 007: Messaggio scaduto.
  • 008: Versione RFC errata.
  • 009: Il messaggio è stato accettato ma non è stato possibile completare con successo il processo di anonimizzazione. L’evento viene inoltrato senza essere associato ad un soggetto.
  • 101: Contenuto applicativo (Body) non valido rispetto agli schema XML di riferimento.
  • 500: Errore generico.
  • 501: Errore nella trasmissione del messaggio.
  • 502: Errore nella anonimizzazione dell’evento.

Il Corpo è un elemento opzionale di cui non è specificata la struttura. Il contenuto del Corpo, se presente, è definito dagli RFC applicativi di riferimento.

All’interno del corpo di un messaggio di accettazione potrebbe ad esempio essere inserita la busta di e.Gov restituita da CART al sistema accettante (es. un proxy applicativo) a seguito della propagazione del messaggio all’erogatore del servizio.

All’interno del corpo di un messaggio di accettazione potrebbe ad esempio essere inserita la busta di e.Gov restituita da CART al sistema accettante (es. un proxy applicativo) a seguito della propagazione del messaggio all’erogatore del servizio.

Si illustrano di seguito le principali primitive di cooperazione tra un sistema Origine del messaggio e un sistema Destinazione e i messaggi scambiati nelle interazioni.

Nello scenario Richiesta/Risposta sincrono, il sistema Origine invia la richiesta che viene elaborata dal destinatario. Il destinatario restituisce quindi in modo sincrono la risposta all’Origine, riportando il corretto riferimento al messaggio ricevuto (RifMessaggio).

Si osserva che la risposta contiene anche l’Acknowledge che riporta l’esito della ricezione ed elaborazione del messaggio.

Nello scenario one-way, il sistema Origine invia la richiesta verso l’infrastruttura (che nell’esempio assume il ruolo di sistema di accettazione). L’infrastruttura effettua i controlli di accettazione e, se questi si concludono con un esito positivo, restituisce in modo sincrono la ricevuta di Accettazione al sistema Origine propagando anche la richiesta al sistema di Destinazione. Il sistema di Destinazione riceve quindi la richiesta in modo asincrono rispetto alla spedizione, la elabora ed eventualmente invia il messaggio di Ackowledge al sistema Origine per mezzo dell’Infrastruttura riportando il corretto riferimento al messaggio ricevuto (RifMessaggio) e l’esito della ricezione ed elaborazione del messaggio.

Si osserva che il messaggio di Ack viene inviato al sistema Origine solo nei casi seguenti:

• Il messaggio di richiesta contiene Modalità di Ack=’S’;
• Il messaggio di richiesta contiene Modalità di Ack=’E’ e si è verificato un problema presso il sistema destinatario, oppure il messaggio di richiesta è arrivato ormai scaduto. In questi casi il messaggio di Ack riporta Esito = ‘E’ (Error) o R = ‘R’ (Reject);

Nello scenario richiesta-risposta asincrono (mostrato nella seguente Figura 11), il sistema Origine invia la richiesta verso l’infrastruttura e ne riceve in modo sincrono la ricevuta di Accettazione (interazioni 1,2), così come descritto nello scenario precedente. Il sistema di Destinazione riceve la richiesta in modo asincrono rispetto alla spedizione (interaz. 3), la elabora (4) ed invia successivamente il messaggio di Risposta al sistema Origine per mezzo dell’Infrastruttura (interazione 5, 6) riportando il corretto riferimento al messaggio ricevuto (RifMessaggio), e l’esito della elaborazione del messaggio.

Alla ricezione del messaggio di Risposta (interaz. 7), il sistema Origine può generare un Acknowledge in direzione del sistema Destinazione per confermare la corretta ricezione/acquisizione della risposta (interaz. 9-11).

Si osserva che il messaggio di Acknowledge viene inviato dal sistema Origine al sistema Destinazione solo nei casi seguenti:

• Il messaggio di Risposta contiene Modalità di Ack=’S’;
• Il messaggio di Risposta contiene Modalità di Ack=’E’ e si è verificato un problema presso il sistema Origine, oppure il messaggio di Risposta è arrivato ormai scaduto. In questi casi il messaggio di Acknowledge riporta Esito = ‘E’ (Error) o R = ‘R’ (Reject);