Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

When matching patients based on demographic data are there any recommendations on what fields should match for the patient to be the "Same Patient"?

I know the algorithms will be different for different implementations, I'm just curious if there are any best practices or recommendations around this process.

First Name
Last Name
Date of Birth
SSN
Address
City
State
Zip

etc?

share|improve this question
4  
Probably the answer to this question may also change depending on the specific country or even on ethnic and cultural considerations. For instance the name of a person may not be a good patient identifier for australian aborigines (or it should be given a lower "weight" in their case) since they may change name over time. Australian aborigines who bear the same name as a deceased abandon it becuase they consider it is very bad to carry the same name of someone who is dead. Something similar happens in other cultures were the name of the dead is taboo.link –  MMattoli Oct 20 '11 at 2:59
4  
Or another example from a as-yet-unpublished study: in Filipino immigrants to the US, the ten most common surnames account for about 6% of all people. In Vietnamese immigrants, they account for ~60%. Names are a significantly better identifier in the Filipinos than the Vietnamese. I'll definitely post that study once it's available. –  Matt Parker Oct 20 '11 at 17:23
    
Just to clarify: is the primary aim to match two sets of records? –  Iterator Nov 6 '11 at 15:16
    
When attempting to match records, be sure to distinguish between the strength of a match ("Bob" is very similar to "Bob") versus the number of possible matches (there are many Bobs). If two records have the same name and there are no other records with that name, it's probably the same person even if the addresses differ. Assuming you have a large corpus, of course. –  Jon of All Trades May 2 '12 at 15:21
add comment

migrated from healthcareit.stackexchange.com May 1 '12 at 21:45

This question came from our site for healthcare IT professionals and solution providers.

7 Answers

up vote 19 down vote accepted

There's this great essay (in spanish, sorry) written by Pablo Pazos, a CS Engineer from Uruguay who has been working on Healthcare IT since 2006 and has made some great contributions to the field, in which he describes an algorithm for doing this.

You can run the article through a translator, but the gist of it is that the basic info to determine a person's identity are their given and family names (both from father and mother), sex, and date of birth. Interestingly enough, he specifically excludes id numbers like SSN from his identity matching algorithms, since "any kind of identifier is NOT part of his identity" (I guess this point could be debatable, though). Also, he excludes attributes like street address, phone numbers, etc. since they aren't really related with the identity of someone, they aren't associated with "who someone actually is".

Also, he assigns different "weights" to each of the former attributes, like this:

  • First name: 17.5%
  • Middle name: 17.5%
  • Family name (father): 17.5%
  • Family name (mother): 17.5%
  • Sex: 10%
  • DOB: 20%

With the matches found on every one of these attributes, he describes a methodology to obtain a composite "concordancy match index" with which comparisons between records can be possible. Also, "partial" matches on the name attributes are possible by using algorithms like Levenshtein's distance.

Good read, IMO. Sorry it's in spanish, but I hope I was able to convey its main ideas.

share|improve this answer
2  
this is great, thanks. +1 also for mentioning distance as typos are quite common especially in communities with high diversity of cultural background as is often the case in North America. That said, most of the instances where I have to perform matches the domain of possible values is quite restricted. So in these cases any reliable criterion (such as health insurance numbers) that return a single hit in the database will be sufficient, if multiple entries is returned I tend to either ask the user (if available) or filter with additional criterion. –  Newtopian Oct 20 '11 at 5:08
    
(...contd) Note though that these cases apply well to local installation of an EMR to a clinic or hospital, or a RIS to a radio9logy department. In these cases the customer is either registered in the clinic or hospital or is not. In cases of MPI however this is a whole new ball game. –  Newtopian Oct 20 '11 at 5:11
add comment

There is no single magic algorithm for patient matching, and I doubt there ever will be.

For starters, there are regional variances. As MMattoli pointed out, what works well in an urban United States hospital probably won't fit well in a rural Australian clinic treating Aborigines.

Also, individual sites have differing views on fault tolerance. If you only matched when you were absolutely sure, you'd get a lot of missed matches. This causes duplicate patient records, which creates a whole other set of problems. Most sites will be willing to settle for pretty sure, but how sure is sure enough? Ask 10 people and you'll get 12 answers.

