Salta la navigazione

Soluzioni informatiche e applicazioni HL7 per il settore medicale

Torna all'homepage    Stampa la pagina    Contatti



Progetto di integrazione
     Figura 4: Progetto di integrazione
Integrazione tra applicativo e middleware
     Figura 5: Integrazione tra applicativo e middleware
Funzionamento dell'adattatore
     Figura 6: Funzionamento dell´adattatore
Invio di un messaggio
     Figura 7: Invio di un messaggio
Messaggio di risposta
     Figura 8: Messaggio di risposta
Flusso e conversione dei dati
     Figura 9: Flusso e conversione dei dati
Mappatura dei campi
     Figura 10: Mappatura dei campi

Scenario reale

Nell´Azienda Ospedaliera di Desenzano del Garda durante la fase di consolidamento prevista dal progetto SISS è stato richiesto di integrare l´applicazione di Pronto Soccorso con l´applicazione RIS per le richieste di prestazioni in regime di urgenza.

In questo caso reale il progetto di integrazione prevedeva l´integrazione delle due applicazioni, realizzando due adattatori uno per ogni applicazione da e verso il middleware di integrazione.

Figura 4: Progetto di integrazione

Con questo tipo di soluzione è molto importante decidere fin da subito la metodologia di integrazione tra l´applicazione il middleware, se web service, data base o altro, oltre che al formato dei dati e dei messaggi da scambiare.

L´adattatore in questo modo si limita a "passare" i dati da e verso il middleware di integrazione aggiungendo eventualmente delle funzioni di conversione da un formato ad un altro , ovviamente tutto questo si riflette pesantemente sulla applicazione in quanto è proprio quest´ultima che deve gestire i dati e gli eventi da e verso l´adattatore.

Dettaglio

Con questo tipo di integrazione , l´applicazione si deve integrare con l´adattatore intervenendo pesantemente sul codice e sugli eventi .

Figura 5: Integrazione tra applicativo e middleware

L´adattatore si limita a prendere in carico il messaggio ( in formato XML o HL7 ) per inoltrarlo alla applicazione destinataria. La costruzione del messaggio è compito della applicazione inviante.

Figura 6: Funzionamento dell´adattatore


Ad un messaggio inviato deve corrispondere un messaggio di risposta per accettazione o rifiuto della transazione. In molti scenari l´applicazione inviante può diventare anche ricevente e quindi è necessario che l´integrazione con l´adattatore preveda anche la ricezione dei messaggi con tutta la complessità che ne consegue ( aggiornamento tabelle nel database , messaggio di risposta , ecc.).

Figura 7: Invio di un messaggio

Figura 8: Messaggio di risposta


Aumento della complessità

A livello dell´applicativo le cose sono ancora più complesse, per ogni evento locale a cui deve corrispondere l´invio di uno o più messaggi HL7 è necessario implementare la logica di costruzione di ogni messaggio XML oltre che quella di integrazione con l´adattatore ( in funzione della metodologia adottata per lo scambio di messaggi , Web services , file system , data base , ecc.).

Figura 9: Flusso e conversione dei dati


L´alternativa è progettare un adattatore molto complesso in grado di gestire diversi messaggi sia in ingresso che in uscita con le opportune logiche di conversione ( XML verso HL7 e viceversa) , questo comporta per l´applicativo dover gestire strutture XML molto complesse. I numerosi tag XML conterranno tutti i campi che verranno interpretati e mappati nei corrispondenti campi HL7 dall´adattatore.

Figura 10: Mappatura dei campi


In pratica questo tipo di soluzione consente di integrare applicazioni affrontando la problematica in modo che lo scenario, i messaggi da scambiare, l´applicazione, la metodologia di integrazione, l´adattatore siano tutti visti come un unico oggetto, inscindibile.

Una variazione nello scenario , come l´uso di un nuovo messaggio in alternativa ad uno deprecato, un nuovo campo non previsto, una diversa metodologia di integrazione dovuta alla sostituzione della applicazione , comporta sicuramente pesanti modifiche sull´adattatore oltre che nell´applicazione.
W3C Standard