Este tutorial de Mirth Connect propone un primer contacto con esta herramienta para integraciones sanitarias. Mirth Connect es una aplicación compleja que puede tener una curva de aprendizaje retadora para los usuarios con menos experiencia. Eso nos ha motivado a crear este tutorial, con el objetivo de facilitar a estos usuarios sus primeros pasos en la realización de integraciones HL7 con Mirth Connect, y a adquirir confianza para abordar desarrollos más complejos.

Este tutorial de Mirth Connect consiste en la realización de una integración HL7 sencilla de la siguiente forma:

• Se expone un escenario simplificado donde se requiere una integración HL7.
• Se explican los requisitos de la integración y se propone una solución sencilla utilizando Mirth Connect como herramienta de integración.
• Tanto los requisitos como la integración están simplificados para que sirvan de aprendizaje de los conceptos básicos.

El punto de partida de este tutorial es la implantación de un nuevo HIS en un hospital. ¿Qué retos de interoperabilidad en salud podemos encontrar con la llegada de este nuevo HIS?

Los responsables de integraciones de sistemas han analizado la situación y han decidido que no van a cometer los errores del pasado. Por experiencia, saben las desventajas de la integración a medida y, por tanto, van a usar un popular motor de integración llamado Mirth Connect. A lo largo del tutorial veremos el proceso que siguen en este hospital para pasar, partiendo de una integración a medida, a integrar mediante un motor de integración y el estándar de mensajería HL7.

Tecnología usada en este tutorial de Mirth Connect #

Para este tutorial vamos a usar la versión 4.5 de Mirth Connect, aunque seguramente puedas seguir la explicación con versiones más moderna sin problemas. Si te interesa, tenemos más información sobre las distintas versiones de Mirth Connect.

Por supuesto, si aun no lo tienes, puedes conseguirlo en nuestra página de descargas de Mirth Connect.

El requisito más importante para utilizar Mirth Connect es tener instalada una versión de Java compatible. Si tienes alguna duda, puedes revisar los requisitos de sistema de Mirth Connect antes de instalar.

En primer lugar conozcamos el nuevo HIS:

Requisitos de integración del nuevo HIS #

¡Nuestro hospital está renovando sus sistemas de información! Así que han sustituido el viejo HIS (Sistema de Información Hospitalario) OldPlainHIS que usaba XML por el moderno NewModernHIS que utiliza mensajería HL7. ¿Cómo podemos integrar nuestros sistemas existentes con el nuevo HIS sin volvernos locos?

Para nuestro tutorial de Mirth Connect vamos a inventar un HIS con unos requisitos de integración simples. Esto nos permitirá llevar a cabo una integración completa y sencilla, pero que nos servirá de aprendizaje.

Los mensajes HL7 de mantenimiento de paciente #

Como hemos dicho, este nuevo HIS NewModernHIS utiliza mensajería HL7 en lugar de XML. Concretamente, utiliza HL7 v2.5, es decir, la versión 2.5 de la mensajería HL7 en la nomenclatura de pipes (|).

Una necesidad frecuente en las integraciones es notificar al resto de sistemas de cambios en la base de datos de pacientes. En concreto, vamos a fijarnos en el registros de nuevos pacientes, la modificación de sus datos demográficos y el exitus (fallecimiento). Los mensajes para registros, modificaciones y exitus se implementan mediante los siguientes eventos y valores:

• Registro de nuevo paciente: ADT^A28.
• Modificación de paciente: ADT^A31, PID.30='N'.
• Alta por exitus del paciente: ADT^A31, PID.30='Y'

Por simplicidad de cara al tutorial de Mirth Connect, supondremos que NewModernHIS utiliza el mismo identificador único del paciente que OldPlainHIS: el NHC, y que éste se mantiene tal cual tras el cambio de HIS. Además, vamos especificar tan sólo los campos necesarios para la mensajería de mantenimiento de pacientes. Asimismo vamos a suponer que los campos requeridos por la aplicación, son los mismos que los requeridos por el nuevo HIS.

Al final de esta sección, puedes encontrar el detalle los campos informados por NewModernHIS en los mensajes HL7.

Registro de paciente #

Este mensaje HL7 se utiliza cuando se da de alta un nuevo paciente y se usaremos un ADT^A28:

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28|T|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||EMR||LASTNAME1^FIRSTNAME^LASTNAME2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Modificación de paciente #

