En este artículo vamos a solucionar el problema planteado en el artículo anterior: nuestro nuevo HIS debe comunicarse con una aplicación que no usa estándares como HL7.
¿Cómo podemos solucionarlo?

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

Para solucionar este problema vamos a implementar un canal en Mirth Connect que reciba los mensajes HL7 del nuevo HIS, NewModernHIS, mediante el protocolo LLP y los transforme en el formato XML que la vieja aplicación, PharmaCoolX 1.0, necesita.

Para la edición de los mensajes de ejemplo y la simulación del envío y recepción de los mensajes HL7 por parte de NewModernHIS utilizaremos la herramienta 7Edit.

Material y tecnologías utilizados

Para poder seguir mejor el artículo, compartimos todo el material necesario para probar los ejemplos:

Los estándares, tecnologías y herramientas que vamos a usar son:

• Versión 2.5 de HL7.
• Java JRE 7u45 (descargar Java).
• Mirth Connect 2.2.3.6825 (descargar Mirth Connect).
• 7Edit Professional 2.6.1 (descargar 7Edit, requiere licencia).

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

Para crear un mensaje con 7Edit, hay que seleccionar la opción de menú File→New… y seleccionar el tipo de mensaje y versión HL7 utilizada.

Por ejemplo, para la creación del mensaje de alta:

Como validador del mensaje usaremos el que nos proporciona por defecto. Aunque vimos en un artículo anterior que es posible crear perfiles para esta característica.

Comprobamos que nada más crear el mensaje HL7 ADT^A28, únicamente tenemos el segmento MSH, por tanto el validador nos pide los segmentos obligatorios EVN, PID y PV1:

Para editar el mensaje, basta con desplegar el árbol del panel de la izquierda Message y hacer doble clic sobre los campos que queremos editar. Veremos cómo se edita el mensaje en tiempo real sobre el área de texto principal de la aplicación.

Ejemplo de edición de un campo de tipo fecha_hora (tipo HL7 DTM, como podemos comprobar en el árbol):

También es posible editar el mensaje pulsando la tecla CTRL y haciendo clic en un campo del área de texto para seleccionarlo en el árbol, y doble clic para editarlo.

Todo lo relativo a la edición se puede encontrar en este breve vídeo en la página web de 7Edit.

De esta sencilla forma, construimos los 3 mensajes que necesitamos para la implementación del canal en Mirth Connect:

ADT^A28

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28|T|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

ADT^A08

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140702123254||ADT^A08|2-modificacion-adt-a08|T|2.5|||AL|NE
EVN|A08|20140702123253
PID|1||NHC||APELLIDO1^nuevo_NOMBRE^APELLIDO2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

ADT^A03

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||20140703123354||ADT^A03|3-exitus-adt-a03|T|2.5|||AL|NE
EVN|A03|20140703123353
PID|1||NHC||APELLIDO1^nuevo_NOMBRE^APELLIDO2||19840123000000|M|||||||||||||||||||||20140703123300|Y
PV1|1|N

Implementación del canal en Mirth Connect

Vamos a especificar cada una de las partes que necesitamos para la construcción del canal:

Configuración global

Lo primero es establecer la configuración global para el canal (algunos consejos los podemos encontrar en un artículo anterior).

Así, habilitamos el canal, establecemos que el estado inicial sea Started y almacenamos la traza completa durante 30 días para realizar pruebas:

Mención especial merece la configuración Set Data Types, donde podemos indicar que la transformación que requerimos (de HL7 a XML) la vamos a realizar en el conector fuente:

Esta configuración se puede establecer más tarde desde aquí o desde los propios conectores a medida que los vamos desarrollando (aún no hemos definido los conectores destino).

Scripts JS

Por simplicidad, en este canal no hacemos uso de estos scripts.

Estructuras de datos

En este canal vamos a hacer uso de la estructura de datos con ámbito del propio canal channelMap para almacenar la información que nos interese en el conector fuente y poder utilizarla en los conectores destino. Veremos su uso en los propios conectores.

Conector Fuente

Queremos recibir mensajes HL7, así que como Connector Type debemos indicar el valor LLP Listener. Establecemos un puerto que nos venga bien para escuchar, por ejemplo el 21110, y dejamos el resto de configuraciones por defecto:

Inbound Message Template

En general, esta plantilla es utilizada en los conectores de Mirth Connect como ayuda a la edición de sus transformadores asociados.

En este caso, como recibimos 3 mensajes ADT con tipos de eventos diferentes, omitimos el valor MSH.9.2 (donde se especifica el evento) para que la herramienta nos proporcione una estructura de ayuda general para el tipo ADT en la versión 2.5 de HL7:

