Entrades classificades amb: Entorn

3a reunió de Foro de Interoperabilidad en Salud

Leer en castellano

El CCI-OFSTI va participar els dies 7 i 8 de maig a la tercera reunió del Fòrum d’Interoperabilitat en Salut, organitzat per la SEIS (Sociedad Española de Informática de la Salud), que es va celebrar a La Granja San Ildefonso. L’edició d’enguany es va centrar en la innovació entorn de les TIC aplicades a l’àmbit sanitari, la interoperabilitat organitzativa i les plataformes de telesalut i teleassistència.

A les dues primeres sessions “Plataformas de Interoperabilidad” i “Interoperabilidad organizativa”, es van presentar els avenços dels respectius grups de treball d’AENOR (comitè tècnic 139 de TIC per salut al qual participa l’OFSTI). Al grup de plataformes de telesalut i teleassistència s’està treballant en una taxonomia que permeti classificar les plataformes existents en dimensions amb nivells. Al d’interoperabilitat organitzativa s’ha revisat la norma ISO/DIS 13940 (també coneguda com a CONTSYS), aplicant-la a casos d’ús reals, per a la votació de pas a normativa ISO.

Des del CCI-OFSTI es va realitzar una presentació a la sessió de plataformes d’Interoperabilitat, sobre el model d’assistència no presencial i l’estat de les plataformes de telesalut i teleassistència al Sistema Sanitari Català:

Al primer bloc també es va exposar l’ús d’una plataforma d’interoperabilitat d’HCE pel suport a la recerca i que permet l’intercanviar d’extractes clínics anonimitzats. La sessió va finalitzar amb una intervenció sobre l’evolució del punt de cura, i les necessitats d’interoperabilitat dels dispositius mèdics derivades, l’estat de l’art dels estàndards a utilitzar i lliçons apreses en la seva aplicació.

La segona sessió va començar amb una presentació sobre l’aplicació de la norma CONTSYS, aportant experiències reals tant a nivell nacional com internacional. La següent intervenció es va centrar en la dificultat d’assolir la interoperabilitat organitzativa i la seva importància a l’HCDSNS (Historia Clínica Digital del Sistema Nacional de Salud). Per últim s’explicà com les solucions basades en models poden potenciar l’interoperabilitat organitzativa.

Al tercer bloc “Actividades de I+D+I en Interoperabilidad” es van exposar iniciatives relatives al perfil XDS (Cross-Enterprise Document Sharing) d’IHE, la definició de guies clíniques amb llenguatge GDL (Guide Definition Language), la combinació d’estàndards d’HCE i tecnologies semàntiques i a les activitats de la Universitat de Sevilla. En la mateixa línia, a la quarta sessió “Potencial de Innovación tecnológica para la Interoperabilidad” des de la indústria es van presentar innovacions en la creació i gestió de repositoris de dades clíniques normalitzades, l’evolució cap a una HEI (Història Electrònica d’Imatge), l’impacte de la interoperabilitat en la continuïtat assistencial i l’oficina d’integració a València.

A la darrera sessió del fòrum “Normalización e Innovación en TICs en los Servicios de Salud”, representants dels serveis de Salud de Madrid, Castilla La Mancha, Castilla y León i Andalusia van aportar una visió general de l’estat del Servei en quant a normalització i iniciatives d’innovació i investigació.

Al següent enllaç es pot consultar el programa del congrés.

Llegir en català

El CCI-OFSTI participó los días 7 y 8 de Mayo en la tercera reunión del Foro de Interoperabilidad, organizado por la SEIS (Sociedad Española de Informática de la Salud), que se celebró en La Granja San Ildefonso. La edición de este año se centró en la innovación entorno de las TIC aplicadas al ámbito de la salud, la interoperabilidad organizativa y las plataformas de telesalud y teleasistencia.

En las dos primeras sesiones “Plataformas de Interoperabilidad” y “Interoperabilidad organizativa” se presentaron los avances de los respectivos grupos de trabajo de AENOR (comité técnico 139 de TIC para la salud en el cual participa la OFSTI). En el grupo de plataformas de telesalud y teleasistencia se está trabajando en una taxonomía que permita clasificar las plataformas existentes en dimensiones con niveles. En el de interoperabilidad organizativa se ha revisado la norma ISO/DIS 13940 (también conocida como CONTSYS), aplicándola a casos de uso reales, para la votación de paso a normativa ISO.

Des del CCI-OFSTI se realizó una presentación en la sesión de plataformas de Interoperabilidad sobre el modelo asistencial no presencial y el estado de las plataformas de telesalud y teleasistencia en el Sistema Sanitario Catalán:

