Propuesta para la interoperabilidad de procesos de negocio en sistemas de información hospitalarios bajo una Arquitectura Orientada a Servicios

Transcripción

1 Propuesta para la interoperabilidad de procesos de negocio en sistemas de información hospitalarios bajo una Arquitectura Orientada a Servicios Abstract This paper describes the achieved findings of implementing a service-oriented architecture that enables interoperability of business processes in healthcare systems information by selecting the appropriate methodology for this purpose allowing deployment of new systems in the Hospital Susana López de Valencia. The system was built using freeware tools with an architectural approach based on a Enterprise Service Bus that provide a high degree of engagement with the international standars for systemic and semantic interoperability (as HL7). Scalability and flexibility was validated by using the right metrics for this purpose. I. INTRODUCCIÓN El dinámico establecimiento de políticas gubernamentales para garantizar la prestación de servicios de salud involucra reformas de los procesos de negocio de las entidades territoriales en salud así como la adecuada administración de la información de manera que garantice la operación, gestión y control de cada uno de sus componentes. Peter Emerson Pinchao, Nicolás Rubén Caballero Universidad Del Cauca Popayán, Colombia peter@unicauca.edu.co ncaballero@unicauca.edu.co sistemas de información en salud. Esto permito determinar el uso de HL7 1 como mecanismo para logar interoperabilidad semántica de la información entre instituciones del sector salud a nivel nacional e internacional y confirmó que el establecimiento de una SOA es una alternativa adecuada para logar la interoperabilidad sistémica del software en salud. Con el fin de aprovechar la experiencia y resultados se estudiaron iniciativas y proyectos en el marco de la interoperabilidad a nivel nacional y mundial como se describe en este documento. Para garantizar el uso de buenas prácticas y técnicas probadas para el diseño e implementación de las arquitecturas se estudiaron las metodologías para el establecimiento de sistemas de información bajo los lineamientos del modelo de referencia para sistemas de Procesamiento Distribuido de Sistemas Abiertos (RM- ODP) lo que permitió apoyarse en la metodología para el análisis y diseño de arquitecturas en salud que permitan la interoperabilidad HIS-DF, y abrió un espacio para la discusión y selección de la metodología de despliegue de la SOA entre las metodologías de referencia para SOA[1] y SOMA[2] de IBM. De esta forma el departamento de sistemas del Hospital Susana López de Valencia (HSLV) desea acreditarse la capacidad de responder a los cambios en los procesos de negocio de la institución de forma efectiva, sostenible a bajos costos y permitiendo la reutilización de los sistemas existentes. Este trabajo propone una Arquitectura Orientada a Servicios (SOA) para lograr la interoperabilidad de procesos de negocio en el HSLV empleando los sistemas existentes y nuevos componentes que permitan de forma flexible y escalable responder a los continuos cambios al interior de la organización. Se estudian especificaciones y estándares internacionales que ofrecen lineamientos a considerar para el establecimiento de interoperabilidad en Pudiéndose emplear enfoques tecnológicos para el despliegue de una SOA como los son las Arquitecturas Punto a Punto, Servidor de Mensajes y Buses de Servicio Empresariales (ESB). Para establecer la adecuada selección del enfoque a emplear se estudiaros los estándares, protocolos que permitan dotar a la arquitectura de las capacidades funcionales y no funcionales que se desea ofrecer la solución propuesta, lo que permitió determinar que el uso de Buses de Servicio Empresariales como la solución adecuada. Bajo los lineamientos de la metodología seleccionada para despliegue de una SOA se analizaron, diseñaron 1 Es un conjunto de estándares para el intercambio electrónico de información clínica.

