Informática Sana: el blog de Caduceus

Solución caso práctico 1.2: múltiples sistemas y la validación de la mensajería HL7

Sin comentarios

En el artículo anterior propusimos un sistema para la validación de la mensajería HL7 en un escenario con múltiples sistemas.

En este artículo desarrollamos con detalle una implementación de una posible solución a este problema.


Este artículo es parte de la serie del Caso Práctico 1.


Puedes repasar el escenario en el primer caso práctico y el problema y la propuesta de solución en el artículo anterior: “Múltiples sistemas y la validación de la mensajería HL7 (I)”.

Como ya adelantamos, implementaremos un canal en Mirth Connect que se comunique con un servicio web de validación de la mensajería y, en función del resultado obtenido, proporcione una respuesta al canal principal para que éste sepa si el mensaje es válido o no. Simularemos el servicio web a través de otro canal de Mirth Connect.

Utilizaremos de nuevo la herramienta 7Edit para editar los mensajes HL7 de ejemplo y simular su envío y recepción por parte de NewModernHIS.

Material y tecnologías utilizados

Al igual que en la solución al caso práctico anterior, para poder seguir mejor el artículo y probar los ejemplos, compartimos todo el material necesario:

Material correspondiente al caso práctico “Múltiples sistemas y la validación de la mensajería HL7”:

  • 1.messages-hl7:
    • 1-alta-adt-a28-ok.hl7: mismo mensaje de alta utilizado en el caso práctico anterior.
    • 1-alta-adt-a28-no-ok.hl7: modificación del mensaje anterior para que no pase la validación.
  • 2.mirth-connect:
    • INFORMATICA_SANA_1_1.xml: exportación del canal principal modificado (para su importación en Mirth Connect).
    • INFORMATICA_SANA_1_2_1.xml: exportación del canal desarrollado para implementar la comunicación con el servicio web de validación de mensajería (para su importación en Mirth Connect).
    • INFORMATICA_SANA_1_2_2.xml: exportación del canal desarrollado para simular el servicio web de validación de mensajería (para su importación en Mirth Connect).
    • code-templates.xml: exportación de las funciones propias utilizadas (para su importación en Mirth Connect).
    • global-scripts.xml: exportación de configuración global utilizada (para su importación en Mirth Connect).
    • config.xml: fichero de configuración propio utilizado.
    • Informática-Sana-1-2-soapui-project.xml: proyecto SoapUI utilizado para probar el servicio web de validación de mensajería.
    • validator.wsdl: fichero WSDL generado por el servicio web de validación de mensajería.
  • 3.out-xml:
    • 1-alta-adt-a28-ok.xml: fichero XML de salida tras probar el alta correcta.

Descargar “Material caso práctico 1.2 - Múltiples sistemas y la validación de la mensajería HL7” material-caso-practico-1.2.zip – Descargado 291 veces – 15 KB

Utilizaremos las siguientes versiones para estándares, tecnologías y herramientas:

Construcción de mensajería de ejemplo con 7Edit

Vamos a generar un mensaje que no pase la validación (1-alta-adt-a28-no-ok.hl7) a partir del mensaje correcto de alta (1-alta-adt-a28-ok.hl7).

Con 7Edit podemos comprobar los posibles valores para el componente MSH-11-1 (‘D’: Debugging, ‘P’: Production, ‘T’: Training) y establecer un valor incorrecto ‘K’. De este modo el mensaje no es válido.

7Edit: Mensaje con 'Processing Id' incorrecta

7Edit: Mensaje con ‘Processing Id’ incorrecta

Simulación del servicio web de validación de mensajería

La creación de un servicio web de validación de mensajería se sale del ámbito de este caso práctico, por tanto lo simularemos mediante un canal de Mirth Connect.

Configuración global

La configuración global es similar a la configuración del canal principal del caso práctico anterior. Para el conector fuente se usa el tipo de dato HL7 v2.x para poder recibir el mensaje HL7 a validar:

Mirth Connect: configuración global del canal para el servicio web de validación de mensajería HL7

Mirth Connect: configuración global del canal para el servicio web de validación de mensajería HL7

Conector Fuente

Para simular el servicio web:

  1. Seleccionamos un conector de tipo Web Service Listener.
  2. Indicamos un nombre para el servicio, por ejemplo InformaticaSanaValidation.
  3. El resto de configuraciones las dejamos por defecto (aunque Mirth Connect permite configurar más aspectos de los servicios web como interfaces, puertos, métodos, argumentos, autenticación, etc.).

