Instalación y adaptación de EMPI en modo Standalone - Notificando altas y vinculaciones a sistemas externos

Revisando los diferentes artículos que he ido publicando he caído en la cuenta de que me faltaba explicar una funcionalidad bastante práctica dentro de nuestro EMPI (Enterprise Master Patient Index) y no es otra que la notificación de altas y vinculaciones a sistemas externos al EMPI.

Esta funcionalidad es francamente útil en una herramienta como es el EMPI y sobretodo en entornos como el sanitario en el cual es muy habitual que un mismo paciente tenga sus datos duplicados en diferentes sistemas y que al final es necesario identificar univocamente. La solución para reducir dicha amalgama de registros es la fusión de todos esos datos en un registro único que unifique toda la información disponible.

Por lo general este trabajo de decidir que registros deberían ser fusionados es bastante complejo si se pretende realizar a mano ya que es muy complicado tener acceso a los diversos sistemas que contengan información de pacientes (sistemas como el HIS, RIS, LIS, etc de diferentes proveedores distribuidos por los diferentes centros de la organización de salud), pero gracias al sistema de vinculaciones del EMPI esta tarea se simplifica al automatizar la gran mayoría de dichas vinculaciones.

¿Cómo podemos informar a todo ese ecosistema de aplicaciones que debe fusionar dos registros de paciente? Pues bien, veámoslo:

Configuración de EMPI

El primer paso para poder empezar a generar notificaciones es configurar el registro de notificación PIX:

Aquí podemos ver que por defecto tenemos dos registros de notificaciones:

Uno de los registros es para notificaciones PIXv3 mediante mensajes de HL7 v.3 (en XML) mientras que el otro será PIXv2 que utiliza mensajería HL7 v.2. 

Para poder generar los mensajes necesarios deberemos o bien definir los dominios en el campo definido por defecto o marcar la casilla All Domains, este concepto de dominio corresponderá con el de Autoridad de Asignación (servicios de salud, centros hospitalarios, etc). Con este paso estaremos definiendo los consumidores de nuestro mensaje de salida, si no definimos ningún dominio el mensaje no se generará.

Ahora abrimos la producción que gestiona el funcionamiento del EMPI echemos un vistazo al Business Process HS.IHE.PIX.Manager.Process que será el encargado de la creación de los mensajes de respuesta.

Prestemos atención a la configuración de dicho BP, como véis tenemos dos parámetros PIXv2Operations y PIXv3Operations que están configurados con 2 business operations de nuestra producción, el primero de ellos será el encargado de recibir un mensaje HL7 v.2 y el segundo un mensaje de HL7 v.3.

Veamos ahora el BO  PIXv2.Notification.Operations:

Como podéis ver hemos definido un BO de la clase EnsLib.HL7.Operation.FileOperation ya que simplemente nos limitaremos a escribir el mensaje HL7 de actualización de los datos de paciente generado a un fichero del servidor, pero podríais utilizar cualquier business operation que tengáis desarrollado y que acepte mensajes de HL7 como entrada, pudiendo reenviarlos vía TCP, incrustados en un SOAP o mediante una llamada REST a una API externa.

Pruebas

Veamos un ejemplo de lo que ocurre con dos pacientes en estado de revisión de la vinculación tras vincularlos normalmente.

Vincularemos a los dos primeros, Juan García y Roberto Martín. Una vez realizada la vinculación veamos la traza del mensaje:

Aquí tenemos nuestro mensaje HL7 generado de tipo ADT_A31 en el que informamos de la actualización del paciente que se ha vinculado con el nuevo MPIID, ahora el paciente Roberto Martín con MRN 556432 del Hospital 12 de Octubre ha reemplazado su antiguo MPIID (100001000) por el mismo que tiene Juan García (100000001). 

Nuestro EMPI mantendra un registro para cada paciente, creando únicamente la vinculación con el MPIID asignado a ambos. Con este mensaje ADT_A31 ahora sería responsabilidad del servicio de salud o del hospital fusionar ambos pacientes en uno sólo.

Conclusión

Como hemos visto en este artículo, el EMPI dispone de funcionalidades preconstruidas que cubren las necesidades de cualquier organización de una forma sencilla y ágil y nos permite ampliarlas para cubrir aquellas que sean más específicas de cada cliente, una de ellas sería precisamente la de notificaciones automáticas a cualquier aplicación externa.