2 he implementaron dos procesos de negocio del HSLV, para probar la interoperabilidad entre ellos y los sistemas existentes en la institución. Para efectos de validación de los requerimientos no funcionales de escalabilidad y flexibilidad se aplicaron pruebas sobre el uno de los servicios de negocio que da solución a un proceso de negocio como lo es el proceso de auditoría que a su vez extiende del otro servicio de negocio y del aplicativo AMedicas (de la empresa Asmet Salud EPS) que modela procesos similares. Una vez aplicadas la pruebas se analiza la capacidad dela arquitectura de responder a los requerimientos de flexibilidad e escalabilidad. II. ESTADO DEL ARTE En esta sección se describen los proyectos más importantes a nivel nacional e internacional relacionados con la definición de arquitecturas y sistemas de información en salud basados en estándares internacionales. Los proyectos se clasifican en dos grupos: aquellos que se encuentran definidos bajo una arquitectura orientada a servicios, y otros que aunque no se apoyan en estas arquitecturas emplean o se basan estándares internacionales. A. Proyectos Basados en SOA Son pocos los proyectos que definen sus arquitecturas de sistemas de información en salud basados en la Arquitectura Orientada a Servicios. A continuación se describen los más importantes. Healthcare Services Specification Project (HSSP) [3] Este proyecto es el resultado de la unión de esfuerzos entre grupos de estandarización como los son HL7 (Health Level Seven) y OMG (Object Management Group), en busca del desarrollo de estándares para SOA en la industria Médica con la finalidad de promover la implementación de Arquitecturas Orientadas a Servicios, y mejorar la interoperabilidad entre organizaciones y al interior de estas. La finalidad es asegurar que las Arquitecturas Orientadas a Servicio en Organizaciones para el cuidado de la Salud sean interoperables y basadas en estándares. Actualmente se han definido especificaciones funcionales para servicios básicos como el Servicio de Identificación de Entidades (Entity Identification Service, EIS), el servicio de Recuperación, Localización y Actualización (Retrieve, Locate, Update Service, RLUS), y el Servicio de Apoyo a la Toma de Decisiones (Decision Support Service, DSS). Cabe destacar que HSSP solamente desarrolla especificaciones funcionales. La especificación de los servicios es responsabilidad de la OMG (Object Management Group). Distributed E-Healthcare System [4] Utiliza SOA para reforzar los principios de arquitectura de software y proveer interoperabilidad entre diferentes plataformas y aplicaciones de computación. Plantea tres módulos: Módulo Clínico, Farmacia y el de Pacientes, los cuales proveen servicios reales para el sistema de e-salud distribuido. B. Proyectos que Emplean Buses de Servicios Empresariales (ESB) y el Estándar de Mensajería HL7 epoc PDA [5] Es un proyecto del Australian Research Council Linkage Grant para la obtención de datos clínicos mediante PDA y la interacción de este con un PC, que permite agregar y consultar observaciones clínicas al sistema de información. El trabajo se basa y hace uso de un trabajo previo que propone como mapear los conceptos y relaciones entre SNOMED CT y HL7 [6]. En este trabajo también se describe el uso de un ESB para la comunicación entre dispositivos y presentan la arquitectura con la que se hizo posible la implementación. Los autores mencionan el uso de de mensajes XML definidos por HL7 versión 3, para establecer la comunicación del PDA con el PC, pero no especifican si la naturaleza del middleware ESB utilizado es propietario o de libre distribución. SerAPI [6] Despliega las aplicaciones sobre servicios web utilizando un Bus de Servicios Empresariales, con el fin de integrar procesos con los sistemas existentes de grupos de diagnósticos relacionados, EPR (Electronic Patient Records), y otras aplicaciones usadas por los funcionarios en momentos determinados. Usando para la comunicación el protocolo de mensajes HL7 Versión 2.Describe la orquestación de los servicios cuando se efectúa un diagnostico determinado, empleando BPEL como lenguaje de orquestación, demostrando que es posible la orquestación de servicios. Este proyecto no describe la arquitectura del ESB implementado.

