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.
Directory to restore [? for help]: /usr/irissys/mgr/t1 /usr/irissys/mgr/t1/??
No database exists in that directory.
(you will be required to redirect to another directory)
Redirect to Directory: /usr/irissys/mgr/t1/
=> /usr/irissys/mgr/t1rest--> /usr/irissys/mgr/t1rest/
Process all globals in /usr/irissys/mgr/t1/? No =>yes
さらにリストア対象データベースがある場合は同様に指定しますが、ない場合は、Enterを押下します
Directory to restore [? for help]:
ここまで指定したディレクトリリストを表示します。変更がなければyesを入力します。
Processing globals from the following datasets:
1. /usr/irissys/mgr/t1/ All Globals
(Redirect to: /usr/irissys/mgr/t1rest/)
Specifications correct? Yes => yes
最終行の質問は、ひとつのジャーナルファイルのリストアが完了して次のジャーナルファイルをリストアする前にプロンプト(入力待ち)をするかどうかです。自動的に指定したすべてのジャーナルファイルをリストアする場合は no を入力します。
Specify range of files to process
Enter ? for a list of journal files to select the first and last files from
First file to process: ?
1) /usr/irissys/mgr/journal/20240425.003
2) /usr/irissys/mgr/journal/20240425.004
3) /usr/irissys/mgr/journal/20240426.001
4) /usr/irissys/mgr/journal/20240426.002
First file to process: 4 /usr/irissys/mgr/journal/20240426.002
Final file to process: /usr/irissys/mgr/journal/20240426.002 =>
Prompt for name of the next file to process? No => no
The following actions will be performed if you answer YES below:
* Listing journal files in the order they will be processed
* Checking for any missing journal file on the list ("a broken chain")
The basic assumption is that the files to be processed are all
currently accessible. If that is not the case, e.g., if you plan to
load journal files from tapes on demand, you should answer NO below.
Check for missing journal files? Yes => Yes
Journal files in the order they will be processed:
1. /usr/irissys/mgr/journal/20240426.002
While the actual journal restore will detect a journal integrity problem
when running into it, you have the option to check the integrity now
before performing the journal restore. The integrity checker works by
scanning journal files, which may take a while depending on file sizes.
Check journal integrity? No => No
The journal restore includes the current journal file.
You cannot do that unless you stop journaling or switch
journaling to another file.
Do you want to switch journaling? Yes =>Yes
Journaling switched to /usr/irissys/mgr/journal/20240426.003
You may disable journaling of updates for faster restore for all
databases other than mirrored databases. You may not want to do this
if a database to restore is being shadowed as the shadow will not
receive the updates.
Do you want to disable journaling the updates? Yes =>Yes
Updates will NOT be journaled
リストアを開始する前にデフォルトオプションを確認しています。
デフォルトは、
データベースに関連するエラーが発生した場合でもリストアを続行します。
ジャーナルに関連するエラーが発生した場合、リストアを中止します。
別の方法は、
データベースに関連するエラーが発生した場合中止します。
ジャーナルファイルに関連する問題が発生した場合でもリストアを続行します。
変更しない場合は、デフォルトのNoを指定します。
Before we job off restore daemons, you may tailor the behavior of a
restore daemon in certain events by choosing from the options below:
DEFAULT: Continue despite database-related problems (e.g., a target
database cannot be mounted, error applying an update, etc.), skipping
updates to that database. Affected database(s) may not be self-consistent
and will need to be recovered separately
ALTERNATE: Abort if an update would have to be skipped due to a
database-related problem (e.g., a target database cannot be mounted,
error applying an update, etc.). Databases will be left in a
self-consistent state as of the record that caused the restore to be
aborted. Parallel dejournaling will be disabled with this setting
DEFAULT: Abort if an update would have to be skipped due to a
journal-related problem (e.g., journal corruption, some cases of missing
journal files, etc.)
ALTERNATE: Continue despite journal-related problems (e.g., journal
corruption, some missing journal files, etc.), skipping affected updates
Would you like to change the default actions? No => No
USER>set$namespace="%SYS"%SYS>do^Integrity
This utility is used to check the integrity of a database
and the pointer structure of one or more globals.
Output results on
Device: /usr/irissys/mgr/integ0424.log
Parameters? "WNS" =>
Stop after any error? No=>
Do you want to check all databases? No=> yes
.png)
.png)
.png)
.png)
.png)
.png)
Open Exchange.png)