Cumberland Valley's 420,000 members must be resolved against ACME's 1,800,000 to produce a single enterprise master patient index for the combined 2,220,000. Some of those people appear in both books. Some appear more than once within one book. Very few of them are recorded identically in any two places. This strategy sets out how the matching is done, what happens to the records that cannot be decided automatically, which value survives when two records disagree, and why the thresholds are set conservatively. Approved September 18, 2023, before closing.
This document is written without having seen the data. The Clean Team Protocol bars any comparison of Cumberland Valley member records against ACME's before closing — that comparison is the entire question, and it is exactly what antitrust law forbids until the transaction completes. So what follows is a method and a set of assumptions, not findings. Profiling runs immediately post-close, and the assumptions in Section 8 are the ones it will confirm or destroy.
Table of Contents
Part I — The Problem
Part II — The Method
- Pass One — Deterministic
- Pass Two — Probabilistic
- Three Outcomes, Not Two
- Why the Thresholds Are Conservative
Part III — Consequences
1. What Bad Member Data Actually Looks Like
Identity resolution sounds like a technical problem and is mostly a clerical one. The same person, enrolled twice over fifteen years, might be recorded as:
| Name | DOB | SSN | Address | Why it happened |
|---|---|---|---|---|
| John Jones | 1961-04-12 | xxx-xx-4417 | 418 Ridgeway Dr | Original enrollment, keyed from a paper form |
| John P. Jones | 1961-04-12 | xxx-xx-4417 | 418 Ridgeway Drive | Re-enrolled through a broker who typed it differently |
| J. Jones | 1961-04-12 | (blank) | 418 Rdgeway Dr | Dependent record created without an SSN; typo never corrected |
| John Paul Jones | 1961-12-04 | xxx-xx-4471 | 2201 Everly Ct | ⚠ Transposed date, transposed SSN digits, and he moved |
| JP Jones | 1961-04-12 | xxx-xx-4417 | 2201 Everly Court | Employer file load using a payroll nickname |
Every one of those defects has an ordinary human cause, and none of them will be fixed at source before the migration. Addresses are not updated when members move; nicknames enter through employer eligibility files; Social Security numbers are mis-keyed and never reconciled because nothing downstream forces them to be; dependents are enrolled without identifiers at all. A health plan's member file is a fifteen-year accumulation of small clerical events, and the migration inherits every one of them.
Two distinct problems follow, and they are often conflated:
- Internal duplicates — one person appearing more than once within a single organization's file. Both parties have these.
- Cross-entity overlap — the same person enrolled with both ACME and Cumberland Valley, typically at different employers or in different years. ⚠ This is the one that cannot be measured before closing.
2. Why You Cannot Simply Compare Everything
The naive approach is to compare every Cumberland Valley record against every ACME record. That is 420,000 × 1,800,000 comparisons — on the order of 756 billion. At any realistic throughput this does not complete inside the migration window, and it would not be worth doing if it did, because the overwhelming majority of those pairs are obviously unrelated.
2.1 Blocking
Blocking reduces the comparison space by only comparing records that share some coarse characteristic — a blocking key. Records in different blocks are never compared.
| Blocking key | Catches |
|---|---|
| Soundex(surname) + birth year | Spelling variants and typos in the surname |
| SSN last 4 + birth year | Records where the name is heavily corrupted but the identifier is partly intact |
| ZIP + surname initial + DOB | Geographic clustering, useful where identifiers are missing entirely |
| Metaphone(given) + Metaphone(surname) | Phonetic variants across both name parts |
Multiple blocking keys are used precisely because any single one has a blind spot. Blocking on surname misses a married-name change; blocking on SSN misses records without one; blocking on ZIP misses anyone who moved. Running several passes and taking the union costs more compute and recovers the pairs each individual key would have thrown away — and a pair that is never compared can never be matched, no matter how good the algorithm downstream is.
3. Pass One — Deterministic
Exact agreement on a combination of high-confidence identifiers. Cheap, fast, and unambiguous.
| Rule | Basis |
|---|---|
| SSN + date of birth | Strongest available. Both present and both agreeing is decisive. |
| Prior member identifier | Where a member moved between the plans and the identifier was carried |
| SSN + surname + birth year | Tolerates a mis-keyed day or month while holding two other anchors |
The deal model assumes deterministic matching resolves roughly 65% of the target population. That figure came from industry benchmarks and management representations about record completeness — not from inspection, because inspection was not permitted.
The deterministic rate is entirely hostage to Social Security number completeness, and that is the assumption carrying the most weight in this document. Where SSN is present and correct on both sides, matching is trivial. Where it is absent — dependents, older records, members who declined to provide it — the deterministic pass simply cannot see them, and they fall through to a probabilistic method that is slower and less certain. A ten-point difference in SSN completeness moves tens of thousands of records from "resolved automatically" to "worked by a human."
4. Pass Two — Probabilistic
Everything the deterministic pass could not decide goes to probabilistic matching, following the Fellegi-Sunter model: each field comparison contributes evidence weighted by how much agreement on that field actually tells you, and the weights sum to a score.
4.1 Standardization first
| Treatment | Purpose |
|---|---|
| Nickname and given-name tables | Resolve Bill/William, Peggy/Margaret, JP/John Paul before comparison |
| Soundex and Double Metaphone | Phonetic encoding so that names spelled differently but sounding alike compare as similar |
| USPS CASS address standardization | Normalize "Drive"/"Dr", directionals, unit designators to a single canonical form |
| NCOA change-of-address | ⭐ Resolve a moved member to their current address before concluding two records are different people |
NCOA is the step most often skipped, and it changes the answer rather than merely tidying it. Two records with different addresses look like two people. Run them through change-of-address processing first and one resolves to the other — the same person, one record simply older. Standardization is not cosmetic preprocessing; it is the difference between a match and a false negative, and in a book of business fifteen years deep, a great many members have moved.
4.2 Field comparison
| Field | Comparator | Discriminating power |
|---|---|---|
| Surname | Jaro-Winkler on phonetic key | Moderate — common surnames carry little information |
| Given name | Jaro-Winkler after nickname resolution | Moderate |
| Date of birth | Exact, plus transposition-tolerant | High — and transposition is a common, detectable error |
| SSN | Exact, plus single-digit and transposition tolerance | Very high where present |
| Address | Standardized comparison after CASS and NCOA | Moderate — households share addresses |
| Sex | Exact | Low on its own; useful as corroboration |
Jaro-Winkler is chosen over simple edit distance because it weights agreement at the start of a string more heavily, which matches how names actually get corrupted — endings get truncated, suffixes get dropped, spellings drift late in the word. And discriminating power matters as much as similarity: two people both named Smith is weak evidence; two people both named Threadgill is strong evidence. Frequency-based weighting is why the model outperforms a rule that treats every field agreement as equal.
5. Three Outcomes, Not Two
The single most consequential design decision in this strategy: the matching process has three outcomes, not two. A system that only decides "match" or "no match" is forced to draw one line through a continuous score, and every record near that line is decided by rounding. In healthcare that is unacceptable, because of what a wrong decision costs on one side of it. The third outcome — a clerical review band worked by trained humans — is not an admission that the algorithm is weak. It is the mechanism by which the algorithm is allowed to be cautious.
Auto-match
Auto-match (probabilistic)
Review
Planning assumption: deterministic 65% · probabilistic auto-match 27% · clerical review band 8%.
| Outcome | Condition | Disposition |
|---|---|---|
| Auto-match | Score above the upper threshold | Records linked; survivorship rules applied automatically |
| Clerical review | Score between the thresholds | ⚠ Queued for a data steward. Nothing merges until a human decides. |
| Auto-reject | Score below the lower threshold | Treated as distinct people. May leave a duplicate. |
6. Why the Thresholds Are Conservative
In healthcare, the two error types are not symmetrical, and this is the argument the whole strategy rests on.
A false negative fails to link two records for the same person. The result is a duplicate: the member appears twice, and someone eventually notices and fixes it. It is annoying, it is visible, and it is recoverable.
A false positive merges two different people into one record. One member's protected health information becomes visible under another's identity. Claims pay against the wrong history. A clinician opens a chart and reads someone else's allergies, medications and diagnoses. It is a privacy breach, a clinical safety event, and a claims integrity failure in a single action — and unlike a duplicate, nothing about normal operations surfaces it. The member with the merged record does not know. The system does not flag it. It is discovered by accident, months later, usually because something already went wrong.
A false negative fails to link two records for the same person. The result is a duplicate: the member appears twice, and someone eventually notices and fixes it. It is annoying, it is visible, and it is recoverable.
A false positive merges two different people into one record. One member's protected health information becomes visible under another's identity. Claims pay against the wrong history. A clinician opens a chart and reads someone else's allergies, medications and diagnoses. It is a privacy breach, a clinical safety event, and a claims integrity failure in a single action — and unlike a duplicate, nothing about normal operations surfaces it. The member with the merged record does not know. The system does not flag it. It is discovered by accident, months later, usually because something already went wrong.
That asymmetry has four direct consequences, and every one of them costs money:
| Consequence | Why it follows |
|---|---|
| The upper threshold sits high | Auto-matching is reserved for scores where a false positive is genuinely improbable, not merely unlikely |
| The review band is deliberately wide | Anything uncertain is pushed to a human rather than resolved by rounding. This is the expensive choice, taken knowingly. |
| Stewards are a budgeted workstream | A wide band without staff to work it is a queue, not a control |
| False-positive rate is audited, not assumed | A sample of auto-matched pairs is independently re-reviewed. ⚠ The error you cannot see is the one you must go looking for. |
An interviewer is likely to ask why not simply tune the algorithm until the review band disappears. The answer is that the band is not an artifact of a weak algorithm — it is where the genuinely ambiguous records live, and they are ambiguous because the underlying data is. Two people with the same common name, born the same year, in the same ZIP code, one with a missing SSN, are ambiguous to any method. Tuning the band away does not resolve those records; it just decides them without telling you.
7. Survivorship — Which Value Wins
When two records are linked, they will disagree on some attributes. Survivorship rules decide which value carries into the golden record. Rules are set per attribute, not globally.
| Attribute | Rule | Reasoning |
|---|---|---|
| Address | Most recent claim or encounter | Where the member actually is, evidenced by activity rather than by an enrollment form nobody updated |
| Social Security number | Enrollment source, never a claim | Enrollment is verified at the point of collection; claims SSN is frequently transcribed and error-prone |
| Date of birth | Enrollment source; conflicts flagged for review | ⚠ A DOB conflict on a matched pair is a signal the match itself may be wrong |
| Name | Most recent enrollment | Captures legal name changes |
| Coverage history | Union of both, never overwrite | ⭐ Coverage is cumulative history, not a current-state field. Losing a period of coverage is losing a member's entitlement. |
| Clinical and claims history | Union of both, retaining source lineage | Same reasoning, with higher stakes |
| Communication preferences | Most recent affirmative election | An opt-out must never be lost in a merge — it is a compliance obligation, not a preference |
"Newest record wins" is the default that seems reasonable and is wrong. Applied globally it takes the SSN from a claim rather than from enrollment, because the claim is newer. It takes an address from a stale enrollment form over a recent encounter, if the form was touched later. And applied to coverage history it is catastrophic — it would overwrite a member's earlier coverage rather than combining it, silently erasing periods of entitlement that determine whether a claim should have paid. Survivorship is an attribute-by-attribute judgment about which source is authoritative for that specific field, and the union cases matter more than the overwrite cases.
8. Steward Capacity and the Planning Assumption
The review band is only a control if it can actually be worked inside the migration window. The arithmetic is stated here explicitly so that it can be re-run against reality the moment profiling completes.
| Input | Planning value | Source |
|---|---|---|
| Target member records to resolve | 420,000 | Known |
| Assumed clerical review band | 8% | ⚠ Deal model assumption — unverified |
| Resulting review queue | 33,600 | Derived |
| Steward throughput per day | 100 | Benchmark, allowing for research on hard cases |
| Stewards staffed | 4 | Resource Plan |
| Working days to clear the queue | 84 | Fits the window with margin |
Read that table as a risk statement rather than a plan, because every input except the first is an assumption and one of them is load-bearing. The review band percentage is not a measurement — it is a projection made without sight of the data, for reasons of antitrust law rather than diligence. The queue scales linearly with it: if the band is twice the assumption, the queue is twice the size and the staffing is half of what it needs to be. And the band is downstream of SSN completeness, which is itself a management representation. This is the single most sensitive number in the program, it rests on the least evidence, and it will not be known until after the money has been spent.
8.1 What happens if the assumption is wrong
- Capacity is scalable, but not instantly. Stewards can be added through the staffing agreement — recruitment, onboarding and training run several weeks, so the response is measured in months rather than days.
- ⚠ Stewards must work onshore. Clerical review requires access to member-level data, and Tennessee Department of Commerce and Insurance conditions plus ACME privacy policy prohibit processing that data outside the United States. The obvious lever for a queue problem — add offshore capacity — is not available.
- Throughput cannot be raised by pressure. A steward reviewing faster is a steward making the error type that does not surface.
- Therefore the queue is the migration's pacing item, and profiling is scheduled as the first substantive post-close activity for exactly that reason.
9. Metrics and Governance
| Metric | Reported | What it tells you |
|---|---|---|
| Match rate | Weekly | Proportion resolved automatically. Falling rate means data quality worse than modeled. |
| Duplicate rate | Weekly | Residual duplication in the golden record. The false-negative measure. |
| Review queue volume | Daily | Absolute size. The pacing item. |
| Steward throughput | Daily | Records cleared per steward. ⚠ Watched for increases as well as decreases. |
| Audited false-positive rate | Monthly | ⭐ Independent re-review of a sample of auto-matched pairs. The only measure of the error that does not surface on its own. |
| Unmerge requests | Monthly | Merges reversed after the fact. Each one is a false positive that reached production. |
Throughput is monitored for increases, which is counterintuitive until you consider what causes them. A steward whose daily rate rises sharply is usually not getting better at the work; they are getting faster at it, which in clerical review means spending less time on the hard cases. Since the hard cases are precisely where false positives originate, a throughput spike is a quality signal before it is a productivity one. This is also why the contract for stewardship is not structured to reward volume.
9.1 Governance
- T. Vandiver, Data Steward Supervisor, owns the queue and the service level.
- Dr. A. Ravindran, Data & EMPI Workstream Lead, owns the thresholds and the survivorship rules. Threshold changes are a documented decision, not a configuration tweak.
- L. Braithwaite, Chief Privacy Officer, owns the false-positive audit. ⚠ Deliberately outside the workstream that produces the matches — a team that sets thresholds should not also grade its own error rate.
- Escalation: any confirmed false positive reaching production is reported to the Steering Committee individually, regardless of volume.
Related artifacts: 5 — Clean Team Protocol · 7 — Due Diligence Findings (DD-02) · 20 — Application Disposition Matrix · 22 — TSA Schedule & Exit Plan (TS-06) · 28 — Risk Register · 31 — Data Profiling Report · 32 — EMPI Match Rules & Survivorship Spec · 33 — Data Steward SOPs & SLA