Arquitectura orientada a servicios para sistemas que utilizan hl7 tsi3

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úblicaRESUMENActualmente, la interoperabilidad entre instituciones de salud es importante no sólo en Uruguay, sino entodo el mundo. Para esto se han desarrollado distintos estándares ANSI y CEN orientados al sector de lasalud, como HL7, EN13606 y OpenEHR. Específicamente, en Uruguay, se ha tomado como estándar aseguir HL7, en lo que tiene que ver con interoperabilidades de sistemas de información clínica a partir dela creación de la SUEIIDISS. El objetivo de este proyecto es evaluar una arquitectura SOA para sistemasque utilizan mensajes HL7. Para cumplir con dicho objetivo se deberá implementar un caso de estudioespecífico, en particular el alta de pacientes del perfil PIX de la IHE, evaluando la utilización demiddlewares avanzados tales como ESBs en la arquitectura planteada.INTRODUCCIÓNLa IHE es una iniciativa de diversos actores de la industria y profesionales del área de salud para mejorarla forma en que los sistemas computarizados en el área de la salud comparten información. La IHE defineuna serie de perfiles que son aplicaciones específicas de los estándares HL7 a áreas comunes acualquier 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 áreasabarcadas 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 siguenpara resolver referencias cruzadas con identificadores de pacientes entre varias organizaciones queutilizan 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 mismopaciente. Un dominio podría ser una organización o un conjunto de organizaciones prestadoras deservicios 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 unrepositorio central compartido. Ducha información está compuesta tanto de identificadores de pacientesen cada organización, como de información demográfica útil para un algoritmo que pueda verificar a quepaciente corresponde cierta información dada. Como muchas veces la información puede estarincompleta o ser incorrecta, por ejemplo si se escribió mal un apellido, el algoritmo de verificación deidentidad debe ser lo suficientemente inteligente para detectar esos casos y comportarse de formarobusta, por ejemplo basándose en algoritmos soudex para encontrar palabras distintas que sonparecidas 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 elrepositorio 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 organizacionesparticipantes en el sistema, por identificadores de pacientes de otras organizaciones participantes oinformación demográfica originada en otros dominios. Por lo tanto, la búsqueda deberá resolverreferencias cruzadas entre pacientes de distintas organizaciones.Opcionalmente se puede proveer la funcionalidad de notificar a las organizaciones participantes del MPIsobre modificaciones en los datos de sus pacientes por otros participantes en el sistema o notificacionesdel agregado de nuevos pacientes al sistema.El perfil PIX de la IHE define un MPI con sus respectivos componentes, casos de uso y transacciones queimplementará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 ytransacciones para que las organizaciones participantes puedan consultar por índices de pacientes yobtengan 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áficade los pacientes, provista por los distintos participantes, para poder ser capaz de resolver duplicados yverificar 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 MPIComunicaciónSi bien PIX presenta comunicación mediante mensajería HL7, las transacciones definidas por la IHEson genéricas, por lo que se podría abstraer del sistema particular de mensajería y ver solo lastransacciones y la información que debe comunicarse. En este sentido, y pensando en unaarquitectura orientada a servicios, sería interesantes de estudiar la implementación de lastransacciones mediante mensajería a medida o mensajería definida por estándares transmisión deinformación clínica y demografica aparte de HL7. Por ejemplo, se podría estudiar la compatibilidaddel estándar EN13606 o de OpenEHR con la mensajería HL7 utilizada en los perfiles IHE, dondetanto EN13606 como OpenEHR definen interoperabilidad semática a nivel de conceptos, separandolo que es conocimiento de lo que es información, mientras que HL7 define una interoperabilidadfuncional mediante mensajes que puedan se comprendidos por humanos. Una motivación pararealizar este análisis es que tanto el estándar EN13606 como OpenEHR son mucho menoscomplejos y voluminosos que HL7, como curiosidad las especificaciones de EN13606 ocupan 6megas 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)EscalabilidadUn MPI no tiene por que ser un elemento único en el sistema, más bien debería tener la forma de unconjunto de componentes distribuídos interconectados, donde cada componente es a la vez sea unMPI para un conjunto menor de organizaciones.En este sentido, pensando en una arquitectura escalable, se podría crear un sistema de MPI que seaun “composite”, en el sentido de patrones de diseño, de dos o más MPIs existentes, y a su vez otrosque puedan “juntar” esos MPIs de forma de poder escalar indefinidamente el sistema y de poderadoptar MPIs parcialmente entre organizaciones, permitiendo agregar nuevas organizaciones ynuevos MPIs al sistema global.SeguridadEl sistema debe proveer seguridad para cada transacción, impidiendo que solo se accedan arecursos o servicios del sistema si se cuentan con las autorizaciones respectivas. Además cadatransacción debería proveer un nivel de atomicidad transaccional, para que los sistemas quedenconsistentes internamente luego de ejecutada una transacción. Una característica particularmente útilserí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., deforma de poder auditar el sistema en caso de detectarse algún problema.

