The Tale of a Patient - or Two?

Exploring the difference between patient data matching and patient identity.

Registration details for the same individual often have slight variances between systems. Depending on the data that was collected, the timing of the collection, and other factors, such as human error, the ability to match records across a health care organization can be difficult to achieve. Patient data matching involves comparing a set of individual attributes to determine if two or more records indicate they belong to the same patient. In other words: the more attributes or data points that are the same, the more likely the records belong to the same patient.

Consider this sample record comparison (use case 1):

While not every data point is an absolute match, we can determine that it is very likely (with a high degree of confidence) that the two records being compared belong to the same individual.

Now, consider this sample record comparison (use case 2):

In this record comparison, only date of birth (DOB) and Sex are an absolute match and First Name is a close match; all the other fields are different.

Is it possible that Record C and D belong to the same individual? Hard to tell simply based on the details listed here. This is patient matching.

Algorithms, such as probabilistic matching which leaves potential for a false positive or a false negative outcome, combined with “fuzzy logic”, like possible nicknames, enable a system to calculate how likely record C and D belong to the same patient. Even with strong patient matching methods, records C and D may have been labeled as two separate patients because they were not a probable match.

Let’s look at how the patient identity concept would have resolved use case 2 from the get go. A recommended first step in patient identity process is known as “Identity Proofing”.

Imagine when Jessica first arrived at hospital C and she was asked to supply a valid drivers’ license to aid in the confirmation of her identity. In this case, her drivers’ license displays her legal name is “MYRTLE JESSICA JENKINS” and the address listed is listed as “475 Millers Way”.

Then, hospital C runs an automatic verification via 3rd party source to check Myrtle’s details. It is learned that her current address is “12908 West Broad Street, Unit 3”, the “89 Elm Street” address as seen in her record is a PO Box, and the “475 Millers Way” address on her drivers’ license is where she lived several years ago and hadn’t had the chance to update her record at the DMV.

If these steps are performed by hospital C, the registration experience at hospital D will result in a more accurate understanding of Myrtle’s demographic details.

A recommended second step to the patient identity concept is authentication.

Now imagine that hospital C provides Myrtle with a strong authentication token to use within its healthcare enterprise each time she visits one of the HCO’s facilities. An example of a token might be a fingerprint biometric which is linked to her record at hospital C.

Myrtle’s next visit is at facility D and she uses her fingerprint biometric to check in for her visit. This process confirms her identity and her record details that were originally established at hospital C can be made available to facility D. This would allow facility D to insert those same, verified details into its health IT system or chose to independently verify beforehand. In this scenario, facility D’s standard operating procedure is to independently verify all demographic details even when they come from another facility within their enterprise. Upon verification, they learn that Myrtle got married and changed her last name to “Longstreet” and moved to a new home since her last visit to hospital C.

Now Myrtle’s singular identity that is known and her fingerprint biometric is affiliated with two different medical record numbers at different organizations.

And because the verified attributes in system C and D have been proofed, the manual record search is comprised of reliable details. With the patient identity concept, the EMPI that disambiguates identities within the enterprise knows with a higher degree of confidence that Myrtle Longstreet and Myrtle Jenkins are the same person.

Patient data matching and the patient identity concepts are complimentary, yet different. The combination of methods would produce a single, correct match every time.

Catherine Schulten

About the Author

Catherine Schulten is VP of Product Management at LifeMed ID where she is responsible for orchestrating product roadmap initiatives and ensuring that LifeMed ID’s solution offering meets industry user needs. Catherine has over 25 years of health information technology experience addressing industry challenges from revenue cycle, HIPAA transactions, fraud, waste and abuse, and patient identity management. She has served as a WEDI board member and has co-chaired several WEDI workgroups.