Arquitectura Orientada a Servicios para Sistemas que utilizan HL7

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Arquitectura Orientada a Servicios para Sistemas que utilizan HL7"

Transcripción

1 Arquitectura Orientada a Servicios para Sistemas que utilizan HL7 Pablo Pazos Gutierrez - Samanta de Barros Taller de Sistemas de Información 3, Instituto de Computación Facultad de Ingeniería, Universidad de la República RESUMEN Actualmente, la interoperabilidad entre instituciones de salud es importante no sólo en Uruguay, sino en todo el mundo. Para esto se han desarrollado distintos estándares ANSI y CEN orientados al sector de la salud, como HL7, EN13606 y OpenEHR. Específicamente, en Uruguay, se ha tomado como estándar a seguir HL7, en lo que tiene que ver con interoperabilidades de sistemas de información clínica a partir de la creación de la SUEIIDISS. El objetivo de este proyecto es evaluar una arquitectura SOA para sistemas que utilizan mensajes HL7. Para cumplir con dicho objetivo se deberá implementar un caso de estudio específico, en particular el alta de pacientes del perfil PIX de la IHE, evaluando la utilización de middlewares avanzados tales como ESBs en la arquitectura planteada. INTRODUCCIÓN La IHE es una iniciativa de diversos actores de la industria y profesionales del área de salud para mejorar la forma en que los sistemas computarizados en el área de la salud comparten información. La IHE define una serie de perfiles que son aplicaciones específicas de los estándares HL7 a áreas comunes a cualquier sistema EPR/EHR/CPR, restringiendo así las opciones de uso que permiten los estándares, simplificando el uso de los mismos y la implementación de sistemas orientados a estándares en las áreas abarcadas por los perfiles, como ser cardiología, radiología, oftalmología, laboratorio, etc. Cada perfil especifica que workflow seguir para cada caso, en este caso PIX define que pasos se siguen para resolver referencias cruzadas con identificadores de pacientes entre varias organizaciones que utilizan distintos identificadores para un mismo paciente. PIX define básicamente un MPI como repositorio de identificadores de pacientes de los distintos dominios, donde cada dominio podría manejar un identificador local distinto al de los demás dominios para el mismo paciente. Un dominio podría ser una organización o un conjunto de organizaciones prestadoras de servicios de salud. Figura 1. Diagrama del perfil PIX + PDQ

2 GLOSARIO: IHE: Integrating the Healthcare Enterprise PIX: Patient Identity Cross-Referencing XDS: Cross-Enterprise Document Sharing PDQ: Patient Demographic Query ITI-TF: IT Infraestructure Technical Framework HL7: Health Level Seven CMET: Common Message Element Type MPI: Master Patient Index empi: Enterprise MPI LDAP: Lightweight Directory Access Protocol RIM: Reference Information Model R-MIM: Reduced Message Information Model D-MIM: Domain Message Information Model HMD: Hierarchical Message Definition DSTU: Draft Standard Trial Use PRPA: Practice Patient Adminsitration MCCI : Message Control Infraestructure COMB : CMET-Oriented Message Builder ESB: Enterprise Service Bus EHR: Electronic Health Record (Historia Clínica Electrónica) EN13606: Estándar ISO/CEN para transferencia de EHRs mediante interoperabilidad semántica. OpenEHR: Estándar de EHR basado en modelo dual, compatible con EN13606.

3 PIX para implementar un MPI: Principales problemas a resolver: - Identificación única de pacientes dentro del sistema, un sistema complejo, distribuido entre varias organizaciones (centros clínicos, mutualistas, clínicas particulares, etc). - Conectividad estandarizada: acceso remoto a servicios e información de forma consistente. Un MPI permite que diversas organizaciones puedan registrar información de sus pacientes en un repositorio central compartido. Ducha información está compuesta tanto de identificadores de pacientes en cada organización, como de información demográfica útil para un algoritmo que pueda verificar a que paciente corresponde cierta información dada. Como muchas veces la información puede estar incompleta o ser incorrecta, por ejemplo si se escribió mal un apellido, el algoritmo de verificación de identidad debe ser lo suficientemente inteligente para detectar esos casos y comportarse de forma robusta, por ejemplo basándose en algoritmos soudex para encontrar palabras distintas que son parecidas y potencialmente la misma mal escrita y en caso de no ser determinista en cuanto al resultado, dar una lista de resultados probables. Las organizaciones participantes en el MPI mantienen el control de sus índices sobre pacientes en el repositorio central. Este debe proveer servicios para agregar y modificar información de pacientes. Además debe proveer soporte para consultar índices de pacientes para las distintas organizaciones participantes en el sistema, por identificadores de pacientes de otras organizaciones participantes o información demográfica originada en otros dominios. Por lo tanto, la búsqueda deberá resolver referencias cruzadas entre pacientes de distintas organizaciones. Opcionalmente se puede proveer la funcionalidad de notificar a las organizaciones participantes del MPI sobre modificaciones en los datos de sus pacientes por otros participantes en el sistema o notificaciones del agregado de nuevos pacientes al sistema. El perfil PIX de la IHE define un MPI con sus respectivos componentes, casos de uso y transacciones que implementarán las funcionalidades necesarias: - Agregar pacientes al MPI. - Modificar información de pacientes en el MPI. - Notificar a otros participantes de eventos en el MPI. - Resolver duplicados de información (saber que los datos de dos pacientes corresponden a la misma persona). A su vez el perfil PDQ es el que provee, sobre los componentes definidos por PIX, los casos de uso y transacciones para que las organizaciones participantes puedan consultar por índices de pacientes y obtengan resultados. En definitiva un MPI debe mantener la información de los participantes del sistema, de los índices de pacientes para cada organización participante del sistema y la información demográfica de los pacientes, provista por los distintos participantes, para poder ser capaz de resolver duplicados y verificar la identidad de un paciente. Algunas ventajas de contar con un MPI son: 1. Se disminuye el costo de sincronización de datos entre sistemas distribuidos entre organizaciones, porque no es necesario resolver la comunicación de N sistemas heterogéneos entre si, solo es necesario resolver la comunicación de cada sistema con el repositorio central. 2. Un MPI disminuye los costos de mantenimiento. La algoritmia necesaria para resolver índices de pacientes reside en un solo lugar, si llegara el caso de necesitar modificar algoritmia u optimizar la misma en algún sentido, esta lógica reside en un único lugar, no es necesario hacer modificaciones en cada uno de os sistemas de cada participante. 3. Disminución del costo computacional. El repositorio central, en el caso de PIX el PIX Manager, tiene una responsabilidad bien definida y limitada, por lo que se puede optimizar dicho sistema para resolver de forma óptima dichas responsabilidades, buscando soluciones óptimas de infraestructura, hardware, middleware y software para eso.

