EMPI installation and customization in Standalone - Patient data ingestion

We start this new article refreshing what we did in the previous EMPI configuration articles:

• Installation in Standalone mode the Patient Index on a HealthShare instance.
• Configuration of basic parameters to start working with the EMPI.
• Definition of indexes and weights for NICE process.

Very well, we are practically ready to start rolling our EMPI. We only have one detail left, to start the production created by the installation to be able to start working.

Here we can see the different components that we have available to work with our EMPI. As you can see we have Business Services for the admission of HL7 files, web services for queries and patient registrations, etc..

In our example we are going to use the one corresponding to the ingestion of HL7 files and for this we will slightly modify its default configuration:

We are going to use 2.5.1 HL7 messages version and the character encoding will be UTF-8, since the data of our messages will include accents in the patient information (very common in spanish).

We would not need to configure anything else, so we can proceed to start production and feed it with randomly generated messages. We will use messages of various types with slight modifications to see how the process works.

We will start with messages ADT^A08, which by definition is the message to update patient information.

MSH|^~\&|HIS|HULP|EMPI||20230330133546||ADT^A08|944784|P|2.5.1
EVN|A08|20230330133546
PID|||50605003N^^^MI^SN~184001^^^HULP^PI||CABEZUELA SANZ^PEDRO^^^||20160627|M|||PASEO JULIA ÁLVAREZ 395 3 E^^MADRID^MADRID^28909^SPAIN||555710791^PRN^^PEDRO.CABEZUELA@GMAIL.COM|||||||||||||||||N|
PV1||N
OBX|1|NM|162986007^Pulso^SNM||52|^bpm|||||F|||20230330133546
OBX|2|NM|105723007^Temperatura^SNM||35|^Celsius|||||F|||20230330133546
OBX|3|NM|163030003^Presión sanguínea sistólica^SNM||118|^mmHg|||||F|||20230330133546
OBX|4|NM|163031004^Presión sanguínea diastólica^SNM||61|^mmHg|||||F|||20230330133546

For those of you who do not have much experience with HL7, just indicate that it is a set of standards for the electronic exchange of clinical information. Its format is the one you see in the previous example, a plain text message divided by a series of special characters that each carry a certain piece of information. Each message line corresponds to a segment of the message with a specific type of information.

In our case, the segments that will be used by the EMPI will correspond to the MSH (message header segment with information about it) and the PID (Patient Identifier, segment with message administrative data).

Let's see what the most relevant data will be:

• MSH.4: HULP. This field informs the center or facility that sent us the message. We have chosen the initials of a hospital in Madrid (University Hospital of La Paz). This information will be relevant in the case of absence of this information in the patient identification segment.
• MSH.6: ADT^A08. It corresponds to the type of message we are sending. Depending on its value, the message will use some segments or others.
• MSH.9: 2.5.1. Message schema version. It will also be relevant, since depending on the version the layout of the fields may vary. Keep this information in mind as it will be very useful in subsequent articles to deal with the issue of adaptation/customization of patient data as we will create a personalized scheme.
• PID.3: 50605003N^^^MI^SN~184001^^^HULP^PI.In this field we will inform the identifiers of the patient. For our example we have included two. The first will correspond to the National Document of Identity or spaniard ID card (50605003N) issued by the Ministry of the Interior (MI) and corresponds to a serial number (SN). The second is the medical record number (184001) of the La Paz hospital (HULP) and is a patient identifier (PI).

Do you remember when we defined the Affinity Domain with the EMPI value in the configuration? Well, if we had not done so when receiving this message, our EMPI would not generate a new code for the patient, but would directly assign the value 184001 used by the HULP. This can be useful for facilities where no more patient identifiers will be received, but this is generally not the case.

Very well, let's inject 50 messages to see how they are recorded in our system by copying the file to the path indicated in the Business Service.

Here we have the trace of one of the registered messages. As you can see, it has been ingested by the Business Service configured to admit HL7 files EnsLib.HL7.Service.FileService, then it has been passed to the Business Operation HS.Hub.Standalone.HL7.Operation where the message data has been transformed from the HL7 format to the SDA format used by EMPI:

As a quick overview, the SDA is nothing more than the XML format used by HealthShare to represent the clinical information stored in its system.

As you can see, the system has automatically captured all the relevant information for the EMPI present in the received message. You can see how the medical record number is not in the list of identifiers, this is so because we have defined it as the most relevant patient identifier for the organization (PI), so it has been extracted to the <MRN> field (Medical Record Number).

Perfect, we are already storing our patient data in the EMPI, congratulations! We are going to search for the patient of this message from the patient search option of the Healthshare management portal.

We will only search by the last name to see all the available matching patients.

Here we have the result. 4 patients registered in the system with the surname Álvarez. If you are wondering what the value of the Rank column means, it is simply the probability that this patient is the one you are looking for. As we have only defined one surname, all those who have that surname have the same probability (it is a probabilistic search). If we introduce more fields in our search, we will see how said probability changes, increasing for those that are closest to the search performed.

Another detail to take into account. We have assigned each patient a new code generated by our EMPI, the MPI (Master Patient Index). This identifier will only be relevant within the EMPI and will be used internally to later link or unlink patients without mixing their information.

As we have previously indicated, by defining an Affinity Domain other than the organization that assigned the clinical record number and which we define as the patient's index, the system has generated its own. Let's see how our patient Antonio Álvarez Margall (yes, we have 2 last names in Spain) has been registered in the system by clicking on the last of the three icons that appear on his line.

From that icon we will have access to what is known as "Composite View". It will be especially useful for us when we record more patient data from other sources, since it will allow us to see as many columns of data as there are sources of data and select the most relevant ones, but don't worry for now, we'll see it in the next article when we talk about the work list management.

In this composite view you can see the administrative data that has been defined in the Local.CompositeRecord.Transient.Definition class (yes, the same class defined in the configuration in the \HSPI\CompositeRecordDefinition parameter). This class is fully customizable by users and as it belongs to the Local package it will not be overwritten in future EMPI updates.

Well, this would be the fastest and easiest case of data ingestion by the EMPI. As you have seen, putting it into operation is not complicated at all with the tools that it provides us by default.

In this example we have used one of the Business Services that provides us with the production generated by the installation in Standalone mode of EMPI for the ingestion of HL7 messages, but we could design all those that we need, from REST or SOAP type web services, sending files by FTP, TCP messaging, etc. In this URL of the official documentation you have an example of how it could be developed.

Well, that's all about patient data ingestion into the EMPI. In the next article we will proceed to feed our production with more HL7 messages with a different source and we will review the management of the work list.