Therefore the "best" algorithm will be configurable, so your customers can tune it to fit their needs.

When considering a match, different fields offer varying degrees of confidence.

Healthcare-specific identifiers offer the most confidence, since their whole purpose is to uniquely identify the person within the health system. Hospitals usually take pains to make sure these do not get duplicated.

Examples:

  • National Health ID (e.g. UK NHS Number)
  • Hospital-assigned Medical Record Number.

Other patient identifiers may offer high confidence as well, depending on the system. For instance, a Military ID is probably very relevant in a military hospital.

Examples:

  • Military ID
  • Insurance ID
  • Social Security Number (In the US, Social Security Number is generally not considered a high-confidence match, due to rampant insurance fraud.)

In absence of unique identifiers, one must resort to demographic information. It is ill-advised to match on any one field, but the more demographic field match, the more confident the match.

Things about a person that don't often change are good for matching:

  • Name
  • Gender
  • Date of Birth

But even more malleable information can be considered in the match to boost confidence:

  • Address
  • Phone Number
  • Email Address
share|improve this answer
3  
SSN also has some very strict restriction, for example in Canada it is illegal to even ask for it unless you are en employer or a bank (perhaps some more too, I'm not a lawyer). Other places like China they use it for almost anything, even to purchase train tickets during high traffic holidays. –  Newtopian Oct 20 '11 at 5:03
    
Name changes are common if you are female. And two people often have the same name and even live in the same place (father with a son namesd after him for instance). –  HLGEM May 2 '12 at 15:09
    
@HLGEM: Entirely correct, which is why no single demographic field should be used for matching. But when folks do have to resort to that, the more static fields (which nonetheless do sometimes change) are more reliable than the alternative. That doesn't make them good, though. –  Lynn May 2 '12 at 19:51
add comment

It is also worth checking previous lastnames as these often change.

share|improve this answer
    
+1 "often" is an understatement. :) This can certainly be the case for patients who are not identifiable or unnamed, newborns, misidentified, and so on. Names are more difficult, yet more significant, in an environment with a lot of transactions. –  Iterator Nov 6 '11 at 15:14
add comment

Apart from obvious combinations of the following three given in your question

First Name
Last Name
Date of Birth
City
State
ZIP/Pin Code

I would think of adding phone number (Home and/or Cell) to the list. These days it is quite common and every will have a unique number and even if some times people change their phone numbers, older phone numbers are remembered by most people, so can come handy.

We found address often suffers from multiple spellings and multiple ways of rendering especially in countries like India where people use a local language and patient management softwares 'still' uses English.

share|improve this answer
add comment

The gender in the records seems often be derived from First Name. I have seen increased variance in gender for foreigners, when we can't derive the gender from the name.

In Germany we have some further variances with names containing the 'Umlaute' like 'äöü', which are sometimes replaces by 'ae oe ue'.

share|improve this answer
add comment

My thought is in the order as below 1). SSN, Last name, and first 5 chars of first name 2). SSN, Birthdate and first 5 chars of first name 3). SSN, Birthdate and last name 4). SSN, Gender, Birthdate 5). Last name, first 5 chars of first name ,city and zip

share|improve this answer
add comment

This is a really tough problem in the US. Names are not unique and often change during a person's lifetime or are presented differntly (Rob versus Robert for instance), so they can never be used to identify the patient except in conjunction with some more realiable information. Health insurance number and provider changes much more frequently and may be the same for multiple members of the family. SSN is supposedly unique, but there is fraud around it. Same with Driver's liscense number which of course not everyone will have.

Personally, I would start with insurance policy number and date of birth and name combination, then ssn and date of birth and name combination. I would check address and phone to give me additonal assurance when they match but not much weight if they don't. Additonally I would use blood type as a rule out factor if it is known (and we all know the hospital vampires will be taking blood samples) as that doesn't change. Name matching would have to be fuzzy match due to the name varaition problem. Other things should generally look for an exact match first themna fuzzy match if the name confidence is really high (could have been a typo entering the SSN).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.