4 Algunas consideraciones de implementación de un MPI Comunicación Si bien PIX presenta comunicación mediante mensajería HL7, las transacciones definidas por la IHE son genéricas, por lo que se podría abstraer del sistema particular de mensajería y ver solo las transacciones y la información que debe comunicarse. En este sentido, y pensando en una arquitectura orientada a servicios, sería interesantes de estudiar la implementación de las transacciones mediante mensajería a medida o mensajería definida por estándares transmisión de información clínica y demografica aparte de HL7. Por ejemplo, se podría estudiar la compatibilidad del estándar EN13606 o de OpenEHR con la mensajería HL7 utilizada en los perfiles IHE, donde tanto EN13606 como OpenEHR definen interoperabilidad semática a nivel de conceptos, separando lo que es conocimiento de lo que es información, mientras que HL7 define una interoperabilidad funcional mediante mensajes que puedan se comprendidos por humanos. Una motivación para realizar este análisis es que tanto el estándar EN13606 como OpenEHR son mucho menos complejos y voluminosos que HL7, como curiosidad las especificaciones de EN13606 ocupan 6 megas comprimidos mientras que la de HL7v3 ocupan 147 megas comprimidos. Ejemplo LEGO de interoperabilidad semántica en dos niveles: Figura 2. Modelo de referencia (información) vs Modelo de arquetipos (conocimiento) Escalabilidad Un MPI no tiene por que ser un elemento único en el sistema, más bien debería tener la forma de un conjunto de componentes distribuídos interconectados, donde cada componente es a la vez sea un MPI para un conjunto menor de organizaciones. En este sentido, pensando en una arquitectura escalable, se podría crear un sistema de MPI que sea un composite, en el sentido de patrones de diseño, de dos o más MPIs existentes, y a su vez otros que puedan juntar esos MPIs de forma de poder escalar indefinidamente el sistema y de poder adoptar MPIs parcialmente entre organizaciones, permitiendo agregar nuevas organizaciones y nuevos MPIs al sistema global. Seguridad El sistema debe proveer seguridad para cada transacción, impidiendo que solo se accedan a recursos o servicios del sistema si se cuentan con las autorizaciones respectivas. Además cada transacción debería proveer un nivel de atomicidad transaccional, para que los sistemas queden consistentes internamente luego de ejecutada una transacción. Una característica particularmente útil sería la de llevar registros de cada transacción realizada, que transacción, quien la hizo, cuando, ocurrió algún problema?, Cuál era el estado del sistema al llevarse a cavo la transacción?, etc., de forma de poder auditar el sistema en caso de detectarse algún problema.

5 CASO DE ESTUDIO En el ITI-TF del 15 de agosto de 2007 en el cual se basa el estudio del perfil PIX, se define un caso de uso llamado Patient Identity Feed HL7v3 dentro de dicho perfil. En el caso de uso antes mencionado se definen las siguientes transacciones: - Patient Registry Record Added: Dar de alta un nuevo identificador para un dominio. - Patient Registry Record Revised: Modificar información del paciente por un dominio. - Patient Registry Duplicates Resolved: Resolver suplicados de información para un mismo paciente. - Accept Acknowledgement: responder al dominio por mensajes recibidos por el PIX Manager. - Update Notification: Notificar a varios dominios de eventos que ocurran en el PIX Manager. Aunque el ITI-TF es un documento con mucha información útil para entender el perfil no hay que olvidar que es un draft de implementación, para probar si lo ahí definido alcanza o no para implementar un MPI. Por esta razón dicho documento no fue tomado como única fuente de información, si no que también basamos el estudio en la documentación provista por HL7 sobre las respectivas transacciones, actores y mensajes. Según su sitio web, la IHE tiene estimado sacar una versión estable del documento en agosto de En este proyecto en particular, se fijó el alcance en la implementación de la transacción Patient Registry Record Added, en donde se da de alta un nuevo identificador e información de un paciente, para un dominio específico, en el PIX Manager. Figura 3. Transacciones del perfil PIX Según lo definido en el perfil PIX, a cada transacción le corresponde un mensaje HL7. Cada uno de estos mensajes contiene tres partes importantes: 1. La parte principal, la cual contiene la información que se quiere transmitir, en el caso de Patient Registry Record Added es información demográfica de pacientes, como ser identificadores del paciente, fecha de nacimiento, nombre, donde vive, de qué país es ciudadano, que idioma habla, etc, esta parte es la parte interna del mensaje en la estructura RIM. 2. Una segunda parte es la que contiene información del evento, cuando pasó, quien lo hizo, etc. Esa sería la parte intermedia del mensaje y contiene la información antes mencionada. 3. Por último, la parte externa del mensaje, o que sería el mensaje en sí, que tiene información de fechas de envío, quien lo envía, para quien es el mensaje, etc. Esta parte contiene a las partes mencionadas antes, y es lo que se denomina payload. PIX define también un mensaje de acknowledge para cada mensaje enviado, el cual contiene información del envío, información del resultado del envío y el mensaje enviado anteriormente, que es del cual se hace ack.

6 SOLUCIÓN PROPUESTA Arquitectura La arquitectura del sistema propuesto consiste en dos grandes componentes, el PID y el PIX Manager, los cuales intercambian mensajes HL7 a través de un ESB. El objetivo del perfil es poder contar con un MPI entre varios Patient Identification Domains, donde se pueden manejar distintos identificadores para los mismos pacientes, lo que dificulta el intercambio de documentos clínicos de dichos pacientes entre PIDs. El PIX Manager actúa como MPI resolviendo referencias cruzadas de identificadores y siendo capaz de procesar consultas desde los PIDs. El perfil para intercambio de documentos clínicos es XDS y el perfil para consultas es PDQ. Figura 4. Componentes en detalle El componente PID a su vez, es un sistema multi-capas, donde se distinguen las siguientes tres capas: 1. GUI: provee una interfaz para que el usuario ingrese datos de pacientes al sistema. 2. Persistencia: provee una solución de persistencia local para la información ingresada desde la GUI. 3. Lógica: contiene los tres grandes componentes que permiten la realización del caso de uso. a. Flujo: controla el flujo del caso de uso de ingreso de datos de paciente, desde la entrada de datos, hasta el envío de datos mediante el ESB al PIX Manager. b. Generación de mensajes: este componente recibe la información del paciente, ingresada desde la GUI, y genera un mensaje HL7 válido que corresponde a la interacción Patient Registry Record Added. c. Comunicación: provee el punto de salida del PID hacia el PIX Manager. El PIX Manager a su vez presenta estas tres capas: 1. Comunicación: interfaz de servicios que provee un punto de entrada para la recepción de los mensajes de las transacciones definidas por PIX. 2. Persistencia: define donde guardar la información que posteriormente se utilizará para resolver referencias cruzadas. 3. Lógica: contiene los componentes que permiten la realización del caso de uso. a. Desconversor de mensajes: este componente recibe los mensajes HL7 enviados y provee una interfaz para acceder a la información contenida en los mismos. b. Flujo: maneja el flow de acciones ante la recepción de mensajes. c. Componente de resolución de identificadores de pacientes cruzados.