3 C. Proyectos que Emplean el Estándar de Interoperabilidad HL7 Australian Health Connect Project and NEHTA Architectural Map (Australia) [7] Con este proyecto, Australia se mueve estratégicamente hacia una plataforma ehealth dirigida por estándares y dirigida por la interoperabilidad basada en semántica múltiple y puntos de control múltiple. El National E-Health Transition Authority (NEHTA) Architectural Map sigue una metodología avanzada y una estrategia basada en una arquitectura orientada a servicios. Sin embargo, se encuentra en la fase de especificación. National Programme for IT (England)[8] Es un programa del Servicio Nacional de Salud Inglés para el establecimiento de IT en todo el sistema de Salud en el país. Después de definir e implementar una infraestructura para el sistema, ya hay diversos programas que se encuentran actualmente en funcionamiento, como el Servicio de Registro para el cuidado de NHS y una aplicación para las prescripciones electrónicas. No considera el uso de la arquitectura SOA, pero sí los estándares HL7. Este proyecto ha demandado altos gastos y retrasos en su puesta en marcha, por eso es bien observado por otros países como caso de éxitos y fallas. Sharable EHR (Finlandia) Finlandia propone un concepto de sistema EHR distribuido. En ese contexto, la comunicación interorganizacional e inter-dominio es soportada por sistemas EHR regionales, ofreciendo una vinculación legal de extractos EHR dentro de la arquitectura de seguridad avanzada. La arquitectura y la comunicación EHR está basada en HL7 usando HL7 CDA y mensajes HL7 versión 3. D. Iniciativas Nacionales de Interoperabilidad GEL-XML (Gobierno en Línea-eXtensive Markup Language) [9] GEL-XML es una iniciativa suscrita dentro del ámbito de Gobierno en línea, que contempla la definición y gestión de un lenguaje común orientado a que diferentes sistemas de información puedan entenderse e intercambiar información que se da en razón de la prestación y/o demanda de trámites y/o servicios entre: entidades de gobierno, y entidades de gobierno y sector privado, con el objeto de ofrecer al ciudadano una información de forma adecuada, que sea oportuna, eficiente y de calidad. Se ha concebido para ser utilizado en la implementación de procesos electrónicos de intercambio de información, sin embargo, se puede considerar la extensión de su aplicabilidad a la definición, desarrollo e implementación de nuevos sistemas de información. Considera un componente para integración en salud que está en desarrollo. SISPRO (Sistema Integrado de Información de la Protección Social) [10] El sistema integrado de información de la protección social es técnicamente una solución de bodega de datos que integra de forma estática las Fuentes de datos de sistemas de información en salud, riesgos profesionales, pensiones, asistencia social y empleo en Colombia. Alrededor de SISPRO se están desarrollando varios aplicativos misionales que son sistemas de información específicos. Teniendo como objetivo principal el construir un Sistema de Información, que bajo el concepto de la Protección Social, permita tomar decisiones que apoyen la elaboración de políticas, el monitoreo regulatorio y la gestión de servicios. Actualmente se tiene en funcionamiento un Portal Web para que los usuarios accedan a la Información del SISPRO, trabajen con los reportes del Sistema de Gestión de Datos, ingresen a los Aplicativos Misionales (Consultas RUAF, SISMED) y al e-learning. III. METODOLOGÍA Se consideró que la metodología que se empleada para la construcción de la SOA debe seguir los lineamientos de un modelo de referencia ampliamente aceptado como lo es el Modelo de Referencia para el Procesamiento Abierto Distribuido (Reference Model Open Distributed Processing, RM-ODP) de la Organización Internacional para la Estandarización (International Organization for Standarization, OSI) por tanto se estudiaron las metodologías HIS-DF para el análisis y diseño de la arquitectura, la metodología SOMA de IBM y la metodología de referencia SOA, seleccionado esta última como alternativa para establecimiento de la SOA al estar desde sus comienzos dirigida por los procesos de negocio. A. Marco de referencia HIS-DF [10] Para el análisis de requerimientos, diseño, implementación, evaluación, uso y mantenimiento de sistemas de información en salud semánticamente interoperables debe seguir un proceso de desarrollo estandarizado. HIS-DF framework es una metodología

