Arquitectura Orientada a Servicios para Sistemas qu e 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

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.

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.

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.

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 2008. 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”.

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.

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 201301, 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).

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.

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

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 distribu ido 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.

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: 000100 , Control Act: 700701 y Role based payload: 201301, los mismos se ilustran en las siguientes imágenes.

Figura 9. Esquema general de un mensaje y niveles de implementación.

A continuación presentamos los diagramas correspond ientes a estos CMETs: El CMET 000100 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 700701 es la parte intermedia del mensaje. Su nodo principal se conecta al CMET 000100 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.

El CMET 201301 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 201301 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.

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 http://www.ihe.net/

2. HL7

http://www.hl7.org/

3. HL7 Argentina http://hl7.org.ar/

4. OpenEHR

http://www.openehr.org/

5. Washington University School of Medicine http://erl.wustl.edu/research/rmsi.html

6. Wiki de la SUEIIDISS

http://wiki.sueiidiss.org/index.php/Portada

7. What is an Enterprise Master Patient Index http://www.anticlue.net/archives/000331.htm

8. Maintenance of Master Patient Index

http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_000071.hcsp?dDocName=bok1_000071

9. Mirth Project

http://www.mirthproject.org/

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 informática biomédica http://www.ibime.upv.es/