Match Rules for a Healthcare Network with Household Sharing
Northwind Health has 900,000 patient records from a hospital system and 400,000 from a clinic network. Patients frequently share a household phone number, and parents often use one email address for multiple family members. The initial unification run with exact email and exact phone matching produced 1.1 million unified profiles from 1.3 million records, but the data steward found clusters containing four to six people with different names and birth dates. The network wants accurate individual-level profiles for outreach, and compliance requires that records not be merged across different individuals.
1. Diagnose why the current match rules over-merge, and propose a revised rule strategy.
Read the worked answer
The rules treat shared contact attributes as identity evidence. A household phone or a shared parent email is not unique to an individual, so exact matching on either alone will merge family members.
Revise the strategy around attribute uniqueness and corroboration:
- Demote shared attributes. Phone and email should not independently create a match. Use them only in combination with a corroborating attribute such as last name plus date of birth, or as a lower-weight signal in a composite rule.
- Promote strong individual attributes. Date of birth combined with a normalized name is far more individual-specific. Exact match on those, with phone or email as supporting evidence, produces defensible merges.
- Add a household concept rather than forcing individual merges. If the business needs household outreach, model it explicitly - group profiles that share an address - instead of collapsing individuals into one profile.
- Tune fuzzy thresholds upward where names are common, and require at least two independent corroborating attributes for any fuzzy match.
Given the compliance constraint, err toward under-merging: duplicate profiles are recoverable, an improper cross-individual merge is not.
2. After tightening rules, the unified profile count drops and the outreach team complains that the same person now appears twice. How do you balance the two failure modes?
Read the worked answer
Make the trade-off explicit and governed rather than resolved by preference.
First, quantify both error types on a labeled sample: how many true duplicates remain (false negatives) and how many incorrect merges persist (false positives). Present both to the outreach team with the compliance constraint attached - the organization has already decided that cross-individual merges are unacceptable, so the acceptable operating point is the one that minimizes duplicates subject to zero tolerated false merges.
Second, reduce false negatives without loosening identity rules: improve normalization (name variants, nicknames, address standardization), add corroborating attributes such as a member ID or date of birth where available, and fix source-level data entry issues that cause legitimate matches to fail.
Third, give the outreach team a workflow for suspected duplicates - a review queue where a steward can confirm a merge - so residual duplicates are handled deliberately instead of by relaxing thresholds globally. Document the chosen thresholds and the rationale so future tuning does not silently reopen the compliance risk.
3. The clinic network's records lack date of birth for 30 percent of patients. How does this gap affect the rule design, and what do you recommend?
Read the worked answer
The gap weakens the strongest individual-level attribute, so those records will either fail to match (duplicates) or match only on shared attributes (over-merges) if rules are not designed for missingness.
Recommend a tiered approach:
- Tier 1 - strong match: records with date of birth and normalized name match exactly, corroborated by phone or email. High confidence.
- Tier 2 - conditional match: records missing date of birth match only when at least two independent attributes align, and never on a shared household attribute alone. Route ambiguous cases to steward review.
- Tier 3 - unresolved: records that cannot meet either tier remain as separate profiles and are flagged, not force-merged.
Also push upstream: ask the clinic network to capture date of birth at registration, since the gap is a source-quality issue that no matching configuration fully solves. Track the unresolved percentage as a quality metric so the business sees the cost of the missing field and can prioritize remediation.