4 para el desarrollo de arquitecturas de sistemas de información sostenibles y semánticamente interoperables. Basado en RUP, HIS-DF provee una base de conocimiento de referencia de tareas, roles, artefactos, y la guía necesaria para el análisis de la arquitectura dentro de proyectos de desarrollo de software en salud. HIS-DF soporta el desarrollo de HIS mediante el uso de modelos UML organizados como puntos de vista separados pero interrelacionados describiendo aspectos diferentes del sistema Par el despliegue de la arquitectura se consideran las metodologías de referencia SOA descrita por Erl y SOMA de IBM. B. Metodología de Referencia SOA [1]. La arquitectura de Referencia SOA define cinco capas verticales y cuatro horizontales, como se muestra en la Figura 1. Como toda arquitectura basada en capas, existen capas de nivel superior que pueden acceder a las capas inferiores y sus Bloques Construidos para la Arquitectura (Architecture Building Blocks, ABB), mientras que las capas inferiores no pueden hacer lo mismo con los superiores y sus ABB. Las capas verticales pueden ser aplicadas o utilizadas por uno o muchos ABB de las capas horizontales. Fase 1. Análisis Orientado a Servicios: En esta fase, los requerimientos y funcionalidades del sistema deben traducirse en servicios, clasificados en distintos niveles, los cuales posteriormente serán modelados como servicios candidatos que conformarán una base preliminar de los servicios de la Arquitectura Fase 2. Diseño Orientado a Servicios: Una vez definido lo que se requiere construir, es necesario determinar cómo debería ser construido. Esta fase debe ser orientada por estándares 2 que incorporen las convenciones de la industria y los principios de orientación a servicios dentro de procesos de diseño de servicios. Fase 3. Desarrollo de Servicios: Esta fase de construcción de los servicios. Aquí las características de las plataformas específicas de desarrollo definen el tipo de servicio. Fase 4. Prueba de Servicios: Debido a la naturaleza genérica y al potencial para ser reutilizados y compuestos, los servicios deben someterse a pruebas rigurosas para su posterior despliegue en un entorno de producción. Fase 5. Despliegue de Servicios: La fase de implementación trae consigo los elementos para la instalación y configuración de componentes distribuidos, interfaces de servicios y software de mediación en entornos de producción. Fase 6. de Servicios: Considera aspectos como administración de aplicaciones estándar, las formas en que serán monitoreados los servicios que son utilizados o consumidos. C. Metodología SOMA[2] Figura 1. Vista Lógica de la Arquitectura de Referencia SOA [1]. Capa 1. Sistemas Operacionales. Capa 2. Componentes de Servicio. Capa 3. Servicios. Capa 4. Procesos de Negocio. Capa 5. Consumidor. Capa 6. Integración. Capa 7. Calidad de Servicio. Capa 8. Arquitectura de la Información. Capa 9. Gobernanza. Se definen un conjunto de fases, que comprenden una estructura metodológica que soporta la construcción de SOA. Las fases básicas para la construcción de SOA Solución: Esta Metodología plantea cuatro fases para el desarrollo de servicios, que no son las mismas fases del Proceso de Desarrollo Unificado (RUP). De esta forma RUP extiende sus técnicas de procesos para dar soporte al Diseño Orientado a Servicios haciendo uso de los métodos definidos en SOMA (extensiones de RUP para SOMA). Las etapas de la metodología SOMA son: Identificación de Servicios: combinación de análisis Top-Down, Técnicas de Mediación de Descomposición de Dominios, análisis de actividades existentes y Modelado de Objetivos de Servicios. Análisis de Sistemas Existentes 2 En el dominio de este proyecto (e-salud) los estándares son ofrecidos como lineamientos de la OMG y HL7: HSSP (Pág. 13).

5 Especificación: dividida en subetapas que son: Clasificación o Categorización de Servicios Análisis de Subsistemas: Especificación de Componentes Realización: constituida por la subetapas: Distribución de Servicios Realización de Servicios IV. RESULTADOS. Empleado HIS-DF se presentan las principales vistas que sugiere este marco de trabajo. A. Vista Empresarial de la Arquitectura. Las especificaciones de proyecto HSSP dan lugar al establecimiento de líneas de negocio y la clasificación de los servicios. Como se muestra en la Tabla 1 donde se cruzan las líneas de negocio y los servicios que soportan y modelan la administración de procesos de negocio que se podrán ser soportados sobre al arquitectura. B. Vista computacional de la arquitectura. Se definió la arquitectura computacional del sistema (Figura 2) donde los diferentes componentes así como las interfaces de adaptación entre ellos. Esta arquitectura es lo suficientemente modular para desacoplar los proveedores y los consumidores, dejando que la infraestructura SOA se encargue de las transacciones, publicación y suscripción de servicios, así como del enrutamiento de mensajes y su transformación de formato. Esta es una Arquitectura que centraliza la administración, lo que permite monitorear y evaluar el desempeño de los elementos que la componen. Esta expone de forma adecuada todos los recursos disponibles en el entorno empresarial. Tabla 1. Vista empresarial del HSLV / Mapa de funciones del negocio SERVICIOS ÚNICOS DE SALUD SERVICIOS DE NEGOCIO SERVICIOS DE INFRAESTRUCTURA LÍNEAS DE NEGOCIO Orden de Ingreso Orden de Salida Valoración de Pacientes. Datos de Laboratorio Datos de Farmacia Registro Clínico de Electrónico. Alertas y Eventos. Índice Maestro de Personas. Terminología de Servicios. Demográficos. Facturación. Programación de Citas. Servicio de Auditoría. de Excepciones. Farmacia. X X X X X X X X X X X X X X X Laboratorio. X X X X X X X X X X X X X X X X de Pacientes. X X X X X X X X X X X Adm. Orden de Ingreso. X X X X X X X X X X X X X X X Programación de Citas. X X X X X X X X X X X de Atención. X X X X X X X X X X de Remisiones. X X X X X X X X X X X X X X X X X X Enfermería. X X X X X X X X X X X X X X X X X X Emergencias. X X X X X X X X X X X X X X X X X X Cirugías. X X X X X X X X X X X X X X X X X Salud Mental. X X X X X X X X X X X X X Facturación. X X X X X X X X X X X X X X Cartera. X X X X X X X X X X X Contabilidad. X X X X X X X X X Cartera. X X X X X X X X X X X X X X X X X Imágenes Diagnósticas. Gestión de la calidad. para la Nutrición. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X BPM Autenticación. Directorio de Servicios. Control de Acceso. X X X X X X X X X Figura 2.. Vista computacional de la Arquitectura Propuesta SOA- SIS para el HSLV. Las capacidades del ESB para la exposición y disponibilidad de los servicios necesarios para modelar los Procesos de Negocio, hacen a la arquitectura altamente flexible en la definición de los actuales y nuevos procesos que soporten los cambios en los objetivos de negocio, haciendo uso de los activos disponibles en el entorno. C. Arquitectura Computacional (Modelo Dinámico). La Arquitectura garantiza la comunicación e interacción entre los componentes que la conforman, la representa la llamada a un proceso que recorre los módulos de la arquitectura. Posteriormente, en la definición de protocolos y considerando el ESB seleccionado se presentará en detalle la comunicación al interior de los módulos con los respectivos protocolos empleados para tal fin.

