Arquitectura Orientada a Servicios para Sistemas que utilizan HL7

Pablo Pazos Gutierrez - Samanta de Barros

Taller de Sistemas de Informacin 3, Instituto de Computacin Facultad de Ingeniera, Universidad de la Repblica

RESUMEN
Actualmente, la interoperabilidad entre instituciones de salud es importante no slo en Uruguay, sino en todo el mundo. Para esto se han desarrollado distintos estndares ANSI y CEN orientados al sector de la salud, como HL7, EN13606 y OpenEHR. Especficamente, en Uruguay, se ha tomado como estndar a seguir HL7, en lo que tiene que ver con interoperabilidades de sistemas de informacin clnica a partir de la creacin 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 especfico, en particular el alta de pacientes del perfil PIX de la IHE, evaluando la utilizacin de middlewares avanzados tales como ESBs en la arquitectura planteada.

INTRODUCCIN
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 informacin. La IHE define una serie de perfiles que son aplicaciones especficas de los estndares HL7 a reas comunes a cualquier sistema EPR/EHR/CPR, restringiendo as las opciones de uso que permiten los estndares, simplificando el uso de los mismos y la implementacin de sistemas orientados a estndares en las reas abarcadas por los perfiles, como ser cardiologa, radiologa, oftalmologa, 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 bsicamente un MPI como repositorio de identificadores de pacientes de los distintos dominios, donde cada dominio podra manejar un identificador local distinto al de los dems dominios para el mismo paciente. Un dominio podra ser una organizacin o un conjunto de organizaciones prestadoras de servicios de salud.

Figura 1. Diagrama del perfil PIX + PDQ

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 Clnica Electrnica) EN13606: Estndar ISO/CEN para transferencia de EHRs mediante interoperabilidad semntica. OpenEHR: Estndar de EHR basado en modelo dual, compatible con EN13606.

PIX para implementar un MPI:

Principales problemas a resolver: Identificacin nica de pacientes dentro del sistema, un sistema complejo, distribuido entre varias organizaciones (centros clnicos, mutualistas, clnicas particulares, etc). Conectividad estandarizada: acceso remoto a servicios e informacin de forma consistente.