Lo que sí hay que configurar es una respuesta propia del servicio web con el resultado de la validación. Esto se debe indicar en la configuración Respond from pero tendremos que hacerlo más adelante, cuando determinemos el valor de custom_ack en el ResponseMap dentro de la configuración del conector destino.

En la configuración se muestra la URL donde estará el WSDL del servicio web SOAP una vez desplegado el canal:

http://localhost:8081/services/InformaticaSanaValidation?wsdl
Mirth Connect: configuración del conector fuente para el servicio web de validación de mensajería HL7

Mirth Connect: configuración del conector fuente para el servicio web de validación de mensajería HL7

Definimos un único transformador para almacenar en el ChannelMap el valor que nos interesa para la validación: el processing_id. Usamos el mismo Inbound Message Template que en el canal del caso práctico anterior:

Mirth Connect: transformador para la validación de mensajería HL7

Mirth Connect: transformador para la validación de mensajería HL7

Conector Destino

Definimos un conector de tipo JavaScript Writer para construir la respuesta del canal en función del valor de nuestro campo de ejemplo processing_id.

Si éste tiene un valor correcto el ACK será positivo (campo MSA-1 con valor ‘AA’), y si tiene un valor incorrecto el ACK será negativo (campo MSA-1 con valor ‘AE’) y contendrá toda la información específica del error en un segmento ERR.

Por último, almacenamos la respuesta custom_ack en el ResponseMap para poder seleccionarla en el conector fuente como vimos anteriormente:

Mirth Connect: conector destino tipo JavaScript Writer para el servicio web de validación de mensajería HL7

Mirth Connect: conector destino tipo JavaScript Writer para el servicio web de validación de mensajería HL7

Pruebas con la herramienta SoapUI

Mediante la herramienta SoapUI se puede probar el servicio web de validación. Veamos cómo hacerlo:

WSDL

Tras desplegar este canal en Mirth Connect, podemos encontrar la definición del servicio web en la URL http://localhost:8081/services/InformaticaSanaValidation?wsdl:

WSDL: definición del servicio web para validación de mensajería HL7

WSDL: definición del servicio web para validación de mensajería HL7

Proyecto en SoapUI

Para probar el servicio web usando SoapUI, podemos crear un proyecto nuevo indicando la ubicación del WSDL (en el material se incluye el fichero validator.wsdl) o podemos importar el proyecto incluido en el material del caso Informática-Sana-1-2-soapui-project.xml.

Si importamos el proyecto de ejemplo, vemos que hay dos peticiones creadas para la operación que crea Mirth Connect por defecto (acceptMessage): una para el mensaje válido y otra para el no válido. Ambas proporcionan el argumento por defecto arg0 para incluir el mensaje HL7 a validar utilizando la nomenclatura CDATA< ![CDATA[message_hl7]]>:

SoapUI: proyecto para probar la validación de mensajería HL7

SoapUI: proyecto para probar la validación de mensajería HL7

Para la petición con el mensaje válido, comprobamos que el servicio web devuelve el valor ‘AA’:

SoapUI: respuesta para mensaje HL7 válido

SoapUI: respuesta para mensaje HL7 válido

Sin embargo, para la petición con el mensaje no válido, comprobamos que el servicio web devuelve el valor ‘AE’ junto con la especificación del error:

SoapUI: respuesta para mensaje HL7 no válido

SoapUI: respuesta para mensaje HL7 no válido

Creación del canal para comunicarse con el servicio web de validación en Mirth Connect

El siguiente paso es implementar la comunicación con el servicio web de validación.

Para ello, se podría definir un nuevo conector destino de tipo Web Service Sender desde el canal principal, pero ésta no es la mejor solución.

De cara a desacoplar y reutilizar esta funcionalidad en más canales, es conveniente configurar un nuevo canal que abstraiga completamente esta comunicación. De esta forma, si se modifica la URL del servicio web de validación, por ejemplo, tan sólo habría que modificar un conector.

Configuración global

La configuración global del canal es similar a la del canal anterior por lo que no entraremos en detalles:

Mirth Connect: configuración del canal para comunicarse con el servicio de validación de mensajes HL7

Mirth Connect: configuración del canal para comunicarse con el servicio de validación de mensajes HL7