7 DSS: interacción con el sistema y envío de mensajes Figura 5. DSS GUI-ESB Figura 6. DSS ESB-PIX Manager Tecnologías En esta sección se detalla las tecnologías que se investigaron para la realización del proyecto, definiendo los motivos que llevaron a la selección de algunas de estas para la implementación del caso de estudio. JavaSIG JavaSIG es la librería que se eligió en primera instancia para implementar los mensajes porque, previa investigación, es la que mejor se adapta a las necesidades particulares de este proyecto. JavaSIG es una implementación Open Source de las clases del RIM HL7 utilizando tecnología Java. Cuenta con funcionalidades para la generación de mensajes HL7 a partir de estructuras RIM. Para esto utiliza archivos MIF provistos por la norma, donde se define la estructura de cada mensaje HL7 y contra la que se validan las estructuras RIM generadas. Se definió la utilización de esta librería, luego de lograr la generación de un mensaje correspondiente al CMET , que es parte del mensaje definido para la transacción Patient Registry Record Added, de forma exitosa. Por este motivo, no se llegó a investigar la otra posible tecnología, planteada en un principio, para la generación de mensajes, el Open Healthcare Framework (OHF).

8 Grails Framework Open Source orientado a un proceso de desarrollo ágil. Lleva el paradigma de codificación por convención al lenguaje Groovy y está orientado al desarrollo de aplicaciones web 2.0. Está basado en frameworks y tecnologías Java como Spring, Groovy, Hibernate, Sitemesh, Quartz Scheduling, Jetty, HSQLDB, entre otros. Las principales ventajas de este framework son que está orientado al desarrollo de sistemas web, implementando MVC con ORM, además de tener otras características útiles como ser scaffolding dinámico, taglibs simplificadas (muy simple en comparación al desarrollo de taglibs para jsp) e integración de herramientas de testing y logging. Posee integración con distintos IDEs, en particular con Eclipse, el IDE utilizado en este proyecto. GRAILS posee una curva de aprendizaje bastante rápida por ser muy intuitivo y simple, garantiza una productividad alta, por lo que es una excelente opción para proyectos con plazos muy cortos como este, o para prototipación de sistemas grandes. GRAILS tiene una arquitectura orientada a plugins y posee varios plugins muy útiles de los que utilizamos un par mencionados abajo. Además GRAILS es un proyecto libre y de código abierto, y su licencia permite desarrollar tanto proyectos libres como proyectos comerciales, y cuenta con una comunidad muy activa. Groovy El lenguaje dinámico de Java. Groovy presenta una extensión dinámica al lenguaje Java, disponiendo de todas las funcionalidades de la Java API más nuevos constructores y funcionalidades, como por ejemplo las clausuras (una construcción de programación funcional). Además Groovy se compila a bytecode lo que no representa un gran problema en la performance. Web Services Se utilizó el AXIS2 plugin para GRAILS para exponer web services de forma sencilla en el componente PIX Manager. A su vez, para consumir web services en el componente PID se utilizó GroovyWS. Apache ServiceMix Apache ServiceMix es un ESB Open Source desarrollado por la fundación Apache y que cumple con el especificación JSR 208 para JBI. El mismo cuenta con un Normalized Message Router (NMR), como es requerido por la especificación JBI. Este es el que se encarga de intercambiar los mensajes normalizados entre los distintos componentes del ESB, que se conectan a ServiceMix como plugins. Estos componentes se dividen en dos grandes tipos: Service Engines (SE) y Binding Components (BC). Los Service Engines son los componentes que proveen servicios dentro del ESB, y sólo se pueden comunicar con el exterior mediante BC. Ejemplos de estos ESB pueden ser motores de reglas, transformadores (XSLT, scripts), contenedores EJB, entre otros. Los Binding Components son los que exponen los servicios desde el ESB hacia el exterior y viceversa, es decir, son los puntos de entrada y salida al ESB. El ServiceMix incluye BC que permiten exponer servicios a través de SOAP, http, ftp, jms, mail, entre otros. Entre las ventajas de utilizar ServiceMix se encuentra la facilidad que provee, a través de arquetipos Maven, para generar nuevas configuraciones de sus componentes, que permiten exponer distintos tipos de servicios. Además cuenta con gran cantidad de ejemplos de utilización de dichos componentes, y documentación detallada sobre la arquitectura del sistema. Entre las desventajas se encuentra la poca integración con IDEs que provee. Se encontraron distintos plugins de Eclipse que ofrecían cierto tipo de ayuda en la tarea de implementación, uno de estos, el CIMERO permitía definir servicios compuestos por el routing y filtrado de mensajes a través de diversos componentes, pero no se obtuvieron buenos resultados con el mismo. Otro de los plugins, en realidad permitía la integración de Eclipse con Maven, pero no fue posible configurar el mismo para que utilizara los arquetipos necesarios para generar componentes ServiceMix, por lo que se optó por la utilización de la línea de comandos para esto. A pesar de la variedad de posibilidades ofrecidas por el ServiceMix, se optó por la utilización de otro ESB en este proyecto, por motivos que se detallan más adelante.

9 Mirth Mirth es un ESB Open Source independiente de la plataforma, orientado a la transmisión de mensajes HL7. La transmisión se realiza a través de canales definidos mediante una interfaz gráfica. Estos canales están conectores de entrada y salida, filtros y transformadores. Los conectores actualmente soportados son: LLP, base de datos, JMS, Webservices SOAP, archivo, PDF, FTP, SFTP. Mediante la interfaz gráfica es posible seleccionar que filtros y transformaciones se le aplican al mensaje entrante antes de enviarlo a la salida. Figura 7. Arquitectura de un canal Mirth También es posible definir nuevos filtros mediante scripts, o incluso código Java. A su vez, es posible acceder al contenido del mensaje si se define un template para el mismo. Esto puede ser de mucha utilidad si se desean filtrar, por ejemplo, mensajes HL7, según algún atributo específico. Los transformadores se utilizan para extraer información del mensaje, luego de que este es convertido a XML. Es posible definir transformadores personalizados, también a través de la interfaz gráfica. El Mirth ofrece la posibilidad de crear no solo canales simples (un conector de entrada, y uno de salida), sino canales con múltiples conectores de salida, de forma de realizar un broadcast de la información recibida, o un ruteo de la misma. El broadcast se realiza enviando el mensaje luego de filtrado y tranformado a varios conectores de salida. Es posible rutear el mensaje a distintas aplicaciones, definiendo para un mismo conector de entrada, un conjunto de conectores de salida cada uno con sus filtros y transformadores. También es posible lograr enrutamientos y transformaciones más complejas, uniendo conectores internos al Mirth, es decir, definiendo un conector de salida que envíe el mensaje a uno de los conectores de entrada definidos. Figura 8. Arquitectura de un canal Mirth