Un MPI permite que diversas organizaciones puedan registrar informacin de sus pacientes en un repositorio central compartido. Ducha informacin est compuesta tanto de identificadores de pacientes en cada organizacin, como de informacin demogrfica til para un algoritmo que pueda verificar a que paciente corresponde cierta informacin dada. Como muchas veces la informacin puede estar incompleta o ser incorrecta, por ejemplo si se escribi mal un apellido, el algoritmo de verificacin de identidad debe ser lo suficientemente inteligente para detectar esos casos y comportarse de forma robusta, por ejemplo basndose 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 informacin de pacientes. Adems 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 informacin demogrfica originada en otros dominios. Por lo tanto, la bsqueda 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 implementarn las funcionalidades necesarias: Agregar pacientes al MPI. Modificar informacin de pacientes en el MPI. Notificar a otros participantes de eventos en el MPI. Resolver duplicados de informacin (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 informacin de los participantes del sistema, de los ndices de pacientes para cada organizacin participante del sistema y la informacin demogrfica 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 sincronizacin de datos entre sistemas distribuidos entre organizaciones, porque no es necesario resolver la comunicacin de N sistemas heterogneos entre si, solo es necesario resolver la comunicacin de cada sistema con el repositorio central. 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 algn sentido, esta lgica reside en un nico lugar, no es necesario hacer modificaciones en cada uno de os sistemas de cada participante. Disminucin 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.

2.

3.

Algunas consideraciones de implementacin de un MPI Comunicacin

Si bien PIX presenta comunicacin mediante mensajera HL7, las transacciones definidas por la IHE son genricas, por lo que se podra abstraer del sistema particular de mensajera y ver solo las transacciones y la informacin que debe comunicarse. En este sentido, y pensando en una arquitectura orientada a servicios, sera interesantes de estudiar la implementacin de las transacciones mediante mensajera a medida o mensajera definida por estndares transmisin de informacin clnica y demografica aparte de HL7. Por ejemplo, se podra estudiar la compatibilidad del estndar EN13606 o de OpenEHR con la mensajera HL7 utilizada en los perfiles IHE, donde tanto EN13606 como OpenEHR definen interoperabilidad semtica a nivel de conceptos, separando lo que es conocimiento de lo que es informacin, mientras que HL7 define una interoperabilidad funcional mediante mensajes que puedan se comprendidos por humanos. Una motivacin para realizar este anlisis es que tanto el estndar 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 semntica en dos niveles:

Figura 2. Modelo de referencia (informacin) vs Modelo de arquetipos (conocimiento)

Escalabilidad
Un MPI no tiene por que ser un elemento nico en el sistema, ms bien debera tener la forma de un conjunto de componentes distribudos 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 podra crear un sistema de MPI que sea un composite, en el sentido de patrones de diseo, de dos o ms 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 transaccin, impidiendo que solo se accedan a recursos o servicios del sistema si se cuentan con las autorizaciones respectivas. Adems cada transaccin debera proveer un nivel de atomicidad transaccional, para que los sistemas queden consistentes internamente luego de ejecutada una transaccin. Una caracterstica particularmente til sera la de llevar registros de cada transaccin realizada, que transaccin, quien la hizo, cuando, ocurri algn problema?, Cul era el estado del sistema al llevarse a cavo la transaccin?, etc., de forma de poder auditar el sistema en caso de detectarse algn problema.

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 informacin del paciente por un dominio. Patient Registry Duplicates Resolved: Resolver suplicados de informacin 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 informacin til para entender el perfil no hay que olvidar que es un draft de implementacin, para probar si lo ah definido alcanza o no para implementar un MPI. Por esta razn dicho documento no fue tomado como nica fuente de informacin, si no que tambin basamos el estudio en la documentacin provista por HL7 sobre las respectivas transacciones, actores y mensajes. Segn su sitio web, la IHE tiene estimado sacar una versin estable del documento en agosto de 2008. En este proyecto en particular, se fij el alcance en la implementacin de la transaccin Patient Registry Record Added, en donde se da de alta un nuevo identificador e informacin de un paciente, para un dominio especfico, en el PIX Manager.

Figura 3. Transacciones del perfil PIX

Segn lo definido en el perfil PIX, a cada transaccin le corresponde un mensaje HL7. Cada uno de estos mensajes contiene tres partes importantes: 1. La parte principal, la cual contiene la informacin que se quiere transmitir, en el caso de Patient Registry Record Added es informacin demogrfica de pacientes, como ser identificadores del paciente, fecha de nacimiento, nombre, donde vive, de qu pas es ciudadano, que idioma habla, etc, esta parte es la parte interna del mensaje en la estructura RIM. Una segunda parte es la que contiene informacin del evento, cuando pas, quien lo hizo, etc. Esa sera la parte intermedia del mensaje y contiene la informacin antes mencionada. Por ltimo, la parte externa del mensaje, o que sera el mensaje en s, que tiene informacin de fechas de envo, quien lo enva, para quien es el mensaje, etc. Esta parte contiene a las partes mencionadas antes, y es lo que se denomina payload. PIX define tambin un mensaje de acknowledge para cada mensaje enviado, el cual contiene informacin del envo, informacin del resultado del envo y el mensaje enviado anteriormente, que es del cual se hace ack.

2.

3.

SOLUCIN PROPUESTA Arquitectura

La arquitectura del sistema propuesto consiste en dos grandes componentes, el PID y el PIX Manager, los cuales intercambian mensajes HL7 a travs 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 clnicos de dichos pacientes entre PIDs. El PIX Manager acta como MPI resolviendo referencias cruzadas de identificadores y siendo capaz de procesar consultas desde los PIDs. El perfil para intercambio de documentos clnicos 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. 2. 3. GUI: provee una interfaz para que el usuario ingrese datos de pacientes al sistema. Persistencia: provee una solucin de persistencia local para la informacin ingresada desde la GUI. Lgica: contiene los tres grandes componentes que permiten la realizacin 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 envo de datos mediante el ESB al PIX Manager. b. Generacin de mensajes: este componente recibe la informacin del paciente, ingresada desde la GUI, y genera un mensaje HL7 vlido que corresponde a la interaccin Patient Registry Record Added. c. Comunicacin: provee el punto de salida del PID hacia el PIX Manager.

El PIX Manager a su vez presenta estas tres capas: 1. 2. 3. Comunicacin: interfaz de servicios que provee un punto de entrada para la recepcin de los mensajes de las transacciones definidas por PIX. Persistencia: define donde guardar la informacin que posteriormente se utilizar para resolver referencias cruzadas. Lgica: contiene los componentes que permiten la realizacin del caso de uso. a. Desconversor de mensajes: este componente recibe los mensajes HL7 enviados y provee una interfaz para acceder a la informacin contenida en los mismos. b. Flujo: maneja el flow de acciones ante la recepcin de mensajes. c. Componente de resolucin de identificadores de pacientes cruzados.

DSS: interaccin con el sistema y envo de mensajes

Figura 5. DSS GUI-ESB

Figura 6. DSS ESB-PIX Manager

Tecnologas
En esta seccin se detalla las tecnologas que se investigaron para la realizacin del proyecto, definiendo los motivos que llevaron a la seleccin de algunas de estas para la implementacin del caso de estudio.

JavaSIG
JavaSIG es la librera que se eligi en primera instancia para implementar los mensajes porque, previa investigacin, es la que mejor se adapta a las necesidades particulares de este proyecto. JavaSIG es una implementacin Open Source de las clases del RIM HL7 utilizando tecnologa Java. Cuenta con funcionalidades para la generacin 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 utilizacin de esta librera, luego de lograr la generacin de un mensaje correspondiente al CMET 201301, que es parte del mensaje definido para la transaccin Patient Registry Record Added, de forma exitosa. Por este motivo, no se lleg a investigar la otra posible tecnologa, planteada en un principio, para la generacin de mensajes, el Open Healthcare Framework (OHF).

Grails
Framework Open Source orientado a un proceso de desarrollo gil. Lleva el paradigma de codificacin por convencin al lenguaje Groovy y est orientado al desarrollo de aplicaciones web 2.0. Est basado en frameworks y tecnologas 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, adems de tener otras caractersticas tiles como ser scaffolding dinmico, taglibs simplificadas (muy simple en comparacin al desarrollo de taglibs para jsp) e integracin de herramientas de testing y logging. Posee integracin con distintos IDEs, en particular con Eclipse, el IDE utilizado en este proyecto. GRAILS posee una curva de aprendizaje bastante rpida por ser muy intuitivo y simple, garantiza una productividad alta, por lo que es una excelente opcin para proyectos con plazos muy cortos como este, o para prototipacin de sistemas grandes. GRAILS tiene una arquitectura orientada a plugins y posee varios plugins muy tiles de los que utilizamos un par mencionados abajo. Adems GRAILS es un proyecto libre y de cdigo abierto, y su licencia permite desarrollar tanto proyectos libres como proyectos comerciales, y cuenta con una comunidad muy activa.

Groovy
El lenguaje dinmico de Java. Groovy presenta una extensin dinmica al lenguaje Java, disponiendo de todas las funcionalidades de la Java API ms nuevos constructores y funcionalidades, como por ejemplo las clausuras (una construccin de programacin funcional). Adems 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 fundacin Apache y que cumple con el especificacin JSR 208 para JBI. El mismo cuenta con un Normalized Message Router (NMR), como es requerido por la especificacin 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 slo 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 travs de SOAP, http, ftp, jms, mail, entre otros. Entre las ventajas de utilizar ServiceMix se encuentra la facilidad que provee, a travs de arquetipos Maven, para generar nuevas configuraciones de sus componentes, que permiten exponer distintos tipos de servicios. Adems cuenta con gran cantidad de ejemplos de utilizacin de dichos componentes, y documentacin detallada sobre la arquitectura del sistema. Entre las desventajas se encuentra la poca integracin con IDEs que provee. Se encontraron distintos plugins de Eclipse que ofrecan cierto tipo de ayuda en la tarea de implementacin, uno de estos, el CIMERO permita definir servicios compuestos por el routing y filtrado de mensajes a travs de diversos componentes, pero no se obtuvieron buenos resultados con el mismo. Otro de los plugins, en realidad permita la integracin 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 utilizacin de la lnea de comandos para esto. A pesar de la variedad de posibilidades ofrecidas por el ServiceMix, se opt por la utilizacin de otro ESB en este proyecto, por motivos que se detallan ms adelante.

Mirth
Mirth es un ESB Open Source independiente de la plataforma, orientado a la transmisin de mensajes HL7. La transmisin se realiza a travs de canales definidos mediante una interfaz grfica. Estos canales estn 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 grfica 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 Tambin es posible definir nuevos filtros mediante scripts, o incluso cdigo 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, segn algn atributo especfico. Los transformadores se utilizan para extraer informacin del mensaje, luego de que este es convertido a XML. Es posible definir transformadores personalizados, tambin a travs de la interfaz grfica. El Mirth ofrece la posibilidad de crear no solo canales simples (un conector de entrada, y uno de salida), sino canales con mltiples conectores de salida, de forma de realizar un broadcast de la informacin 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. Tambin es posible lograr enrutamientos y transformaciones ms complejas, uniendo conectores internos al Mirth, es decir, definiendo un conector de salida que enve el mensaje a uno de los conectores de entrada definidos.

Figura 8. Arquitectura de un canal Mirth

Para la realizacin de este proyecto se opt por el Mirth como ESB debido a la simplicidad ofrecida para integrar el mismo a la aplicacin, ya que es posible definir los canales de comunicacin a travs de la interfaz, y tambin monitorear los mensajes enviados y posibles errores. Adems, permite definir fcilmente reglas de validacin y filtrado de mensajes segn 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 produccin poda verse favorecido con la existencia de un ESB para canalizar las comunicaciones. Una primer aplicacin podra ser el loging de las transacciones, o sea un registro de los mensajes que se envan 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 comunicacin. Luego se podra proveer a travs del mismo ESB y servicio de consultas de logs al que todos los componentes registrados para envo y recepcin de mensajes puedan acceder. Otra aplicacin interesante es la del reenvo 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 deteccin de fallas de comunicacin y el intento de reenvo son funcionalidades bsicas de un sistema de informacin y comunicacin de estas caractersticas (orientado al rea de salud), por lo tanto se podra utilizar la infraestructura existente en el tier que tiene el deploy del ESB para tener una solucin que pueda persistir mensajes y estados de envo, y algn tipo de tarea tipo job que corra en segundo plano y que automticamente, cada cierto tiempo, intente reenviar los mensajes que no se pudieron enviar porque hubo algn tipo de falla. Tambin se podra guardar informacin del tipo de falla y si el mensaje se intenta reenviar ms de cierta cantidad de veces que pare los reintentos y avise al componente que envo el mensaje que el mismo no pudo ser entregado y porqu motivos, en s podra avisar a quien enva o como se coment antes, que quien enva pueda acceder a travs de un servicio al log de envo del mensaje y pueda ver cuales mensajes fueron enviados y cuales no y porque motivo. En el caso el Mirth como ESB, es tambin 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 migracin de una aplicacin que comunica datos sin utilizar el estndar HL7, a una aplicacin que s lo hace, sea fcil y no requiera una modificacin en la estructura de la misma.

OpenLDAP
La utilizacin de LDAP para el registro de informacin de pacientes en el componente PID era uno de los requerimientos del proyecto. Ms especficamente se requiri la utilizacin de OpenLDAP, ya que es una implementacin libre y de cdigo abierto del protocolo, con la cual contaban los clientes. El acceso al servidor LDAP se hace a travs 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 definicin de clases groovy que se mapean con los esquemas de LDAP, y la configuracin del servidor requerido. Las funcionalidades incluyen tanto la persistencia, como la consulta y actualizacin de datos.

Componentes Tecnologa
Las tecnologas utilizadas para la implementacin de los distintos componentes del PID son las siguientes: 1. 2. 3. GUI: Se utiliz el framework GRAILS para generar las vistas mediante una webapp. Persistencia: Se opt por utilizar un plugin de GRAILS para LDAP que permite persistir informacin en un LDAP de forma sencilla. Lgica: contiene los tres grandes componentes que permiten la realizacin del caso de uso. a. Flujo: implementado en Java. b. Generacin de mensajes: se implement un componente de generacin de mensajes orientado a CMETs en Java, el cual depende de la librera JavaSIG. c. Comunicacin: se utiliz el plugin GroovyWS para GRAILS para poder consumir un WebService donde se enva el mensaje generado y del cual se recibe un resultado.

Los componentes del PIX Manager a su vez est implementados utilizando las siguientes tecnologas: 1. 2. 3. Comunicacin: Se hicieron pruebas con el plugin de AXIS2 para GRAILS para exponer el servicio de recepcin de mensajes va SOAP, pero decidimos utilizar REST. Persistencia: En este caso un modelo de dominio de GRAILS fue suficiente para guardar la informacin a un DBMS MySQL. Lgica: contiene los componentes que permiten la realizacin del caso de uso. a. Desconversor de mensajes: componente implementado en Java para obtener la informacin contenida en los mensajes recibidos. b. Flujo: implementado en Java. c. Componente de resolucin de identificadores de pacientes cruzados: implementado en Java.

Mensajera HL7 para transacciones PIX Para la implementacin de la mensajera 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 implementacin de la mensajera. Si bien el perfil PIX define mensajes tanto para ack de mensajes recibidos por el PIX Manager como mensajes de notificacin a otros dominios cuando informacin 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 implementacin ya que la mayora del tiempo del proyecto fue de estudio de las normas (HL7, IHE) y de las tecnologas (LDAP, GRAILS, WS, ESB, MIRTH). Cada transaccin PIX es implementada mediante la comunicacin de un mensaje HL7. Cada mensaje est basado principalmente en tres CMETs, el wrapper del mensaje, el act control y la informacin del paciente (un role based CMET). En el caso de la transaccin Patient Registry Record Added, la que se plante para implementar, los CMETs principales son: Mensaje: 000100 , Control Act: 700701 y Role based payload: 201301, los mismos se ilustran en las siguientes imgenes.

Figura 9. Esquema general de un mensaje y niveles de implementacin.

A continuacin presentamos los diagramas correspondientes a estos CMETs:

El CMET 000100 representa el nodo principal del mensaje generado. Este contiene informacin referente al envo del mensaje, informacin de los actores (quien enva y quien recibe) y de los dispositivos de comunicacin que se usan para enviar el mensaje.

Figura 10. Transmisin Wrapper para los mensajes del CU Patient Identity Feed.

El CMET 700701 es la parte intermedia del mensaje. Su nodo principal se conecta al CMET 000100 a travs de su ControlActProcess. Este CMET contiene informacin del acto y el evento que gener dicho acto. Lo ms importante es la informacin 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.

El CMET 201301 es la parte interna del mensaje, la que contiene la informacin til del paciente para resolver referencias cruzadas en el PIX Manager.

Figura 12. CMET 201301 contiene la informacin del paciente para la interaccin Patient Registry Record Added, del CU Patient Identity Feed.

CONCLUSIONES
En este caso en particular, donde la comunicacin entre un manager y N dominios, con mensajera normalizada, es prcticamente unilateral, lo que hace de PIX un protocolo de comunicacin relativamente simple, no se le encontr mayor utilidad a la integracin de un ESB como middleware en la arquitectura definida. En otros casos, por ejemplo para implementar el perfil XDS, donde la comunicacin es de N a N sistemas entre s, podra ser de utilidad contar con un ESB que se responsabilice de la exposicin de servicios y la comunicacin entre componentes quitndole a cada sistema la complejidad de manejar la comunicacin con otros N sistemas heterogneos. La norma En la generacin de mensajes tuvimos problemas con archivos MIF provistos por HL7, dichos archivos los toma JavaSIG como entrada para poder generar un XML vlido 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 documentacin sobre si las versiones que utilizamos tanto de JavaSIG como de los MIF de HL7 tienen alguna incompatibilidad. La solucin fue modificar los MIFs problemticos en los nodos que daban error.

TRABAJO FUTURO
Se podra 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 ms aplicacin, por haber comunicacin de N a N nodos heterogneos. Mejorar el componente de generacin y desconversin de mensajes HL7 para hacerlo ms genrico y ampliarlo a la generacin de ms tipos de mensajes. Tanto para los mensajes de las distintas transacciones, como para mensajes de documentos clnicos como por ejemplo mensajera HL7 CDA.

Implementar un cliente inteligente de mensajera HL7 que pueda extenderse fcilmente (mediante configuracin y sin tener que re-compilar/re-deployar toda la aplicacin) para recibir nuevos tipos de mensajes, lo que sera de especial inters para organizaciones que provean servicios a travs de mensajera HL7. Ahora el PIX Manager implementado sigue algunos de estos lineamientos pero no es totalmente genrico 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 dems perfiles, se podra investigar con otros estndares de comunicacin de informacin clnica para ver que nivel de compatibilidad tienen con los mensajes HL7 y hacer prototipos de implementacin del perfil con dichos estndares. Por ejemplo con OpenEHR o el estndar EN13606, el cual propone interoperabilidad semtica de informacin clnica 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 http://www.ihe.net/ HL7 http://www.hl7.org/ HL7 Argentina http://hl7.org.ar/ OpenEHR http://www.openehr.org/ Washington University School of Medicine http://erl.wustl.edu/research/rmsi.html Wiki de la SUEIIDISS http://wiki.sueiidiss.org/index.php/Portada What is an Enterprise Master Patient Index http://www.anticlue.net/archives/000331.htm Maintenance of Master Patient Index http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_000071.hcsp?dDocName=b ok1_000071 Mirth Project http://www.mirthproject.org/

2.

3.

4.

5.

6.

7.

8.

9.

10. ESB architecture and life-cicle definition http://www.sonicsoftware.com/products/sonic_esb/architecture_definition/index.ssp 11. ESB alternative @ InfoQ http://www.infoq.com/articles/ESB-alternative 12. Apache ServiceMix http://servicemix.apache.org 13. OpenLDAP http://www.openldap.org 14. The Role of the Enterprise Service Bus (InfoQ - Video Presentation) http://www.infoq.com/presentations/Enterprise-Service-Bus 15. Grupo de informtica biomdica http://www.ibime.upv.es/