Este mensaje HL7 se utiliza cuando hay que modificar los datos demográficos de un paciente y usaremos un ADT^A31 con PID.30='N:

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140702123254||ADT^A31|2-modification-adt-a31|T|2.5|||AL|NE
EVN|A31|20140702123253
PID|1||EMR||LASTNAME1^new_FIRSTNAME^LASTNAME2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Exitus del paciente #

Este mensaje HL7 se utiliza cuando hay que notificar el exitus del paciente u usaremos un ADT^A31 con PID.30='Y:

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140703123354||ADT^A31|3-exitus-adt-a31|T|2.5|||AL|NE
EVN|A31|20140703123353
PID|1||EMR||LASTNAME1^FIRSTNAME^LASTNAME2||19840123000000|M|||||||||||||||||||||20140703123300|Y
PV1|1|N

Detalles de los campos de los mensajes HL7 informados por el HIS

Campos de los mensajes HL7 informados por el HIS #

Segmento MSH

CAMPO	TIPO DE DATO	REQUERIDO	DESCRIPCIÓN
MSH.1	ST	Sí	Carácter separador de campos, valor fijo a ‘|’
MSH.2	ST	Sí	Codificación de caracteres, valor fijo a ‘^~&’
MSH.3	HD	Sí	Aplicación emisora del mensaje, valor fijo a NEWHIS
MSH.5	HD	Sí	Aplicación receptora del mensaje, valor fijo a PHARMACOOLX1.0
MSH.7	TS	Sí	Fecha y hora del mensaje, en formato yyyymmddhh24miss
MSH.9	MSG	Sí	Tipo y evento del mensaje, en formato TIPO^EVENTO (en el caso práctico, el tipo irá fijo a ADT y el EVENTO podrá ser A28 o A31)
MSH.10	ST	Sí	Identificador único del mensaje
MSH.11	PT	Sí	Entorno de ejecución del mensaje, valor fijo a ‘T’ en el entorno de desarrollo, y a ‘P’ en el entorno de producción
MSH.12	VID	Sí	Versión de HL7 utilizada, valor fijo a ‘2.5’
MSH.15	ID	Sí	ACK de confirmación de recepción, valor fijo a AL para requerir siempre este tipo de ACK
MSH.16	ID	Sí	ACK de aplicación, valor fijo a NE para no requerir nunca este tipo de ACK

Segmento EVN

CAMPO	TIPO DE DATO	REQUERIDO	DESCRIPCIÓN
EVN.1	ID	Sí	Evento del mensaje (en el caso práctico podrá ser A28, y A31)
EVN.2	TS	Sí	Fecha y hora del evento, en formato yyyymmddhh24miss

Segmento PID 

CAMPO	TIPO DE DATO	REQUERIDO	DESCRIPCIÓN
PID.1	SI	Sí	Identificador de segmento PID dentro del mensaje HL7, valor fijo a ‘1’
PID.3	CX	Sí	NHC del paciente
PID.5	XPN	Sí	Nombre y apellidos del paciente, en formato APELLIDO1^NOMBRE^APELLIDO2
PID.7	TS	No	Fecha y hora de nacimiento del paciente, en formato yyyymmddhh24miss
PID.8	IS	No	Sexo del paciente, con valores ‘M’ Hombre, ‘F’ Mujer, ‘O’ Otro
PID.29	TS	No	Fecha y hora del exitus del paciente, en formato yyyymmddhh24miss
PID.30	ID	Sí	Indicador del exitus del paciente, con valores ‘Y’ Sí, ‘N’ No

Segmento PV1

CAMPO	TIPO DE DATO	REQUERIDO	DESCRIPCIÓN
PVN.1	SI	Sí	Identificador de segmento PV1 dentro del mensaje HL7, valor fijo a ‘1’
PVN.2	IS	Sí	Tipo de episodio, valor fijo a ‘N’ para indicar que no aplica

Integrar el sistema heredado con Mirth Connect #

¡Ha llegado un nuevo HIS al hospital! La vieja aplicación PharmaCoolX 1.0 y sus mensajes XML necesitan ser interoperable con el nuevo HIS NewModernHIS y HL7. Sin embargo, nuestra aplicación de farmacia PharmaCoolX 1.0 no es compatible con HL7 y usa mensajes XML.

