Managing Patient Identifiers

Managing patient IDs in healthcare IT is difficult. There's no way around it. Patient P at Health System H might have 20 different identifiers; at least one per software vendor, and in the case of the major EHRs like Epic and Cerner, they could have 5 different IDs for one patient just within that system. And, of course, when you look up that same patient in a different health system, they will have a completely new set of IDs.

As an application developer, this can be a nightmare. Something as simple as querying for a patient's CCD becomes a major chore when you have to constantly be figuring out which ID you should be using in which situation. Usually you have to maintain a table of all the patients' IDs for a particular health system, have some logic built into the application to determine which ID to use in which situations, and be sure to update that table with any new IDs you receive from the health system.

To make things more complicated, from time to time health systems figure out that two different patient records in their system actually correspond to the same patient. To fix the situation, they perform a patient merge, merging the two charts into one. Usually the health system is nice enough to notify all connected systems of the patient merge, generally through an HL7 version 2 message. At this point it is on the connected applications to perform their own patient merge, something that can be programmed, but often requires manual intervention. 

The kicker is that all of this complexity lives within one health system, and if you are a developer connecting an application to multiple health systems, trying to figure out which patient in health system B is the same patient as the patient in health system A is laughably difficult.

So how do you solve this problem? Well, it would be simple if only there were some number that every patient had that could identify them no matter where they were. A personal security number perhaps? One might even call it a social security number?

Using the social security number is certainly one approach. But there are a couple problems with that.

1. Not every patient in an EHR will have a social security number. There are a couple reasons for that, but essentially it boils down to not all patients being US citizens, and not all patients providing their SSN when they enter a health system.

2. Not all health systems want to share social security numbers with third party applications. This is about reducing exposure to sensitive data.

So if SSN doesn't always work, what else can we try?

We know matching on name won't work well, since many patients share the same name. But what about some kind of more complex matching algorithm? Combining name with address, phone number, or something of the sort?

This can work, but it's not perfect, and it's not easy. Patient names aren't always typed the same in each system, and addresses and phone numbers change. The algorithm has to be smart enough to match when there's a clear match, but error out and force a manual review when the match doesn't meet some threshold. Think about how hard it can be to match patients between health systems manually, using all your powers of reason, then imagine trying to program it. It would be a good project for a Computer Science masters thesis in artificial intelligence.

There may be other ways to try and solve this problem, but suffice it to say that no one has come up with a solid, scalable, easy solution yet. At least not that I've seen.

It should be noted that the same problem used to exist for providers, but CMS has helped solve that problem by giving every provider an National Provider Identifier (NPI). Forcing providers to apply for an NPI is something that works in the medical field, because it is tied to a provider's work. Forcing patients to do something like this most likely wouldn't go over quite so well.

Here at Redox, we're starting simple. We have a patient model, and for each health system, patients get a list of identifiers. In this way we can provide one Redox Identifier to all of our customers for the same patient within the same health system. They can then use this identifier to communicate back and forth with us. The downside is that the same patient will have multiple Redox IDs if they are in multiple health systems. We simply have no way of cross referencing the patients between health systems without collecting more patient information, which is something we're hesitantly exploring with the cooperation of a few health systems.

Eventually, we'd like to solve the problem of Managing Patient Identifiers. Clearly it's not an easy task, and it's one where security and patient privacy are of utmost importance. As we connect more health systems to more applications, we'll continue learning what it's going to take to solve the problem across the board. 

Until we get there, we encourage you to share your strategy with the community. What works? What doesn't work? Any success stories out there that others can learn from? Join the discussion here.