En el primer bloque también se expuso el uso de una plataforma de interoperabilidad de HCE para el soporte a la investigación que permite el intercambio de extractos clínicos anonimizados. La sesión finalizó con una intervención sobre la evolución del punto de atención, y las necesidades de interoperabilidad de los dispositivos médicos derivadas, el estado del arte de los estándares a utilizar y lecciones aprendidas en su aplicación.

La segunda sesión comenzó con una presentación sobre la aplicación de la norma CONTSYS, aportando experiencias reales tanto a nivel nacional como internacional. La siguiente intervención se centró en la dificultad de alcanzar la interoperabilidad organizativa y su importancia en la HCDSNS (Historia Clínica Digital del Sistema Nacional de Salud). Por último se explicó cómo las soluciones basadas en modelos pueden potenciar la interoperabilidad organizativa.

En el tercer bloque “Actividades de I+D+I en Interoperabilidad” se expusieron iniciativas relativas al perfil XDS (Cross-Enterprise Document Sharing) de IHE, la definición de guías clínicas con lenguaje GDL (Guide Definition Language), la combinación de estándares de HCE y tecnologías semánticas y las actividades de la Universidad de Sevilla. Siguiendo la misma línea, en la cuarta sesión “Potencial de Innovación tecnológica para la Interoperabilidad”, desde la industria se presentaron innovaciones en la creación y gestión de repositorios de datos clínicos normalizados, la evolución hacia una HEI (Historia Electrónica de Imagen), el impacto de la interoperabilidad en la continuidad asistencial y la oficina de integración en Valencia.

En la última sesión del foro “Normalización e Innovación en TICs en los Servicios de Salud”, representantes de los servicios de Salud de Madrid, Castilla La Mancha, Castilla y León y Andalucía aportaron una visión general del estado del Servicio en cuanto a normalización e iniciativas de innovación e investigación.

En el siguiente enlace se puede consultar el programa del congreso.

This post is only available in Catalan and Spanish:
Llegir en català (Read it in Catalan)
Leer en castellano (Read it in Spanish)

Interoperabilidad, la base para una atención integrada del paciente crónico

Leer en castellano

El CCI va participar els passats dies 19 i 20 de març a la Jornada tècnica d’interoperabilitat organitzada pel Servei Andalús de Salut, IHE Espanya i HL7 Spain que tenia per títol “Interoperabilidad, la base para una atención integrada del paciente crónico”.
Al primer dia de la jornada es van realitzar les tres sessions següents:

  • Reunió del comitè tècnic d’HL7 Spain, en la qual es van repassar les principals novetats i avenços més rellevants des de l’última reunió. Destacar que s’ha començat a treballar en les derivacions de proves diagnòstiques, tant des del punt de vista funcional com de missatgeria i informes associats.
  • Presentació “Últimos avances en los estándares de documentación clínica”, orientada a acostar els estàndards al perfil documentalista.
  • Sessió IHE centrada en la implantació de XDS a Espanya.

Al segon dia es van realitzar diferents intervencions sobre la interoperabilitat entre sistemes i la integració de dispositius, presentant estàndards i sistemes que permeten garantir la continuïtat assistencial a diferents nivells. Es van destacar els nous reptes que tenen els CIOs en quant a la interoperabilitat i a l’atenció dels pacients crònics, així com a la importància de la capacitació del ciutadà de manera que formi part activa de la seva salut. Aquestes ponències es van complementar explicant el paper dels perfils IHE, de la norma CONTSYS (ISO/DIS 13940) i dels estàndards d’HL7, incloent els d’àmbit semàntic com CTS2 (Common Terminology Services Release 2). L’esdeveniment va finalitzar amb la compartició d’experiències i la presentació de diferents eines. Des del CCI-OFSTI es va realitzar una ponència sobre serveis terminològics avançats:

A la presentació es va explicar la necessitat d’aquesta mena de serveis, així com les funcionalitats que poden cobrir les eines que els ofereixen. També es va presentar l’estàndard CTS2, que defineix, a nivell funcional, una interfície estàndard per l’ús i la gestió de terminologies. Per acabar la intervenció, es va resumir la participació del CCI al grup de serveis semàntics del projecte europeu epSOS, en el qual es treballa amb l’estàndard CTS2.

Llegir en català

El CCI participó los pasados 19 y 20 de marzo en la Jornada técnica organizada por el Servicio Andaluz de Salud, IHE España y HL7 Spain que tenía por título “Interoperabilidad, la base para una atención integrada del paciente crónico”.
En el primer día de la jornada se realizaron las tres sesiones siguientes:

  • Reunión del comité técnico de HL7 Spain, en la cual se repasaron las principales novedades y avances des de la última reunión. Destacar que se ha empezado a trabajar en las derivaciones de pruebas diagnósticas, tanto a nivel funcional como de mensajería y informes asociados.
  • Presentación “Últimos avances en los estándares de documentación clínica”, orientada a acercar los estándares al perfil documentalista.
  • Sesión IHE centrada en la implantación de XDS en España.