10 Para la realización de este proyecto se optó por el Mirth como ESB debido a la simplicidad ofrecida para integrar el mismo a la aplicación, ya que es posible definir los canales de comunicación a través de la interfaz, y también monitorear los mensajes enviados y posibles errores. Además, permite definir fácilmente reglas de validación y filtrado de mensajes según datos provenientes en el mismo y definidos por HL7. Posibles aplicaciones de ESB en un sistema distribuido Si bien para este proyecto particular el uso de ESB no presenta mayores ventajas, el mismo proyecto en un sistema en producción podía verse favorecido con la existencia de un ESB para canalizar las comunicaciones. Una primer aplicación podría ser el loging de las transacciones, o sea un registro de los mensajes que se envían y reciben, para cada componente del sistema y que la responsabilidad de mantener dicho log sea en el propio ESB, haciendo un solo repositorio de logs que puede ser consultado por los diversos componentes sobre los mensajes enviados por ellos o enviados a ellos, de forma tal de no necesitarse implementar esta funcionalidad por cada uno de los componentes que participan en la comunicación. Luego se podría proveer a través del mismo ESB y servicio de consultas de logs al que todos los componentes registrados para envío y recepción de mensajes puedan acceder. Otra aplicación interesante es la del reenvío de mensajes. Como es imposible garantizar que cada mensaje enviado es recibido del otro lado en tiempo y forma, y como hay mensajes que deben si o si ser transmitidos correctamente, la detección de fallas de comunicación y el intento de reenvío son funcionalidades básicas de un sistema de información y comunicación de estas características (orientado al área de salud), por lo tanto se podría utilizar la infraestructura existente en el tier que tiene el deploy del ESB para tener una solución que pueda persistir mensajes y estados de envío, y algún tipo de tarea tipo job que corra en segundo plano y que automáticamente, cada cierto tiempo, intente reenviar los mensajes que no se pudieron enviar porque hubo algún tipo de falla. También se podría guardar información del tipo de falla y si el mensaje se intenta reenviar más de cierta cantidad de veces que pare los reintentos y avise al componente que envío el mensaje que el mismo no pudo ser entregado y porqué motivos, en sí podría avisar a quien envía o como se comentó antes, que quien envía pueda acceder a través de un servicio al log de envío del mensaje y pueda ver cuales mensajes fueron enviados y cuales no y porque motivo. En el caso el Mirth como ESB, es también interesante el hecho de que provee funcionalidades que permiten mapear datos de los mensajes entrantes a variables, que se pueden utilizar para generar mensajes HL7, permitiendo así que la migración de una aplicación que comunica datos sin utilizar el estándar HL7, a una aplicación que sí lo hace, sea fácil y no requiera una modificación en la estructura de la misma. OpenLDAP La utilización de LDAP para el registro de información de pacientes en el componente PID era uno de los requerimientos del proyecto. Más específicamente se requirió la utilización de OpenLDAP, ya que es una implementación libre y de código abierto del protocolo, con la cual contaban los clientes. El acceso al servidor LDAP se hace a través de un plugin de GRAILS, GLDAPO, el cual se basa en el componente de Spring Framework que ofrece acceso al protocolo. Este plugin ofrece un mapeo de clases java a persistencia LDAP, mediante la definición de clases groovy que se mapean con los esquemas de LDAP, y la configuración del servidor requerido. Las funcionalidades incluyen tanto la persistencia, como la consulta y actualización de datos. Componentes Tecnología Las tecnologías utilizadas para la implementación de los distintos componentes del PID son las siguientes: 1. GUI: Se utilizó el framework GRAILS para generar las vistas mediante una webapp. 2. Persistencia: Se optó por utilizar un plugin de GRAILS para LDAP que permite persistir información en un LDAP de forma sencilla. 3. Lógica: contiene los tres grandes componentes que permiten la realización del caso de uso. a. Flujo: implementado en Java. b. Generación de mensajes: se implementó un componente de generación de mensajes orientado a CMETs en Java, el cual depende de la librería JavaSIG. c. Comunicación: se utilizó el plugin GroovyWS para GRAILS para poder consumir un WebService donde se envía el mensaje generado y del cual se recibe un resultado.

11 Los componentes del PIX Manager a su vez está implementados utilizando las siguientes tecnologías: 1. Comunicación: Se hicieron pruebas con el plugin de AXIS2 para GRAILS para exponer el servicio de recepción de mensajes vía SOAP, pero decidimos utilizar REST. 2. Persistencia: En este caso un modelo de dominio de GRAILS fue suficiente para guardar la información a un DBMS MySQL. 3. Lógica: contiene los componentes que permiten la realización del caso de uso. a. Desconversor de mensajes: componente implementado en Java para obtener la información contenida en los mensajes recibidos. b. Flujo: implementado en Java. c. Componente de resolución de identificadores de pacientes cruzados: implementado en Java. Mensajería HL7 para transacciones PIX Para la implementación de la mensajería HL7 para este proyecto, nos basamos sobre todo en los diagramas provistos por HL7 en el dominio PRPA y por la IHE en su ITI-TF para la implementación de la mensajería. Si bien el perfil PIX define mensajes tanto para ack de mensajes recibidos por el PIX Manager como mensajes de notificación a otros dominios cuando información de los pacientes en el PIX Manager es agregada o modificada, ninguno de estos mensajes fue implementado por considerarse fuera del alcance y por contar con poco tiempo para implementación ya que la mayoría del tiempo del proyecto fue de estudio de las normas (HL7, IHE) y de las tecnologías (LDAP, GRAILS, WS, ESB, MIRTH). Cada transacción PIX es implementada mediante la comunicación de un mensaje HL7. Cada mensaje está basado principalmente en tres CMETs, el wrapper del mensaje, el act control y la información del paciente (un role based CMET). En el caso de la transacción Patient Registry Record Added, la que se planteó para implementar, los CMETs principales son: Mensaje: , Control Act: y Role based payload: , los mismos se ilustran en las siguientes imágenes. Figura 9. Esquema general de un mensaje y niveles de implementación.

12 A continuación presentamos los diagramas correspondientes a estos CMETs: El CMET representa el nodo principal del mensaje generado. Este contiene información referente al envío del mensaje, información de los actores (quien envía y quien recibe) y de los dispositivos de comunicación que se usan para enviar el mensaje. Figura 10. Transmisión Wrapper para los mensajes del CU Patient Identity Feed. El CMET es la parte intermedia del mensaje. Su nodo principal se conecta al CMET a través de su ControlActProcess. Este CMET contiene información del acto y el evento que generó dicho acto. Lo más importante es la información de para quien se generó el acto, o sea el subject. Figura 11. Control Act Wrapper para los mensajes del CU Patient Identity Feed OBS: en los mensajes de muestra el subject del RegistrationEvent se llama subject1 y de esta forma está implementado en JavaSIG, puede ser un error en el diagrama.

