Soluzioni informatiche e applicazioni HL7 per il settore medicale

Vediamo ora in pratica la facilità con cui Hydra può risolvere tutti i problemi di interventi sul codice lato applicazione (eventi , costruzione e interpretazione dei messaggi, gestione messaggi di risposta, connessione) e di implementazione adapter. Essenzialmente Hydra è composto da tre moduli software lato server:

• ORMService. È il servizio che si occupa dello smistamento dei messaggi da e verso le applicazioni coinvolte. Grazie ad un modulo software con interfaccia grafica l´HL7 Integration Engine è facilmente configurabile. Viene installato automaticamente dalla procedura di installazione.
• OMCService. È il servizio che si occupa della traduzione e interpretazione dei messaggi da e verso XML/HL7. Fornisce le funzionalità avanzate per la generazione automatica dei messaggi HL7 da inviare oltre che la gestione dei messaggi di risposta. Viene installato automaticamente dalla procedura di installazione.
• omnHL7Remoting. È il servizio utilizzato dai programmi di gestione di Hydra per la configurazione da remoto.

Oltre ad una serie di tools di configurazione e di gestione :

• ORMSetup. Con questo programma è possibile configurare tutte le funzionalità del servizio ORMService. Tra le funzioni principali ci sono la creazione delle code private per lo smistamento e il monitoraggio dei messaggi all´interno di Hydra. La gestione della cronologia dei messaggi scambiati e dei file di log. La configurazione dei metodi di connessione, tra cui viste o tabelle di database, TCP/IP , File system , code di ICAN. Non vi sono limiti sui canali contemporanei che è possibile gestire.
• Hydra Monitor. Con questo programma è possibile monitorare in tempo reale lo scambio dei messaggi tra le applicazioni, visualizzare i log e verificare lo stato dei messaggi ( da inviare, inviati , invio non possibile , ecc.)
• HL7 Messaging Wizard. È il programma che grazie ad avanzate funzionalità grafiche crea le associazioni tra l´HL7 e i dati da scambiare. Genera la struttura nel repository di Hydra in funzione dei messaggi HL7 da ricevere, le associazioni tra i dati della applicazione e i messaggi HL7 da inviare, oltre a avanzate funzionalità di analisi, verifica e generazione di report per i conformant statement.

Figura 13: Schema operativo

Primo esempio: Integrazione standard (G-H)

Dallo schema operativo si vede come l´applicazione RIS sia in grado di scambiare messaggi HL7 mediante due metodi. Mediante il primo criterio (G) l´applicazione è in grado di inviare e ricevere messaggi XML tramite uno dei canali standard di comunicazione (H) di Hydra.

Con questo tipo di integrazione l´applicazione deve essere sostanzialmente modificata per aggiungere tre componenti fondamentali.

Il primo componente serve per comporre le stringhe XML corrispondenti ai messaggi HL7 da inviare, il secondo serve per l´invio delle stringhe XML o su file system come file o come stringhe attraverso un socket tcp/ip o come valore campo attraverso una tabella o vista di database.

Sullo stesso canale lo stesso componente deve o con tecniche di polling ( database ) o di evento ( canale tcp/ip e file system ) , essere in grado di ricevere i messaggi di risposta ( ack/nack ) oltre che i normali messaggi di richiesta.

Il terzo componente deve occuparsi della interpretazione dei messaggi ricevuti siano essi di risposta ( ack/nack ) ai nostri messaggi , che messaggi richiesta da altre applicazioni e intraprendere le azioni opportune.

Questo tipo di integrazione che solo apparentemente è simile a quanto offerto finora dalle altre soluzioni general purpose, si discosta principalmente in un punto, non ci sono adapter. Hydra si spinge più in là e offre una metodologia di integrazione molto più semplice e svincolata ancora di più dalla applicazione.

Secondo esempio: integrazione avanzata (B-F-A). Invio messaggi HL7

Il metodo è identificato nello schema operativo con (B). Questo metodo (B) si occupa di verificare sul database della applicazione (polling) quando vi sono eventi di invio messaggio (F) (ad ogni evento corrisponde un messaggio HL7, per esempio al salvataggio referto corrisponde il messaggio di nuovo referto, all´aggiornamento dello stato dell´esame, eseguito o altro, corrisponde il messaggio di aggiorna stato).

Questi eventi vengono generati automaticamente dalla applicazione nel momento in cui avviene l´aggiornamento di una opportuna tabella (Update, Insert, Delete ). È possibile associare all´aggiornamento di un record ( insert - inserimento di un nuovo referto nella tabella referti ) o alla cancellazione ( delete - referto annullato ) o all´aggiornamento ( update - referto modificato) l´invio di un opportuno messaggio ( messaggio di referto disponibile, di referto cancellato o di referto modificato ).

È anche consentito associare più messaggi allo stesso evento, per esempio a seguito di un evento di insert nella tabella referti di un nuovo referto, Hydra può inviare un messaggio HL7 di cambio stato e un messaggio di referto disponibile.

Ovviamente non vi è limite a tabelle ed eventi che Hydra può monitorare. Con questo tipo di integrazione non è necessario intervenire nel codice applicazione se non in casi particolari ove sia necessario attivare gli eventi di invio utilizzando eventi non previsti dalla applicazione.

Per esempio supponiamo che non si vuole inviare il referto al momento del salvataggio ma in un momento successivo ( solo dopo la firma ), in questo caso se non è disponibile un evento automatico ( update - aggiornamento dello stato del referto a firmato ) è sufficiente scrivere un record dummy in una tabella di appoggio e usare quest´ultima come tabella-evento per scatenare l´invio del messaggio HL7 associato.

In ogni caso le modifiche sono sostanzialmente a livello di stored-procedure se previste o di codice per gestire i record dummy in tabelle di appoggio diverse da quelle standard della applicazione. L´integrazione si basa quindi sugli eventi che sono già disponibili nel database della applicazione.

Alla attivazione di ogni evento quindi Hydra legge i valori direttamente dalle tabelle del database della applicazione e li inserisce nei campi del messaggio HL7 che verrà generato. Grazie ad una interfaccia grafica amichevole il processo di associazione campo messaggio HL7 campo tabella è drammaticamente semplice.

Non vi sono limiti a tabelle e relazioni che possono essere utilizzate per la costruzione di messaggi HL7. Infine il messaggio HL7 è pronto per essere inviato tramite il canale di connessione (A) verso le code di ICAN e inoltrato quindi alla applicazione destinataria.

Ovviamente per l´invio è possibile utilizzare uno dei canali (H) standard offerti da Hydra e inoltrare il messaggio a qualsiasi altra applicazione senza dover utilizzare un middleware "esterno".

Se non fosse possibile inviare il messaggio alla applicazione destinataria per esempio per indisponibilità delle code di ICAN, o altro, lo stato del messaggio viene lasciato a "da inviare". Se il messaggio generato non è corretto secondo lo standard HL7 ( caratteri non permessi , ecc ) , lo stato viene aggiornato a "invio non possibile", infine in caso di invio positivo lo stato viene aggiornato a "inviato".

Tutte queste situazioni vengono registrare sui log della applicazione e possono essere interrogate in ogni momento dal programma di monitor.