Arxius de l'autor: Matias Lizana

Matias Lizana

Sobre Matias Lizana

Enginyer Superior en Informàtica, treballo al CCI a la línia d’entorns d’interoperabilitat. Certificat en CDA R2, especialitzat en treballar amb plataformes d’integració i interessat per les noves tecnologies, que promouen l’eficiència en els sistemes d’informació

Pàgina web:

2a Jornada Integració de Nivells Assistencials

Leer en castellano

El passat 7 de Novembre, el CCI va assistir a la 2a Jornada d’Integració de Nivells Assistencials que organitzava el Departament de Salut a Barcelona. L’acte presentava diversos casos d’integració de les TIC en l’àmbit de l’atenció primària i l’especialitzada, mostrant com s’han dut a terme, les tecnologies utilitzades, i comentant en cada cas els problemes i solucions que s’han trobat, que van ser de gran utilitat pel públic assistent.

A la jornada, van presentar els següents projectes d’integració:

  • Mercè Fernández (Hospital Universitari Girona Dr. Josep Trueta)

Estudi sobre els metges de Girona que es desplacen per fer visites, que generen un gran cost de desplaçament. Han posat a prova un pilot amb videoconferència, i han comparat les despeses generades en ambdos casos.

  • Carolina Burgos (Badalona Serveis Assistencials)

Plataforma per teledermatología, envien foto del pacient, s’avalua i es genera una resposta. L’anàlisi els demostra que millora la qualitat, i es poden avaluar més casos. Han aconseguit reduir la llista d’espera a la meitat de dies en 4 anys. El benefici augmenta a nivell de cost amb el numero de consultes.

  • Jordi Martinez (Institut Català de la Salut)

Integració amb el projecte PIPA (Plataforma d’Interoperabilitat de Processos Assistencials), que segueix el protocol WiFIS.

  • David Lacasta (EAP La Salut, Badalona)

Projecte de comunicació entre professionals, forum gestionat per especialistes, bloc, documents de referència. Els pacients poden accedir per consultar, i reduir així derivacions.

  • Andreu Parareda (Àrea Pediàtrica Alt Urgell)

Objectiu: Cobrir assistència pediatrica degut a la mancança per territori, amb el Consorci Pediatria de Pirineus. Portal per comunicar pacients i pediatres. Medibaby: Monitorització de nens.

  • Xavier Conill (Corporació de Salut Maresme i La Selva)

Reciclar eines en la situació actual: HC3, eConsultes, alertes, coordinació entre professionals. Èmfasi en treballar HC3, CPS i WiFIS.

  • Diego Palao (Corporació Sanitària Parc Taulí)

Plataforma per gestionar pacients, processos, agendes i comunicació entre centres.

  • Carlos Gallego (Oficina d’Estàndards i Interoperabilitat de TicSalut)

Definició dels marcs d’interoperabilitat: Model per compartir informació, imatges: HC3-RCIM. Tothom ha de tenir la mateixa seguretat per compartir informació. Cal homologar la terminologia i missatgeria utilitzades. Els marcs defineixen els processos independentment de la tecnologia.

La jornada va ser útil per els assistents, ja que van poder compartir dubtes en el món de la integració, tant dins com fora la jornada. Es va poder veure que a molts llocs diferents, només parlant de Catalunya, es generen projectes similars, i jornades com aquesta serveixen per posar en comú aquestes eines que poden millorar-se interaccionant entre elles, compartint informació, i solucionant els problemes que es poden trobar mútuament.



Llegir en català

El pasado 7 de Noviembre, el CCI asistió a la 2a Jornada de Integración de Niveles Asistenciales que organizaba el Departamento de Salud a Barcelona. El acto presentaba diversos casos de integración de las TIC en el ámbito de la atención primaria y la especializada, mostrando como se han llevado a cabo, las tecnologías utilizadas, y comentando en cada caso los problemas y soluciones que se han encontrado, que fueron de gran utilidad para el público asistente.

A la jornada, se presentaron los siguientes proyectos de integración:

  • Mercè Fernández (Hospital Universitari Girona Dr. Josep Trueta)

Estudio sobre los médicos de Girona que se desplazan para hacer visitas, que generan un gran coste de desplazamiento. Han puesto a prueba un piloto con videoconferencia, y han comparado los gastos generados en ambos casos.

  • Carolina Burgos (Badalona Serveis Assistencials)

Plataforma para teledermatología, envían foto del paciente, se evalúa y se genera una respuesta. El análisis les demuestra que mejora la calidad, y se pueden evaluar más casos. Han conseguido reducir la lista de espera a la mitad de días en 4 años. El beneficio aumenta a nivel de coste con el numero de consultas.

  • Jordi Martinez (Institut Català de la Salut)

Integración con el proyecto PIPA (Plataforma de Interoperabilidad de Procesos Asistenciales), que sigue el protocolo WiFIS.

  • David Lacasta (EAP La Salut, Badalona)

Proyecto de comunicación entre profesionales, foro gestionado por especialistas, bloc, documentos de referencia. Los pacientes pueden acceder para consultar, y así reducir derivaciones.

  • Andreu Parareda (Àrea Pediàtrica Alt Urgell)

Objetivo: Cubrir asistencia pediátrica debido a la carencia de esta por territorio, junto con el Consorci Pediatria de Pirineus. Portal para comunicar pacientes y pediatras. Medibaby: Monitorización de niños.

  • Xavier Conill (Corporació de Salut Maresme i La Selva)

Reciclar herramientas en la situación actual: HC3, eConsultas, alertas, coordinación entre profesionales. Trabajar HC3, CPS i WiFIS.

  • Diego Palao (Corporació Sanitària Parc Taulí)

Plataforma para gestionar pacientes, procesos, agendas y comunicación entre centros.

  • Carlos Gallego (Oficina d’Estàndards i Interoperabilitat de TicSalut)

Definición de los marcos de interoperabilidad: Modelo para compartir información, imágenes: HC3-RCIM. Todo el mundo ha de tener la misma seguridad para compartir información. Es necesario homologar la terminología y mensajería utilizadas. Los marcos definen los procesos independientemente de la tecnología.

La jornada fue útil para los asistentes, ya que pudieron compartir dudas en el mundo de la integración, tanto dentro como fuera de la jornada. Se pudieron ver que a muchos lugares distintos, solo hablando de Catalunya, se generan proyectos similares, y jornadas como ésta sirven para poner en común éstas herramientas que pueden mejorar-se interaccionando entre ellas, compartiendo información, y solucionando los problemas que se pueden encontrar mutuamente.



Formació Entorns d’Interoperabilitat

Leer en castellano 

El CCI-TCM (Centre de Competències d’Integració de la fundació Tecnocampus Mataró-Maresme) ofereix serveis de formació en l’àmbit dels Entorns d’Interoperabilitat i el de la Terminologia. Aquesta entrada vol presentar el curs d’integració de dispositius, referent a l’àmbit dels entorns d’interoperabilitat, que es proposa des del CCI i TicSalut.

Descripció del Curs

El curs d’integració de dispositius té com a objectiu formar especialistes en dispositius mèdics, amb coneixements en estàndards d’informació mèdica (HL7) i en els marcs d’interoperabilitat existents, tot fent ús d’una de les plataformes d’integració orientades a sanitat més utilitzades: Mirth Connect. Per això, el curs va dirigit a responsables d’integració i a tècnics informàtics, que puguin entendre i aprendre a desenvolupar aplicacions i solucions d’integració sota  la plataforma d’integració Mirth.

A continuació podeu veure el tríptic del curs:



Com es pot veure en el temari, el curs es divideix en diversos apartats:

Primer de tot, una introducció explicant la base dels estàndards i la interoperabilitat, veient la seva aplicació en diferents àmbits i en els sistemes d’informació y dispositius, que s’expliquen al següent apartat. A continuació, es fa referència als marcs d’interoperabilitat d’IHE i Continua Alliance, que defineixen les bones pràctiques d’utilització dels estàndards.