13 El CMET es la parte interna del mensaje, la que contiene la información útil del paciente para resolver referencias cruzadas en el PIX Manager. Figura 12. CMET contiene la información del paciente para la interacción Patient Registry Record Added, del CU Patient Identity Feed. CONCLUSIONES En este caso en particular, donde la comunicación entre un manager y N dominios, con mensajería normalizada, es prácticamente unilateral, lo que hace de PIX un protocolo de comunicación relativamente simple, no se le encontró mayor utilidad a la integración de un ESB como middleware en la arquitectura definida. En otros casos, por ejemplo para implementar el perfil XDS, donde la comunicación es de N a N sistemas entre sí, podría ser de utilidad contar con un ESB que se responsabilice de la exposición de servicios y la comunicación entre componentes quitándole a cada sistema la complejidad de manejar la comunicación con otros N sistemas heterogéneos. La norma En la generación de mensajes tuvimos problemas con archivos MIF provistos por HL7, dichos archivos los toma JavaSIG como entrada para poder generar un XML válido a partir del RIM generado para el mensaje. Estos problemas pueden deberse a problemas internos de la norma en estos archivos MIF o problemas de compatibilidad entre JavaSIG y los archivos MIF, talvez dados por problemas de versiones, ya que JavaSIG debe adaptarse a la norma cuando esta es liberada y no hay documentación sobre si las versiones que utilizamos tanto de JavaSIG como de los MIF de HL7 tienen alguna incompatibilidad. La solución fue modificar los MIFs problemáticos en los nodos que daban error. TRABAJO FUTURO Se podría utilizar el conocimiento generado en este proyecto para implementar tanto los perfiles PDQ como XDS, integrando así los tres perfiles, en donde un ESB tiene mucha más aplicación, por haber comunicación de N a N nodos heterogéneos. Mejorar el componente de generación y desconversión de mensajes HL7 para hacerlo más genérico y ampliarlo a la generación de más tipos de mensajes. Tanto para los mensajes de las distintas transacciones, como para mensajes de documentos clínicos como por ejemplo mensajería HL7 CDA.

14 Implementar un cliente inteligente de mensajería HL7 que pueda extenderse fácilmente (mediante configuración y sin tener que re-compilar/re-deployar toda la aplicación) para recibir nuevos tipos de mensajes, lo que sería de especial interés para organizaciones que provean servicios a través de mensajería HL7. Ahora el PIX Manager implementado sigue algunos de estos lineamientos pero no es totalmente genérico y extensible en los mensajes que puede recibir, pero es una buena base para un sistema con estas capacidades. En cuanto al perfil PIX y los demás perfiles, se podría investigar con otros estándares de comunicación de información clínica para ver que nivel de compatibilidad tienen con los mensajes HL7 y hacer prototipos de implementación del perfil con dichos estándares. Por ejemplo con OpenEHR o el estándar EN13606, el cual propone interoperabilidad semática de información clínica mediante arquetipos. Investigar que soluciones de seguridad existen para garantizar que las transacciones son seguras. Investigar el perfil ATNA de la IHE para este fin. REFERENCIAS: 1. IHE 2. HL7 3. HL7 Argentina 4. OpenEHR 5. Washington University School of Medicine 6. Wiki de la SUEIIDISS 7. What is an Enterprise Master Patient Index 8. Maintenance of Master Patient Index ok1_ Mirth Project 10. ESB architecture and life-cicle definition 11. ESB InfoQ 12. Apache ServiceMix 13. OpenLDAP 14. The Role of the Enterprise Service Bus (InfoQ - Video Presentation) 15. Grupo de informática biomédica

Sistema de identificación de pacientes orientado a servicios

Sistema de identificación de pacientes orientado a servicios Sistema de identificación de pacientes orientado a servicios Pablo Pazos Gutierrez SICTI, DiaCronic Samanta de Barros DiaCronic Que son estas tres letras? EHR: Electronic Health Record IHE: Integrating

Más detalles

Generador de sistemas normalizados de historia clínica electrónica basados en el estándar OpenEHR

Generador de sistemas normalizados de historia clínica electrónica basados en el estándar OpenEHR Generador de sistemas normalizados de historia clínica electrónica basados en el estándar OpenEHR Agenda 1. Introducción 2. Problemas comunes en SIS 3. Posibles soluciones 4. El framework 5. Demo 1. Introducción

Más detalles

Sistema de comunicación de sesiones de hemodiálisis vía HL7 CDA. A/C Pablo Pazos Gutierrez pablo.swp@gmail.com

Sistema de comunicación de sesiones de hemodiálisis vía HL7 CDA. A/C Pablo Pazos Gutierrez pablo.swp@gmail.com Sistema de comunicación de sesiones de hemodiálisis vía HL7 CDA A/C Pablo Pazos Gutierrez pablo.swp@gmail.com Marco Proyecto de ingenieria de software Propuesta del Hospital Maciel y el FNR 2 grupos de

Más detalles

UTILIZANDO IHE EN LA IDENTIFICACIÓN DE PACIENTES

UTILIZANDO IHE EN LA IDENTIFICACIÓN DE PACIENTES UTILIZANDO IHE EN LA IDENTIFICACIÓN DE PACIENTES Carlos Gallego Coordinador Proyectos Dirección Sistemas Información Asepeyo cgallego@asepeyo.es www.ihe-e.org/ Introducción: IHE: Integrating the Healthcare

Más detalles

OpenESB FEMI Sofis Solutions - PMA

OpenESB FEMI Sofis Solutions - PMA OpenESB FEMI Sofis Solutions - PMA Página 1 de 22 1 BPMS... 3 1.1 Introducción... 3 1.2 Modelado de Procesos... 5 1.2.1 Editor Gráfico de Procesos... 5 1.2.2 Gestión de Tareas... 6 1.2.3 Interacción Humana...

Más detalles

Propuestas de Proyectos de Grado 2012

Propuestas de Proyectos de Grado 2012 Propuestas de Proyectos de Grado 2012 Laboratorio de Integración de Sistemas 6 de Marzo, 2012 Instituto de Computación Facultad de Ingeniería Universidad de la República de Uruguay Agenda Laboratorio de

Más detalles

MARCANDO LA DIFERENCIA

MARCANDO LA DIFERENCIA MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Arquitectura Java para el Cuarto Ejercicio José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Sumario Introducción Arquitectura en n-capas Arquitectura y el Cuarto Examen Java y su modelo

Más detalles

Taller de Sistemas de Información 3. Presentación SCA

Taller de Sistemas de Información 3. Presentación SCA Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1 Introducción a SCA Aplicación: conjunto de componentes de software trabajando

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Introducción a Javato

Introducción a Javato Introducción a Javato Fº. Javier Pereñiguez Steria Iberica 20/02/2008 Índice Introducción Arquitectura Ejemplo arquitectura Plataforma Desarrollo Ejemplo de entorno de desarrollo Vías futuras Casos de

Más detalles

Uso de estándares de interoperabilidad

<Insert Picture Here> Uso de estándares de interoperabilidad Uso de estándares de interoperabilidad Alexander Fedorowicz Director de soluciones en salud, América Latina Agenda de la presentación Por qué buscar la interoperabilidad?

Más detalles

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores.

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores. GLOSARIO Glosario Acoplamiento. Posibilidad que tiene un servicio de funcionar de forma autónoma. Se dice que un servicio o aplicación es bajamente acoplado cuando puede funcionar de forma independiente

Más detalles

Análisis y diseño del sistema CAPÍTULO 3

Análisis y diseño del sistema CAPÍTULO 3 Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la

Más detalles

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Tesina Licenciatura en Informática (UNLP) Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Boccalari Cristian Temario General Visión

Más detalles

La integración de información. Presente y futuro de la empresa moderna

La integración de información. Presente y futuro de la empresa moderna La integración de información. Presente y futuro de la empresa moderna Ing. Josue Carralero Iznaga, MSc. ISPJAE, Facultad de Ingeniería Informática, Departamento de Ingeniería de Software. Complejo de

