# Integrating the Healthcare Enterprise

Integrating the Healthcare Enterprise (IHE) è un'organizzazione internazionale no-profit con sede in Illinois che lavora in sinergia con altre associazioni legate alla sanità (ACR, NEMA, EAR, ECR, SIRM, ecc.) per promuovere l'uso di standard informatici già definiti in ambito medicale, allo scopo di condividere dati ed informazioni.
IHE non si occupa di come sono fatti i componenti, ma di come possono collegarsi ed interoperare fra loro. A tale fine cerca di armonizzare l'uso degli standard esistenti (DICOM, HL7, XML, ecc.), e propone ogni anno un connect-a-thon fra le aziende per verificare l'interoperabilità.

## Struttura

L'esperienza di IHE nasce nel 1999 ed attualmente la struttura è divisa in tre grandi Regioni (Nord America, Europa, Asia), a loro volta divise in nazioni. Questo tipo di suddivisione permette di gestire la localizzazione, ovvero la caratterizzazione in ambito regionale o nazionale di quanto contenuto nei Technical Framework.

## Technical Framework

IHE non è uno standard bensì una metodologia di lavoro, e le indicazioni sono contenute nei Technical Framework, che si possono scaricare dal sito. I Technical Framework sono stati divisi per dominio di interesse:
* Cardiologia
* Infrastrutture IT
* Laboratori
* Radiologia
* Pazienti
* Oculistica
* Altro
Di seguito vengono descritti i tre concetti principali di IHE.

### Attori

Gli attori sono microsistemi informatici ben specifici, definiti dal produttore ed oggetto dell'integrazione.

### Transazioni

Le transazioni sono interazioni fra attori, e sono definite in tre fasi:
* Evento trigger, che scatena la transazione
* Messaggio, da inviare attraverso la transazione
* Expected action, cosa ci aspettiamo dopo l'invio del messaggio

### Profili di integrazione della sezione IT Infrastructure

Sono scenari di problemi/soluzioni, alla base di IHE. Ogni dominio di interesse ha i propri profili di integrazione. Di seguito sono riportati alcuni esempi di profili riferiti alla sezione IT Infrastructure (IT Infrastructure Technical Framework).

#### Consistent Time (CT)

È il profilo che permette di sincronizzare tra loro gli orologi di sistema in modo da rendere univoca l'informazione temporale tra diversi sistemi.

#### Cross-Enterprise Document Sharing (XDS)

È il profilo IHE che detta le linee guida per lo scambio di documentazione clinica tra aziende o strutture sanitarie diverse, consistano esse in singoli reparti ospedalieri, cliniche, medici privati, ecc... La prima versione del profilo (XDS.a) differisce da una sua seconda versione denominata XDS.b in quanto in quest'ultimo caso vengono adottati degli standard in revisioni più recenti (ebXML 3.0, SOAP v1.2, MTOM/XOP). I nuovi implementatori sono caldamente invitati a considerare esclusivamente il profilo XDS in versione b, anche se la migrazione da un profilo all'altro risulta relativamente semplice, i due profili possono coesistere e sono equivalenti in termini di funzionalità. Resta il fatto che sul profilo XDS.b si fondano le basi di molti altri profili IHE in corso di definizione, tra cui il profilo XUA (Cross-Enterprise User Assertion) e XCA (Cross-Community Access). In questo profilo si assume che ogni organizzazione appartenga ad uno o più Affinity Domain, ciascuno consistente in un insieme di organizzazioni sanitarie che sottoscrivono delle policies e condividono una infrastruttura tecnologica con lo scopo di scambiarsi tra loro documenti clinici. Le policies oggetto degli accordi riguardano aspetti quali l'identificazione dei pazienti, il controllo degli accessi, l'ottenimento del consenso alla trattazione dei dati, ma anche il formato, il contenuto, la struttura, l'organizzazione e la rappresentazione delle informazioni cliniche.

#### Cross-Community Access (XCA)

