I Profili di Integrazione

Gli standard noti in ambiente sanitario, ad esempio DICOM e HL7, sono implementati per offrire risposta ad un esteso numero di processi clinici. Per uniformare l'utilizzo di questi standard, al fine di rendere i sistemi interoperabili e quindi di permettere una comunicazione più efficiente tra loro, IHE crea i profili di integrazione [49] che forniscono una serie di funzionalità essenziali che servono per dare risposta ad una specifica attività clinica. In particolare, i profili descrivono precisamente come gli standard in questione debbano essere utilizzati per trasmettere i dati rilevanti da un'applicazione ad un'altra all'interno di un particolare dominio clinico, partendo dall'analisi del workflow clinico reale. Oltre alle modalità con cui avvengono le comunicazioni, i profili IHE definiscono le informazioni che devono essere scambiate tra sistemi e specificano le azioni che i sistemi devono effettuare alla ricezione di tali informazioni: i prodotti e i sistemi implementati seguendo questi profili, diventano quindi interoperabili.

contenute negli standard esistenti, migliorando quindi la condivisione delle richieste per l'integrazione dei prodotti da parte degli utenti di sistemi informativi sanitari (medici) verso i produttori di sistemi informativi sanitari e assicurando infine che tutti i dati richiesti dai clinici per la cura dei pazienti siano corretti e facilmente reperibili. Tutto questo conduce all'obiettivo di migliorare la qualità, l'efficienza e la sicurezza delle cure cliniche.

Ogni profilo include le definizioni dei casi d'uso, delle informazioni cliniche e del workflow coinvolto. Per ogni profilo di integrazione, il TF definisce attori e transazioni coinvolti e fornisce istruzioni dettagliate per l'implementazione di ogni transazione (utilizzate principalmente dai produttori come linee guida). La comunicazione dell'informazione è descritta in termini di transazioni tra attori. Gli attori sono le componenti funzionali dell'azienda sanitaria (sistemi informativi o componenti di sistemi informativi) che producono, gestiscono o agiscono secondo categorie di informazioni richieste dalle attività operative nell'impresa, e le interazioni tra loro sono definite da un set di transazioni coordinate che trasferiscono le informazioni richieste attraverso messaggi basati su standard. Le transazioni sono quindi gli elementi chiave dell'interoperabilità perché rappresentano lo scambio effettivo di informazioni tra attori e, per ognuna di esse, il TF descrive come utilizzare uno standard stabilito per permettere la comunicazione.

IHE propone dei principi e delle convenzioni che definiscono un profilo [50]: 1. Un profilo dovrebbe risolvere un bisogno/problema descrivibile dall'utente.

2. Un profilo dovrebbe utilizzare meccanismi flessibili che possono essere adattati a siti differenti.

3. Un profilo dovrebbe seriamente evitare di avere due meccanismi diversi per fare la stessa cosa.

4. Un profilo dovrebbe avere in generale un valore autonomo (cioè aggiunge valore quando è utilizzato da solo, anche se è ricco di benefici che potrebbero non essere realizzati fino a quando non viene utilizzato assieme ad altri profili).

5. Un profilo è ciò che un produttore può pretendere, un Connectathon può verificare e un utente può richiedere.

6. Un profilo è una “unità di marketing”. Dovrebbe in generale affrontare le problematiche degli utenti ad esso collegate. Se le transazioni si rivolgono agli ingegneri, i profili dovrebbero rivolgersi, e quindi essere compresi, agli utenti.

7. La dimensione di un profilo è un compromesso tra:

• profili estesi che richiedono minori decisioni nella costruzione e nella coordinazione da parte dell'utente;

• profili ridotti che danno agli utenti maggior flessibilità nel selezionare le caratteristiche e nel progettare le proprie soluzioni.

• In generale, l'errore risiede nel costruire profili estesi. 8. Attori:

• gli attori sono assegnati ai profili quando hanno un ruolo da ricoprire; • un attore è ciò con cui un utente (o un altro sistema) interagisce;

• un attore rappresenta un “contenitore di responsabilità” (boundle of responsability).

dargli un nome basato su una singola transazione di cui sono gli accettori finali. Va bene avere diversi attori alla fine di una transazione.

• L'utilizzo dello stesso attore in più profili è accettabile e incoraggiato quando il ruolo/responsabilità è essenzialmente lo stesso.