6 Figura 3. Vista del Modelo Dinámico de la Arquitectura (comunicación entre componentes). D. Vista de la Ingeniería de la Arquitectura El despliegue de una SOA es implementado sobre la plataforma JEE y a fin de estandarizar la tecnología con las mejores enfoques tecnológicas existentes actualmente se determina que la creación de los nuevos servicios web bajo una capa de negocio soportada por EJB y la capa de modelo soportada por JPA, y en la capa de presentación Java Faces, como se muestra en la Figura 4. Figura 5. Vista Tecnológica (Modelo de despliegue). F. Selección del ESB. Se realizó un estudio das necesidades en estándares que soporten la interoperabilidad de sistemas que se desea soporte el ESB para lo que se definieron los protocolos y tecnologías apropiadas para dar cumplimiento a los requisitos funcionales y no funcionales deseados en el bus empresarial de servicios como se muestra en la Figura 6. Figura 6. Tecnologías para SOA. Figura 4. Vista de la Ingeniería de la Arquitectura. Esa vista está divida en tres partes principales con el fin de separar la distribución de los recursos que dispone para la creación de aplicaciones a partir de los sistemas existentes en el ESB. Los servicios de aplicación se establecen el contenedor EJB como parte fundamental para el desarrollo de servicios web tanto para ser empelados en los servicio o como para que los EJB sean acensados como un servicio web E. Vista Tecnológica del Sistema. El presente Diagrama de Despliegue muestra de manera gráfica los nodos que conforman el sistema, además los describe indicando la localización de las tareas en los nodos físicos. Cada nodo representa un recurso de ejecución como una computadora o servidor y se encuentra conectado con otros mediante un enlace de comunicación [11]. En este caso, la red será de tipo LAN, para el caso institucional. Para la selección de ESB a estudiar se consideraron diferentes niveles dentro del dominio de la solución como lo son: Nivel de transporte: Permita la comunicación entre servicios. Nivel de protocolos de red y comunicación: estándares que soportan la trasmisión de los mensajes entre servicios. Nivel de descripción de servicios: Permite la descripción de completa de servicios para ser consultados, identificados, y consumidos. Nivel de servicios: Tipo de software que ejecutara los servicios. Nivel de procesos de negocio: Permita definir y ejecutar procesos y flujos de negocio. Nivel de registros de servicios: Mecanismos de publicación y descubrimiento de servicios. Nivel de políticas de Políticas: define las políticas funcionales y no funcionales de acuerdo a las capacidades de los servicios.

