Determine the combinations of fields that should trigger a merge

Background and Strategy

Ursa Studio includes a suite of very flexible tools that are used to execute the matching logic central to master data management. These tools can be configured in the Master Data Management Record Matching panel of any Integrator object; when so configured, Ursa Studio performs a post-processing step (after executing the object logic as usual) that applies the specified matching criteria to the resulting records and generates a single additional field on the object representing the new “mastered” identifier for each original record.

Configuring the matching logic involves identifying one or more Matching Criteria Sets, composed of one or more fields (or Field Families; more on those below). Each Matching Criteria Set represents a scenario in which two records meet the minimum criteria for a match by virtue of sharing identical values in all the fields in the set. For example, a Matching Criteria Set for mastering patients might consist of just a single field, like Patient SSN, meaning two records with the same Patient SSN value would be matched; or might include multiple fields, like Patient First Name, Patient Last Name, Patient Date of Birth, and Patient ZIP Code, in which case only patient records that share the same first name, last name, date of birth, and ZIP code will be considered matching. Each Matching Criteria Set is evaluated independently, and a pairwise record match occurs if any one of them returns a positive match.

The concept of Field Families extends this basic matching functionality, allowing users to identify “families” of two or more fields that should be considered interchangeable for the purposes of matching. This is particularly useful when there are several very similar fields on hand, each of which might contain a matching value. For example, consider a situation in which the patient record includes fields for Home Phone and Cell Phone, and we want to enforce a matching rule that two records should have the same phone number regardless of which of those two fields is used to store it. This could be accomplished by creating a Field Family composed of those two fields and including that Field Family (as if it were a single field) in a Matching Criteria Set; with that configuration, a positive match on that criterion will occur when any of the following are true:

Record 1 Home Phone = Record 2 Home Phone
Record 1 Home Phone = Record 2 Cell Phone
Record 1 Cell Phone = Record 2 Home Phone
Record 1 Cell Phone = Record 2 Cell Phone

One special case for which this Field Family functionality can be harnessed is to perform matching between current and prior identifier values. For example, CMS periodically changes the unique identifier for a Medicare beneficiary, but will helpfully provide, as part of certain data packages, a “cross-reference” file containing both the current and previous identifier values. Creating a Field Family containing these two identifiers, and setting up a Matching Criteria Set with that Field Family as its only element, will result in the desired matching behavior: older records with the prior beneficiary identifier will automatically be matched, during mastering, to the new identifier.

This system of pairwise matches between two records can sometimes result in chains of “transitive” matches. That is, records A and B match, and records B and C match, but records A and C don’t match. (This would only occur, naturally, when A and B matched on different criteria than those B and C matched on.) For the purpose of mastering, the desired result is for all three records to be considered matching. In databases that allow recursive queries, Ursa Studio automatically resolves these kinds of transitive matches, tracing the chain of matches as long as necessary to connect all records involved. In databases that don’t support recursion, the user can configure the Resolve X Transitive Matches field to simulate this recursive behavior up to a certain number of matches.

Detailed Implementation Guidance

1. For a reference example of how a plausible set of matching criteria for patients can be set up in Ursa Studio, review the pre-fab patient mastering object in the Core Data Model, Source Local Patient ID Crosswalk to Data Model Patient ID.