• Un attore che supporta più profili deve implementare tutte le transazioni richieste nei profili pre-requisiti in aggiunta a quelle nel profilo desiderato.

9. Transazioni:

• Una transazione dovrebbe integrare un compito specifico.

• Una transazione può coinvolgere una comunicazione bidirezionale (e.g. Richiesta e risposta).

• I nomi delle transazioni dovrebbero descrivere ciò che è compiuto dal punto di vista dell'iniziatore della transazione.

• Le transazioni possono essere utilizzate in più profili. La fase di progettazione della transazione dovrebbe tenere in considerazione questo tipo di riutilizzo. • Le transazioni possono essere assegnate a più attori.

10. Gruppi di attori:

• Gli attori raggruppati sono attori che sono implementati insieme su un singolo sistema.

• I produttori comunemente raggruppano gli attori per riunire raccolte di funzionalità utili.

• Gli stessi profili richiedono che un'implementazione raggruppi certi attori insieme.

• Agli attori raggruppati è consentito di utilizzare protocolli equivalenti non-IHE quando eseguono funzioni di transazione tra se stessi. Ad esempio, uno Schermo (attore Display), che è raggruppato con un Gestore di Immagine (attore Image Manager), può utilizzare un protocollo interno per ricercare le immagini piuttosto che il protocollo DICOM richiesto nella transazione IHE per la ricerca delle immagini (Retrive Images).

• Agli attori raggruppati è ancora richiesto di supportare tutte le transazioni IHE richieste per integrarsi con attori su altri sistemi. Ad esempio, il Image Manager nell'esempio precedente deve essere in grado di utilizzare il DICOM come specificato nella transazione Retrive Images per fornire immagini a un attore Display esterno.

Gli attori e le transazioni IHE descritti nel TF [51] sono astrazioni di ambienti dei sistemi informativi sanitari del mondo reale. Mentre alcune delle transazioni sono eseguite tradizionalmente da categorie di prodotti specifiche (per esempio HIS, Electronic Patient Record, RIS, PACS, CIS, dispositivi per la cura dei pazienti o modalità di imaging), il TF volutamente evita di associare le funzioni o gli attori a tali categorie di prodotti. Per ogni attore, si definiscono solo quelle funzioni associate all'integrazione dei sistemi informativi. La definizione IHE di un attore non dovrebbe essere quindi considerata come la definizione completa di un qualsiasi prodotto che lo possa implementare, né il framework stesso dovrebbe essere portato a descrivere completamente l'architettura di un sistema informativo sanitario. Gli sviluppatori hanno molte opzioni per implementare gli attori e le transazioni IHE nella fase

di sviluppo dei prodotti. Le decisioni coprono quattro livelli:

1. per un sistema, selezionare quali attori incorporerà (sono accettabili anche più attori per un sistema);

2. per ogni attore, selezionare a quali Profili di Integrazione parteciperà;

3. per ogni attore-profilo, selezionare quali transazioni opzionali saranno implementate. Tutte le transazioni richieste devono essere implementate perché il profilo sia supportato. 4. Infine, per ogni transazione, selezionare quali caratteristiche opzionali saranno

supportate.

Gli implementatori dovrebbero fornire una dichiarazione (Integration Statement) che descrive quali attori, Profili di Integrazione, transazioni opzionali e caratteristiche facoltative sono incorporati in un certo prodotto.

4.1.4.1 Convenzioni per le transazioni

Il modello generico di transazione [52]

Le transazioni, contenute in un profilo di integrazione, vengono descritte nel TF di un particolare dominio seguendo un modello generale qui esposto.

In ogni descrizione della transazione, gli attori, i ruoli che giocano, e le transazioni tra loro sono presentate come casi d'uso.

La generica descrizione della transazione include i seguenti componenti: • Ambito: una breve descrizione della transazione.

• Ruoli del caso d'uso: definizioni testuali degli attori e dei loro ruoli, con un diagramma semplice che li relaziona (per esempio Figura 4.4).

Actor Actor

Transaction

Figura 4.4 – Diagramma che lega attori e transazione tra loro • Standard di riferimento: gli standard da utilizzare per la transazione.

• Diagramma di interazione UML: un grafico degli attori e dei messaggi che supportano la transazione, con relativo sviluppo in cui un attore è visualizzato come un rettangolo e il tempo di progressione si sviluppa verso il basso, simile a Figura 4.5.

Actor Actor Actor MSG1

MSG2 MSG3

Figura 4.5 – Diagramma di interazione.

Le transazioni sono rappresentate come frecce orientate secondo il flusso dell'informazione primaria gestita dalla transazione e non necessariamente dal promotore. • Definizioni dei messaggi: le descrizioni di ogni messaggio implicato nella transazione,

gli eventi che innescano il messaggio, la sua semantica e le azioni che il messaggio innesca nel ricevente.

Convenzioni sui messaggi HL7 [52]

I messaggi HL7, attraverso cui vengono trasmessi i dati, sono descritti nel TF utilizzando tabelle a livello di messaggio e a livello di segmento secondo definizioni statiche di "profili di messaggio vincolabili HL7".

Una tabella a livello di messaggio rappresenta una struttura del messaggio vincolato a IHE con la sua lista di segmenti utilizzabili. Le tabelle a livello di messaggio sono inserite in sottosezioni del messaggio con ogni sezione della transazione, e rappresentano la definizione statica dei messaggi specificati. Una tabella di messaggio è seguita da commenti che evidenziando l'utilizzo del segmento. La sottosezione che descrive un messaggio fornisce anche le descrizioni di qualsiasi segmento specifico per questo messaggio.

Sono descritti solo i segmenti che hanno un codice di utilizzo R (Required), RE (Required but may be empty), C (Conditional) o CE (Conditional but may be empty) in almeno un messaggio sono descritti. In altre parole, segmenti, che sono sempre facoltativi (O) o non supportati (X), non sono descritti nel PCD TF.

HL7 v2.6 non specifica un protocollo di comunicazione di rete, quindi IHE fa queste raccomandazioni [59]:

1. le applicazioni dovrebbero usare Minimal Lower Layer Protocol (MLLP) definito nell'Appendice C di HL7 Implementation Guide. Attualmente il MLLP è utilizzato da tutti gli attori IHE PCD che operano dietro i firewall ospedalieri e la selezione di MLLP rispetto ad altre opzioni di trasporto è basata sull'implementazione o sulla configurazione; 2. un'applicazione iniziale che vuole inviare un messaggio (iniziare una transazione)

inizializzerà una connessione di rete per cominciare la transazione. L'applicazione ricevente risponderà con una conferma o risposta alla domanda sulla connessione aperta. L'applicazione iniziale può inizializzare una nuova transazioni sulla stessa connessione e comunque deve essere in grado di gestire i casi in cui la connessione è stata chiusa a

causa di possibili timeout dall'applicazione finale. Per esempio, se l'applicazione iniziale non fa una richiesta sulla connessione tempestivamente, l'applicazione finale ha il diritto di chiudere la connessione. Quando avviene questa condizione, l'applicazione iniziale necessita di aprire una nuova connessione per successive richieste.

Utilizzo di entità codificate e schemi di codifica [52]

IHE non produce, non mantiene o in caso contrario non specifica uno schema di codifica o un'altra risorsa per la terminologia controllata (entità codificate). Per le transazioni IHE PCD, tuttavia, gli identificatori dell'osservazione dovrebbero per preferenza essere basati su ISO/IEEE 11073-10101. Una lista di questi termini e aggiunte proposte allo standard è mantenuta da IHE PCD nel progetto Rosetta Terminology Mapping. Le implementazioni utilizzeranno i termini definiti nella versione corrente della Harmonize Terminology Rosetta. Questi sono basati su termini dalla nomenclatura ISO/IEEE 11073 dove disponibili e dove la nomenclatura attualmente non contiene un termine corrispondente, dà a termini provvisori neutrali dai produttori da sottomettere all'ISO/IEEE 11073 appropriato come suggerimenti per adozione nella nomenclatura. Se un termine non può essere trovato in questo modo e un termine corrispondente è disponibile in LOINC (Logical Observation Identifiers Names and Codes), allora la preferenza successiva è di utilizzare il termine LOINC. Se LOINC anche non supporta un termine allora schemi di codifica richiesti dallo standard HL7 prendono precedenza se è disponibile un termine corrispondente. Nei casi dove tali risorse non sono identificati esplicitamente da standard, le implementazioni possono utilizzare qualsiasi risorsa (includente proprietario o locale) a condizione che qualsiasi requisito di licenze/copyright sia soddisfatto.