Reviewing the different articles that I have published, I realized that I needed to explain a very practical functionality within our EMPI (Enterprise Master Patient Index) and it is none other than the notification of registrations and links to systems external to the EMPI.
This functionality is frankly useful in a tool such as EMPI and especially in environments such as healthcare in which it is very common for the same patient to have their data duplicated in different systems and in the end it is necessary to uniquely identify it. The solution to reduce this amalgamation of records is to merge all this data into a single record that unifies all the available information.
In general, this work of deciding which records should be merged is quite complex if it is intended to be done by hand since it is very complicated to have access to the various systems that contain patient information (systems such as HIS, RIS, LIS, etc. from different providers distributed throughout the different centers of the health organization), but thanks to the EMPI linkage system this task is simplified by automating the vast majority of said links.
How can we inform that entire ecosystem of applications that they need to merge two patient records? Well, let's see it:
EMPI configuration
The first step to start generating notifications is to configure the PIX Notification Register:
Here we can see that by default we have two notification records:
One of the records is for PIXv3 notifications using HL7 v.3 messages (in XML) while the other will be PIXv2 using HL7 v.2 messaging.
In order to generate the necessary messages we must either define the domains in the field defined by default or check the All Domains box, this domain concept will correspond to the Assignment Authority (health services, hospital centers, etc.). With this step we will be defining the consumers of our output message; if we do not define any domain, the message will not be generated.
Now we open the production that manages the operation of the EMPI, let's take a look at the Business Process HS.IHE.PIX.Manager.Process that will be in charge of creating the response messages.
Let's pay attention to the configuration of said BP, as you can see we have two parameters PIXv2Operations and PIXv3Operations that are configured with 2 business operations of our production, the first of them will be in charge of receiving an HL7 v.2 message and the second an HL7 message v.3.
Let's now look at the BO PIXv2.Notification.Operations:
As you can see, we have defined a BO of the EnsLib.HL7.Operation.FileOperation class since we will simply limit ourselves to writing the HL7 message for updating the patient data generated to a file on the server, but you could use any business operation that you have developed and that accepts HL7 messages as input, being able to forward them via TCP, embedded in a SOAP or through a REST call to an external API.
Testing
Let's look at an example of what happens with two patients in linkage review status after linking them normally.
We will link the first two, Juan García and Roberto Martín. Once the link is made, let's see the trace of the message:
Here we have our HL7 message generated of type ADT_A31 in which we report the update of the patient that has been linked to the new MPIID, now the patient Roberto Martín with MRN 556432 from Hospital 12 de Octubre has replaced his old MPIID (100001000) with the the same one that Juan García has (100000001).
Our EMPI will maintain a record for each patient, creating only the link with the MPIID assigned to both. With this ADT_A31 message it would now be the responsibility of the health service or hospital to merge both patients into one.
Conclusion
As we have seen in this article, EMPI has pre-built functionalities that cover the needs of any organization in a simple and agile way and allows us to expand them to cover those that are more specific to each client, one of them would precisely be automatic notifications. to any external application.
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
.png)
.png)
.png)
.png)
.png)
.png)
.png)