7 Nivel de Seguridad: Se encarga de aspectos de seguridad como autenticación, autorización, privacidad, integridad, confidencialidad, y comunicación segura. Posteriormente sobre los ESB estudiados se evaluaron criterios de selección básicos para el despliegue de una SOA en el sector salud como lo son la capacidad de enrutamiento de mensajes, la existencia de una consola de administración, el soporte a los protocolos de los niveles anteriormente descritos y la posibilidad de habilitar componentes de negocio HL7 entre otros. Herramientas Consideradas Tabla 2. Criterios de seleccion del ESB. Enrutamiento. Protocolos de Transporte. Transformación. Mensajes Sincrónicos y Asincrónicos. Criterios de Selección Basado en Estándares. Seguridad. Definición de Servicios. Extensibilidad. Orquestación de Servicios. Calidad de Servicio. Soporte Técnico. Entorno de Desarrollo. Integrado. Versión Estable. Soporte para HL7. Auditoría: permite hacer una verificación de los servicios prestados por el HSLV y sus valores facturados. Tele-consulta: permite a personal médico especializado de otras entidades conectadas a través de la Red Nacional de Tecnología Avanzada (RENATA) el acceso a la información clínica de los pacientes del HSLV. El modelo de composición obtenido luego del análisis y diseño orientado a servicios propuesto por la metodología de referencia SOA permitió determinar que el servicio de negocio Auditoria que a su vez está compuesto de un servicio l servicio de negocio como o Tele-consulta, permitiendo consumir el servicio de negocio de consulta de epicrisis, este servicio reporta un mensaje de cabecera HL7 como validación del uso el componente de negocio HL7 BC. Lo que establece la necesidad de orquestación de los servicios web como se muestra en la Figura 7. OpenESB ChainBuilder ESB Fuse ESB PEtALS JBoss ESB Apache Synapse Apache ServiceMix WS02 ESB Mule ESB JeeESB Celtix La Tabla 2 muestra en resumen los principales ESB que se ajustan más a los criterios de selección considerando además que son tecnologías de libre distribución. Lo anterior permitió establecer a OpenESB como la tecnología sobre la que se desplegará el bus de servicios empresariales. V. EVALUACIÓN DE LA ARQUITECTURA En el establecimiento de una SOA es fundamental incluir la totalidad de los procesos de negocio de la institución, en orden a esto se aplican modelos como el TOGAF para la descripción de arquitecturas empresariales, y para este caso de estudio, se emplea la metodología de referencia SOA sobre dos de los procesos de negocio del HSLV que se describen a continuación: Figura 7. Jerarquía de composición del servicio de negocio de Auditoria. Para realizar las pruebas de escalabilidad y flexibilidad del software sobre la interoperación de estos servicios de negocio se empleó un hibrido entre la metodologías para pruebas de escalabilidad propuesta por Microsoft [12] y Oracle y se aplicaron métricas de paso a la evolución de software para establecer la flexibilidad del sistema. Las pruebas de escalabilidad fueron las que determina el valor de las métricas de Latencia y Throughout principalmente en diferentes escenarios de pruebas de carga, y stress, escalando el procesamiento del sistema en un cluster donde se agregaron hasta tres dominios. Los resultados de las pruebas de carga están representados por las gráficas de las Figuras 8 y 9, la latencia y el throughout respectivamente contra el nivel de carga (en número de invocación de servicios por segundo).