MSH|^~\&|NewModernHIS||PharmaCoolX 1.0||fh_mensaje||ADT|mid|T|2.5|||AL|NE
EVN||fh_evento
PID|1||NHC||APELLIDO1^NOMBRE^APELLIDO2||19840101000000|M||||||||||||||||||||||N
PV1|1|N

Filtros

Por simplicidad, en este conector no hacemos uso de filtros.

Se podrían haber utilizado para filtrar mensajes cuyo par tipo/evento no está entre los esperados, pero, para este ejemplo, supondremos que NewModernHIS tan sólo enviará mensajes HL7 de acuerdo a los pares tipo/evento establecidos.

Outbound Message Template

En general, esta plantilla es utilizada en los conectores de Mirth Connect como base y ayuda para la construcción de la salida.

En este caso, establecemos la plantilla XML de la salida que necesitamos:

<paciente>
    <nhc></nhc>
    <nombre></nombre>
    <apellidos></apellidos>
    <fec_nacimiento></fec_nacimiento>
    <sexo></sexo>
    <exitus></exitus>
    <fec_exitus></fec_exitus>
</paciente>

Transformadores

Antes de entrar en el detalle de los 9 transformadores que necesitamos para este conector, vamos a hablar de los 3 paneles diferentes que nos ofrece la herramienta (según la pestaña seleccionada en el panel de la derecha) para ayudarnos en su edición.

De izquierda a derecha en la imagen, vemos el detalle para las 3 posibles pestañas:

• Messages Templates: donde especificamos las plantillas Inbound Message Template y Outbound Message Template.
• Messages Trees: donde la herramienta nos ofrece árboles de ayuda, generados a partir de las plantillas especificadas (llamados Inbound Message Template Tree y Outbound Message Template Tree), y con la posibilidad de arrastrar valores a los transformadores.
• Reference: donde tenemos acceso a las funciones y estructuras de datos de Mirth Connect, también con la posibilidad de arrastrarlas a los transformadores.

Transformador 0

Transformador de tipo Mapper, que almacena el identificador del mensaje HL7 en el ChannelMap para usarlo más tarde en los conectores destino como nombre del fichero XML final.

Establecemos su valor arrastrando el campo MSH.10.1 desde el árbol Inbound Message Template Tree:

Transformador 1

Transformador de tipo Mapper, que almacena el identificador del mensaje HL7 en el ChannelMap para usarlo más tarde en los conectores destino como filtros del tipo de evento.

Como el campo MSH.9.2 no pertenece al árbol Inbound Message Template Tree, podemos editar manualmente su valor tras arrastrar el campo MSH.9.1:

Transformador 2

Transformador de tipo Message Builder, que establece el valor de nhc para la salida XML del conector.

Establecemos la conversión arrastrando los valores nhc.empty desde el árbol Outbound Message Template Tree y PID.3.1 desde el árbol Inbound Message Template Tree:

Transformador 3

Transformador de tipo Message Builder, que establece el valor de nombre para la salida XML del conector.

Establecemos la conversión arrastrando los valores nombre.empty desde el árbol Outbound Message Template Tree y PID.5.2 desde el árbol Inbound Message Template Tree:

Transformador 4

Transformador de tipo Message Builder, que establece el valor de apellidos para la salida XML del conector.

Establecemos la conversión arrastrando los valores apellidos.empty desde el árbol Outbound Message Template Tree y PID.5.1 / PID.5.3 (notar que concatenamos estos valores) desde el árbol Inbound Message Template Tree:

Transformador 5

Transformador de tipo Message Builder, que establece el valor de fec_nacimiento para la salida XML del conector.

Establecemos la conversión arrastrando los valores fec_nacimiento.empty desde el árbol Outbound Message Template Tree y PID.7.1 desde el árbol Inbound Message Template Tree:

Para la conversión de fechas, como necesitamos esta funcionalidad también para establecer la fecha de éxitus, hemos desarrollado una sencilla función en los code_templates, tal y como ya aconsejamos en un artículo anterior:

Esta función está accesible en la pestaña Reference del panel de la derecha, en la categoría User Defined Functions, y se puede arrastrar hacia el transformador:

Transformador 6

Transformador de tipo Javascript (puesto que en este caso necesitamos hacer una conversión un poco más compleja), que establece el valor de sexo para la salida XML del conector.

Establecemos la conversión arrastrando los valores sexo.empty desde el árbol Outbound Message Template Tree y PID.8.1 desde el árbol Inbound Message Template Tree:

Transformador 7

Transformador de tipo Message Builder, que establece el valor de exitus para la salida XML del conector.

Establecemos la conversión arrastrando los valores exitus.empty desde el árbol Outbound Message Template Tree y PID.30.1 (notar que convertimos sólo el valor que necesitamos) desde el árbol Inbound Message Template Tree:

Transformador 8