Conector Fuente

Para que el canal pueda recibir peticiones desde el canal principal dentro del propio Mirth Connect, tenemos que definir un conector de tipo Channel Reader.

De nuevo, tendremos que definir la respuesta del canal mediante la configuración Respond from, pero tendremos que hacerlo más adelante cuando determinemos el valor de custom_response en el ResponseMap dentro de la configuración de uno de los conectores destino:

Mirth Connect: conector fuente Channel Reader para comunicarse con el servicio de validación de mensajería HL7

Mirth Connect: conector fuente Channel Reader para comunicarse con el servicio de validación de mensajería HL7

Conector Destino 1

Para comunicarnos con el servicio web, ahora sí tenemos que definir un conector de tipo Web Service Sender. Para cargar la mayor parte de la configuración automáticamente podemos especificar la URL del WSDL y darle al botón Get Operations.

Tras esto, debemos darle al botón Generate Envelope para obtener la estructura XML de la petición SOAP para el servicio web, con la única operación definida por defecto acceptMessage.

Al igual que hemos visto en la herramienta SoapUI, simplemente debemos incluir dentro del único argumento arg0 el mensaje HL7 original dentro de un CDATA:

Mirth Connect: conector destino para enviar el mensaje HL7 al servicio web de validación

Mirth Connect: conector destino para enviar el mensaje HL7 al servicio web de validación

Conector Destino 2

En este conector destino tenemos que:

  1. obtener la respuesta del destino anterior,
  2. limpiarla (aunque existen formas más elegantes de hacer esto),
  3. procesarla para obtener la parte que nos interesa
  4. y añadirla a la respuesta del canal para poder seleccionarla en el conector fuente.
Mirth Connect: conector destino para recibir la respuesta de la validación del mensaje HL7

Mirth Connect: conector destino para recibir la respuesta de la validación del mensaje HL7

Modificaciones sobre el canal principal en Mirth Connect

Una vez en este punto, desde el canal principal tenemos que:

  1. interactuar con el canal que realiza la comunicación con el servicio web de validación,
  2. construir nuestro propio ACK en función del resultado
  3. y evitar la generación de los ficheros de salida XML en caso de que el mensaje original no pase la validación.

Y todo lo anterior con la posibilidad de habilitar o deshabilitar la validación a través de una configuración propia. Vamos a ello.

Configuración para la validación de la mensajería

Para poder habilitar y deshabilitar la validación mediante configuración, haremos uso de los Global Scripts y la estructura de datos Global Map, siguiendo una de las recomendaciones de un artículo anterior.

Fichero de configuración propio

Utilizaremos un fichero propio config.xml, incluido en el material del caso práctico, con una única configuración llamada validation, y que puede tomar los valores 1 ó 0 para habilitar o deshabilitar la validación respectivamente:

<config> 
    <validation>1</validation> 
</config>
Global Scripts

Situando el fichero en la ruta C:\tmp\informaticasana\1\1.2, por ejemplo, podemos cargarlo en el Global Map desde los Global Scripts para tener acceso desde cualquier ámbito dentro de la configuración de los canales de Mirth Connect.

Esta carga se realizará cada vez que se despliegue un canal, según el valor Deploy establecido en la configuración Script, por lo que si queremos habilitar o deshabilitar la validación, tendremos que desplegar algún canal:

Mirth Connect: carga de fichero de configuración mediante un Global Script

Mirth Connect: carga de fichero de configuración mediante un Global Script

Code Templates

Siguiendo de nuevo otra de las recomendaciones del mismo artículo anterior, vamos a definir una función para acceder a un valor del GlobalMap para poder utilizarla directamente como valor booleano en los filtros de los conectores. Esta función devuelve true o false en función de si éste toma el valor 1 ó 0 respectivamente:

Mirth Connect: función de acceso a las propiedades del fichero de configuración

Mirth Connect: función de acceso a las propiedades del fichero de configuración

Scripts JS

Debido a que el conector fuente ya tenía una salida de tipo XML, que no podemos cambiar, para realizar el proceso de validación del mensaje original HL7 necesitamos almacenarlo previamente.

Esto lo podemos hacer a través de un Script de tipo Preproccesor haciendo uso de la estructura de datos GlobalChannelMap:

Mirth Connect: almacenado del mensaje HL7 para su validación

Mirth Connect: almacenado del mensaje HL7 para su validación