8 Latencia (ms) Throughout (TPS) Nivel de Carga (H/s) Cluster con 1 Nodo Cluster con 2 Nodos Cluster con 3 Nodos Benchmarking Figura 8. Latencia en las pruebas de carga Nivel de Carga (H/s) Benchmarking Cluster con 1 Nodo Cluster con 2 Nodos Cluster con 3 Nodos Figura 9. Throughout en las pruebas de carga. Como se puede observar en las Figura 8 el sistema carga con un nodo en el cluster ESB a mayor esperaría este tipo de sistemas. Sin embargo cuando se amplía a dos el número de nodos en el cluster y el nivel de cargo la curva presenta un comportamiento aparentemente extraño pues la curva a mayor carga tiende a responder más rápido y luego toma el comportamiento normal de retardar los tiempos de respuesta. En la curva del cluster ESB con tres nodos presenta un comportamiento aún más pronunciado a este respecto, estos comportamientos obedecen a que al estar basados en EJB los servicios de negocios, por cada solicitud de servicio no se instancias nuevos recursos (EJB de sesión) sino que es el contenedor de EJB que administras los Beans que ya se encuentran en la memoria Heap. Un comportamiento similar se puede observar en la Figura 9, a excepción del throughout del cluster con tres nodos que ligeramente tiene a crecer. Para realizar un análisis comparativo entre las distintas configuraciones del cluster ESB, se presenta la gráfica de la Error! No se encuentra el origen de la referencia.. En ella se puede observar los diferentes niveles de carga en los que se estresa al sistema donde más del 20% de las trasferencias de información se cancelan o se deniegan. Denegaci n de Servicios (%) Nivel de Carga (H/s) Cluster 1 Nodo Cluser 2 Nodos Cluser 3 Nodos Figura 10 Pruebas de stress. En la gráfica de la Figura 10 muestra claramente que existen límites en la prestación de servicios y también que se puede mejorar considerablemente estos límites si la configuración de cluster ESB se escala a dos o tres nodos, de esta forma mientras el cluster ESB con un nodo se estresa con un nivel de carga de 612 hilos por segundo ( hilos en 4,25 minutos) el clúster con dos nodos se satura de igual forma con un nivel de carga de carga de hilos por segundo ( hilos en 9 minutos), es decir un nivel de carga que equivale 2,8 veces el nivel de carga que el del cluster ESB con un nodo. De esta forma se puede ver que el cluster ESB con 3 nodos se estresa a un nivel de carga de Hilos por segundo ( hilos en 14,25 minutos) que equivale a 5,5 veces y 1,98 veces el nivel de carga del cluster ESB con un nodo y el cluster ESB con dos nodos respectivamente. Estas pruebas se realizaron a un aplicativo que presta similares servicios llamado AMedicas (implementadas con tecnologías de la plataforma JEE) con la salvedad que no se pudo probar la escalabilidad agregando cluster. Los resultados de las prunas de flexibilidad arrojaron resultados similares en comportamiento para un solo nodo en el cluster mas en valores fue superior dadas las características del servidor sobre el que se realizaron las pruebas. Para las prueba de flexibilidad se emplearon métricas de costo de evolución del software para ambos aplicativos cuando el problema modificado era cambiar la fuente de datos a las bases de datos del sistema Dinámica Gerencial, dado como resultado que el sistema la ser podo dependiente de la implementación el cambio fue menor al solo tener que modificar en las fuentes los Beans del servicio.

9 VI. CONCLUSIONES Es importante que exista una conciencia de la necesidad de analizar estándares y recomendaciones cuando se emprenden proyectos en sistemas telemáticos, y en particular en el ámbito de la salud ya que al encontramos en un ambiente interinstitucional fortalecido por los medios de comunicación electrónicos y ellos la necesidad de interoperar información y procesos entre organizaciones de ámbito nacional e internacional-. Establecer un enfoque metodológico es importante en las fases previas a la puesta en marcha proyectos en el ámbito de las tecnologías de la información y comunicación, incluyendo en la implementación de arquitecturas SOA a pesar que para esta tecnología son poco utilizadas, ya que estos enfoques proveen mecanismos procedimentales y de control que recogen la experticia y estimulan el empleo de las mejores prácticas en el despliegue de sistemas tecnológicos. Hacer una correcta selección de tecnologías, protocolos y estándares es una imperante necesidad en el establecimiento es sistemas informáticos altamente compatibles. En orden a esto las tecnologías y protocolos abiertos ofrecen un amplio margen de alternativas, sin embargo no todas enfocadas pueden ser aplicables al dominio de aplicación, de tal forma que se deben establecer recursos para su estudio y análisis en el las etapas iniciales de del desarrollo. Existe una amplia gama de productos ESB en el mercado para el establecimiento de una SOA de libre distribución que permiten el empleo de estándares abiertos para tal fin como se pudo evidenciar en los anexo B, sin embargo; hacer una selección rigurosa es una ardua tarea que demanda de muchas actividades. Es deseable profundizar en el establecimiento de un ambiente de pruebas de campo en las diferentes posibilidades presentes, de manera que permitan aun selección crítica y basada en evidencias medibles. Existen varias formas de desplegar nuevos servicios web sobre una arquitectura JEE, sin embargo la inclusión de las principales características de JEE como lo son los EJB y la persistencia mediante JPA, simplifican mucho la labor de elaboración de servicios de negocio, fundamentalmente por que permiten concentrarse en la lógica del servicios más que en los detalles de la implementación o el acceso a datos provenientes de diversas fuentes y arquitecturas de datos, a esto se suma que el rendimiento de los servicios web se ven directa y positivamente a afectados al ser gestionados por contenedores de EJB que administran encapsulado los componentes de negocio. El uso de HL7 es viable en sistemas informáticos de manera que se puedan compartir información entres sistemas informáticos de las instituciones en el sector salud. La labor de realizar pruebas de performance es fundamental en la selección de una arquitectura y según la experiencia adquirida consume un 40% del trabajo total de un proyecto para logar una propicia selección de componentes arquitectónicos para grandes sistemas informáticos. Con este trabajo se demuestra que la selección de tecnologías de libre distribución es una buena alternativa para sistemas altamente escalables y flexibles. Sin embargo se debe evaluar de manera crítica la actividad de la comunidad libre, pues existen alternativas que aunque prometedoras en su especificación; son poco activas, lo que compromete su viabilidad y capacidad de sostenimiento. Este proyecto demuestra que el uso de un enfoque arquitectónico basado en Buses Empresariales de Servicios (ESB) es una buena alternativa para el establecimiento de una Arquitectura Orientada a Servicios. El uso de OpenESB como plataformas tecnológicas de un Bus de Servicios Empresariales es una buena alternativa para empresas en el sector de la salud, por ser flexible y escalable, capaz de responder a las necesidades de las empresas de la industria de la salud. REFERENCIAS [1] Erl, Thomas Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR : Prentice Hall PTR,

