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:
.png)
Here we can see that by default we have two notification records:
.png)
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.
.png)
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:
.png)
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.
.png)
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:
.png)
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.
.png)