En el artículo anterior planteamos el problema de la gestión de errores en un escenario con múltiples sistemas.

En este artículo desarrollamos con detalle una posible solución a este problema, basada en Mirth Connect.

Este artículo es parte de la serie del tutorial de Mirth Connect.

Para ello, utilizaremos las siguientes versiones para estándares, tecnologías y herramientas:

• Versión 2.5 de HL7.
• JRE 7u72 (descargar desde el sitio de Java).
• Mirth Connect 2.2.3.6825 (descargar desde el sitio de Mirth Connect).

Material utilizado

De nuevo, para poder seguir mejor el artículo y probar los ejemplos, publicamos el material necesario:

Fichero de log

En primer lugar, vamos a ubicar el fichero de entrada log en la ruta C:\tmp\informaticasana\1\1.3, para poder leerlo desde Mirth Connect.

El contenido del fichero es el siguiente:

W,"2014-09-22 12:16:22",warning-1
W,"2014-09-22 12:16:23",warning-1
E,"2014-09-22 12:16:24",error-2
I,"2014-09-22 12:16:25",info-3
F,"2014-09-22 12:16:26",error-fatal-1

Destacamos dos errores que debemos mapear con los del catálogo y comunicar a NewModernHIS:

1. error-2 de tipo ‘E’ (Error)
2. error-fatal-1 de tipo ‘F’ (Fatal Error).

Implementación del canal que rastrea el fichero de log en Mirth Connect

Vamos a configurar el canal que lee el fichero de log, lo procesa, mapea los errores con los del catálogo, y realiza las llamadas correspondientes al servicio web.

Configuración global

La configuración del canal es la habitual que venimos usando para los canales polling (ver artículo sobre consejos útiles y buenas prácticas).

Vamos a utilizar el tipo de datos Delimited Text para el conector fuente, conforme al formato del fichero de log que queremos leer:

Conector Fuente

Para leer el fichero log, es necesario:

1. Elegir un tipo de conector File Reader.
2. Indicar el directorio donde se encuentra el fichero.
3. Establecer la frecuencia de rastreo en Polling Type / Polling Frecuency (ms).

Para indicar que el fichero ya ha sido leído y no procesarlo de nuevo podemos renombrarlo y situarlo en un directorio old de ‘ficheros leídos’. Esto se puede llevar a cabo mediante las configuraciones Move-to Directory y Move-to File Name para moverlo y renombrarlo. El momento de la lectura se puede obtener mediante el uso de ${SYSTIME}:

Conector Destino

Para comunicarnos con el nuevo servicio web se puede definir un conector de tipo Web Service Sender, al igual que se hizo en el caso práctico anterior para la validación de la mensajería.

De nuevo, es posible cargar la mayor parte de la configuración automáticamente, indicando la URL del WSDL, y a través de los botones Get Operations y Generate Envelope.

Como contenido del mensaje SOAP, le indicamos la salida del propio conector a través de ${message.encodedData} dentro de <arg0>:

Transformador

Aquí se lleva a cabo el trabajo principal del canal: construir el XML con la información de los errores mapeados a partir de la información del fichero de log.

Para ello, se indicará:

• El formato del fichero de log que leemos en el Inbound Message Template.
• El XML que enviaremos al servicio web de notificación de errores en el Outbound Message Template.

Las transformaciones necesarias se pueden realizar en un único transformador de tipo Javascript. Sin entrar en detalles, en el código podemos observar cómo iteramos sobre las líneas del fichero y, para los casos que nos interesa notificar (‘E’ y ‘F’), se realiza una correspondencia con los errores del catálogo de NewModernHIS para añadirlos a la salida del conector:

Implementación del canal que simula el servicio web de notificación de errores en Mirth Connect

En el caso práctico anterior ya vimos cómo configurar un canal en Mirth Connect para simular un servicio web, por tanto en esta ocasión, no entraremos en los detalles.

Configuración global

Configuración habitual para el caso práctico:

Conector Fuente

Conector de tipo Web Service Listener, donde indicamos el nombre del servicio InformaticaSanaErrores. De nuevo, configuramos una respuesta propia custom_ack para el servicio web en Respond from:

Conector Destino

Conector de tipo Javascript Writer, donde construimos el XML de respuesta con el mensaje Error notificado correctamente, y lo almacenamos en custom_ack tal y como vimos en la configuración del conector fuente:

Despliegue de los canales

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

Si todo ha ido bien hasta el momento, será posible ver los canales desplegados sin errores en el Dashboard:

Pruebas de funcionamiento de los canales en Mirth Connect

Dashboard

Para comenzar con las pruebas, iniciamos el canal de rastreo e, inmediatamente después, comprobamos que ambos canales reciben un único mensaje y lo envían correctamente:

Comprobación de la salida

Accediendo al directorio de ‘ficheros leídos’ C:\tmp\informaticasana\1\1.3\old, podemos comprobar que el fichero original ha sido movido y renombrado correctamente:

Traza de los conectores

Por último, realizamos algunas observaciones sobre las salidas generadas en los dos canales utilizados.

Canal que rastrea el fichero de log

En el Transformed Message del conector destino, podemos acceder a la salida del conector y comprobar el XML que se envía al servicio web de notificación de errores:

Canal que simula el servicio web de mensajería

En los Mappings del conector destino, por ejemplo, podemos acceder a la información del XML generado como respuesta del canal, y almacenado en la variable custom_ack:

Y con esto ponemos el punto final a nuestro primer caso práctico con Mirth Connect, una serie de 6 artículos en los que hemos abordado problemas típicos en las integraciones sanitarias como la validación de la mensajería o la gestión de errores. Todo ello tras la implantación de un nuevo HIS, y desde el punto de vista de una aplicación integrada en un sistema hospitalario.