Esta aplicación ya estaba integrada con el antiguo HIS, pero, con la llegada del nuevo NewModernHIS y el estándar HL7 se plantea la pregunta: ¿Cómo mantenemos la interoperabilidad entre el nuevo HIS con HL7 y nuestra vieja aplicación con XML?

En esta primera parte del tutorial vamos resolver el problema utilizando HL7 y Mirth Connect, mediante la migración de una integración basada en ficheros XML y carpetas compartidas a una nueva integración basada en HL7 y comunicación MLLP.

Requisitos de integración del sistema heredado #

Como hemos visto, en nuestro hospital teníamos un viejo HIS llamado OldPlainHIS. Este HIS estaba integrado con la aplicación departamental de farmacia PharmaCoolX 1.0 mediante un desarrollo a medida. Tanto el viejo HIS, como la aplicación de farmacia permitían el intercambio de información mediante ficheros XML que escribían y leían de una carpeta compartida en la red.

PharmaCoolX tiene que mantener una base de datos con los pacientes del hospital para realizar sus operaciones y cumplir su misión. Así que necesita recibir los registros de los nuevos pacientes y las modificaciones de datos demográficos.

Para este tutorial de Mirth Connect, vamos a considerar que la aplicación permite tres operaciones posibles:

• Registro de un nuevo paciente.
• Modificación de los datos demográficos.
• Exitus del paciente.

Todas las operaciones se realizan mediante intercambio de ficheros XML en una carpeta compartida. Además, estos ficheros XML tienen el mismo formato independientemente de la operación que se vaya a realizar. La aplicación de farmacia usa el número de historia clínica como identificador del paciente (NHC), por tanto, cuando lea un fichero de la carpeta compartida:

• Si el NHC no existe en la base de datos, dará de alta a un nuevo paciente.
• Si el NHC ya existe, modificará el paciente con los datos nuevos del fichero.
• El indicador de exitus se implementa como un dato demográfico más del paciente, es decir, como una modificación de los datos.
• Por simplicidad, no contemplaremos operaciones más complejas como fusiones, anulación de fusiones ni eliminación de historias clínicas.

Mensajes XML usados por el sistema heredado #

La aplicación PharmaCoolX usa mensajes XML sencillos, a continuación puedes ver una descripción de las diferentes etiquetas usadas en esos mensajes.

Campo	Tipo de dato	Requerido	Descripción
nhc	integer	Sí	Número de historia clínica (NHC) del paciente
nombre	string	Sí	Nombre del paciente
apellidos	string	Sí	Apellidos del paciente
fec_nacimiento	string	No	Fecha de nacimiento del paciente, en formato dd/mm/yyyy (por ejemplo 26/05/2001)
sexo	char	No	Sexo del paciente con valores ‘H‘ (Hombre), ‘F‘ (mujer)
exitus	char	Sí	Exitus del paciente, con valores ‘S‘ (Sí) o ‘N‘ (No)
fec_exitus	string	No	Fecha del exitus del,paciente, en formato dd/mm/yyyy

Ejemplo de fichero XML #

<patient>
    <emr>EMR</emr>
    <firstname>FirstName</firstname>
    <lastnames>LastName1 LastName2</lastnames>
    <birth_date>01/01/2000</birth_date>
    <sex>M</sex> 
    <exitus>N</exitus>
    <exitus_date/>
</patient>

Mensajes HL7 frente a ficheros XML #

Veamos las diferencias entre los ficheros XML del sistema PharmaCoolX 1.0 y la mensajería HL7 del nuevo HIS. La aplicación PharmaCoolX 1.0 entiende un único formato de fichero XML, frente a los tres mensajes HL7 diferentes que usa NewModernHIS. Además, esta aplicación lee de una carpeta compartida en red los ficheros XML mientras que el nuevo HIS envía los mensajes HL7 mediante el protocolo LLP.

También cambia el formato para los siguientes campos:

• Nombre y apellidos: en el XML son dos campos separados, pero HL7 los informa en un único campo mediante 3 componentes.
• Fecha de nacimiento: en el XML se usa el formato dd/mm/yyyy, pero el mensaje HL7 informa el campo en formato yyyymmddhh24miss.
• Sexo: el XML usa los valores ‘H‘ y ‘F‘, pero los mensajes HL7 tienen el campo con los valores: M (Hombre), F (Mujer), O (Otro).
• Exitus: para indicar el exitus se usan los valores ‘S‘ (Sí) y ‘N‘ (No) en el XML, pero HL7 usa un campo con los valores ‘Y‘ (Sí), ‘N‘ (No).
• Fecha de éxitus: al igual que con la fecha de nacimiento, el XML de PharmaCoolX usa el formato dd/mm/yyyy, pero HL7 usa un campo en formato yyyymmddhh24miss.