CASO DE ESTUDIOEn el ITI-TF del 15 de agosto de 2007 en el cual se basa el estudio del perfil PIX, se define un caso deuso llamado “Patient Identity Feed HL7v3” dentro de dicho perfil. En el caso de uso antes mencionado sedefinen 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 olvidarque 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énbasamos el estudio en la documentación provista por HL7 sobre las respectivas transacciones, actores ymensajes. Según su sitio web, la IHE tiene estimado sacar una versión estable del documento en agostode 2008.En este proyecto en particular, se fijó el alcance en la implementación de la transacción “Patient RegistryRecord Added”, en donde se da de alta un nuevo identificador e información de un paciente, para undominio específico, en el PIX Manager. Figura 3. Transacciones del perfil PIXSegún lo definido en el perfil PIX, a cada transacción le corresponde un mensaje HL7. Cada uno de estosmensajes 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 PROPUESTAArquitecturaLa arquitectura del sistema propuesto consiste en dos grandes componentes, el PID y el PIX Manager, loscuales intercambian mensajes HL7 a través de un ESB. El objetivo del perfil es poder contar con un MPIentre varios Patient Identification Domains, donde se pueden manejar distintos identificadores para losmismos 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 deprocesar consultas desde los PIDs. El perfil para intercambio de documentos clínicos es XDS y el perfilpara consultas es PDQ. Figura 4. Componentes en detalleEl 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 ManagerTecnologíasEn esta sección se detalla las tecnologías que se investigaron para la realización del proyecto, definiendolos motivos que llevaron a la selección de algunas de estas para la implementación del caso de estudio.JavaSIGJavaSIG es la librería que se eligió en primera instancia para implementar los mensajes porque, previainvestigación, es la que mejor se adapta a las necesidades particulares de este proyecto. JavaSIG es unaimplementación Open Source de las clases del RIM HL7 utilizando tecnología Java. Cuenta confuncionalidades para la generación de mensajes HL7 a partir de estructuras RIM. Para esto utilizaarchivos MIF provistos por la norma, donde se define la estructura de cada mensaje HL7 y contra la quese validan las estructuras RIM generadas. Se definió la utilización de esta librería, luego de lograr lageneración de un mensaje correspondiente al CMET 201301, que es parte del mensaje definido para latransacción Patient Registry Record Added, de forma exitosa. Por este motivo, no se llegó a investigar laotra posible tecnología, planteada en un principio, para la generación de mensajes, el Open HealthcareFramework (OHF).

GrailsFramework Open Source orientado a un proceso de desarrollo ágil. Lleva el paradigma de “codificaciónpor convención” al lenguaje Groovy y está orientado al desarrollo de aplicaciones web 2.0. Está basadoen 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 desistemas web, implementando MVC con ORM, además de tener otras características útiles como serscaffolding dinámico, taglibs simplificadas (muy simple en comparación al desarrollo de taglibs para jsp) eintegración de herramientas de testing y logging. Posee integración con distintos IDEs, en particular conEclipse, el IDE utilizado en este proyecto. GRAILS posee una curva de aprendizaje bastante rápida porser muy intuitivo y simple, garantiza una productividad alta, por lo que es una excelente opción paraproyectos con plazos muy cortos como este, o para prototipación de sistemas grandes. GRAILS tiene unaarquitectura orientada a plugins y posee varios plugins muy útiles de los que utilizamos un parmencionados abajo. Además GRAILS es un proyecto libre y de código abierto, y su licencia permitedesarrollar tanto proyectos libres como proyectos comerciales, y cuenta con una comunidad muy activa.GroovyEl lenguaje dinámico de Java. Groovy presenta una extensión dinámica al lenguaje Java, disponiendo detodas las funcionalidades de la Java API más nuevos constructores y funcionalidades, como por ejemplolas clausuras (una construcción de programación funcional). Además Groovy se compila a bytecode loque no representa un gran problema en la performance.Web ServicesSe utilizó el AXIS2 plugin para GRAILS para exponer web services de forma sencilla en el componentePIX Manager. A su vez, para consumir web services en el componente PID se utilizó GroovyWS.Apache ServiceMixApache ServiceMix es un ESB Open Source desarrollado por la fundación Apache y que cumple con elespecificación JSR 208 para JBI. El mismo cuenta con un Normalized Message Router (NMR), como esrequerido por la especificación JBI. Este es el que se encarga de intercambiar los mensajes normalizadosentre los distintos componentes del ESB, que se conectan a ServiceMix como “plugins”. Estoscomponentes se dividen en dos grandes tipos: Service Engines (SE) y Binding Components (BC). LosService Engines son los componentes que proveen servicios dentro del ESB, y sólo se pueden comunicarcon 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 losservicios 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, entreotros. Entre las ventajas de utilizar ServiceMix se encuentra la facilidad que provee, a través dearquetipos Maven, para generar nuevas configuraciones de sus componentes, que permiten exponerdistintos tipos de servicios. Además cuenta con gran cantidad de ejemplos de utilización de dichoscomponentes, y documentación detallada sobre la arquitectura del sistema.Entre las desventajas se encuentra la poca integración con IDEs que provee. Se encontraron distintosplugins de Eclipse que ofrecían cierto tipo de ayuda en la tarea de implementación, uno de estos, elCIMERO permitía definir servicios compuestos por el routing y filtrado de mensajes a través de diversoscomponentes, pero no se obtuvieron buenos resultados con el mismo. Otro de los plugins, en realidadpermitía la integración de Eclipse con Maven, pero no fue posible configurar el mismo para que utilizaralos arquetipos necesarios para generar componentes ServiceMix, por lo que se optó por la utilización dela línea de comandos para esto. A pesar de la variedad de posibilidades ofrecidas por el ServiceMix, seoptó por la utilización de otro ESB en este proyecto, por motivos que se detallan más adelante.

