By Tim Kaschinske

This is the fourth blog in a series focusing on how healthcare organizations are dealing with unprecedented volumes of unstructured data and how this impacts the holistic view of the patient’s data.  The previous blogs are available here:

Much Ado About Unstructured Data

IHE, Hard at Work Solving Healthcare’s Big Data Dilemma

How Radiology and Oncology Deal with Multiple Forms of Patient Data

In this blog I will address the challenges surrounding patient identification in current healthcare environments.

Multiple Patient ID Scenario

A very common problem in regard to patient identification is a situation where there are multiple patient IDs for a given patient.  How can this happen?  Consider the scenario where a healthcare system has acquired two different hospitals in the same region.  Patient “John Jones” has visited both hospitals, has data at each hospital, and each hospital has assigned him a different patient ID.  As a result, John Jones has two different patient IDs within the same healthcare system.

This results in two problems when data from both hospitals is combined into a single system:

  • Patient ID Collisions
  • Patient ID Fragmentation

Patient ID collisions occur when two patients have the same patient ID in different systems, and that data is combined in a central system.  In the example above, John Jones has patient ID “1234” at Hospital A, and Fred Smith has patient ID “1234” at Hospital B.  If the data from both hospitals is combined into a central system, and a search is performed for patient ID “1234” in that central system, data for both John Jones and Fred Smith will be returned in the search results.  This is a patient ID collision, and is obviously an undesirable result.

 

Patient ID Fragmentation occurs when a single patient has different patient IDs in different systems.  In the example above, John Jones has patient ID “1234” at Hospital A, and patient ID “5678” at Hospital B.  When the data is combined into a central system and a search is performed for patient ID “1234,” only part of John Jones data is returned.  All of the data associated with patient ID “5678” is omitted.

 

If both problems of patient ID collisions and fragmentation are present, then a search for patient ID “1234” will omit some of John Jones’ data, but include some of Fred Smith’s data.  This situation would make any user question the validity of any search in the central system.

Master Patient Index

Many healthcare environments have implemented a Master Patient Index, or MPI, to link the different patient records together and serve as the authoritative global patient ID.  In this scenario, the different patient IDs for John Jones are maintained within those environments, but John Jones is also assigned an MPI of “9876” at both hospitals.  Now, when the data from both hospitals is combined into a central system, and the MPI is used as the primary identifier for patient ID searches, the problems of patient ID collisions and fragmentation are resolved.

There are still a few problems with this environment, however.  In the first place, you need to know the context in which the patient IDs are used, but the context is often not transmitted with the patient ID.  For example, legacy systems at Hospital A may continue to use the local patient ID “1234” for John Jones.  This is valid within the context of the Hospital A legacy system, but becomes ambiguous when the data with patient ID “1234” is transmitted outside of this context.  The same is true for patient ID “5678” at Hospital B. The problem is further complicated when hospitals that have implemented an MPI are subsequently acquired.  You now could have multiple MPI’s for a given patient.  A method for keeping track of the context of any giving patient ID is required.

Fortunately, IHE has worked to help resolve these problems by defining the Patient ID Cross-reference, or PIX, integration profile.  With PIX, different patient ID domains are defined that establish the environment, or context, in which a patient ID is valid.  Note that one patient ID domain may contain other patient ID domains, as is the case with an MPI.  It is the job of the PIX manager to keep track of the different patient ID domains and their patient IDs.

Patient ID Domains

So, in our previous example there would be three different patient ID domains.  Hospital A would have one patient ID domain, Hospital B would have another patient ID domain, and the Healthcare System would have the global, MPI domain.

Domain identifiers are required and need to be included with the patient ID in order to know the domain for any given patient ID.  Both HL7 and DICOM support the use of an “Issuer of Patient ID” or IPID fields to communicate the patient ID domain.  The first step is to define a domain identifier for each patient ID domain and ensure that it is included in the IPID field with every patient ID.

In our example, Hospital A is assigned the domain ID of “SiteA,” Hospital B is assigned the domain ID of “SiteB,” and the global MPI domain is assigned the domain ID of “MPI.”

As mentioned before, the PIX manager keeps track of the different patient ID domains.  If it is given the IPID and patient ID of one domain, it can look up and return the IPID and patient ID of any other domain for a patient.

The final result is that the different patient IDs are uniquely defined for each environment.  If data for John Jones is transmitted to the central system with an IPID and patient ID of “SiteA,” “1234” then the central system can query the PIX manager using this information to obtain the IPID and patient ID of “MPI,” “9876” for the global MPI domain.  The same thing happens when data from Hospital B is transmitted using the IPID and patient ID of “SiteB,” “5678”.

The result is that each patient ID can be used within the context of its domain to correctly identify a patient.  Again, this is the desired future state.  To reach this state, applications must support the use of the IPID field in their transactions to identify the different domains, a PIX manager must be implemented, and each application must support the ability to query the PIX manager.

In my final blog, I will talk about some of the possible solutions that exist within the healthcare market today.

Download the BridgeHead whitepaper: VNA Does Not Equal Image Availability: What You Need to Know