Por último, el proveedor de la aplicación no quiere saber nada de HL7 y tan sólo quiere que su sistema continúe funcionando con XML tal y como está tras la implantación del nuevo HIS.

Tranformación de HL7 a XML con Mirth Connect #

Para integrar estos dos sistemas, vamos a crear un canal en Mirth Connect que reciba los mensajes HL7 del nuevo HIS mediante el protocolo LLP y los transforme en el formato XML que la vieja aplicación necesita. Además, los ficheros XML generados se dejarán en la carpeta de red compartida. De este modo, el cambio de HIS le resultará completamente invisible a PharmaCoolX 1.0.

Para el desarrollo de este canal para nuestro tutorial de Mirth Connect, usaremos tipos de conectores frecuentemente utilizados como:

• Entrada de datos (Source): LLP Listener.
• Salida de datos (Destination): File Writer.

En los conectores se hará uso de filtros (filters) para distinguir el evento del mensaje HL7 recibido y realizar diferentes acciones, así como de transformadores (transformers) para convertir cada uno de los campos al formato requerido por PharmaCoolX 1.0.

Mensajes HL7 que se transformarán a XML #

Como punto de partida, necesitamos los tres mensajes HL7 que nuestro nuevo HIS NewModernHIS necesita y que utilizaremos de plantilla para la implementación del canal en Mirth Connect. Para ello, podemos construirlos mediante el propio Mirth Connect, un editor de texto o una herramienta especializada para editar HL7.

A continuación están los mensajes HL7 que deberemos transformar a ficheros XML, hemos usado HL7 versión 2.5.

Registro de paciente #

Para el registro de paciente el HIS utiliza un mensaje ADT^A28.

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-alta-adt-a28|T|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||EMR||LASTNAME1^FIRSTNAME^LASTNAME2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Modificación de paciente #

Para la modificación de paciente, se utiliza un mensaje ADT^A31 con PID.30='N'.

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140702123254||ADT^A31|2-modification-adt-a31|T|2.5|||AL|NE
EVN|A31|20140702123253
PID|1||EMR||LASTNAME1^new_FIRSTNAME^LASTNAME2||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Exitus del paciente #

Por último, para indicar el exitus de un paciente, usaremos un mensaje ADT^A31 con PID.30='Y'.

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140703123354||ADT^A31|3-exitus-adt-a31|T|2.5|||AL|NE
EVN|A31|20140703123353
PID|1||EMR||LASTNAME1^FIRSTNAME^LASTNAME2||19840123000000|M|||||||||||||||||||||20140703123300|Y
PV1|1|N

Implementación del canal en Mirth Connect #

Ya tenemos el planteamiento de la integración y toda la información que necesitamos. El siguiente paso de nuestro tutorial de Mirth Connect es pasar a la acción y empezar a utilizar la herramienta. En primer lugar, vamos a especificar cada una de las partes que necesitamos para la construcción del canal de Mirth Connect:

Configuración global #

Lo primero es establecer la configuración global para el canal. Así, habilitamos el canal, establecemos que el estado inicial sea «Started» y almacenamos la traza completa durante 30 días para realizar pruebas:

Merece especial atención la configuración «Set Data Types», donde podemos indicar que la transformación que requerimos (de HL7 a XML). Esta transformación la vamos a realizar en el conector fuente:

Esta configuración también se puede establecer más tarde desde aquí o desde los propios conectores a medida que los vayamos desarrollando.

Scripts JavaScript #

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

Conector de origen (Source Connector) #

Queremos recibir mensajes HL7 a través de la red, así que haremos lo siguiente:

• Como «Connector Type» debemos escoger TCP Listener.
• Establecemos un puerto que nos venga bien para escuchar, por ejemplo el 21110.
• Y marcamos el modo de transmisión como MLLP dejamos el resto de configuraciones por defecto:

Filtros (Filters) #

Por simplicidad para el propósito de este tutorial de Mirth Connect, vamos a suponer que NewModernHIS tan sólo enviará mensajes HL7 de acuerdo a lo establecido. Por tanto no necesitaremos filtrar los mensajes.

Transformadores del origen (Source Transformers) #