10 [2] IBM Corp Building SOA Solutions Using the Rational SDP. [ ml] s.l. : RedBooks, [3] Healthcare Services Specification Project, Health Level Seven, Object Management Group. The Practical Guide for SOA in Health Care, [4] Firat Kart, Louise E. Moser, and P. Michael Melliar-Smith. Building a Distributed E-Healthcare System Using SOA. IEEE Xplore, 2009 [5] A. Ryan, P. Eklund and B. Esler, Toward the Interoperability of HL7 v3 and SNOMED CT: a case study modeling mobile clinical treatment, in MedInfo 2007: IOS Press, Amsterdam, [6] Timo ITÄLÄ, Jari UKKOLA, Aino VIRTANEN, Juha MYKKÄNEN. SOA approach for integration of departmental systems. ehealth Beyond the Horizon. [7] United Nations Economic and Social Commission for Asia and the Pacific, Dispobible en Tpaper pdf, [8] BLOBEL, Bernd, EHR-Architectures- Comparisons and Trends. [2] Microsoft Corporation, "Enabling Real World SOA through the Microsoft Platform," microsoft.com, Dec, Disponible en: 80a a6e- 9d2866d8b581/Real%20World%20SOA.doc. [Consultada: Agosto 12 de 2009]. [6] RYAN Amanda, A Framework for Semantic Interoperability in Healthcare: A Service Oriented Architecture based on Health Informatic Standards. Organizing Committee of MIE [7] Timo ITÄLÄ, Jari UKKOLA, Aino VIRTANEN, Juha MYKKÄNEN. SOA approach for integration of departmental systems. ehealth Beyond the Horizon. [8] DM Lopez, B Blobel, Arquitecturas para la Implementación de Sistemas de Información en Salud Basadas en el Estándar HL7. ehealth Competence Center, Regensburg University Hospital, Germany [9] Proyecto Gel-xml, Disponible en: [Consultada: Octubre 8 de 2009]. [10] López, Diego Mauricio Interoperable Architectures for Advanced Health Information Systems. PhD thesis. University of Regensburg, Germany : s.n., [11] Minoli, Daniel Enterprise Architecture A to Z. s.l. : Taylor & Francis Group, [12] J.D. Meier, Carlos Farre y otros, Performance Testing Guidance for Web Applications, 2007 Microsoft Corporation. [3] A. Ordanini and P. Pasini, "Service coproductioin and value co-creation: The case for a service-oriented architecture (SOA)," European Management Journal, vol. 26, no. 5, p. 289, Octubre Disponible en: ProQuest, d=2&fmt=2&clientid=23754&rqt=309&vname=p QD. [Consultada: Agosto. 15 de 2009]. [4] HEITMANN KAY, HL7 Communication standard in medicine. 1 Ed. Cologne Palantresr ISBN [5] A. Ryan, P. Eklund and B. Esler, Toward the Interoperability of HL7 v3 and SNOMED CT: a case study modeling mobile clinical treatment, in MedInfo 2007: IOS Press, Amsterdam, 2007.