Transformador de tipo Message Builder, que establece el valor de fec_exitus para la salida XML del conector.

Establecemos la conversión arrastrando los valores fec_exitus.empty desde el árbol Outbound Message Template Tree y PID.29.1 (notar que aplicamos la misma función que en fec_nacimiento) desde el árbol Inbound Message Template Tree:

Conector Destino 1

En general, vamos a definir un conector destino por cada tipo de mensaje. Se podría haber utilizado un único conector destino, pero usaremos más de uno para ilustrar el uso de los filtros en los destinos, y para mostrar que para cada tipo de mensaje se podrían realizar acciones completamente diferentes.

Los conectores tan sólo se limitarán a escribir el mensaje XML de salida en un directorio (para realizar pruebas hemos elegido el C:/tmp/informaticasana/1/1.1), por lo que el Connector Type debe ser File Writer, usando el Method file.

Como nombre de los ficheros de salida, elegimos el identificador del mensaje HL7, que recordemos que está almacenado en el ChannelMap y está accesible para ser arrastrado desde el panel derecho Destination Mappings.

Como Template, de nuevo desde el panel Destination Mappings, podemos arrastrar el valor Encoded Data para que el mensaje se escriba en el fichero de salida:

Filtros

En este caso, utilizaremos un tipo de filtro Rule Builder, que aceptará el mensaje si el valor evento almacenado en el ChannelMap (podemos arrastrarlo desde Reference -> Available Variables) se corresponde al esperado para el alta ‘A28’:

Transformadores

Según hemos configurado el conector fuente, en la entrada de los conectores destino ya tenemos el XML que nos interesa, por lo que no es necesario realizar ninguna transformación adicional.

Conector Destino 2

Lo creamos clonando el destino anterior:

Tras lo anterior, tenemos que editar su nombre y su filtro.

Conector Destino 3

Lo creamos clonando uno de los destinos anteriores, editando su nombre y su filtro.

Finalmente tenemos los 3 destinos preparados:

Despliegue del canal

Una vez acabada la edición, desplegamos el canal para que pueda comenzar a recibir mensajes HL7:

En el Dashboard ya se podría ver que el canal está preparado.

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

Creación del perfil “Sender” en 7Edit

Para simular el envío de la mensajería, lo primero que debemos hacer es crear un perfil Sender en 7Edit, donde establecemos principalmente la dirección IP y el puerto:

Simulación del envío de la mensajería

Mediante el botón Send, vamos enviando cada uno de los mensajes:

En la traza podemos ver cómo recibimos los mensajes ACK.

Pruebas de funcionamiento del canal en Mirth Connect

Dashboard

En el lado del Mirth Connect, en el panel de administración podemos comprobar cómo han llegado los 3 mensajes, se han filtrado 6 (para los eventos no correspondientes en los destinos), y se han enviado 3 (correspondientes a la generación de los ficheros de salida):

Haciendo doble clic sobre el canal, podemos acceder en detalle a la traza generada en cada uno de los conectores, para cada uno de los 3 mensajes recibidos:

Comprobación de la salida

Finalmente comprobamos que los ficheros de salida se han generado en el directorio establecido en los destinos:

Si los abrimos, podemos comprobar que se han generado los ficheros XML que PharmaCoolX 1.0 necesita para cada caso (se han formateado para que se puedan leer mejor):

Alta

<paciente>
    <nhc>NHC</nhc>
    <nombre>NOMBRE</nombre>
    <apellidos>APELLIDO1 APELLIDO2</apellidos>
    <fec_nacimiento>23/01/1984</fec_nacimiento>
    <sexo>H</sexo>
    <exitus>N</exitus>
    <fec_exitus/>
</paciente>

Modificación

<paciente>
    <nhc>NHC</nhc>
    <nombre>nuevo_NOMBRE</nombre>
    <apellidos>APELLIDO1 APELLIDO2</apellidos>
    <fec_nacimiento>23/01/1984</fec_nacimiento>
    <sexo>H</sexo>
    <exitus>N</exitus>
    <fec_exitus/>
</paciente>

Éxitus

<paciente>
    <nhc>NHC</nhc>
    <nombre>nuevo_NOMBRE</nombre>
    <apellidos>APELLIDO1 APELLIDO2</apellidos>
    <fec_nacimiento>23/01/1984</fec_nacimiento>
    <sexo>H</sexo>
    <exitus>S</exitus>
    <fec_exitus>03/07/2014</fec_exitus>
</paciente>

Con esto resolvemos el primer problema planteado para este ejercicio.

Partiendo de aquí, en los próximos artículos plantearemos y propondremos posibles soluciones en Mirth Connect a otros problemas típicos en los sistemas sanitarios, tales como la validación de mensajes HL7 y la notificación asíncrona de errores.