En el segundo día se realizaron distintas intervenciones sobre la interoperabilidad entre sistemas y la integración de dispositivos, presentando diferentes estándares y sistemas que permiten garantizar la continuidad asistencial a distintos niveles. Se destacaron los nuevos retos que tienen los CIOs en cuanto a la interoperabilidad y a la atención de los pacientes crónicos, así como la importancia de la capacitación del ciudadano de manera que forme parte activa de su salud. Estas ponencias se complementaron explicando el papel de los perfiles IHE, de la norma CONTSYS (ISO/DIS 13940) y de los estándares de HL7, incluyendo los de ámbito semántico como CTS2 (Common Terminology Services Release 2). El evento finalizó con la compartición de experiencias y la presentación de distintas herramientas. Des de CCI-OFSTI se realizó una ponencia sobre servicios terminológicos avanzados:

En la presentación se explicó la necesidad de este tipo de servicios, así como las funcionalidades que pueden cubrir las herramientas que los ofrecen. También se presentó el estándar CTS2 que define, a nivel funcional, una interface estándar para el uso y la gestión de terminologías. Para acabar la intervención se resumió la participación del CCI-OFSTI en el grupo de servicios semánticos del proyecto europeo epSOS, en el cual se trabaja con el estándar CTS2.

Formació SNOMED CT

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 té per objectiu presentar i explicar en detall les diferents modalitats i tipologies de formació relacionada amb SNOMED CT:

Tallers d’interoperabilitat semàntica al TCM
Aquesta mena de tallers s’organitzen des del CCI-TCM i es realitzen al Tecnocampus Mataró-Maresme, amb la col·laboració de la fundació TicSalut. S’han realitzat dues edicions i la tercera, la inscripció de la qual ja està oberta, està programada pels dies 3 i 4 d’octubre del 2012. La informació sobre aquesta 3a edició es pot consultar a l’enllaç següent: tríptic. A aquesta mena de formació s’expliquen els diferents tipus de llenguatges i vocabularis controlats, es fa una introducció a SNOMED CT i s’aprofundeix en els mecanismes de conjunts de referències creuades (mapejos), subconjunts i extensions. També s’ofereix una visió general del procés de gestió de SNOMED CT a Catalunya i en línia amb el MSSSI (Ministerio de Sanidad, Servicios Sociales e Igualdad) i epSOS (projecte europeu de compartició d’informació clínica), i es fa un repàs a les eines existents que permeten treballar amb la terminologia. Les explicacions teòriques d’aquests conceptes es combinen amb exercicis pràctics de navegació i codificació amb SNOMED CT i de creació de components. El taller d’enguany compta amb varies novetats:

  • Presentació dels subconjunts de SNOMED CT creats per l’HC3 i pautes d’implantació i ús.
  • Cas pràctic de creació de components basat en l’experiència real del Sistema Sanitari Català.
  • Presentació i pràctica del navegador SNOB a més a més de CliniClue Xplore.
  • Cas real de navegació i codificació a partir de l’experiència real de l’Hospital Clínic de Barcelona.

Tallers de SNOMED CT amb HL7
El CCI-TCM ha col·laborat amb HL7 en la impartició de varis tallers sobre SNOMED CT i vocabularis clínics controlats, a diferents Comunitats Autònomes. Aquestes modalitats solen ser més concentrades que els tallers d’interoperabilitat semàntica i inclouen una part d’HL7 i CDA que permet obtenir una visió general de com transmetre i compartir la informació codificada en SNOMED CT.
El dia 18 de juny va començar la primera edició online d’aquesta mena de cursos amb el taller virtual d’introducció a SNOMED CT. L’edició e-learning, programada en 5 setmanes, ha permès augmentar el nivell de detall amb el qual es tracta cada part de SNOMED CT i maximitzar la part pràctica dels tallers. Cada setmana es lliura una unitat teòrica als alumnes, sobre la qual han de realitzar un qüestionari i una pràctica. La informació sobre aquesta primera edició online es pot consultar al següent enllaç: tríptic.

Jornades tècniques i altres accions de difusió
El CCI-TCM també ha participat en les dues edicions de la jornada tècnica de SNOMED CT que s’ha organitzat des de la fundació Doctor Robert, UAB. L’esdeveniment d’enguany va tenir molt d’èxit i va oferir una visió general de l’evolució de SNOMED CT al Sistema Sanitari Català orientada a experts en documentació clínica. El grup també ha participat en altres congressos i jornades que tenen per objectiu potenciar l’ús de les TIC al sector salut, com InforSalut, InforMed, FòrumCis, la segona reunió del foro de Interoperabilidad, etc. amb ponències sobre SNOMED CT.

La informació sobre els cursos, tallers, congressos, etc. en els quals està involucrat el CCI-TCM es pot trobar al web del grup:

La propera entrada tractarà sobre la formació que ofereix el CCI-TCM en l’àmbit dels EI (Entorns d’Interoperabilitat). Avançar que ja està oberta la inscripció per la segona edició del taller d’integració de dispositius mèdics amb Mirth Connect, els dies 26 i 27 de setembre del 2012. La informació relacionada i el formulari d’inscripció es poden consultar a l’enllaç que es presenta a continuació: tríptic.

Llegir en català

CCI-TCM (Centre de Competències d’Integració de la fundación Tecnocampus Mataró-Maresme) ofrece servicios de formación en el ámbito de los Entornos de Interoperabilidad y el de la Terminología. Esta entrada tiene por objetivo presentar y explicar en detalle las diferentes modalidades y tipologías de formación relacionada con SNOMED CT:

Talleres de interoperabilidad semántica en TCM
Este tipo de talleres se organizan des del CCI-TCM y se llevan a cabo en el Tecnocampus Mataró-Maresme, con la colaboración de la fundación TicSalut. Se han realizado dos ediciones y la tercera, cuya inscripción ya está abierta, está programada para los días 3 y 4 de Octubre del 2012. La información sobre esta 3a edición se puede consultar en el enlace siguiente: tríptico. En este tipo de formación se explican los diferentes tipos de lenguajes y de vocabularios controlados, se hace una introducción a SNOMED CT y se profundiza en los mecanismos de conjuntos de referencias cruzadas (mapeos), subconjuntos y extensiones. También se ofrece una visión general del proceso de gestión de SNOMED CT en Catalunya y en línea con el MSSSI (Ministerio de Sanidad, Servicios Sociales e Igualdad) y epSOS (proyecto europeo de compartición de información clínica), y se hace un repaso de las herramientas existentes que permiten trabajar con la terminología. Las explicaciones teóricas de estos conceptos se combinan con ejercicios prácticos de navegación y codificación con SNOMED CT, y de creación de componentes. El taller de este año cuenta con diversas novedades:

  • Presentación de los subconjuntos de SNOMED CT creados para HC3 y pautas de implantación y uso.
  • Caso práctico de creación de componentes basado en la experiencia real del  Sistema Sanitario Catalán.
  • Presentación y práctica del navegador SNOB, a demás de CliniClue Xplore.
  • Caso real de navegación y codificación a partir de la experiencia real del Hospital Clínic de Barcelona.

Talleres de SNOMED CT con HL7
CCI-TCM ha colaborado con HL7 en la impartición de varios talleres sobre SNOMED CT y vocabularios clínicos controlados, en diferentes Comunidades Autónomas. Estas modalidades suelen ser más concentradas que los talleres de interoperabilidad semántica y incluyen una parte de HL7 y CDA, que permite obtener una visión general sobre cómo transmitir y compartir la información codificada con SNOMED CT.
El día 18 de Junio empezó la primera edición online de este tipo de cursos, con el taller virtual de introducción a SNOMED CT. La edición e-learning, programada en 5 semanas, ha permitido aumentar el nivel de detalle con el que se trata cada parte de SNOMED CT y maximizar la parte práctica. Cada semana se entrega a los alumnos una unidad teórica, sobre la cual tienen que realizar un cuestionario y una práctica. La información sobre esta primera edición online se puede consultar en el siguiente enlace: tríptico.

Jornadas técnicas y otras acciones de difusión
CCI-TCM también ha participado en las dos ediciones de la jornada técnica de SNOMED CT, organizada des de la fundación Doctor Robert, UAB. El evento de este año ha tenido un gran éxito y ofreció una visión general de la evolución de SNOMED CT en el Sistema Sanitario Catalán orientada a expertos en documentación clínica. El grupo también ha participado en otros congresos y jornadas que tienen por objetivo potenciar el uso de la TIC en el sector salid, como InforSalut, InforMed, FòrumCis, la segunda reunión del foro de Interoperabilidad, etc. con ponencias sobre SNOMED CT.

La información sobre los cursos, talleres, congresos, etc. en los que está involucrado el CCI-TCM se pueden encontrar en la web del grupo:

La siguiente entrada tratará sobre la formación que ofrece CCI-TCM en el ámbito de los EI (Entornos de Interoperabilidad). Adelantar que ya está abierta la inscripción para la segunda edición del taller de integración de dispositivos médicos con Mirth Connect, los días 26 y 27 de Setiembre del 2012. La información relacionada y el formulario de inscripción se pueden consultar en el enlace que se presenta a continuación: tríptico.

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