Interoperabilitat: Integració, Serveis, Processos, Events, Transformacions de dades, Operacions i Adaptadors (connectors).

Es evident de que quan parlem d'un gran sistema distribuit, els diferents membres que el formen ha de ser capaços de comunicar-se entre ells.
Quan s'estableix una comunicació, aquesta pot donar-se de manera sincronitzada o no. Sigui com sugui aquesta, el receptor, sempre rep la petició asincronament, ja que no sap en quin moment arriba.

Dit això, quan parlem de integrar dos sistemes, el que volem dir exactament, es que d'alguna manera s'intercanviin infromació entre ells. Ara bé, quan són tres, quatre, o més els que s'han de intercanviar informació, la cosa comença a complicar-se, si volem que tot funcioni correctament. I per tant hem de buscar una solució el més transparet pel nostre sistema.

Situem-nos. EL sistema que volem desenvolupar és una part de tots els sistemes que formen el sistema d'informació complert. S' ens dubte, és el més important, i per tant les acciones o esdeveniments que es produeixin en ell afecten a la resta. Imagime-nos que un pacient modifica la seva ubicació, d'urgències pasa a radiologia. Aquesta acció ha d' avisar al sistema que gestiona la radiologia de que aquest pacient es dirigeix cap allà perque se li realitzi alguna prova, o de que a un pacient se li ha realitzat un nou informe i aquest s'ha de publicar a la HCCC (Historia clínica compartida de Catalunya), d'aguna manera o altre ho haurem de comunicar.

Quan pasa qualsevol esdeveniment al sistema, com els abans esmentats, cal que aquest sigui el sufientment intel.ligent per a saber-los gestionar. Aquesta gestió o intel.ligècia, és la que determina una bona interoperabiltat entre els sistemes. És el que en el món del programador coneixement com a events, accions i esdeveniments que es van produin dins el sistema i els quals em de capturar.

"I com diu un company, en C.R, el sistema serà complert quan aquest sigui capaç de gestionar qualsevol event empresarial i ....".

Evidentment, i més coses que ara no venen al cas.

Arquitectura conduida per events.

Tornant al principi, i per tal d'aconseguir una bona interoperabilitat entre els sistemes, ja hem vist que cal gestionar events, però això no es tot. Un cop capturat el event, cal comunicar-lo. Un cop comunicat, cal processar-lo, potser aplicar alguna transformació de dades i fer-lo arribar al seu destinatari o destinataris (sistemes receptors). O també podem rebre, quina gràcia si nos fos així, i seguir el mateix procés.

Com a solució a tot això, s'ha optat a comprar una eina especialitzada per fer aquestes coses (EAI). La millor opció actualment al mercat és Ensemble de Intersystems. La arquitectura de desenvolupament d'aquesta eina és molt senzilla i potent. Es basa en serveis (de negoci) que escolten i quan els hi arriba algún missatge, engeguen el procés (de negoci, workflow) que aten al missatge, en ell es fan les operacions i transformacions de dades necessàries, i mitjançant operacions, comunica els resultats als sistemes destinataris. Per aconseguir cominar-se amb els sistemes receptors, aixì com per rebre missatges d'aquest, disposa d'una serie de d'adaptadors (odbc, web services, fitxer, http, ftp, etc) que faciliten aquesta part. Per altre banda, i molt important dins el món de la sanitat, ajuda de manera extrema la utilització de missatgeria HL7 fins versió 2.6.

"Com podem observar en el dibuix, un sistema envia un missatge a través d'un adaptador a un servei d' ensemble, aquest egenga un procés que el tractarà, i aquest invocarà les operacions necesàries, fins que un cop finalitzi, a traves d'una operació/ns i un adaptador/s anirà comunicant el resultat al o els sistemes receptors. S'ha de tenir en compte, que tot el que passa per Ensemble queda enregistrat, cosa que ajuda molt en el moment de buscar incidències, errors, o simplement, fer el seguiment d 'un missatge (tracert). No es propaganda, és una bona eina. Demaneu opinió.".

Si parlem d'un sistema conduit per events (event driven), haurem de pensar en fer un gestió d'aquest. Això em fa pensar amb la necessitat d'un servei més dins del sistema, un manejador d'events (event manager), el qual s'encarregarà de tractar tots els events que es produeixin en el sistema, engegant o fent les accions oportunes.

"Una aplicació, invoca un servei del HIS per realitzar alguna operació. El Servei atent la petició i invoca el fluxe de treball que la processarà. Si cal aquest utilitzararé la capa de dades per per operacions de presistència (CRUD). Un cop acabat el procés, si cal es comunicarà al Manejador d'events, de l'event que ha passat dins el sistema, i també, si cal retornarà resposta al client (Aplicació). El manejador, és el que decideix si cal comunicar aquest tipus d'event al EAi perque informi a la resta de sistemes. Si la resta de sistemes actuen igual podem tenir una interoperabilitat entre tots molt bona".

Seguint aquest patró aconseguim una escabilitat del sistema molt gran. A més li donem transparència, ja que podem arribar a desconeixer que hi ha darrera del EAI. Assegurem reutilització de codi, ja que la gestió d'un event pot comunicar a varis sistemes la seva resolució, o sigui que si afegim sistemes, pot ser que al nostre sistema no hi haguem de fer res, ja que la informació que necessita pot ser que ja estigui disponible dins el EAI pels events exitents. La integració quedaria reduida a una operació més dins el EAI que faria arribar el missatge al nou sistema.