Más detalles

Prueba de conectividad y soluciones de integración para sistemas de salud

Prueba de conectividad y soluciones de integración para sistemas de salud 4 CONGRESO IBEROAMERICANO DE INFORMÁTICA MÉDICA NORMALIZADA Foro de Conectividad Foro de Informática Normalizada para Enfermería Foro de Informática Normalizada en Registros Médicos Prueba de conectividad

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Propuestas de Proyectos de Grado 2014

Propuestas de Proyectos de Grado 2014 Propuestas de Proyectos de Grado 2014 Laboratorio de Integración de Sistemas 26 de Febrero, 2014 Instituto de Computación Facultad de Ingeniería Universidad de la República de Uruguay Laboratorio de Integración

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

Guía de OpenEHRGen v0.8

Guía de OpenEHRGen v0.8 Guía de OpenEHRGen v0.8 Generador de Sistemas de Historia Clínica Electrónica openehr Autor: Ing. Pablo Pazos Gutiérrez Director en CaboLabs.com Traducción: Lic. Bárbara Cardozo v1.0 26-02-2013 1 Índice:

Más detalles

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl no asume responsabilidades o garantías sobre el contenido y uso de ésta documentación y declina cualquier garantía explicita o implícita de comercialidad

Más detalles

El Framework de desarrollo del Consejo

El Framework de desarrollo del Consejo El Framework de desarrollo del Consejo Superior de Investigaciones Científicas Director de la OPCSIC Centro Técnico de Informática (CSIC) Directora Centro Técnico de Informática (CSIC) Palabras clave Framework,

Más detalles

Servicios para la integración de sistemas de información sanitarios

Servicios para la integración de sistemas de información sanitarios Servicios para la integración de sistemas de información sanitarios Francisco Javier García Muñoz Resposable de la Unidad de Innovación Área de Tecnologías de la Información jgarcia@sescam.org http://sescam.jccm.es

Más detalles

Silenus Consultoría. SOA Silenus SOA/09009. Mayo de 2009. Análisis SOA Silenus

Silenus Consultoría. SOA Silenus SOA/09009. Mayo de 2009. Análisis SOA Silenus SOA Silenus SOA/09009 Mayo de 2009 Análisis SOA Silenus Índice 1 Introducción...4 2 Contexto del Proyecto...7 3 Casos de Uso...11 3.1 CU 1: Creación y Modificación de Cuentas...11 3.2 CU 2: Creación de

Más detalles

Sistema de gestión de procesos institucionales y documental.

Sistema de gestión de procesos institucionales y documental. [Documento versión 1.7 del 10/10/2015] Sistema de gestión de procesos institucionales y documental. El sistema de gestión de procesos institucionales y documental, es una solución diseñada para mejorar

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Proyecto de curso. Durante el curso de análisis y diseño 1, los estudiantes desarrollaron sus habilidades de abstracción y visión sistemática.

Proyecto de curso. Durante el curso de análisis y diseño 1, los estudiantes desarrollaron sus habilidades de abstracción y visión sistemática. Universidad de San Carlos Facultad de Ingeniería Ingeniería en Ciencias y Sistemas Análisis y Diseño de Sistemas 2 Proyecto de curso Durante el curso de análisis y diseño 1, los estudiantes desarrollaron

Más detalles

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect IT Insight podcast Este podcast pertenece a la serie IT Insight Pueden suscribirse al podcast a través de itunes. El material

Más detalles

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 El problema: las aplicaciones tradicionales no le proveen la agilidad necesaria

Más detalles

Proyecto Help Desk en plataforma SOA Glosario Versión 1.3. Historia de revisiones

Proyecto Help Desk en plataforma SOA Glosario Versión 1.3. Historia de revisiones Proyecto Help Desk en plataforma SOA Glosario Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 18/08/2005 1.0 Terminología a utilizar en este proyecto. 22/08/2005 1.1 Se agregaron los

Más detalles

Capítulo II. Arquitectura del Software

Capítulo II. Arquitectura del Software Capítulo II. Arquitectura del Software Después de un cuidadoso análisis de los objetivos del proyecto, se determinó que la mejor manera de estructurar el sistema era haciendo uso del muy famoso patrón

Más detalles

Oracle Application Server 10g

Oracle Application Server 10g Oracle Application Server Oracle Application Server 10g La plataforma de aplicaciones más completa e integrada del mercado Puntos a comparar Lo más importante antes de realizar un análisis comparativo

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

Indizen Labs imade. Marco de Desarrollo Aplicaciones de Indizen

Indizen Labs imade. Marco de Desarrollo Aplicaciones de Indizen Indizen Labs imade Marco de Desarrollo Aplicaciones de Indizen Índice de contenidos Indizen Labs Introducción a imade Metodología imade Arquitectura imade Herramientas imade Indizen Labs Indizen Labs Son

Más detalles

Curriculum Vitae I. DATOS PERSONALES FORMACION ACTUAL. Estudios en Curso

Curriculum Vitae I. DATOS PERSONALES FORMACION ACTUAL. Estudios en Curso I. DATOS PERSONALES Curriculum Vitae Nombre y apellido: Mariano Patricio Tugnarelli Documento: DNI 27.811.847 Fecha de nacimiento: 22 de abril de 1980 Domicilio: Mansilla 2902 4ºA, Ciudad Autónoma de Buenos

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

Web Services. Richard Rossel rrossel@inf.utfsm.cl. 23 de noviembre de 2004. Web Services

Web Services. Richard Rossel rrossel@inf.utfsm.cl. 23 de noviembre de 2004. Web Services Richard Rossel rrossel@inf.utfsm.cl 23 de noviembre de 2004 JAVA2 TOC s JAVA2 JAVA2 Definición Aplicaciones Autocontenidas y Modulares Basado en estándares (XML,HTTP) Aplicaciones se anuncian por la red

Más detalles

Tema 5. Plataforma Java EE

Tema 5. Plataforma Java EE Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs enero 2009 FJRP, FMBR 2008/09 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

Más detalles

Proyecto Piloto. Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE

Proyecto Piloto. Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE Proyecto Piloto Integración de Ventanillas Únicas de Comercio Exterior dela RED VUCE Contenido Punto de Partida Objetivos Solución Propuesta Como Trabajaremos Calendario de Alto Nivel Siguientes Pasos

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

Mensajes Electrónicos

Mensajes Electrónicos Mensajes Electrónicos Mensajería Electrónica [HL7 V3] Parte 1 Conceptos Generales Autor: Mario Enrique Cortés M. datasalud IT Ltda Colombia mario.cortes@datasalud.net Las necesidades Los principales desafíos

Más detalles

Experiencias en proyectos de conectividad en Uruguay

Experiencias en proyectos de conectividad en Uruguay Experiencias en proyectos de conectividad en Uruguay SUEIIDISS 2009 Montevideo, Uruguay Javier Preciozzi (SUAT) Juan Andrés Ghigliazza (FNR) Carlos Curbelo (Grupo SEMM) Gerardo Gómez (Grupo SEMM) Gustavo

