False-Positive Merges in a Customer 360 Hub
Meridian Health's Customer 360 program on Informatica MDM loads 3.1 million records from eight source systems: an Epic EHR, a billing platform, two regional CRMs, a patient portal, a marketing automation tool, a legacy mainframe, and a claims clearinghouse. After the initial load the hub holds 940,000 golden records. A review of a 1,000-record sample found that 22% of merges were false positives: siblings sharing a last name and address, and twins with identical dates of birth. Match rules use exact match on last name plus a fuzzy threshold of 70 on address and 65 on first name, with no negative rules. Trust scores are configured per source system, but survivorship is set to 'most recent' on every column, so a marketing opt-in record from the portal overwrites the validated clinical address. The enterprise data warehouse keys on the MDM party ID.
1. How do you reduce false positives without destroying recall?
Read the worked answer
The threshold is not the root cause - exact last name plus a shared household address is a near-exact match under the current rules, so siblings will always pass. Fix the rule logic first.
Sample 300 confirmed false positives and record which rule path fired. Then: (1) promote discriminating identifiers into a high-confidence auto-merge path - medical record number, national ID, verified email or phone in exact match; (2) add disqualifying conditions that block auto-merge, such as different first name and different date of birth, different gender, or conflicting national ID; (3) use probabilistic name matching with token-level comparison rather than exact last name, and reduce address weight when the address is a household; (4) separate twins by requiring first name and gender agreement, since DOB cannot disambiguate them.
Then introduce tiered outcomes instead of binary merge/no-merge: auto-merge above the high threshold, a steward review queue in the middle band, auto-reject below. Measure precision and recall on the labeled sample after each change. Optimizing only for false positives will silently split genuine duplicates, which is more expensive to repair downstream.
2. How should survivorship be redesigned?
Read the worked answer
Replace 'most recent on every column' with cell-level survivorship driven by column-specific trust.
Build a survivorship matrix: for clinical address, the Epic record outranks the patient portal; for marketing email, the portal's consent-based record should win; for national ID, only sources flagged as verified may contribute. Each column gets a trust-ordered precedence list plus a fallback chain, and within a trust tier a recency tiebreaker.
Handle nulls explicitly, or a NULL from the highest-trust source will blank a valid golden value - a common and damaging configuration error. Record which source won each cell so a steward can explain any value in the golden record.
Publish the matrix in the business glossary and review it with the data owners from each source system, because survivorship is a business policy decision, not a technical default. Re-run survivorship on existing golden records and compare before and after, so the change is auditable rather than a silent rewrite of 940,000 patients' addresses.
3. The false-positive merges are already published and the warehouse keys on party ID. What is the remediation plan?
Read the worked answer
Do not simply re-key records. Use the merge audit log to identify affected party IDs, then unbundle in a controlled batch: separate the parties, keep cross-reference records for both so downstream foreign keys still resolve, and publish a delta file plus merge/unmerge events to the warehouse.
Party IDs must remain stable - never reuse an identifier for a different entity, because historical facts already reference it. Instead, correct the attributes and re-point the relationship, and let the warehouse apply the delta on its own key.
Freeze inbound loads during the remediation window, reconcile row counts before and after, and notify downstream consumers with a dated change notice. Then add guardrails: the disqualifying rules, a review queue, and an unmerge-rate metric reviewed monthly. Track the number of merges reversed per thousand as a quality KPI, and feed confirmed errors back into the labeled sample used to tune match rules.