En esta sección del programa asociaremos los datos entrantes (inbound) de tipo HL7 con transformadores para luego obtener una salida (outbound) en el formato XML de PharmaCoolX 1.0. Para ello, usaremos los mensajes que generamos anteriormente como plantillas (templates), que nos permitirán expresar cómo se presentará la información en la entrada y en la salida.

Antes de entrar en el detalle de los nueve transformadores que necesitamos para este conector, vamos a hablar de los tres paneles diferentes que nos ofrece la herramienta. Estos se encuentran en la pantalla de edición de un transformador, en el panel derecho. Al seleccionar cada pestaña podemos ver nuestras plantillas de dos formas diferentes o acceder a la lista de funciones disponibles.

De izquierda a derecha en las columnas de 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»). Estos árboles nos dan la posibilidad de arrastrar valores a los transformadores.
• «Reference»: donde tenemos acceso a las funciones y estructuras de datos de Mirth Connect,. Además ,también con la posibilidad de arrastrarlas a los transformadores.

Plantilla del mensaje de entrada (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. Como hemos visto en el planteamiento del tutorial, en este caso, como recibimos 3 mensajes ADT con dos tipos de eventos diferentes, y el valor de exitus, omitimos el valor MSH.9.2 (donde se especifica el evento) para así combinar los tres mensajes en una plantilla:

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||fh_message||ADT|mid|T|2.5|||AL|NE
EVN||fh_event
PID|1||EMR||LASTNAME1^FIRSTNAME^LASTNAME2||19840101000000|M||||||||||||||||||||||N
PV1|1|N

Plantilla del mensaje de salida (Outbound Message Template) #

Esta plantilla es utilizada generalmente en los conectores de Mirth Connect como base y ayuda para la construcción de la salida. En nuestro tutorial de Mirth Connect lo usaremos para establecer la plantilla XML de la salida que necesitamos:

<patient>
  <emr></emr>
  <firstname></firstname>
  <lastnames></lastnames>
  <birth_date></birth_date>
  <sex></sex>
  <exitus></exitus>
  <exitus_date/>
</patient>

Después de añadir ambas plantillas quedaría así:

Pasamos añadir los transformadores que necesitamos desde la opción:

Transformador 0: Mapper para el identificador del mensaje para nombre de fichero XML #

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.

Arrastramos el campo MSH.10.1 desde el árbol «Inbound Message Template Tree» a la casilla Mapping y le ponemos el nombre mid.

Transformador 1: Mapper para el identificador del mensaje para conectores destino #

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, así que nombraremos la variable de esa forma.

Como el campo MSH.9.2 no pertenece al «Inbound Message Template Tree», ya que no existe esa información en la entrada, arrastramos el campo MSH.9.1 y editamos su valor manualmente al MSH.9.2:

Transformador 2: Message Builder para el valor de emr #

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

Arrastramos los valores emr.empty desde el árbol «Outbound Message Template Tree» y PID.3.1 desde el árbol «Inbound Message Template Tree»:

Transformador 3: Message Builder para el campo first_name #

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

Arrastramos los valores first_name.empty desde el árbol «Outbound Message Template Tree» y PID.5.2 desde el árbol «Inbound Message Template Tree»:

Transformador 4: Message Builder para el campo last_names #

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

Arrastramos los valores last_names.empty desde el árbol «Outbound Message Template Tree», PID.5.1 y PID.5.3. desde el árbol «Inbound Message Template Tree». Para unirlos en un solo campo, los hemos concatenado colocando una cadena vacía en medio:

Transformador 5: Message Builder para transformar la fecha #

Para la conversión de fechas, como necesitamos esta funcionalidad también para establecer la fecha de exitus, hemos desarrollado una sencilla función en los code_templates, tal y como ya aconsejamos en las mejores prácticas con Mirth Connect. Para ello guardamos y cerramos el canal actual, volvemos a la lista de canales (Channels) y seleccionamos la opción «Edit Code Templates»:

Código JavaScript:

function date_conversion(date) {
  return date.length < 8? "" : date.substr(6,2)+"/"+date.substr(4,2)+"/"+date.substr(0,4);
}

Esta función estará accesible en la pestaña Reference del panel de la derecha del editor de transformaciones, en la categoría «User Defined Functions», y se podrá arrastrar hacia el código del transformador:

Volvemos al transformador de Source de nuestro canal y creamos un transformador de tipo Message Builder, que establece el valor de birth_date para la salida XML del conector.

Seleccionamos nuestra función desde «User Defined Functions» y la arrastramos al campo «Mapping»:

Arrastramos los valores birth_date.empty desde el «Outbound Message Template Tree» a «Message Segment» y el PID.7.1 desde el «Inbound Message Template Tree» como la variable de la función:

Transformador 6: Javascript para establecer el valor de sex #

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.

Arrastramos los valores sex.empty desde el «Outbound Message Template Tree» y PID.8.1 desde el «Inbound Message Template Tree» como se indica en la captura para crear el siguiente código:

Código JavaScript:

tmp['sex'] = msg['PID']['PID.8']['PID.8.1']
  .toString()
  .replace("M", "W")
  .replace("M","F");

Transformador 7: Message Builder para exitus #

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

Arrastramos los valores exitus.empty desde el árbol «Outbound Message Template Tree» a «Message Segment» y PID.30.1 desde el «Inbound Message Template Tree» a «Mapping»:

Transformador 8: Mapper de filtrado de XML #

Transformador de tipo Mapper, utilizado para poder filtrar el fichero XML que se escribirá posteriormente. Hemos creado dos transformadores con el exitus: El anterior convierte el valor y lo escribe en la salida XML y este es para usarlo posteriormente en el filtro de destino.

Transformador 9: Message Builder para fec_exitus #

Transformador de tipo Message Builder, que establece el valor de exitus_date para la salida XML del conector obteniéndola y transformándola del mensaje HL7.

Arrastramos o escribimos nuestra función date_conversion y el valor exitus_date.empty desde el árbol «Outbound Message Template Tree» y PID.29.1 desde el árbol «Inbound Message Template Tree»:

Conectores Destino (Destination Connectors) #

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, como por ejemplo guardarlos en diferentes ubicaciones.

Conector Destino 1 (Registros): File Writer #

Los conectores tan sólo se limitarán a escribir el mensaje XML de salida en un directorio (para realizar pruebas hemos elegido el directorio /tmp/tutorial/exit_xml/), por lo que el «Connector Type» debe ser un «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», además de añadir la extensión XML

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

Si se decide usar la misma ruta, hay que tener en cuenta que el contenido de /tmp puede desaparecer del ordenador en un reinicio.

Filtros del conector de destino

Para crear el filtro debemos pulsar la opción Edit Filter de la barra de la izquierda tras haber seleccionado nuestro canal que escribe XML.

Para este destino, 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 registro A28.

Transformadores del destino

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 (Modificaciones): File Writer #

Lo creamos clonando el destino anterior:

Tras lo anterior, tenemos que editar su nombre y su filtro. En el filtro hay que modificar el evento A28 por A31. También hay que añadir una comprobación, ya que se envían dos mensajes diferentes con el evento A31 que determinan si se ha modificado un paciente o se ha producido un exitus. Añadiremos una nueva regla de tipo AND con la anterior comprobando que el valor de éxitus sea ‘N‘

Conector Destino 3 (Exitus): File Writer #

Lo creamos clonando el destino anterior, editando su nombre y su filtro. En este caso el valor del exitus debe ser ‘Y‘ y no ‘S‘, puesto que en el transformador de tipo mapper del origen no hemos modificado el valor de exitus, al contrario que el transformador de tipo message builder, donde sí hemos sustituido ‘Y‘ por ‘S‘.

Finalmente tenemos los 3 destinos preparados:

Despliegue del canal #

Llegados a este punto del tutorial de Mirth Connect, ya hemos finalizado la edición. Así que desplegamos el canal para que pueda comenzar a recibir mensajes HL7. Existen dos opciones:

• En el lateral izquierdo en el menú de «Channel Tasks» seleccionando el canal y haciendo click en «Deploy Channel».
• Con el botón derecho del ratón sobre el canal que se desee desplegar aparecen varias opciones y elegir «Deploy Channel «.

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

Simulación desde Mirth Connect de envío y recepción de la mensajería #

Para finalizar nuestro tutorial de Mirth Connect vamos a simular el envío y la recepción de la mensajería. Para ello, podemos utilizar el propio Mirth Connect. De este modo no necesitaremos utilizar un canal de comunicación como es LLP. Para ello, lo único que tenemos que hacer es:

1. Ir al Dashboard
2. Enviar el mensaje de una de estas formas:
   • Hacer click derecho sobre el canal con el que nos queramos comunicar y seleccionar la opción «Send Message».
   • Seleccionar esta opción directamente desde el panel «Dashboard Tasks» situado a la izquierda.

De esta forma podremos comprobar de forma sencilla que nuestros canales funcionan correctamente.

Probamos a mandar los siguientes mensajes de prueba, de uno en uno, simulando que hubieran sido enviados por NewModernHIS a través de la conexión LLP:

Registro de paciente #

Recordemos que se trata de un mensaje ADT^A28.

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140701123154||ADT^A28|1-record-adt-a28|T|2.5|||AL|NE
EVN|A28|20140701123153
PID|1||123456789||García^Juan^Martín||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Modificación de paciente #

Mensaje ADT^A31 con PID.30='N'

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140702123254||ADT^A31|2-modification-adt-a31|T|2.5|||AL|NE
EVN|A31|20140702123253
PID|1||123456789||García^Juan^Martinez||19840123000000|M||||||||||||||||||||||N
PV1|1|N

Alta por exitus del paciente #

Mensaje ADT^A31 con PID.30='Y'.

MSH|^~&|NewModernHIS||PharmaCoolX 1.0||20140703123354||ADT^A31|3-exitus-adt-a31|T|2.5|||AL|NE
EVN|A31|20140703123353
PID|1||123456789||García^Juan^Martinez||19840123000000|M|||||||||||||||||||||20140703123300|Y
PV1|1|N

Comprobamos que se han escrito tres ficheros XML con la información de los mensajes HL7 que hemos simulado enviar desde NewModernHIS. PharmaCoolX 1.0 ya debería ser capaz de leer estos ficheros.

Pruebas de funcionamiento del canal en Mirth Connect #

Por último, vamos comprobar el resultado del trabajo realizado con Mirth Connect durante el tutorial. Podemos observar tanto el resultado en el Dashboard de Mirth Connect como en en los ficheros generados por este.

Dashboard #

En el lado del Mirth Connect, en el Administrator 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 XML generada a partir de XML #

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):