Más detalles

Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1. Gerardo Lecaros Felipe Díaz

Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1. Gerardo Lecaros Felipe Díaz Proyecto ELO-330 Administración Salas del Departamento de Electrónica RC1 Gerardo Lecaros Felipe Díaz Problemática Petición de salas de forma tradicional Solución J2EE Java 2 Platform, Enterprise Edition

Más detalles

JavaEE. www.javasoft.com

JavaEE. www.javasoft.com JavaEE Java Enterprise Edition www.javasoft.com Por qué Java en el servidor? Ventajas Independencia de la plataforma portabilidad Gran conjunto de APIs Reusabilidad y modularidad Seguro en la ejecución

Más detalles

Grails: Desarrollo ágil de aplicaciones

Grails: Desarrollo ágil de aplicaciones Grails: Desarrollo ágil de aplicaciones Contenido Información general... 2 Requerimientos... 2 Grails Framework... 2 Objetivos del curso... 3 A quién está dirigido... 3 Conocimientos previos recomendados...

Más detalles

JBoss Enterprise Middleware. Gustavo N Yasue IT Architect Latinoamérica Red Hat Latinoamérica gyasue@redhat.com

JBoss Enterprise Middleware. Gustavo N Yasue IT Architect Latinoamérica Red Hat Latinoamérica gyasue@redhat.com JBoss Enterprise Middleware Gustavo N Yasue IT Architect Latinoamérica Red Hat Latinoamérica gyasue@redhat.com UN FUTURO TAN ABIERTO COMO SEA POSIBLE CODIGO ABIERTO ESTANDARES ABIERTOS CONTENIDO ABIERTO

Más detalles

Interoperabilidad y Estándares de HCE

Interoperabilidad y Estándares de HCE Interoperabilidad y Estándares de HCE Montserrat Robles Viejo Directora del Grupo de Informá:ca Biomédica (Ibime). Ins:tuto ITACA Universidad Politécnica de Valencia Interoperabilidad y Estándares de HCE

Más detalles

Proyecto de integración de sistemas de información sanitaria mediante un motor de integración y el estándar HL7

Proyecto de integración de sistemas de información sanitaria mediante un motor de integración y el estándar HL7 Proyecto de integración de sistemas de información sanitaria mediante un motor de integración y el estándar HL7 S. Ramis Oliver, P. M. Hurtado Garí, F. Tous Llull, P. Ferriol Montserrat Fundació IBIT,

Más detalles

Proyecto Help Desk en plataforma SOA Glosario Versión 1.0. Historia de revisiones

Proyecto Help Desk en plataforma SOA Glosario Versión 1.0. Historia de revisiones Proyecto Help Desk en plataforma SOA Glosario Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 18/08/2005 1.0 Terminología a utilizar en este proyecto. Javier Oliva Hugo Cepeda Francy

Más detalles

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2

TABLA DE CONTENIDO 1. REQUERIMIENTOS NO FUNCIONALES... 2 TABLA DE CONTENIDO Pág. 1. REQUERIMIENTOS NO FUNCIONALES... 2 1.1 ATRIBUTOS DE CALIDAD DEL SISTEMA... 2 1.2 OTROS REQUERIMIENTOS NO FUNCIONALES... 4 1.3 REQUERIMIENTOS NO FUNCIONALES PARA HERRAMIENTAS

Más detalles

INTEGRACIÓN DE IMÁGENES ELECTROCARDIOGRÁFICAS EN EL SERVICIO DE SALUD DE LAS ISLAS BALEARES

INTEGRACIÓN DE IMÁGENES ELECTROCARDIOGRÁFICAS EN EL SERVICIO DE SALUD DE LAS ISLAS BALEARES INTEGRACIÓN DE IMÁGENES ELECTROCARDIOGRÁFICAS EN EL SERVICIO DE SALUD DE LAS ISLAS BALEARES J. AMER 1, D. BOERNER 1, J. CAMPINS 1, D. GÁNDARA 1, E. GARCÍA 1, L. LAPRESA 2, S. RAMIS 3 1 Fundació IBIT, Palma

Más detalles

Curso de Android con Java

Curso de Android con Java Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 1 Este es un tiempo único para el mundo de los celulares, en particular de los Smartphones. Este tipo de dispositivos

Más detalles

Herramienta de Gestión Integral de E-Business

Herramienta de Gestión Integral de E-Business Herramienta de Gestión Integral de E-Business Ingeniería técnica de informática de sistemas Autor: David López Martín Tutor: Antoni Oller Arcas Índice Introducción Metodología Análisis Diseño Planificación

Más detalles

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web Servicio Web Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones

Más detalles

BOLETÍN DE NOVEDADES Barcelona, Julio de 2011

BOLETÍN DE NOVEDADES Barcelona, Julio de 2011 BOLETÍN DE NOVEDADES Barcelona, Julio de 2011 Introducción El objeto de este documento es presentar y describir brevemente actuaciones realizadas en los últimos meses por Carver en algunos de sus clientes,

Más detalles

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria 2007

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria 2007 Arquitectura de Aplicaciones Empresariales 2007 TEMARIO Introducción Aplicaciones Empresariales Introducción a la Arquitectura de Aplicaciones empresariales Layering Patrones Arquitecturas Empresariales

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

La reutilización de software en Grails Framework

La reutilización de software en Grails Framework La reutilización de software en Grails Framework Sistemas de Información Cornejo, V. E., Cázarez, P. C. A. ecornejo@uaeh.edu.mx, shadowangel_1109@hotmail.com Universidad Autónoma del Estado de Hidalgo,

Más detalles

Qué ofrece Autentia Real Business Solutions S.L?

Qué ofrece Autentia Real Business Solutions S.L? Avenida de Castilla,1 - Edificio Best Point - Oficina 21B 28830 San Fernando de Henares (Madrid) tel./fax: +34 91 675 33 06 info@autentia.com - www.autentia.com Qué ofrece Autentia Real Business Solutions

Más detalles

Implantación Plataforma SOA. La experiencia del Principado de Asturias

Implantación Plataforma SOA. La experiencia del Principado de Asturias Implantación Plataforma SOA La experiencia del Principado de Asturias I. Situación inicial II. Necesidades III. Búsqueda de soluciones IV. Solución seleccionada V. Implantación I. Situación inicial La

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

XDS LA SOLUCIÓN DE IHE PARA

XDS LA SOLUCIÓN DE IHE PARA XDS LA SOLUCIÓN DE IHE PARA COMPARTIR HISTORIA CLÍNICA Carlos Gallego Coordinador Proyectos Dirección Sistemas Información Asepeyo cgallego@asepeyo.es www.ihe-e.org/ Cross-Enterprise Intra-Enterprise IHE

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Características de OpenCms

Características de OpenCms Características de OpenCms Se basa en Java y Xml OpenCms está totalmente desarrollado en java bajo el estándar servlet. Por lo tanto, se puede integrar fácilmente en entornos hardware y software existentes,

Más detalles

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

Tecnologías Grid Estándares grid

