Hemos instalado un nuevo HIS que utiliza mensajería estándar HL7 ¿Cómo afrontamos el problema de la validación de la mensajería HL7?
En el ejercicio anterior vimos una posible solución al problema de la integración de una vieja aplicación con el nuevo HIS en un sistema sanitario.
Partiendo de esa situación, en este caso práctico vamos a plantear otro problema habitual en integraciones sanitarias: la validación de la mensajería HL7.
Este artículo es parte de la serie del tutorial de Mirth Connect.
Si no te has leído el ejercicio anterior, hazlo ahora. Este ejercicio se basa en el escenario propuesto para el ejercicio anterior.
Según el escenario del ejercicio anterior, el nuevo HIS, NewModernHIS, utiliza el estándar HL7 v2 para notificar a la aplicación PharmaCoolX 1.0:
- Las nuevas altas de usuario.
- Modificaciones de datos demográficos.
- Y notificaciones de éxitus.
PharmaCoolX 1.0 requiere utilizar formato XML, así que lo resolvimos configurando un canal en Mirth Connect para la recepción y transformación de los mensajes HL7.
Necesidad
Pasado un tiempo desde la implantación de nuestro nuevo HIS NewModernHIS, se aprecia que cada sistema consumidor realiza una validación diferente de la mensajería HL7 que recibe.
Se está invirtiendo demasiado esfuerzo en gestionar las incidencias particulares de cada sistema que consume su mensajería HL7, por lo que es imprescindible homogeneizar este comportamiento.
A la hora de gestionar la recepción de la mensajería por parte del resto de sistemas se observan diferentes comportamientos:
- Sistemas que siempre devuelven los ACK positivos tras no realizar ninguna validación (como el de nuestro caso práctico anterior, PharmaCoolX 1.0).
- Sistemas que realizan una validación sintáctica de los mensajes (de la parte que a cada uno le interesa) antes de devolver los ACK positivos o negativos.
Por ejemplo: comprobar que en algunos tipos de mensajes recibidos existe el segmento obligatorio PV1. - Sistemas que realizan una validación semántica de los mensajes (de la parte que a cada uno le interesa) antes de devolver los ACK positivos o negativos.
Por ejemplo: comprobar que existen ciertas codificaciones propias del sistema sanitario, como pueden ser las de unidades hospitalarias, servicios, etc. - Sistemas que procesan los mensajes recibidos antes de devolver los ACK positivos o negativos, y que suelen devolver en él errores funcionales propios de la aplicación.
Por ejemplo, que no se ha encontrado al paciente.
Por simplicidad, supondremos que NewModernHIS:
- No envía mensajes repetidos.
- Que todos los mensajes llegan en orden y sin retrasos.
Por lo que estos dos aspectos no se tendrán en cuenta a la hora de validar la mensajería.
Solución propuesta por NewModernHIS
Aunque el estándar HL7 establece ciertas recomendaciones respecto a la validación de mensajes, lo cierto es la validación de la mensajería frecuentemente genera problemas en este tipo de integraciones. Esto hace que en la práctica cada sistema suela establecer su propia estrategia de validación.
Así, NewModernHIS decide imponer una política de validación de la mensajería común a todos los sistemas consumidores para homogeneizar los ACK de confirmación de recepción.
La implementación se lleva a cabo mediante un único servicio web basado en el protocolo SOAP.
Todos los sistemas consumidores de mensajería deben preguntarle al servicio web tras recibir un mensaje HL7 de NewModernHIS si éste es válido antes de construir la respuesta ACK.
A continuación se muestran las llamadas XML a este servicio web (por legibilidad se omiten los namespaces). Existe un único parámetro que contiene el propio mensaje HL7 a validar, dentro de una estructura típica de una petición SOAP:
<Envelope>
<Header/>
<Body>
<Validacion>
<Mensaje></Mensaje>
</Validacion>
</Body>
</Envelope>Por otro lado, las respuestas XML del servicio web contienen la información necesaria para completar el segmento MSA y los segmentos ERR de los mensajes ACK:
<Envelope>
<Body>
<ValidacionRespuesta>
<MSA></MSA>
<ERR></ERR>
<ERR></ERR>
...
</ValidacionRespuesta>
</Body>
</Envelope>Una posible solución utilizando Mirth Connect
De entrada, se nos plantea el siguiente problema: desde el propio canal Mirth Connect implementado en el artículo anterior, tenemos que devolver los mensajes ACK a NewModernHIS en función del resultado devuelto por el servicio web de validación de la mensajería.
Para resolver el problema anterior, nos podemos preguntar los siguiente:
- ¿Cómo podemos interferir entre la recepción de un mensaje y el envío del ACK para realizar la llamada a un servicio web externo a Mirth Connect?
- ¿Cómo podemos construir nuestro ACK a partir de una respuesta externa?
- ¿Cómo podemos evitar la generación de los ficheros de salida XML si el mensaje no pasa la validación?
Una posible solución utilizando Mirth Connect es implementar un nuevo canal. Este canal realizará las llamadas al servicio web y capturará las respuestas.
Por otro lado, para el canal que ya tenemos implementado, tendremos que configurar un nuevo conector destino que:
- Se ejecute antes que el resto.
- Obtenga y procese las respuestas del servicio web a través del nuevo canal.
- Y modifique los ACK de confirmación de recepción que proporciona por defecto Mirth Connect.
Para desarrollar lo anterior, utilizaremos:
- Un tipo de conector Channel Writer.
- Un tipo de conector Channel Reader.
- Un tipo de conector Web Service Sender.
- Un tipo de conector Javascript Writer.
- La estructura de datos Response Channel Map para establecer la respuesta de un canal.
- Filtros para evitar la generación del XML de salida si el mensaje HL7 original no pasa la validación.
Desde el punto de vista de nuestro sistema consumidor de mensajería HL7, al abordar este nuevo cambio, corremos el riesgo de no poder volver atrás si modificamos excesivamente algo que ya se encuentra funcionando en producción:
- ¿Qué ocurriría si tuviéramos que volver atrás temporalmente porque el servicio web de validación de mensajería no estuviera accesible durante unos días?
Para hacer el caso práctico más completo, veremos que es posible habilitar y deshabilitar la validación mediante un fichero de configuración externo, el uso de los Global Scripts y la estructura de datos Global Map, como ya adelantamos en un artículo anterior.
Utilizaremos la herramienta 7Edit, al igual que en el ejercicio anterior, para la construcción de la mensajería HL7 de prueba y el envío y recepción de la misma por parte de NewModernHIS.
Debido a que se escapa al ámbito del caso que pretendemos explicar y por simplicidad simularemos el funcionamiento del servicio de web de validación de la mensajería sin entrar en detalles. Aunque sí explicaremos brevemente cómo utilizar la herramienta SoapUI para probar la correcta simulación del servicio web.
Todo lo veremos al detalle en el próximo artículo.
Deja una respuesta