Soluzioni informatiche e applicazioni HL7 per il settore medicale

Vediamo ora il caso reale affrontato presso l´Azienda Ospedaliera di Desenzano del Garda. In questo scenario il PS invia al RIS le richieste di prestazioni in regime di urgenza, il RIS accetta tutte le richieste e completa automaticamente la scheda di accettazione in modo che l´esame possa essere subito eseguito dal tecnico di radiologia.

Alla compilazione del referto il RIS invia al PS la lista degli esami effettivamente refertati con il testo del referto. Non è prevista la notifica da parte del RIS verso il PS per esame preso in carico , ma solo di esame eseguito. Questa notifica segnala al PS che non può più inviare al RIS una richiesta di cancellazione quando un ordine è stato eseguito.

Figura 11: Integrazione tra PS e RIS

Considerazioni

Nello schema precedente viene mostrata come una semplice integrazione come quella prevista tra PS e RIS coinvolga pesantemente le applicazioni. Tra le varie attività principali si evidenzia : l´implementazione della logica per la gestione dell´evento, la creazione del messaggio XML , l´invio del messaggio all´adapter secondo la tecnologia adottata ( web service , db , file sistem , ecc. ) .

Allo stesso modo vanno implementate le funzionalità per la ricezione dei messaggi di risposta ( acquisizione dall´adapter del messaggio ) e l´interpretazione dello stesso (lettura del formato XML), il comportamento nel caso dei messaggi di errore, e ancora, la logica per la gestione dei messaggi di evento generati dal RIS ( evento esame eseguito , evento referto disponibile ) . Le stesse attività vanno replicate ovviamente anche sul RIS.

Criticità

Le criticità del progetto con questo modello di integrazione possono riassumersi nei seguenti punti:

• È necessario implementare il codice per la gestione dell´evento (evento trigger per l´invio del messaggio), pensiamo ad un evento di nuova anagrafica o modifica anagrafica , dove questi dati possono essere generati in diversi punti della applicazione.
• Gli eventi riguardano tipicamente i messaggi che devono essere inviati dalla nostra applicazione ( ordine , nuova anagrafica , ecc. ) , ad ogni nostro messaggio inviato è necessario prevedere l´evento di ricezione almeno del messaggio di risposta ( ack , nack ).
• Oltre a questi eventi ci sono quindi gli eventi generati dalla ricezione dei messaggi inviati da altre applicazioni, ai quali dobbiamo rispondere almeno con dei messaggi di ack, nack.
• Questa parte è essenziale per la corretta generazione e interpretazione dei messaggi, la complessità aumenta nei casi dove è necessario gestire messaggi di classi diverse ( anagrafica , ordini , accettazione , ecc ) in moduli diversi.
• Oltre a questo bisogna costruire il codice per generare e interpretare il messaggio da e verso l´XML e per interfacciarsi con l´adapter a seconda della metodologia tecnologica adottata ( web service o altro ).

L´alternativa

Per il PS si è preferito comunque utilizzare questo modello in quanto la software house aveva già realizzato una integrazione simile per un´altra azienda ospedaliera.

Per quanto riguarda il RIS si è preferito al contrario valutare una soluzione diversa. Di seguito vengono elencati i punti chiave che la nuova soluzione doveva avere.

Obiettivi

• consentire alla applicazione una piena integrazione verso il mondo HL7 non solo per i messaggi previsti dal progetto SISS
• un motore di integrazione e di inoltro messaggi leggero e performante espressamente disegnato per l´HL7
• integrazione code-less
• eventi trigger di invio e ricezione messaggio e gestione risposta gestiti dal motore di integrazione con linguaggio T-SQL senza nessun intervento lato applicazione
• nessun adapter
• un sistema di monitor e log estremamente facile e con un´interfaccia grafica stile windows
• elevata sicurezza e tracciabilità delle transazioni