Category 2: Household and Individual Rules
Specification v3.4.0, section III.C.2 to III.C.5
C.2. Household-tier threshold and Table 2-H
Acceptance threshold for Step A alone: P(household collision) ≤ 1e-7 (1 in 10 million). No single field in Table A reaches this threshold alone — the strongest, at u = 0.000001, is one order of magnitude short. This structurally enforces "at least two independent household-level fields," rather than relying on an administrative note. To be precise about what's doing the real work: every row in Table 2-H actually lands at 1e-8 or stronger, so in practice the binding constraint is the combined 2e-12 bar, not this 1e-7 floor — 1e-7 is a structural "at least two fields" heuristic, not a value derived from first principles, and no row is anywhere near that weak; the weakest actual row (H-11) is a full order of magnitude stronger, at 1e-8.
Table 2H - Household-tier threshold
| ID | Household field combination | P(household collision) |
|---|---|---|
| H-01 | SSN Last 4 + Phone Number | 1.0e-10 |
| H-02 | SSN Last 4 + Email Address | 1.0e-10 |
| H-03 | SSN Last 4 + Street Line | 3.0e-9 |
| H-04 | ITIN Last 4 + Phone Number | 1.0e-10 |
| H-05 | ITIN Last 4 + Email Address | 1.0e-10 |
| H-06 | ITIN Last 4 + Street Line | 3.0e-9 |
| H-07 | Subscriber ID (w/ Payer namespace) + Phone Number | 1.0e-10 |
| H-08 | Subscriber ID (w/ Payer namespace) + Email Address | 1.0e-10 |
| H-09 | Subscriber ID (w/ Payer namespace) + Street Line | 3.0e-9 |
| H-10 | Phone Number + Email Address | 1.0e-12 |
| H-11 | SSN Last 4 + Subscriber ID (w/ Payer namespace) | 1.0e-8 |
| H-12 | Phone Number + ZIP Code | 3.0e-10 |
| H-13 | Email Address + ZIP Code | 3.0e-10 |
| H-14 | Phone Number + Street Line | 3.0e-11 |
Table 2-H. Last Name may be added to any row as non-scored corroboration but does not change the listed probability.
C.3. Individual-within-household Table 2-I
Once a household match is determined in C.2, the next step is to identify the individual within that household.
Table 2I - Individual within household
| ID | Individual field combination | P(individual | household) | Gating condition |
|---|---|---|---|
| I-01 | First Name + Date of Birth | 2.0e-6 (exact) / 3.0e-6 (fuzzy) | Default combination. Use exact First Name whenever DOB is shared by another candidate in the resolved household. |
| I-02 | First Name + Last Name + Date of Birth | 1.0e-8 | Optional, extra-conservative variant. This is the one exception to Last Name being excluded from Table 2-I: an implementer may opt into scoring it here for added conservatism, but I-01 already clears the threshold without it — Last Name is not required. |
| I-03 | First Name alone (exact) | 0.02 | General rule: permitted only when paired with a Household row whose own P(household collision) ≤ 1.0e-10 — First Name alone is too weak to safely pair with a weaker household row. |
Why I-03 is defined but not used here. First Name alone is exposed to a risk this proposal's twin handling (§3.7) does not cover: two household members sharing a first name across generations (e.g., "Robert Sr." and "Robert Jr.") without a machine-readable suffix. Unlike twins, these two people usually have different dates of birth — so requiring DOB alongside First Name (I-01) resolves this case cleanly, while First Name alone (I-03) cannot distinguish them at all. This is why §4.5 pairs every Category 2 rule with I-01, not I-03, even though I-03 remains available in this table as a building block for a future rule that can independently justify it (e.g., one with no DOB field available at all).
Last Name is deliberately absent from Table 2-I as a standing rule. It may be used as an opportunistic, per-query enhancement only when the resolved household's candidate records empirically show more than one distinct last name — an observed fact about that specific household, not a population-wide assumption.
This is a partial mitigation, not a complete one. A blended-family household where two step-siblings share a similar First Name and a close Date of Birth, differing only in Last Name, is not fully stress-tested by this proposal — it is listed in §3.9 as a required addition to the vulnerable-populations test pack, not as a solved case.
C.4. Category 2 — Combined Probabilities of Household + Individual Rules
These are the eight Category 2 rules — the only rules that require the two-step household process. Each pairs one Household row (Table 2-H, §3.3/§4.3) with one Individual row (Table 2-I, §3.4/§4.4); the combined probability is the product of the two.
On "Last Name retained as non-scored corroboration" (Rules 13-16): to remove any ambiguity, corroboration here is advisory only, never mandatory. A responder MAY log or flag a Last Name mismatch for data-quality review, but SHALL NOT withhold an otherwise-qualifying match because Last Name differs — doing so would silently reintroduce the exact blended-family failure (a dependent whose last name differs from the subscriber's) that these rules exist to fix. The listed P(collision) values do not depend on Last Name in any way.
| Household leg | Individual leg | Combined P(collision) |
|---|---|---|
| H-01 (SSN Last 4 + Phone) | I-01 (First Name + DOB); Last Name retained as non-scored corroboration | 2.0e-16 |
| H-04 (ITIN Last 4 + Phone) | I-01 (First Name + DOB); Last Name retained as non-scored corroboration | 2.0e-16 |
| H-02 (SSN Last 4 + Email) | I-01 (First Name + DOB); Last Name* retained as non-scored corroboration | 2.0e-16 |
| H-05 (ITIN Last 4 + Email) | I-01 (First Name + DOB); Last Name* retained as non-scored corroboration | 2.0e-16 |
| H-12 (Phone + ZIP) | I-01 (First Name + DOB) | 6.0e-16 |
| H-13 (Email + ZIP) | I-01 (First Name + DOB) | 6.0e-16 |
| H-14 (Phone + Street Line) | I-01 (First Name + DOB) | 6.0e-17 |
| H-07 (Subscriber ID + Phone) | I-01 (First Name + DOB) | 2.0e-16 |
| Guardian's identity (independently matched under Table 2) + Street Line | Relationship Linkage, clinical (child-of guardian) + First Name + DOB | ≈6e-13 (flat product: 0.02 × 0.0001 × 0.01 × 0.00003) — flagged: Street Line is correlated with the relationship term (same household address), so this overstates the margin; needs a dependency discount or drop Street Line before adoption |
| Mother's identity (independently matched under Table 2) | Relationship Linkage, clinical (newborn-of mother) + DOB + per-encounter namespace-bound birth-encounter ID | Clears with wide margin if the birth-encounter ID is a true per-encounter unique identifier — does not clear if only a shared facility ID is available; a facility ID is far above the threshold |
I-03 (First Name alone) remains defined in Table 2-I (§3.4) as a general-purpose building block for future proposals, but no Category 2 rule in this proposal uses it, for the reasons in the callout above. A future rule that genuinely has no DOB available would need to re-justify I-03 on its own merits, including the generational-name risk noted in §3.4 and §3.7.
C.5. Combined decision rule
A responding entity SHALL return a match when a query's Household-tier fields resolve to exactly one household per Table 2-H (§3.3), its Individual-tier fields resolve to exactly one member of that household per Table 2-I (§3.4), and the product of the two listed probabilities does not exceed 2e-12. Any Household row may in principle be paired with any Individual row, subject to the gating conditions already noted in Table 2-I — implementers are not limited to combinations this proposal happens to name.