Transformadores del Conector Fuente

Para construir nuestro propio mensaje ACK, necesitamos previamente almacenar ciertos elementos del mensaje HL7 original, por lo que debemos crear varios transformadores para ello.

Por similitud a algunos de los transformadores ya explicados en el caso práctico anterior, vamos a omitir la explicación detallada de los mismos, y tan sólo presentaremos las capturas de pantalla.

Elemento sending_app:

Mirth Connect: transformador del conector fuente, elemento sending_app

Mirth Connect: transformador del conector fuente, elemento sending_app

Elemento receiving_app:

Mirth Connect: transformador del conector fuente, elemento receiving_app

Mirth Connect: transformador del conector fuente, elemento receiving_app

Elemento processing_id:

Mirth Connect: transformador del conector fuente, elemento receiving_app

Mirth Connect: transformador del conector fuente, elemento receiving_app

Elemento version_id:

Mirth Connect: transformador del conector fuente, elemento version_id

Mirth Connect: transformador del conector fuente, elemento version_id

Finalmente, definimos un transformador para inicializar a ‘AA’ el valor que tendrá el campo MSA-1 de nuestro mensaje ACK.

Si la validación esté activada y el mensaje no la pasa, este valor se modificará a ‘AE’:

Mirth Connect: transformador del conector fuente para inicializar MSA-1

Mirth Connect: transformador del conector fuente para inicializar MSA-1

Conector Destino 1

En los conectores destino lo primero que debemos hacer es comprobar si el mensaje pasa o no la validación, si ésta está activada.

Para ello, definimos un conector de tipo Channel Writer que le pase al canal validador el mensaje HL7 original en Template, y que espere su respuesta indicando Yes en Wait for Channel Response:

Mirth Connect: conector destino Channel Writer para pasar el mensaje HL7 a validar

Mirth Connect: conector destino Channel Writer para pasar el mensaje HL7 a validar

Mediante un filtro, indicamos que el destino tan sólo debe ejecutarse si la validación de la mensajería está habilitada en la configuración:

Mirth Connect: filtro para comprobar la configuración de validación

Mirth Connect: filtro para comprobar la configuración de validación

Asimismo, en un transformador de tipo JavaScript debemos almacenar el mensaje HL7 original en el ChannelMap para tener el valor disponible en el Template de la configuración principal del conector:

Mirt Connect: transformador JavaScript para almacenar el mensaje HL7 original

Mirt Connect: transformador JavaScript para almacenar el mensaje HL7 original

Conector Destino 2

En el siguiente conector, si procede, debemos procesar la respuesta del canal de validación y almacenar en el ChannelMap todo lo necesario para construir el segmento MSA y los segmentos ERR del mensaje ACK:

Mirt Connect: transformador JavaScript para almacenar el mensaje HL7 original

Mirt Connect: transformador JavaScript para almacenar el mensaje HL7 original

De nuevo, este canal sólo debe ejecutarse si la validación de la mensajería está habilitada en la configuración:

Mirth Connect: control de la ejecución del canal según la configuración

Mirth Connect: control de la ejecución del canal según la configuración

Conector Destino 3

En este punto, ya tenemos todo lo necesario para construir nuestro propio mensaje ACK.

Para ello, definimos un tipo de conector JavaScript Writer para almacenar el mensaje ACK ack_response en el ResponseMap y tenerlo disponible desde el conector fuente:

Mirth Connect: conector destino JavaScript Writer para almacenar el mensje ACK

Mirth Connect: conector destino JavaScript Writer para almacenar el mensje ACK

Para construir el mensaje ACK, vamos a hacer uso de un transformador de tipo JavaScript, y con la ayuda de un OutboundMessageTemplate genérico, vamos a establecer los campos de interés. Muchos de ellos ya los tenemos en el ChannelMap.

En el caso particular de los segmentos de errores, si procede, podemos concatenarle la variable errs que los contiene al mensaje tmp de la salida del conector:

Mirth Connect: construcción del mensaje ACK mediante transformador JavaScript

Mirth Connect: construcción del mensaje ACK mediante transformador JavaScript

Conector Destino 4

Para no machacar la salida del caso práctico anterior, en la configuración del conector que genera los ficheros XML de salida para las altas, le podemos indicar el directorio C:\tmp\informaticasana\1\1.2:

Mirth Connect: conector destino para indicar la salida XML