Definisce attori e transazioni per la condivisione delle informazioni ad un livello superiore di quello ospedaliero. Attualmente il profilo XCA detta linee guida concrete principalmente per lo scambio documentale. Nel profilo XCA viene definito il concetto di Community come un insieme di strutture sanitarie che sottoscrivono delle policies e adottano protocolli di comunicazione condivisi con lo scopo di condividere documentazione clinica. Ciascuna Community viene identificata da un codice univoco (homeCommunityId). In questo profilo vengono definiti due nuovi attori: Initiating Gateway e Responding Gateway. Il primo si prende carico di tutte le transazioni in uscita dalla Community locale, e si preoccupa di inoltrarle alle altre Community. Il Responding Gateway, invece, gestisce tutti i flussi in ingresso dalle altre Community e li recapita agli attori afferenti alla Community locale. Un notevole vantaggio derivante dall'adozione del profilo XCA è che consente l'interoperabilità sia tra Community strutturate al loro interno secondo il profilo XDS che tra e con Community non aderenti ad XDS o sviluppate secondo principi legacy.

### Profili di integrazione della sezione di Radiologia

Sono scenari di problemi/soluzioni, alla base di IHE. Ogni dominio di interesse ha i propri profili di integrazione. Di seguito sono riportati alcuni esempi di profili contenuti nella sezione di Radiologia (Radiology Technical Framework).

#### Scheduled Workflow (SWF)

Lo Scheduled Workflow (SWF) mostra l'interazione fra Hospital Information System, sistema informatico radiologico, modalità e PACS e rappresenta la spina dorsale del lavoro di routine, dall'accettazione del paziente per un esame fino alla stesura del referto.
Gli attori e le transazioni coinvolti in questo profilo sono i seguenti (dal Technical Framework 1 IHE Year 5 rev. 6.0):

#### Patient Reconciliation

Si tratta di un profilo che indica le azioni ed i messaggi che devono essere scambiati quando è necessario cambiare i dati del paziente. Un esempio di questa necessità: un paziente giunge in ospedale incosciente e deve essere sottoposto ad un esame; le immagini dell'esame vengono correlate ad un paziente fittizio. Solo successivamente si ottengono i dati anagrafici precisi. I nuovi dati vengono inseriti sull'Order Placer and Order Filler, da cui parte un messaggio verso gli altri, che aggiornano i loro riferimenti interni. Questo profilo estende il precedente SWF offrendo un mezzo per collegare immagini, referti ed altre evidenze con il paziente.

#### Consistent Presentation of Images (CPI)

Profilo che specifica le transazioni necessarie per mantenere la consistenza delle immagini e dei dati relativi tra più stazioni di visualizzazione. In questo modo, un'immagine comparirà allo stesso modo su monitor di refertazione diversi, comprese le annotazioni aggiunte, lo zoom, la rotazione. Questa parte definisce la Grayscale Standard Display Function, che permette di visualizzare allo stesso modo i livelli di grigio dell'immagine, qualunque sia il monitor diagnostico usato.

#### Key Image Note (KIN)

Stabilisce le azioni che permettono di indicare una o più immagini come importanti per la diagnosi, collegando loro un'annotazione che riporta commenti del medico che ha eseguito la refertazione. Può essere usato a scopo di consultazione, per indicare i punti salienti al medico di base oppure per scopi didattici.

#### Simple Image and Numeric Report (SINR)

Facilita l'uso del riconoscimento vocale e di altri pacchetti per la refertazione, indicando ai produttori una via per l'integrazione di tali prodotti.

#### Portable Data for Imaging (PDI)

Definisce le procedure per distribuire le immagini e informazioni collegate su un supporto, allo scopo di scambiare immagini, dati e referti per importazione, visualizzazione o stampa. Un esempio pratico è la consegna dei risultati dell'esame su un supporto ottico (CD-ROM).

#### Cross-enterprise Document Sharing for Imaging (XDS-I)

Definisce attori e transazioni per la condivisione delle informazioni a livello ospedaliero e oltre (enterprise). Definisce anche le informazioni da condividere, come p.es. oggetti DICOM come immagini e referti, forniti in forma leggibile.