Tecnologías Grid Estándares grid Tecnologías Grid Estándares grid Master en Sistemas y Servicios Informáticos para Internet Universidad de Oviedo Estándares grid Introducción Introducción Justificación El grid se construye a base de diversos

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Desarrollo Web con Grails Framework

Desarrollo Web con Grails Framework Desarrollo Web con Grails Framework Sistemas de Información García Granados Alejandro, Cornejo Velázquez Eduardo sat_vai_mal_1261@hotmail.com, ecornejo@uaeh.edu.mx Universidad Autónoma del Estado de Hidalgo,

Más detalles

Marco Normativo de IT

Marco Normativo de IT Marco Normativo de IT ES0101 Estándar de Arquitectura para los Sistemas de Información e Infraestructura del Data Center Agencia de Sistemas de Información Gobierno de la Ciudad Autónoma de Buenos Aires

Más detalles

Experiencias con J2EE

Experiencias con J2EE Experiencias con J2EE Carlos Luna García Project Manager J2EE carlos.luna@sistel.es Presentación corporativa (1)! Presentación de la compañía.» Sistel es una compañía de integración y desarrollo de sistemas

Más detalles

Marco nacional de interoperabilidad basado en HL7 CDA-ISO27932

Marco nacional de interoperabilidad basado en HL7 CDA-ISO27932 JORNADA INTERNACIONAL INTEGRACIÓN DE LOS SISTEMAS DE INFORMACIÓN DE SALUD E HISTORIA CLÍNICA ELECTRÓNICA Marco nacional de interoperabilidad basado en HL7 CDA-ISO27932 Arquitectura de repositorios DACS

Más detalles

UNIDAD I INTRODUCCIÓN M.S.C AGUSTIN JAIME NUÑEZ RODRIGUEZ

UNIDAD I INTRODUCCIÓN M.S.C AGUSTIN JAIME NUÑEZ RODRIGUEZ UNIDAD I INTRODUCCIÓN M.S.C AGUSTIN JAIME NUÑEZ RODRIGUEZ El programa base fundamental de todos los programas de sistema, es el Sistema Operativo, que controla todos los recursos de la computadora y proporciona

Más detalles

Tema 5. Plataforma Java EE

Tema 5. Plataforma Java EE Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs septiembre 2011 FJRP, FMBR 2008-2011 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD

MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD Francisco Tous Llull, Antoni Reus Darder, Felip Salas Suau Fundació Illes Balears per la Innovació Tecnològica (IBIT) Parc

Más detalles

Elección de tecnología para la capa de presentación de SOA. Huibert Aalbers Senior Certified Software IT Architect

Elección de tecnología para la capa de presentación de SOA. Huibert Aalbers Senior Certified Software IT Architect Elección de tecnología para la capa de presentación de SOA Huibert Aalbers Senior Certified Software IT Architect IT Insight podcast Este podcast pertenece a la serie IT Insight Pueden suscribirse al podcast

Más detalles

Tema 3. 3.3 Tecnologías de Desarrollo

Tema 3. 3.3 Tecnologías de Desarrollo Tema 3 3.3 Tecnologías de Desarrollo HTML pronto pasa a ser insuficiente para todas las posibilidades de la Red No se puede interactuar con el servidor Aparecen los primeros scripts para propocionar dichar

Más detalles

Introducción CAPÍTULO 1

Introducción CAPÍTULO 1 Introducción CAPÍTULO 1 6 CAPÍTULO 1 - Introducción. En la actualidad hay una gran cantidad de repositorios en los que se puede alojar código fuente para poder compartirlo con los usuarios que visiten

Más detalles

Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS

Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio Parte 1 del kit completo de herramientas del comprador

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

Más detalles

PATRON:DAO LENGUAJE DE PROGRAMACION: JAVA IDE: ECLIPSE FRAMEWORK: STRUST2. -Permite Abstraer y Encapsular los accesos a un repositorio de datos.

PATRON:DAO LENGUAJE DE PROGRAMACION: JAVA IDE: ECLIPSE FRAMEWORK: STRUST2. -Permite Abstraer y Encapsular los accesos a un repositorio de datos. PATRON:DAO DAO -Permite Abstraer y Encapsular los accesos a un repositorio de datos. -Separa el acceso de datos de la lógica de negocio. -Oculta el Api por donde se accede a los datos. -Controla los accesos

Más detalles

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web.

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web. Microsoft Office SharePoint Server 2007 es un conjunto integrado de características de servidor que puede contribuir a mejorar la eficacia organizativa al ofrecer completas funciones de administración

Más detalles

Servicios Web con Java EE

Servicios Web con Java EE Servicios Web con Java EE Daniel López Fuentes Laura Tolsada Bris Sergio Tejero López Irene Clemente Bueno Departamento de Ingeniería Telemática Universidad Carlos III de Madrid 2 Introducción Un servicio

Más detalles

Servicios Web con Java EE

Servicios Web con Java EE Introducción Servicios Web con Java EE Daniel López Fuentes Laura Tolsada Bris Sergio Tejero López Irene Clemente Bueno Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

Contexto Internacional de la estandarización e interoperabilidad en salud. Arquitectura. Componentes y modelo de madurez de un ecosistema de esalud.

Contexto Internacional de la estandarización e interoperabilidad en salud. Arquitectura. Componentes y modelo de madurez de un ecosistema de esalud. Contexto Internacional de la estandarización e interoperabilidad en salud Componentes y modelo de madurez de un ecosistema de esalud. Nov 21, 2013, Bogotá Colombia Empresarial MOTIVACION (Porque) TIEMPO

Más detalles

CMS, Repositorios y Gestores de Portales.

CMS, Repositorios y Gestores de Portales. CMS, Repositorios y Gestores de Portales. En el mundo de la programación estamos acostumbrados a que la mayoría de los avances que se realizan vayan orientados a simplificar el desarrollo de proyectos.

Más detalles

Introducción a la herramienta para administración de información de especies y especímenes: Ara. María Mora, INBio. Costa Rica mmora@inbio.ac.

Introducción a la herramienta para administración de información de especies y especímenes: Ara. María Mora, INBio. Costa Rica mmora@inbio.ac. Introducción a la herramienta para administración de información de especies y especímenes: Ara María Mora, INBio. Costa Rica mmora@inbio.ac.cr Temario Objetivo del sistema Mecanismos de implementación

Más detalles

Requisitos técnicos para la instalación. Arquitectura Hardware Arquitectura Software. Instrucciones de instalación GONG-R

Requisitos técnicos para la instalación. Arquitectura Hardware Arquitectura Software. Instrucciones de instalación GONG-R v 3 Junio 2015 ÍNDICE Introducción Requisitos técnicos para la instalación Arquitectura Hardware Arquitectura Software Instrucciones de instalación Instalación módulo GONG2 Instalación módulo eporte Instrucciones

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

Framework ATLAS. Entorno de Desarrollo

Framework ATLAS. Entorno de Desarrollo Framework ATLAS Entorno de Desarrollo Febrero de 2011 Unidad de Arquitectura y Soporte de Aplicaciones Área de Aplicaciones Especiales y Arquitectura de Software DIAS Índice Introducción Visión general

Más detalles