Why using Unique IDs from third-party data providers in your patient matching can be a challenge
Recently I’ve had the same conversation with multiple customers. These customers have an existing master data management (MDM) or enterprise master patient index (EMPI) system. These same customers recognize that (a) they spend a lot of time reviewing near-misses or potentially duplicate records, and (b) they know they have many false negatives (i.e. duplicate records that should be merged but are currently separate).
They’re looking for a way to bring these records together automatically – without having to manually review each one. Interestingly, they’ve arrived at the same approach and wanted to discuss it with me.
The approach they’re inquiring about is: Send their data to a third-party data provider (you know the usual suspects), and have the data provider assign a unique ID to their data. Something like a “PersonID.” Then change the matching algorithm within their MDM/EMPI to include this “PersonID” to assist in the person/patient record matching.
The classic example is: We have two records with the same name, same address, and same phone, but one has a date of birth and the other has an SSN. We just need a little bit more confidence to push these records together automatically. If we had this PersonID attribute and it was the same for both records, we could confidently merge these records automatically. That is, the PersonID would be the gentle push over the cliff that the matching engine needs in order to automatically match the records.
In concept, I get it. In practice, it doesn’t really work that way.
To see why, take this example. You have two records that have the same last name, address, phone number, and date of birth, and each only has a first initial “M.” Including a PersonID within the match rules would push these records together. But the problem here is you’ve already tuned your existing matching algorithm to avoid creating false positives – and therefore it might otherwise keep records like these apart in case they are twins, for example. But when you introduce the PersonID, you have essentially granted the ability to create false positives to an external vendor – and you have no insight into the vendor’s matching engine, nor whether future changes they make on their end will honor or behave the same way as today.
Furthermore, in cases where records represent the same person but have wildly different data (think a maiden name and old address vs. a married name and current address), the PersonID would need to be weighted heavily in order to automatically merge records together. But this would increase the chances of creating more false positives, as well as contradict the philosophy of using the PersonID to gently push matching decisions over the cliff.
In both examples, you’ve placed such importance on the PersonID at the expense of the original matching algorithm.
Congrats, you’ve just lost all the value of the matching engine you spent so much time building and configuring.
You’ve also introduced an insidious data audit/data quality issue, in that it becomes very difficult to track and tell why records came together. Did they come together by themselves, or did the third party’s PersonID force them together?
On the other hand, Verato Auto-Steward provides a much gentler and more nuanced approach to auto-merging the near-misses and finding the “not so near” misses. It sits alongside your existing EMPI or MDM – without replacing it and without disrupting any of your existing workflows or business rules. You can track every match it makes, you can interrogate the reason the decision was made, you can build rules around the decision evidence, and you can fine-tune the consumption of those decisions. Most importantly, the Verato team has the expertise to help guide you on best practices, customer implementation styles, and avoiding project hurdles.