El curs continua amb una segona part més tècnica, on s’expliquen primer de tot les plataformes d’integració, basades en l’arquitectura ESB (en concret Mirth Connect). Finalment, l’últim apartat consisteix en desenvolupar dos casos d’ús per integrar un espiròmetre i un electrocardiògraf.

Edicions del curs

Als passats 10 i 11 de Maig es va dur a terme la primera edició del curs, amb 20 participants que van omplir totes les places, i amb uns resultats satisfactoris. En el curs, els alumnes van poder aprendre les bases dels estàndards en l’àmbit de sanitat, i es van poder enfrontar als problemes reals d’una integració, treballant amb la plataforma Mirth Connect. Els assistents alhora, tenen la possibilitat de posar en comú els seus coneixements en l’àmbit, i proposar problemes amb els que es troben dia a dia.

La segona edició es durà a terme aquest Setembre del 2012, dies 26 i 27, la qual ja esta tenint una bona acollida degut a l’interès mostrat per part de la gent que es comença a inscriure. Les inscripcions estan obertes, amb places limitades, i es poden realitzar al següent enllaç:

Inscripció al Curs d’Integració de Dispositius 2a Edició

Llegir en català 

El CCI-TCM (Centre de Competències d’Integració de la fundació Tecnocampus Mataró-Maresme) ofrece servicios de formación en el ámbito de los Entornos de Interoperabilidad y el de la Terminología. Esta entrada quiere presentar el curso de integración de dispositivos, referente al ámbito de los entornos de interoperabilidad, que se propone des del CCI y TicSalut.

Descripción del Curso

El curso de integración de dispositivos tiene como objetivo formar especialistas en dispositivos médicos, con conocimientos en estándares de información médica (HL7) y en los marcos de Interoperabilidad existentes, haciendo uso de una de las plataformas de integración orientadas a salud más utilizadas: Mirth Connect. Por eso, el curso va dirigido a responsables de integración y técnicos informáticos, que puedan entender y aprender a desarrollar aplicaciones y soluciones de integración bajo la plataforma de integración Mirth.

A continuación podéis ver el tríptico del curso:



Com se puede ver en el temario, el curso se divide en varios apartados:

Primero de todo, una introducción explicando la base de los estándares y la interoperabilidad, viendo su aplicación en diferentes ámbitos y en los sistemas de información y dispositivos, que se explican en el siguiente apartado. A continuación, se hace referencia a los marcos de interoperabilidad de IHE y Continua Alliance, que definen las buenas practicas de utilización de los estándares.

El curso continua con una segunda parte más técnica, donde se explican primero de todo las plataformas de integración, basadas en la arquitectura ESB (en concreto Mirth Connect). Finalmente, el último apartado consiste en desarrollar dos casos de uso para integrar un espirómetro y un electrocardiógrafo.

Ediciones del curso

Los pasados 10 y 11 de Mayo se llevo a cabo la primera edición del curso, con 20 participantes que llenaron todas las plazas, y con unos resultados satisfactorios. En el curso, los alumnos pudieron aprender las bases de los estándares en el ámbito sanitario, y pudieron enfrentarse a los problemas reales de una integración, trabajando con la plataforma Mirth Connect. Los asistentes a la vez, tuvieron la posibilidad de poner en común sus conocimientos en el ámbito, y proponer problemas con los que se encuentran dia a dia.

La segunda edición se llevará a cabo éste Septiembre del 2012, días 26 y 27, la cuál ya esta teniendo una buena aceptación debido al interés mostrado por parte de la gente que empieza a escribirse. Las inscripciones estan abiertas, con plazas limitadas, y se pueden realizar al siguiente enlace:

Inscripción al Curso de Integración de Dispositivos 2a Edición

WiFIS a ForumCIS

Leer en castellano

El CCI va participar, com ja vam anunciar al seu moment, a la jornada del ForumCIS que es va celebrar els dies 18, 19 i 20 d’Abril a Barcelona. En una de les assistències, el CCI va fer una ponència sobre el projecte WiFIS: Workflow en Institucions de Salut.

El projecte WiFIS té com a objectiu principal, definir la interoperabilitat entre centres a dos nivells: A nivell de procediment i a nivell de comunicació. Això vol dir, com definir d’una banda uns procediments que siguin comuns per tots els centres (com poden ser “Nova Comanda Clínica”, “Petició de eConsulta” o “Nova Citació”, i d’altra banda, definir un canal de comunicació estàndard, per tal de que la informació que viatgi tingui un criteri comú, amb el qual tots els centres es puguin entendre.

D’aquesta manera, es vol aconseguir connectar tots els centres d’una forma interoperable i centralitzada, utilitzant una plataforma d’integració que gestioni el flux de totes les connexions entre els centres.

El principal avantatge és que es resolen les comunicacions i desenvolupaments punt a punt, com s’ha fet fins ara, a través d’acords entre centres. Això, amb el temps, ha produït tot un sistema descentralitzat, que es difícil de mantenir i poc usable.

Amb la inclusió d’una plataforma d’integració, alhora que s’integren els processos entre centres, s’aconsegueix la interoperabilitat que ens permet afegir nous centres al conjunt, que es puguin comunicar amb tots els altres centres que ja estan connectats, fent-ho d’una manera senzilla.

Per aconseguir aquesta interoperabilitat, es fa us dels estàndards de comunicació (HL7). Amb aquest estàndard s’aconsegueix definir una missatgeria, amb la qual tots els centres es podran comunicar enviant la mateixa informació ens els casos descrits (com ara un missatge OMG_019 per fer la petició d’una comanda clínica, o un ORU_R01 per retornar els resultats de les proves).

Tota la definició dels missatges i dels processos WiFIS esta descrita en l’anomenada “Guia de Missatgeria WiFIS”, la qual conté tots els diagrames dels casos d’ús que es duen a terme, i també la definició de la missatgeria a partir de documents Excel que descriuen tots i cadascun dels camps dels missatges HL7.

Pel que fa la implantació, s’ha realitzat un pilot a Calella del projecte WiFIS, el qual s’ha dut a terme mitjançant la plataforma d’integració Ensemble d’Intersystems. La connexió entre els centres es fa a partir de WebServices, els quals es criden desde la plataforma, la qual té una taula amb les direccions IP de tots els centres, per tal de poder dirigir el tràfic de informació tal i com pertoqui (fent servir la plataforma com un enrutador, i evitant així les connexions punt a punt).

Per a més informació sobre el projecte, i poder descarregar la guia de missatgeria, juntament amb la definició dels missatges, podeu visitar la web de la Oficina d’Estàndards i Interoperabilitat:

http://www.gencat.cat/salut/ticsalut/html/ca/dir3480/doc35693.html

Llegir en català

El CCI participó, como ya anunciamos en su momento, a la jornada del ForumCIS que se celebró los días 18, 19 y 20 de Abril a Barcelona. En una de las asistencias, el CCI hizo una ponéncia sobre el proyecto WiFIS: Workflow en Instituciones de Salud.

El proyecto WiFIS tiene como objetivo principal, definir la interoperabilidad entre centros a dos niveles: A nivel de procedimiento y a nivel de comunicación. Eso quiere decir, cómo definir por un lado unos procedimientos que sean comunes para todos los centros (com pueden ser “Nueva Comanda Clínica”, “Petición de eConsulta” o “Nueva Citación”, y por otro lado, definir un canal de comunicación estándard, para que la información que viaja tenga un criterio común, con el cuál todos los centros se puedan entender.

De ésta forma, se quiere conseguir conectar todos los centros de una forma interoperable y centralizada, utilizando una plataforma de integración que gestione el flujo de todas las conexiones entre los centros.

La principal ventaja es que se resuelven las comunicaciones y desarrollos punto a punto, como se ha hecho hasta ahora, a través de acuerdos entre centros. Esto, con el tiempo, ha producido todo un sistema descentralizado, que es difícil de mantener y poco usable.

Con la inclusión de una plataforma de integración, a la vez que se integran los procesos entre centros, se consigue la interoperabilidad que nos permite añadir nuevos centros al conjunto, que se puedan comunicar con todos los otros centros que ya estan conectados, haciéndolo de una forma sencilla.

Para conseguir esta interoperabilidad, se hace uso de los estándares de comunicación (HL7). Con éste estándard se consigue definir una mensajeria, con la cuál todos los centros se podran comunicar enviando la misma información en los casos descritos (como un mensaje OMG_019 para hacer la petición de una comanda clínica, o un ORU_R01 para devolver los resultados de las pruebas).

Toda la definición de los mensajes y de los procesos WiFIS esta descrita en la “Guía de Mensajería WiFIS”, la cuál contiene todos los diagramas de los casos de uso que se llevan a cabo, y también la definición de la mensajeria a partir de documentos Excel que describen todos y cada uno de los campos de los mensajes HL7.

Por lo que hace a la implantación, se ha realitzado un piloto a Calella del proyecto WiFIS, el cuál se ha llevado a cabo mediante la plataforma de integración Ensemble de Intersystems. La conexión entre centros se hace a partir de WebServices, los cuáles se llaman desde la plataforma, que tiene una tabla con las direcciones IP de todos los centros, para poder dirigir el tráfico de información tal y como toca (haciendo servir la plataforma como un enrutador, y evitando así las conexiones punto a punto).

Para más información sobre el proyecto, y poder descargar la guía de mensajería, junto con la definición de los mensajes, podéis visitar la web de la Oficina de Estándares e Interoperabilidad:

http://www.gencat.cat/salut/ticsalut/html/ca/dir3480/doc35693.html

Congrés AppsONhealth 2012 a Barcelona

Leer en castellano

El CCI va assistir ahir al appsONhealth, un congrés que es va celebrar a l’hospital Sant Joan de Deu, en relació a les aplicacions mòbils orientades a la salut. L’objectiu de la jornada era, d’una banda, transmetre el coneixement d’experts en el món de les empreses que treballen amb aplicacions mòbils en general, i d’altra banda, obtenir també el feedback de les necessitats del personal sanitari, per veure com ambdós àmbits es podien unir per cobrir les necessitats tecnològiques del sector.

El congrés el va iniciar Chia Hwu @chiah, de l’empresa Qubop, que va fer un repàs de l’estat del sector, en quant a aplicacions sanitàries i en quant a les plataformes utilitzades, en el que va deixar remarcat que Apple era el producte més utilitzat, i en el que també va fer una diferenciació entre els avantatges de les aplicacions web (aplicacions per navegador, en HTML5 actualment), i les apps normals (app). Dan Phillips, de l’empresa SandBox, va parlar sobre les oportunitats actuals del sector de la sanitat, i va fer una presentació sobre la seva aplicació Healthbox. Lekshmy Parameswaran, de l’empresa Fuelfor, va presentar un tema molt important, que és el contacte amb l’entorn sanitari alhora de desenvolupar aplicacions o resoldre necessitats. Tenen un projecte en el qual han recorregut diversos hospitals, veient com es desenvolupen totes les tasques, i intentant millorar tots els processos que s’hi duen a terme.

A part dels ponents principals, entre mig es van desenvolupar una sèrie de xerrades en taula rodona, en les quals experts del sector d’empreses com Telefònica o Inuovo, professionals de la sanitat, així com els mateixos ponents. Les xerrades van tractar sobre les necessitats dels hospitals i pacients (en la qual una doctora va explicar problemes que tenien alhora de realitzar alguns processos, i les situacions amb les que es trobaven), també sobre les 10 maneres de potenciar una aplicació pròpia (en la qual els experts van comentar els punts forts com el tipus de finançament, les necessitats de l’usuari, la integració de les dades…) i finalment una xerrada centrada exclusivament en com obtenir diners d’una aplicació mòbil (en la que es van plantejar diversos plans de negoci, com ara l’appstore, la publicitat (banners, anuncis…) i també el model trial/premium).

Un cop finalitzats tots aquests actes, es va celebrar l’AppCircus, un concurs que es fa a diversos països, on aquí es van presentar 11 aplicacions, les quals van ser:

  • Universal Doctor: Un traductor de frases exclusives de sanitat, per quan vas a un altre país i et fa mal alguna cosa, poder-ho comunicar sense problemes.
  • Tweri: Geolocalització de pacients que tenen alzheimer.
  • iDoc24: Telemedicina en mòbil, per poder enviar consultes de dermatologia.
  • Ablah: Relació d’objectes mitjançant fotografia amb un text, per poder-les reproduir amb sons, per persones que no poden parlar.
  • VitaDock: Gestor de dades biomèdiques amb dispositius externs adaptats al iPhone.
  • InShape Moms (Finalista): Guia/suport d’embarassades per mòbil, amb xarxa social i videos per fer exercicis.
  • WithBaby: Monitor per a bebès, amb una càmara externa de visió nocturna, i configurable amb colors i música.
  • Social Diabetes: Planificador de diabetis, amb comunitat social.
  • Helptalk: Comunicació per persones minusvàlides.
  • iPVoidingDiary: Registre de les orines, per incontinència.
  • doctordoctor: PHR per mòbil.

Després de tot això, es va anunciar el guanyador (InShape Moms) al qual se li va entregar el premi d’anar a la final a presentar la seva aplicació.

La conclusió de la jornada per part nostra, ha sigut que el món de la salut té molts fronts oberts en quan a negoci, desenvolupament, i resolució de necessitats, i les aplicacions per mòbil en aquest àmbit, són un front molt important a tenir en compte, ja que d’una banda estenen més àmpliament el negoci de les apps, i d’altra banda entren amb força dins el món sanitari, ajudant al personal sanitari i als pacients, en el seu dia a dia.

Llegir en català

El CCI asistió ayer al appsONhealth, un congreso que se celebró al hospital Sant Joan de Deu, en relación a las aplicaciones móviles orientadas a la salud. El objetivo de la jornada era, por una parte, transmitir el conocimiento de expertos en el mundo de las empresas que trabajan con aplicaciones móviles en general, y por otra parte, obtener también el feedback de las necesidades del personal sanitario, para ver como los dos ámbitos se podían unir para cubrir las necesidades tecnológicas del sector.

El congreso lo inició Chia Hwu @chiah, de la empresa Qubop, que hizo un repaso del estado del sector, en cuanto a las aplicaciones sanitarias y en cuanto a las plataformas utilitzadas, en el que remarcó que Apple era el producto más utilizado, y en el que también hizo una diferenciación entre las ventajas de les aplicaciones web (aplicaciones para navegador, en HTML5 actualmente), y las apps normales (app). Dan Phillips, de la empresa SandBox, habló sobre las oportunidades actuales del sector de la sanidad, y hizo una presentación sobre su aplicación Healthbox. Lekshmy Parameswaran, de la empresa Fuelfor, presentó un tema muy importante, que es el contacto con el entorno sanitario, cuando se han de desarrollar aplicaciones o resolver necesidades. Tienen un proyecto en el qual han recorrido diferentes hospitales, viendo como se desarrollan todas las tareas, intentando mejorar todos los procesos que se llevan a cabo.

A parte de los ponentes principales, entre medio se desarrollaron una serie de debates en una mesa redonda, en los cuáles expertos del sector de empresas como Telefònica o Inuovo, profesionales de la sanidad, así como los mismos ponentes. Los debates trataron sobre las necesidades de los hospitales y pacientes (en las cuáles una doctora explicó los problemas que tenían cuando realizaban algunos procesos, y las situaciones con las que se encontraban), también sobre las 10 formas de potenciar una aplicación propia (en la cual los expertos comentaron los puntos fuertes como el tipo de financiamiento, las necesidades del usuario, la integración de los datos…) y finalmente un debate centrado exclusivamente en como obtener beneficios de una aplicación móvil (en la que se plantearon diferentes planes de negocio, com el l’appstore, la publicidad (banners, anuncios…) y también el modelo trial/premium).

Una vez finalizados todos éstos actos, se celebró el AppCircus, un concurso que se hace a diferentes países, donde aquí se presentaron 11 aplicaciones, las cuales fueron:

  • Universal Doctor: Un traductor de frases exclusivas de sanidad, para cuando vas a otro país y te encuentras mal, poder comunicarlo sin problemas.
  • Tweri: Geolocalización de pacientes que tienen alzheimer.
  • iDoc24: Telemedicina en móvil, para poder enviar consultas de dermatología.
  • Ablah: Relación de objetos mediante fotografía con texto, para poderlas reproducir con sonidos, para personas que no pueden hablar.
  • VitaDock: Gestor de datos biomédicos con dispositivos externos adaptados al iPhone.
  • InShape Moms (Finalista): Guia/soporte de gestantes para móvil, con red social y vídeos para hacer ejercicios.
  • WithBaby: Monitor para bebés, con una cámara externa de visión nocturna, configurable con colores y música.
  • Social Diabetes: Planificador de diabetis, con comunidad social.
  • Helptalk: Comunicación para personas minusválidas.
  • iPVoidingDiary: Registro del orín, para la incontinencia.
  • doctordoctor: PHR para móvil.

Después de todo esto, se anunció el ganador (InShape Moms) al que se le entregó el premio de ir a la final a presentar su aplicación.

La conclusión de la jornada por nuestra parte, ha sido que el mundo de la salud tiene muchos frentes abiertos en cuanto a negocio, desarrollo, y resolución de necesidades, y las aplicaciones para móvil en éste ámbito, són un frente muy importante a tener en cuenta, ya que por una parte ayudan a difundir el negocio de las apps, i por otra parte entran con fuerza dentro del mundo sanitario, ayudando al personal sanitario y a los pacientes, en su dia a dia.

Efficient XML Interchange

Leer en castellano

En aquest post mostrarem una tecnologia per transmetre els fitxers XML d’una manera més ràpida, especialment dissenyat per les tecnologies d’avui en dia, com poden ser els smartphones. Un cop introduida, farem una prova treballant en el camp dels estàndards (concretament amb l’estàndard CDA R2) i veurem l’impacte que crea aquesta tecnologia sobre fitxers CDA XML.

EXI (Efficient XML Interchange) és un format de dades proposat per el Efficient XML Interchange Working Group, i ja es considera estandard W3C. L’objectiu d’aquest format és codificar documents XML en un format binari, per reduir l’espai dels missatges, i permetre una transmissió entre dispositius molt més àgil.

Format

Un document EXI està format per un EXI Header i un EXI Body.

EXI Header

Conté les propietats de codificació necessàries per poder codificar i descodificar l’EXI-stream. La mida mínima de capçalera és de 1 byte, per tant podem considerar que té un overhead molt baix.

EXI Body

El cos d’un document EXI esta composat per events EXI. Els ítems XML es codifiquen en un o més EXI events. Els events s’agrupen seguint una definició de gramàtica, per veure els elements que es repeteixen més o menys, per codificar la informació en funció d’això, i pode r comprimir molt més la cadena, semblant al mètode de compressió dels codis Huffman. La idea és comprimir al màxim l’espai que ocupen els “tags” de l’XML, que solen repetir-se molt.

Primer mostrem un exemple d’XML qualsevol:

<?xml version="1.0" encoding="UTF-8"?>
<notebook date="2007-09-12">
<note category="EXI" date="2007-07-23">
<subject>EXI</subject>
<body>Do not forget it!</body>
</note>
<note date="2007-09-12">
<subject>Shopping List</subject>
<body>milk, honey</body>
</note>
</notebook>

Aquest XML es representa en EXI events de la següent forma:

Un cop tenim els EXI events, s’ordenen per poder fer la compressió dels tags:


Rendiment

Per veure una prova del rendiment d’aquest mètode, farem un parell de proves amb fitxers XML, amb propietats diferents.

Compressió de fitxer d’espirometria propietari

Baix rendiment degut a les poques repeticions de tags, ja que cada tag és diferent, per transmetre cada dada que és única de l’espiròmetre.

Original:               27 KB

EXI:                        8 KB

Ratio:                    1/3

Compressió del document CDA d’espirometria

Alt rendiment degut a la gran quantitat de tags a repetir tant d’estructura de CDA (entries, components, code…) com d’estructura del text html per mostrar l’informe (td, tr, table…).

Original:               680 KB

EXI:                        35 KB

Ratio:                    1/20

Conclusió

Aquest nou mètode és molt important, primer de tot perquè ha sigut aprovat com un estàndard per la W3C, i per tant no és cap format propietari.

El punt fort del mètode és que està concretament orientat a codificar XML, res més, a diferència d’altres sistemes de compressió genèrics.

La compressió es pot veure aplicada en documents CDA i això pot ser molt interessant per integrar documents en format EXI, per ocupar menys espai, i per transmetre en un temps més ràpid.

A més cal dir que aquest estàndard s’ha desenvolupat pensant en dispositius mòbils, per facilitar una transmissió més ràpida i amb menys pes, per tant tenir aquest format crearia un impacte important en aquests dispositius, i en el desenvolupament de noves aplicacions per aquests.

Fragment extret del document “EXI (Efficient XML Interchange) – M. Lizana”

Llegir en català

En esta entrada mostraremos una tecnología para transmitir los ficheros XML de una manera más rápida, especialmente diseñada para las tecnologías de hoy en día, como los smartphones. Una vez introducida, haremos una prueba trabajando en estándares (en concreto con el estándar CDA R2) i veremos el impacto que crea esta tecnología sobre ficheros CDA XML.

EXI (Efficient XML Interchange) es un formato de datos propuesto por el Efficient XML Interchange Working Group, y se considera estándar W3C. El objetivo de éste formato es codificar documentos XML en un formato binario, para reducir el espacio de los mensajes y permitir una transmisión entre dispositivos mucho más ágil.

Formato

Un documento EXI está formado por un EXI Header y un EXI Body.

EXI Header

Contiene las propiedades de codificación necesarias para poder codificar y descodificar el EXI-stream. El tamaño mínimo de cabecera es de 1 byte, por tanto podemos considerar que tiene un overhead muy bajo.

EXI Body

El cuerpo de un documento EXI esta compuesto por eventos EXI. Los ítems XML se codifican en uno o más EXI events. Los eventos se agrupan siguiendo una definición de gramática, para ver los elementos que se repiten más o menos, para codificar la información en función de estos elementos, y poder comprimir mucho más la cadena, parecido al método de compresión de los códigos Huffman. La idea es comprimir al máximo el espacio que ocupan los “tags” del XML, que suelen repetirse mucho.

Primero mostramos un ejemplo de XML cualquiera:

<?xml version="1.0" encoding="UTF-8"?>
<notebook date="2007-09-12">
<note category="EXI" date="2007-07-23">
<subject>EXI</subject>
<body>Do not forget it!</body>
</note>
<note date="2007-09-12">
<subject>Shopping List</subject>
<body>milk, honey</body>
</note>
</notebook>

Éste XML se representa en EXI events de la siguiente forma:

Una vez tenemos los EXI events, se ordenan para poder hacer la compresión de los tags:

Rendimiento

Para ver una prueba del rendimiento de éste método, haremos un par de pruebas con ficheros XML, con propiedades diferentes.

Compresión del fichero de espirometría propietario

Bajo rendimiento debido a las pocas repeticiones de los tags, ya que cada tag es diferente, para transmitir cada dato que es único del espirómetro.

Original:               27 KB

EXI:                        8 KB

Ratio:                    1/3

Compressión del documento CDA de espirometría

Alto rendimento debido a la gran cantidad de tags a repetir tanto de estructura de CDA (entries, components, code…) como de estructura del texto html para mostrar el informe (td, tr, table…).

Original:               680 KB

EXI:                        35 KB

Ratio:                    1/20

Conclusión

Éste nuevo método es muy importante, primero de todo porque ha sido aprobado como un estándar por la W3C, y por lo tanto no es formato propietario.

El punto fuerte del método es que esta concretamente orientado a codificar XML, nada más, a diferencia de otros sistemas de compresión genéricos.

La compresión se puede ver aplicada en documentos CDA i esto puede ser muy interesante para integrar documentos en formato EXI, ocupando menos espacio y transmitiendo en un tiempo más rápido.

Además éste estándar se ha desarrollado pensando en dispositivos móviles, para facilitar la transmisión más rápida y con menos peso. Con éste formato se crearía un impacto importante en estos dispositivos, y en el desarrollo de nuevas aplicaciones para estos.

Fragmento extraído del documento “EXI (Efficient XML Interchange) – M. Lizana”

Entorns d’Integració (III)

En aquesta última entrada sobre entorns d’integració, parlarem dels ESB i farem unes conclusions generals sobre aquests entorns.

ESB (Enterprise Service Bus)

Introducció

És possible referir-se  a un ESB com la forma de portar a la pràctica un EAI, ja que és un dels principals artefactes en una estratègia d’integració d’aplicacions a nivell corporatiu. Es pot afirmar que és una de les solucions possibles, ja que hi ha altres formes per crear una EAI, tot i que en els últims temps, els ESB s’haguessin convertit en una de les opcions globalment més utilitzades.

Actuant com middleware, proveeix una capa d’abstracció de baix nivell que facilita l’intercanvi entre aplicacions a través de protocols de comunicació heterogenis. Això és possible gràcies a la inclusió de tecnologies estàndards i obertes. L’intercanvi, abans esmentat, no només es refereix a l’òbvia funció de dispatching de missatges, portant dades d’un punt a un altre, sinó a la possibilitat de reutilitzar processos de negocis a través d’un conjunt de funcionalitats exposades en forma de serveis, que és exactament la finalitat de SOA.

Els processos de negocis solen estar definits en artefactes externs als ESB, concretament als Business Process Management. Ara be, la majoria dels ESB que suporten una mínima lògica de processos, solen estar bastant lluny de les prestacions oferides pels BMPs.

Una solució corporativa

Fent èmfasi en l’ambient en el qual és propicia la implementació d’un ESB: les empreses d’una envergadura tal que, per necessitats pròpies i de tercers, compten amb un nombre considerable d’aplicacions funcionant, per solucionar problemàtiques particulars. Sistemes de gestió, administratiu-comptables, de relació amb el client, d’abastament, de recursos humans i tants d’altres. Tradicionalment la forma d’interactuar d’aquests sistemes es basa en el model “spaghetti” (figura A), on cada aplicació exposa les seves interfícies i es realitzen comunicacions punt a punt entre elles. Aquest model porta aparellats problemes com dependències entre sistemes, dificultat de manteniment de les aplicacions (a causa del acoblament), responsabilitats poc clares, documentació no sincronitzada .

Distribució d'aplicacions punt a punt
Figura A

La incorporació d’un middleware que administri la comunicació, de com un ESB ajuda a millorar i ordenar de manera notable la manera de pensar i treballar és necessari, ja que defineix les responsabilitats de les interfícies dels sistemes, separa les tasques en forma clara, evita l’acoblament entre els sistemes, facilita la manutenció dels sistemes i, sobretot, simplifica l’arquitectura conceptual del model d’interacció dels sistemes involucrats (figura B).

Connexió d'aplicacions centralitzada
Figura B

Característiques comuns

Als ESB se’ls hi pot trobar una sèrie de característiques comunes:

– Configuració per sobre de la programació: Els ESB solen comptar amb una característica particular: el seu ús en forma declarativa. Això redueix l’aparició d’errors per errors de programació i simplifica les proves dels serveis, i centralitza en una sola capa la responsabilitat de la interconnexió dels sistemes, el que simplifica l’administració.

– Orquestració de serveis: a través de llenguatges estàndards com BPEL, permeten la coordinació i organització de la invocació dels diferents serveis. D’aquesta manera és possible definir processos de negoci dins dels ESB.

– Transformació de dades: és la facultat de realitzar correspondències de dades entre diferents contextos d’aplicació. Mitjançant correspondències és possible “traduir” unes dades del context d’una aplicació en particular, de tal manera que sigui reconegut per un altre sistema.

– Síncron + asíncron: Ja que la durada d’algun dels processos exposats en forma de servei pot ser considerable (des de dies fins a setmanes), és important comptar amb la possibilitat d’executar tasques en forma asincrònica i en paral·lel. El processament síncron obliga a esperar el resultat d’una tasca per continuar amb la següent, que és convenient de ser aplicada, per exemple, en accions que requereixen interacció amb usuaris.

– Web Services: És la tècnica més difosa en els últims temps per exposar processos de negoci en forma simple, a través d’HTTP.

– Basat en estàndards: L’intercanvi d’informació normalment es realitza en documents basats en XML.

– Enrutament: La majoria dels ESB permeten definir processos, oferint alguna lògica de fluxos, com estructures iteratives, condicionals, processament en paral·lel, invocació d’altres serveis, entre altres.

– Seguretat Incorporada: Normalment cada ESB porta incorporada la seva pròpia seguretat referida a l’autenticació i autorització d’usuaris. També suporten protocols de comunicació segura, mitjançant HTTPS.

– Interfície d’usuari: Alguns ESB brinden la possibilitat d’administrar el bus a través d’una interfície amigable.

 

Avantatges

– Acomodació de sistemes existents de forma més ràpida i barata

– Major flexibilitat, més fàcil de canviar si hi ha nous requisits.

– Basat en normes (estàndards oberts)

– Tipus de servei  (ready-to-use) predefinits

– Major part de configuració en comptes d’haver de codificar la integració.

– Sense motor de normes central, sense divisor central

Quan no aplica?

Tot i que repassem a grans trets els motius que justifiquen l’ús d’un ESB juntament amb el seus beneficis, és convenient també ser realistes i entendre quan un ESB es pot convertir més en un problema que en un benefici. Imaginem un cas d’una empresa amb tradició, que inevitablement vol incorporar l’ús d’un sistema de gestió intern i una aplicació de tipus CRM. Aquesta organització, reticent al canvi, es troba amb la necessitat de compartir informació entre ambdós sistemes. El responsable de l’àrea de sistemes d’aquesta empresa, llegint una revista de tecnologia es troba cada vegada amb més articles sobre SOA,  d’integració d’aplicacions, Web Services, etc. Sense estar convençut i fins i tot desconeixent a fons aquests termes, decideix que el que es necessita és un ESB, pressionat pels temps dels seus superiors que necessiten una solució urgent al problema que els afecta. En aquesta petita història podem trobar pràcticament tots els paradigmes de la “anti-necessitat”  per comptar amb un ESB. Enumerant:

– Poques aplicacions: En aquest (extrem) cas en el qual coexisteixen només dues aplicacions, el bus d’integració no faria més que funcionalitat com a comunicació punt a punt.

– Modes: Si bé no hi ha dubte que la integració d’aplicacions és una necessitat real i concreta en l’actualitat, inclinar-se per una opció d’integració en lloc d’una altra pel sol fet de la publicitat que circula en els mitjans, és un error tristament comú.

– Mentalitat de serveis: endinsar-se en el món de SOA quan no hi ha una política seriosa, acompanyada d’una mentalitat d’acord amb la “filosofia de serveis” és un error que moltes companyies cometen en l’actualitat.

Desavantatges

– Normalment requereix d’un model de missatgeria “d’empresa”, la qual cosa exigeix una administració addicional.

– Necessita més maquinari que per a un simple sistema de missatgeria de punt-a-punt.

– És necessiten coneixements amb  anàlisi de middlewares per a configurar, administrar i operar un ESB.

– Major latència general causada pels missatges que travessen  la capa extra del ESB, especialment si és compara amb les comunicacions punt-a-punt. La major latència també s’origina per un processament de XML extra (el ESB normalment s’utilitza XML com a llenguatge de comunicació).

– El ESB és converteix en un element únic d’error.

– Encara que els sistemes ESB puguin requerir un esforç significatiu per a ser implementats, no produeixen un valor comercial sense el consegüent desenvolupament de serveis SOA per el ESB.

Patrons d’integració, VETRO pattern

Qualsevol entorn d’integració te que complir amb aquest patró d’integració per tal de poder poder-lo anomenar com a tal. El seu acrònim esta composat per les següent paraules:

– Validació: S’encarrega d’auditar/validar els missatges entrant al entorn, aquesta validació es basa en estàndards, per exemple, validar un XML contra el seu respectiu XSD.

– Enriquiment: Enriquiment del missatge inicial del client amb informació necessària per a la invocació del servei final. En la majoria de les ocasions aquest enriquiment és generat en trucades a serveis de negoci i afegint informació al missatge

– Transformació: Aquesta part és l’encarregada de transformar el missatge original a un altre format que sigui necessari pel servei final, per exemple les proves en XML del espiròmetre de NDD  al format HL7-CDA

– Enrutament: Aquesta part és molt interessant, és l’encarregada de direccionar el missatge a diferents serveis d’acord al contingut o l’operació, inclús es poden tenir taules de direccionament.

– Operar: És la que part que s’encarrega de comunicar-se amb el servei final, és a dir es connecta amb els serveis de negoci.

Conclusions

Les tecnologies sobre els entorns d’integració encara estan en desenvolupament i no hi ha un consens sobre quin és l’enfocament ideal o el grup correcte de tecnologies que una companyia hauria de fer servir. El futur dels entorns d’integració passa per proporcionar llenguatges que permetin dissenyar les solucions d’integració a un alt nivell d’abstracció, independentment de tecnologies, i que es pugui d’una forma automàtica fer transformacions dels models de solució a tecnologies concretes.

En l’actualitat la gran majoria d’empreses mitjanes-grans tenen un gran volum de informació que ens transmet per varies aplicacions i departaments a traves de les tecnologies de la informació, tenint molts fluxos d’informació que provoquen ineficiència entre les seves comunicacions. Avui dia, per tenir un avantatge competitiu respecte a d’altres, cal dedicar-hi més temps a la reenginyeria dels processos de negoci y no a com estructurar aquests per de tal de aconseguir una comunicació entre ells.

La implementació d’un entorn d’integració  dintre de la organització, provoca una normalització del procés de cadascuna de les aplicacions que te la empresa per connectar-se amb el framework , un estalvi en manteniment d’aplicacions especifiques, major eficiència de transmissió de dades entre sistemes i processos de negoci, enriquiment, monitorització, validació, i enrutament de cadascuna de les dades entrants i sortints en l’entorn d’integració. Donant coma resultat un canal únic de comunicació entre totes les aplicacions de diferents departaments de dintre de l’organització que permet tenir un entorn de la informació fàcilment explotable, i que es pugui compartir informació entre departaments de manera senzilla .

Altre dels aspectes a tenir en compte es la integrat de les dades, ja que es pot realitzar un seguiment exhaustiu de la mateixa des de que surt de la seva corresponent aplicació fins a que es tractat y surt del corresponent framework, permetent realitzar auditories sobre la informació de la organització.

 

Fins aquí la nostra última entrada sobre entorns d’integració.

 

Entorns Integració (II)

En aquesta segona entrada, parlarem sobre les arquitectures del software sota els entorns d’integració: SOA i EAI.

SOA (Arquitectura orientada a serveis)

L’Arquitectura Orientada a Serveis (en anglès Service Oriented Architecture), és un concepte d’arquitectura de programari basada en la utilització de serveis per donar suport als requisits del negoci.

Permet crear sistemes altament escalables que suporten el creixement del negoci i ofereix una forma ben definida d’exposició i invocació de serveis (comunament però no exclusivament, serveis web), fent que els sistemes siguin interoperables.

SOA comporta una metodologia i un marc de treball per documentar les capacitats de negoci i pot donar suport a les activitats d’integració i consolidació.

Disseny i desenvolupament de SOA

La metodologia de modelatge i disseny per a aplicacions SOA es coneix com anàlisi i disseny orientat a serveis. L’arquitectura orientada a serveis és, al mateix temps, un marc de treball per al desenvolupament de programari i un marc de treball per a la seva implementació. Perquè un projecte SOA tingui èxit, els desenvolupadors de programari han de tenir la mentalitat de crear serveis comuns, que són orquestrats per clients o middleware per implementar els processos de negoci. El desenvolupament de sistemes usant SOA requereix un compromís amb aquest model en termes de planificació, eines i infraestructura.

Quan es parla d’una arquitectura orientada a serveis s’està parlant d’un joc de serveis residents a Internet o en una intranet, usant serveis web. Hi ha diversos estàndards relacionats als serveis web. Incloent els següents: XML, HTTP, SOAP, WSDL, UDDI.

Cal considerar, però, que un sistema SOA no necessàriament necessita utilitzar aquests estàndards per ser “orientat a serveis”.

En un sistema que treballa segons SOA, els nodes de la xarxa fan disponibles els seus recursos a altres participants en la xarxa com a serveis independents als que tenen accés d’una manera estandarditzada. La majoria de les definicions de SOA identifiquen l’ utilització de Serveis Web (emprant SOAP i WSDL) en la seva implementació, però es pot implementar SOA utilitzant qualsevol tecnologia basada en serveis.

Connexions

La següent figura mostra una arquitectura orientada a serveis bàsics. Es mostra un consumidor de serveis a la dreta, enviant un missatge de sol·licitud de servei a un proveïdor de serveis , a la part esquerra. El proveïdor de serveis torna un missatge de resposta al consumidor de serveis. La sol·licitud i la resposta de les connexions subsegüents es defineixen d’alguna manera que sigui comprensible tant per al consumidor de serveis i proveïdor de serveis. La manera en com es defineixen aquestes connexions s’explica en els serveis web. Un proveïdor de serveis també pot ser un consumidor de serveis.

EAI (Enterprise Application Integration)

És el procés de connectar unes aplicacions amb altres per intercanviar informació. Quan els sistemes no poden compartir la seva informació efectivament es creen colls d’ampolla que requereixen de la intervenció humana en la forma de presa de decisions o en l’ ingrés mateix de la informació. Amb una arquitectura EAI correctament implementada, les organitzacions poden concentrar la majoria dels seus esforços en la creació de competències que generin valor en lloc de dedicar-se a la coordinació de tasques operatives.

Moltes de les aplicacions en ús actualment es recolzen en tecnologies antigues, per la qual cosa aquests sistemes s’enfronten dificultats a l’hora de moure aquesta informació entre les aplicacions i  proporcionar informació en temps real.

EAI, com una disciplina, busca solucionar molts d’aquests problemes, així com crear nous paradigmes per certament millorar les organitzacions, tractant de transcendir l’objectiu de connectar les aplicacions individuals per buscar ser un mecanisme per incrementar el coneixement de l’organització i ajudar a obtenir nous avantatges competitius a l’empresa.

Millora de la connectivitat

La integració d’aplicacions d’empresa ha incrementat la seva importància perquè la computació en les empreses sovint pren la forma d’illes d’informació. Això ocasiona que el valor dels sistemes individuals no sigui aprofitat al màxim per culpa del seu mateix aïllament.

Si la integració s’aplica sense seguir un enfocament estructurat d’EAI, les connexions punt a punt s’incrementen exponencialment a l’interior de l’organització resultant un conjunt difícil de mantenir.

Objectiu

Un EAI pot ser utilitzat amb diferents finalitats:

– Integració de dades (informació): Assegurant que la informació de diversos sistemes és consistent.

– Integració de processos: Enllaç dels processos de negoci entre diferents aplicacions.

– Independència de proveïdor: Extraient les polítiques o regles de negoci de les aplicacions i implementant  les mateixes en un sistema EAI, de manera que qualsevol de les aplicacions utilitzades per el mateix pugui ser canviada sense que aquestes regles de negoci hagin de ser reimplementades.

– Façana comú: Un sistema EAI pot actuar com el front-end d’un cúmul d’aplicacions, proporcionant una interfície d’accés única i consistent a aquestes aplicacions i aïllant als usuaris de la interacció amb diferents aplicacions.

Patrons d’integració

Hi ha dos Patrons per a implementar sistemes EAI:

– Mediació: Aquí, els sistemes d’EAI actuen com l’enllaç dels enrutadors entre diverses aplicacions. Quan ocorre un esdeveniment interessant en alguna aplicació (per exemple, és crea una nova informació, és completa una nova transacció, etc.) és notifica a un mòdul d’integració del sistema EAI. El mòdul llavors propaga aquests canvis a les altres aplicacions rellevants.

– Federació: En aquest cas , el sistema EAI actua com a façana entre diverses aplicacions. Tots els accessos de l’exterior a qualsevol de les aplicacions són rebuts per el sistema EAI, i aquest està configurat per exposar nomes la informació  més rellevant connectant-se a les aplicacions del món exterior, i fer totes les corresponents interaccions amb les aplicacions internes sense intervenció d’agents extern.

Tots dos Patrons són utilitzats en conjunt freqüentment. El mateix sistema EAI pot tenir diverses aplicacions sincronitzades (mediació), a mida que serveix demandes d’agents externs contra aquestes aplicacions (federació).

EAI suporta patrons d’accés tant síncrons com asíncrons, el primer és l’habitual en el cas del patró de mediació i el segon en el cas de federació

Topologies de EAI

Hi ha dues topologies principals: hub-and-spoke, i bus. Cadascuna d’elles té els seus propis avantatges i desavantatges:

– En el model hub-and-spoke, el sistema EAI actua com el centre (el concentrador), el qual interactua amb les aplicacions via les converses (o spokes).

– En el model de bus, el sistema EAI és el bus (o és implementat com un mòdul resident en un bus de missatges existent o un middleware orientat a missatges).

Tecnologies

– Bus / hub: Aquest s’implementa freqüentment per ampliar la funcionalitat de productes middleware existents (servidors d’aplicacions, busos de missatges) o s’implementa com un programa monolític (sense utilitzar cap middleware), que actua com el seu propi middleware.

– Connectivitat d’aplicacions: el bus / hub es connecta a les aplicacions mitjançant un conjunt d’adaptadors (també coneguts com a connectors). Aquests són programes que coneixen com interactuar amb l’aplicació específica. L’adaptador efectua una comunicació en dues vies, enviant requeriments del hub cap a l’aplicació, i notificant al hub quan un esdeveniment d’interès ocorre en una aplicació (un nou registre és inserit, una transacció és completada, etc.). Els adaptadors poden ser tant específics de l’aplicació com d’un conjunt d’aplicacions. L’adaptador pot residir en el mateix espai de processos que el bus / hub o executar-se en una localització remota i interactuar amb el hub / bus a través de protocols estàndards d’indústria com cues de missatges, serveis web, o protocols propietaris.

– Formatat de dades i transformació: per prevenir que cada adaptador hagi de convertir les dades que van o vénen d’altres aplicacions, els sistemes EAI usualment empren un format de dades comú, des del qual es converteixen els formats de les aplicacions mitjançant uns serveis de transformació. Això es fa en dos passos, l’adaptador converteix la informació del format de l’aplicació al format comú del bus,  i llavors es poden aplicar transformacions semàntiques a això (exemple: convertint codis postals a noms de ciutats, separant / fusionant objectes d’una aplicació en objectes d’altres aplicacions, i així successivament).

– Mòduls d’integració: Un sistema EAI pot participar en operacions d’integració concurrents en un moment donat, cada tipus d’integració és processada per un mòdul d’integració diferent. Els mòduls d’integració es subscriuen a esdeveniments de tipus específics i ells reben les notificacions de processos en el moment en que aquests esdeveniments tenen lloc.

– Suport a transaccions: Quan s’empren per ha l’integració de processos, el sistema EAI proveeix consistència transaccional entre les aplicacions a l’executar totes les operacions que involucren una sola transacció distribuïda, ja sigui utilitzant el protocol de commit de dues fases, o transaccions de compensació (operacions que desfan les accions sobre un sistema donat).

Problemes d’implementació dels EAI

Durant l’any 2003 el  70% de tots els projectes amb sistemes EAI van fallar. La majoria d’aquestes falles no eren a causa de falles tècniques del programari mateix o la implementació, sinó problemes de governabilitat. Els principals reptes que afronten tant desenvolupador com companyies que volen implantar un sistema EAI son:

– Canvi constant: La pròpia naturalesa d’EAI és dinàmica i requereix directors de projecte dinàmics per a la seva aplicació.

– Manca  d’expertesa en EAI: EAI requereix coneixement de moltes problemàtiques i aspectes tècnics.

– Estàndards en competència: Dins del camp d’EAI, la paradoxa és que els estàndards no són per si mateixos universals, ja que cada proveïdor particular tracta d’imposar els propis.

– EAI és un paradigma d’eines: EAI no és una eina, si no és un sistema i ha de ser implementat com a tal.

– Construir interfícies és un art: Realitzar el procés d’enginyeria de la solució pot no ser suficient. Les solucions requereixen ser negociades amb departaments d’usuaris per aconseguir un consens comú sobre l’entrega final. La manca de consens en els dissenys de les interfícies tendeix a comportar un esforç excessiu per realitzar les correspondències entre els requeriments de dades de diversos sistemes.

– Comptabilitat: Ja que diversos departaments poden tenir requeriments contradictoris entre si, tots ells s’han de tenir en compte per l’estructura final del sistema.

– Altres problemes potencials poden abastar les següents àrees:

– Requeriments nous

– Les implementacions d’EAI han de ser extensibles i modulars per permetre canvis futurs.

– Les dades de les aplicacions son integrades, freqüentment pertanyen a departaments diferents els quals tenen raons tècniques, culturals i polítiques per no voler compartir la seva informació amb altres departaments.

Com a conclusió, indicarem els avantatges i inconvenients d’aquest sistema:

Avantatges

– Accés a la informació en temps real entre els sistemes.

– Permet enllaçar els processos de negoci i ajuda a incrementar l’eficiència de l’organització.

– Manté la integritat de la informació entre diversos sistemes.

Desavantatges

– Costos de desenvolupament molt alts, especialment per a petites i mitjanes empreses (PIME)

– Les implementacions d’EAI consumeixen molt de temps i requereixen molts recursos.

– Requereixen una gran quantitat d’enginyeria frontal, el qual molts gerents són incapaços de visualitzar o molts no volen invertir. La majoria dels projectes d’EAI usualment comencen com esforços d’integració punt a punt, i molt ràpidament es tornen poc útils a la mesura que el nombre d’aplicacions augmenta.

 

En la tercera entrada de la semana que ve, parlarem de la tecnología de bus ESB i treurem unes conclusions finals de tota la teoria exposada.

Entorns Integració (I)

En aquesta nova entrada al nostre bloc (que tindrà continuació), volem explicar la importància dels entorns d’integració, una de les línies en les quals el CCI treballa contínuament. En aquesta primera entrada sobre els “EI” presentarem què són i quines problemàtiques resolen.

Des d’un principi, quan es planteja la implantació d’un sistema d’informació o d’un software en un determinat entorn (nosaltres ens centrarem en la vesant sanitària, que és la que tractem), sovint es decideix desenvolupar un software específic en mode “adaptador”, entre cada tipus de dispositiu mèdic i la HCE, habilitant la comunicació entre ambdós, i possibilitant la integració de les dades provinents del dispositiu mèdic amb la HCE, prèviament normalitzades per l’adaptador.

Cada implantació d’un nou adaptador provoca noves connexions punt a punt entre el dispositiu mèdic i la HCE a més a més de nous fluxos d’informació dins dels hospitals i centres. Conseqüentment augmenta el manteniment per els departaments informàtics, i l’eficiència de transmissió de dades dins de l’entorn dels hospitals públics i centres decreix. A més a més, el seu desenvolupament s’ha d’iniciar pràcticament des de zero, degut a que en la majoria de casos s’ha de dissenyar una nova interfície entre dispositiu mèdic i HCE.

Això comporta una càrrega d’estructures i de recursos identificada com a estructura “Spaghetti”, tal com es veu a la imatge.

Connexió d'aplicacions punt a punt

 

La opció que es proposa, per portar a cap la corresponent normalització i integració entre dispositiu mèdic i HCE són els entorns d’integració. La seva implantació implica la creació d’un canal homogeni de comunicació i informació per totes les aplicacions i sistemes, creant així un entorn d’informació sanitari a través del qual poder gestionar modularment tots els processos de negoci implicats en cadascun dels sistemes i aplicacions integrats en aquest entorn.

Això proporciona una major eficiència en cadascun d’ells: Tractar cadascun dels missatges entrants procedents de qualsevol sistema o aplicació, ja sigui realitzant algun tipus de transformació de format o validació de informació; Coordinar els fluxos d’informació segons el seu destí i protocol de enviament; Orquestrar i monitoritzar tots els processos de negoci a partir del seguiment de missatges i esdeveniments, i prioritzar cadascun dels missatges entrants tant síncrona com asíncronament.

El que s’aconsegueix doncs és la centralització, en forma d’integració, de les dades del sistema.

Connexió d'aplicacions centralitzada

Què és doncs un Entorn d’Integració (EI)? Doncs com hem comentat anteriorment, és un sistema que vol centralitzar i controlar totes les dades, alhora que proporciona una sèrie de funcionalitats que permeten una ràpida implantació i un baix cost en desenvolupament.

 

Plantegem ara els problemes més habituals, i veiem com els EI ho resolen:

Desenvolupament de rutines o interfícies

Problema general: Cada programa s’ha creat amb unes pautes diferents, tant de llenguatge com d’estructura, i això fa que, a un programador nou, li costi entendre totes les seccions. Això implica un cost significatiu en temps i diners per el centre.

Solució EI: Generem diferents programes, sí, però tots seguint el llenguatge i estructura de la plataforma d’integració. Així, un programador, només ha de tenir en compte les normes de la plataforma, és capaç d’entendre ràpidament tots els desenvolupaments i, en menys temps, poder fer funcionar el sistema.

 

Monitorització de les aplicacions

Problema general: La monitorització és complicada. Hem de saber, per a cada aplicació, com transmet les seves dades per poder fer-hi el tractament corresponent  i generar el visor específic.

Solució EI: La monitorització és molt senzilla. Com que les dades viatgen de forma interna per la plataforma segons els estàndards propis, és possible monitoritzar tot tipus de dades, vinguin de l’aplicació que vinguin, utilitzant una sèrie de visors genèrics ja definits a la plataforma (o que podem definir nosaltres amb les seves eines).

 

Seguiment d’esdeveniments

Problema general: Durant l’execució de les aplicacions, es generen multitud d’esdeveniments que, a mesura que augmenta el nombre d’aplicacions integrades, són cada cop més incontrolables degut a la dispersió de les aplicacions i a la diversitat d’aquests esdeveniments.

Solució EI: Amb les plataformes d’integració podem fer un seguiment de tots els esdeveniments d’una manera estàndard, ja que aquests es centralitzen en la mateixa plataforma i ens arriben amb el mateix format, els podem organitzar per categories, dates, i altres filtres.

 

Seguiment de les dades

Problema general: Amb les dades passa el mateix, les dades que circulen ho fan amb la pròpia estructura i format  de cada aplicació. Això fa que tallar en un punt per observar les dades sigui difícil, ja que s’ha de conèixer específicament el format o codificació.

Solució EI: Com que les dades viatgen sempre per la plataforma, en un format intern (encara que hagin arribat per HTTP, SQL o per fitxer), podem seguir el rastre d’aquestes dades més fàcilment, i decidir que fer amb elles.

 

Seguiment del procés de negoci

Problema general: En el procés de negoci es complica una mica més perquè, si cada aplicació funciona per la seva banda, costa més tenir un procés de negoci ben definit i robust, que no generi accions incongruents amb altres aplicacions en un determinat procés.

Solució EI: En aquest tipus d’entorn, podem tenir definit un procés de negoci general que, segons el tipus de missatge concret que rep, actua d’una manera o una altra, però les decisions es prenen totes en un sol procés, cosa que fa que sigui molt més senzill de seguir i revisar, guanyant en eficiència.

 

Tota aquesta problemàtica es deu al fet de que fins fa poc temps no s’esperava que les aplicacions tinguessin la capacitat de “parlar” entre elles. Fins l’esdeveniment de les xarxes, les aplicacions informàtiques han sigut dissenyades amb un propòsit específic, i sovint van ser escrites amb varietat de llenguatges de programació, utilitzant estructures de dades diferents i sense pensar en la integració.

Molts processos de negoci vitals depenen de l’accés a les dades emmagatzemades en  una àmplia gamma de sistemes, pel que és essencial  que tinguin la capacitat de compartir dades, respondre a certs esdeveniments, intercanviar missatges i fer-ne la gestió i el seguiment quan calgui, amb la finalitat de controlar y agilitzar els fluxos d’informació.

L’ideal seria que les organitzacions que decidissin començar de nou una aplicació, ho fessin utilitzant una infraestructura dissenyada per facilitar la integració.  Malauradament, la majoria de les organitzacions comencen integrant una aplicació i no tenen la perspectiva de que, amb el temps, apareixerà la necessitat d’integrar-ne una altra i una altra, i així successivament. Per això, al començament consideren que la utilització d’un entorn d’integració és un cost (en formació, temps i diners) innecessari.

Els problemes d’eficiència que això comporta no s’han de subestimar. Un  funcionament empresarial de 10 aplicacions independents en funcionament,  requereix de 45 connexions punt a punt  per aconseguir la integració. Una empresa gran que tingui corrent 50 aplicacions que requereixen 1225  connexions, tindrà problemes seriosos per aconseguir una eficiència acceptable dels seus fluxos d’informació.

La integració, és la solució que es presenta.

Després d’aquesta introducció a la problemàtica dels sistemes d’informació, a la pròxima entrada explicarem les diferents arquitectures que contempla un EI, així com patrons utilitzats i avantatges i inconvenients que hi podrem trobar.

Extret del document “Informe d’Entorns d’Integració”, redactat per: Jordi Ayza, Manel Domingo i Matias Lizana