MirthMirth es un ESB Open Source independiente de la plataforma, orientado a la transmisión de mensajesHL7. La transmisión se realiza a través de canales definidos mediante una interfaz gráfica. Estos canalesestán conectores de entrada y salida, filtros y transformadores. Los conectores actualmente soportadosson: LLP, base de datos, JMS, Webservices SOAP, archivo, PDF, FTP, SFTP. Mediante la interfaz gráficaes posible seleccionar que filtros y transformaciones se le aplican al mensaje entrante antes de enviarlo ala salida. Figura 7. Arquitectura de un canal MirthTambién es posible definir nuevos filtros mediante scripts, o incluso código Java. A su vez, es posibleacceder al contenido del mensaje si se define un template para el mismo. Esto puede ser de muchautilidad si se desean filtrar, por ejemplo, mensajes HL7, según algún atributo específico. Lostransformadores 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ónrecibida, o un ruteo de la misma. El broadcast se realiza enviando el mensaje luego de filtrado ytranformado 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 susfiltros 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 auno 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 paraintegrar el mismo a la aplicación, ya que es posible definir los canales de comunicación a través de lainterfaz, y también monitorear los mensajes enviados y posibles errores. Además, permite definirfácilmente reglas de validación y filtrado de mensajes según datos provenientes en el mismo y definidospor HL7.Posibles aplicaciones de ESB en un sistema distribuidoSi bien para este proyecto particular el uso de ESB no presenta mayores ventajas, el mismo proyecto enun sistema en producción podía verse favorecido con la existencia de un ESB para canalizar lascomunicaciones. Una primer aplicación podría ser el “loging” de las transacciones, o sea un registro de losmensajes que se envían y reciben, para cada componente del sistema y que la responsabilidad demantener dicho log sea en el propio ESB, haciendo un solo repositorio de logs que puede ser consultadopor los diversos componentes sobre los mensajes enviados por ellos o enviados a ellos, de forma tal deno necesitarse implementar esta funcionalidad por cada uno de los componentes que participan en lacomunicación. Luego se podría proveer a través del mismo ESB y servicio de consultas de logs al quetodos 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 cadamensaje enviado es recibido del otro lado en tiempo y forma, y como hay mensajes que deben si o si sertransmitidos correctamente, la detección de fallas de comunicación y el intento de reenvío sonfuncionalidades básicas de un sistema de información y comunicación de estas características (orientadoal área de salud), por lo tanto se podría utilizar la infraestructura existente en el tier que tiene el deploy delESB para tener una solución que pueda persistir mensajes y estados de envío, y algún tipo de tarea tipojob que corra en segundo plano y que automáticamente, cada cierto tiempo, intente reenviar los mensajesque no se pudieron enviar porque hubo algún tipo de falla. También se podría guardar información del tipode falla y si el mensaje se intenta reenviar más de cierta cantidad de veces que pare los reintentos y aviseal componente que envío el mensaje que el mismo no pudo ser entregado y porqué motivos, en sí podríaavisar a quien envía o como se comentó antes, que quien envía pueda acceder a través de un servicio allog 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 quepermiten mapear datos de los mensajes entrantes a variables, que se pueden utilizar para generarmensajes HL7, permitiendo así que la migración de una aplicación que comunica datos sin utilizar elestándar HL7, a una aplicación que sí lo hace, sea fácil y no requiera una modificación en la estructura dela misma.OpenLDAPLa utilización de LDAP para el registro de información de pacientes en el componente PID era uno de losrequerimientos del proyecto. Más específicamente se requirió la utilización de OpenLDAP, ya que es unaimplementació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 elcomponente 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 groovyque se mapean con los esquemas de LDAP, y la configuración del servidor requerido. Las funcionalidadesincluyen tanto la persistencia, como la consulta y actualización de datos.Componentes – TecnologíaLas tecnologías utilizadas para la implementación de los distintos componentes del PID son lassiguientes: 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 PIXPara la implementación de la mensajería HL7 para este proyecto, nos basamos sobre todo en losdiagramas provistos por HL7 en el dominio PRPA y por la IHE en su ITI-TF para la implementación de lamensajería. Si bien el perfil PIX define mensajes tanto para “ack” de mensajes recibidos por el PIXManager como mensajes de notificación a otros dominios cuando información de los pacientes en el PIXManager es agregada o modificada, ninguno de estos mensajes fue implementado por considerarse fueradel alcance y por contar con poco tiempo para implementación ya que la mayoría del tiempo del proyectofue 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 mensajeestá basado principalmente en tres CMETs, el wrapper del mensaje, el act control y la información delpaciente (un “role based” CMET). En el caso de la transacción Patient Registry Record Added, la que seplanteó para implementar, los CMETs principales son: Mensaje: 000100 , Control Act: 700701 y Rolebased 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 correspondientes a estos CMETs:El CMET 000100 representa el nodo principal del mensaje generado. Este contiene información referenteal envío del mensaje, información de los actores (quien envía y quien recibe) y de los dispositivos decomunicació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 através de su ControlActProcess. Este CMET contiene información del acto y el evento que generó dichoacto. 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 FeedOBS: en los mensajes de muestra el “subject” del RegistrationEvent se llama “subject1” y de esta formaestá 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 pararesolver 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.CONCLUSIONESEn este caso en particular, donde la comunicación entre un manager y N dominios, con mensajeríanormalizada, es prácticamente unilateral, lo que hace de PIX un protocolo de comunicación relativamentesimple, no se le encontró mayor utilidad a la integración de un ESB como middleware en la arquitecturadefinida. En otros casos, por ejemplo para implementar el perfil XDS, donde la comunicación es de N a Nsistemas entre sí, podría ser de utilidad contar con un ESB que se responsabilice de la exposición deservicios y la comunicación entre componentes quitándole a cada sistema la complejidad de manejar lacomunicación con otros N sistemas heterogéneos.La normaEn la generación de mensajes tuvimos problemas con archivos MIF provistos por HL7, dichos archivos lostoma JavaSIG como entrada para poder generar un XML válido a partir del RIM generado para elmensaje. Estos problemas pueden deberse a problemas internos de la norma en estos archivos MIF oproblemas 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 lasversiones que utilizamos tanto de JavaSIG como de los MIF de HL7 tienen alguna incompatibilidad. Lasolución fue modificar los MIFs problemáticos en los nodos que daban error.TRABAJO FUTUROSe podría utilizar el conocimiento generado en este proyecto para implementar tanto los perfiles PDQcomo XDS, integrando así los tres perfiles, en donde un ESB tiene mucha más aplicación, por habercomunicació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 yampliarlo a la generación de más tipos de mensajes. Tanto para los mensajes de las distintastransacciones, 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 (medianteconfiguración y sin tener que re-compilar/re-deployar toda la aplicación) para recibir nuevos tipos demensajes, lo que sería de especial interés para organizaciones que provean servicios a través demensajería HL7. Ahora el PIX Manager implementado sigue algunos de estos lineamientos pero no estotalmente genérico y extensible en los mensajes que puede recibir, pero es una buena base para unsistema con estas capacidades.En cuanto al perfil PIX y los demás perfiles, se podría investigar con otros estándares de comunicación deinformación clínica para ver que nivel de compatibilidad tienen con los mensajes HL7 y hacer prototiposde implementación del perfil con dichos estándares. Por ejemplo con OpenEHR o el estándar EN13606, elcual 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=b ok1_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/

http://cgallego.blogspot.com	271
http://cgallego.blogspot.com.es	61
http://10.136.3.34	32
http://cgallego.blogspot.mx	6
http://cgallego.blogspot.com.ar	4
http://cgallego.blogspot.be	3
http://cgallego.blogspot.de	1

Arquitectura orientada a servicios para sistemas que utilizan hl7 tsi3

by Pablo Pazos

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 378

Statistics

Arquitectura orientada a servicios para sistemas que utilizan hl7 tsi3 Document Transcript