Registro de paciente #

<patient>
   <emr>123456789</emr>
   <firstname>Juan</firstname>
   <lastnames>GarcíaMartín</lastnames>
   <birth_date>23/01/1984</birth_date>
   <sex>F</sex>
   <exitus>N</exitus>
   <exitus_date />
</patient>

Modificación de paciente #

<patient>
   <emr>123456789</emr>
   <firstname>Juan</firstname>
   <lastnames>GarcíaMartinez</lastnames>
   <birth_date>23/01/1984</birth_date>
   <sex>F</sex>
   <exitus>N</exitus>
   <exitus_date />
</patient>

Exitus de paciente #

<paciente>
   <emr>123456789</emr>
   <firstname>Juan</firstname>
   <lastnames>GarcíaMartinez</lastnames>
   <birth_date>23/01/1984</birth_date>
   <sex>F</sex>
   <exitus>S</exitus>
   <exitus_date>03/07/2014</exitus_date>
</patient>

Con esto comprobamos que nuestra integración es todo un éxito y resolvemos el reto planteado en este tutorial de Mirth Connect.

Conclusión #

En este tutorial de Mirth Connect, se ha presentado la integración de una aplicación que utiliza intercambio de archivos XML con un nuevo HIS que utiliza mensajería HL7 mediante Mirth Connect. Este proceso ha permitido la conexión de dos sistemas dispares, la transformación de datos, el enrutamiento de mensajes y observar los resultados de la integración.

Aprender a utilizar Mirth Connect es un conocimiento valioso para profesionales que trabajan en la integración de sistemas de salud. Con estos conocimientos podemos integrar sistemas de salud dispares y mejorar la interoperabilidad de los sistemas de salud. Lo que en última instancia, mejorará la calidad de la atención al paciente, la eficiencia y la seguridad.

Os animamos a seguir aprendiendo a partir de este punto con todos los recursos que tenemos en nuestra base de conocimiento.

Recursos adicionales #

Recursos sobre Mirth Connect:

• ¿Qué es Mirth Connect?
• El Administrator de Mirth Connect.
• Los canales y conectores de Mirth Connect.
• Trucos y mejores prácticas con Mirth Connect.
• Descargar Mirth Connect.

Otros recursos:

• Foro sobre Mirth Connect e Interoperabilidad.
• Guía sobre los estándares de interoperabilidad.
• Guía sobre los estándares fundamentales de HL7.