Mirth Connect: conector destino para indicar la salida XML

Además, tendremos que añadir con el operador AND un nuevo filtro para indicar que se ejecute tan sólo si el valor del MSA-1 es ‘AA’ (validación deshabilitada o validación habilitada con mensaje válido):

Mirth Connect: filtrado para controlar la ejecución

Mirth Connect: filtrado para controlar la ejecución

Conector Destino 5

Omitimos la explicación y las capturas de pantalla por simetría con el conector del destino 4.

Conector Destino 6

Omitimos la explicación y las capturas de pantalla por simetría con el conector del destino 4.

Respuesta propia para el conector fuente

Finalmente, en la configuración del canal fuente, debemos indicarle en la propiedad Respond from el valor propio ack_response:

Mirth Connect: configuración de la respuesta del canal fuente

Mirth Connect: configuración de la respuesta del canal fuente

Despliegue de los canales

Ya nos encontramos en condiciones de habilitar los canales y desplegarlos a través de la opción Redeploy All:

Mirth Connect: despliegue de los canales

Mirth Connect: despliegue de los canales

Tras lo anterior, si todo ha ido bien hasta el momento, veremos los canales recién desplegados sin errores en el Dashboard:

Mirth Connect: canales desplegados

Mirth Connect: canales desplegados

Simulación de envío y recepción de la mensajería con 7Edit

Haciendo uso del mismo perfil Sender utilizado en el caso práctico anterior, vamos a enviar los 2 mensajes de prueba.

Comprobamos que para el mensaje válido recibimos un ACK positivo:

7edit: mensaje de prueba válido con resultado ACK positivo

7edit: mensaje de prueba válido con resultado ACK positivo

Sin embargo, para el mensaje no válido recibimos un ACK negativo junto con el segmento de error correspondiente, justo lo que queríamos:

7edit: mensaje de prueba no válido con resultado ACK negativo

7edit: mensaje de prueba no válido con resultado ACK negativo

Pruebas de funcionamiento de los canales en Mirth Connect

Vamos a comentar brevemente el estado del Mirth Connect tras realizar los envíos.

Dashboard

Debemos asegurarnos que los números que obtenemos son los que se muestran a continuación:

Mirth Connect: estado del Dashboard tras los envíos

Mirth Connect: estado del Dashboard tras los envíos

Comprobación de la salida

Y también comprobar que tan sólo se ha generado el fichero XML para el mensaje válido en la salida:

Fichero XML generado

Fichero XML generado

Traza de los conectores

Por último, vamos a realizar algunas observaciones sobre los conectores de los 3 canales.

Canal que simula el servicio web

Podemos comprobar la respuesta propia para el mensaje no válido:

Mirth Connect: respuesta propia para el mensaje no válido

Mirth Connect: respuesta propia para el mensaje no válido

Canal que implementa la comunicación con el servicio web

Podemos comprobar la respuesta SOAP del servicio web para el mensaje no válido:

Mirth Connect: respuesta SOAP del servicio web para el mensaje no válido

Mirth Connect: respuesta SOAP del servicio web para el mensaje no válido

Canal principal

Podemos observar que para el mensaje no válido, se filtra el conector ‘Escribe XML para Altas’, a diferencia de lo que ocurre con el mensaje válido:

Mirth Connect: conector filtrado para mensaje no válido

Mirth Connect: conector filtrado para mensaje no válido

Pruebas deshabilitando la validación de la mensajería

Si queremos deshabilitar la validación de la mensajería sólo hay que modificar el fichero config.xml y desplegar de nuevo los canales para volver a la situación del caso práctico anterior.

Dejamos al lector la posibilidad de hacerlo: repetir el envío de los 2 mensajes y comprobar que, efectivamente, el estado de los conectores cambia, ambos ACK son positivos y se generan los 2 ficheros XML de salida.

 

Aquí finaliza este caso práctico. En el próximo artículo plantearemos el último caso práctico para este escenario. Estará relacionado con la gestión de errores y la notificación asíncrona de los mismos, temas muy relevantes en el ámbito de las integraciones sanitarias.

De nuevo, todo el material necesario para el caso puede ser descargado desde aquí: Material caso práctico 1.2 - Múltiples sistemas y la validación de la mensajería HL7 (291 descargas)

Francisco J. CarrascoSolución caso práctico 1.2: múltiples sistemas y la validación de la mensajería HL7

Entradas Relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *