Getting StartedStatus

Status

Current version

ItemValue
Specificationv3.4.0, Final Consolidated Draft
Release date9/10/2026, as printed in the specification's Document Control table
Comment periodThe specification gives the end of the comment period only as the placeholder [Date + 60 days].
Effective dateNot set ([TBD after finalization])

See the Changelog and the Compatibility Matrix.

Open proposals

Two proposals are under review: v3.3.6 (Institutional Address Identification Methodology) and v3.4.1 (Remove Rule 29). See Under Review.

Rule counts

The specification's Executive Summary counts 30 Category 1 rules and 8 Category 2 rules, and separately names two new rules, 39 and 40. The section III.C.4 table has two further rows (guardian and newborn) that correspond to them, without numbers. Adding these gives 40 rules, a total the specification does not state itself. The reference library implements 39, because it omits rule 29 ahead of proposal v3.4.1. Always state which specification version a rule count refers to.

Notes on the specification text

These are observations about the text of v3.4.0 that readers may trip over. They are not changes; the wording of the specification pages is reproduced without modification. If you think one is an error in the specification, send a comment (see Report an Issue).

  • Section references from earlier proposals. Several passages in section III.C use section numbers such as §3.3, §3.4, §3.7, §3.9, §4.3, §4.4 and §4.5, which come from the proposal that introduced them and do not match the numbering of v3.4.0.
  • Rule numbers in prose. Section III.C.8 refers to "Rules 13, 14, 15, 16, 34, 35, 37, and 38" for the household-then-individual pairings, but Table 2 numbers its Category 1 rules 01 to 30, so 13 to 16 there are different rules. Section III.C.7 refers to "Rule 26" for a persistent identifier with ≈0 collision, whereas Table 2 lists namespace-bound unique identifiers as rule 22 and rule 26 is Email Address + Member ID.
  • Which fields may be fuzzy. Section IV.C says fuzzy comparison may be used only for first name, last name, and street line, and is not applied to structured fields such as DOB. Table 3 lists date of birth as exact comparison only. Table 2 marks date of birth with an asterisk in rules 01, 02, 03, 10 and 24, and its notes allow a ±1-day tolerance, while the note under Table 2 about insurance identifiers says that email, phone, date of birth, subscriber ID, and member ID must match exactly after normalization.
  • Combination counts. Section IV.D describes an analysis of 2554 combinations reduced to 1150, and about 68 additional combinations that could be added. The chart in the same section reports 692 canonical combinations, 556 threshold-qualified, 224 that are not a superset of a threshold-qualified combination, and 20 reference-list rows. Section IV.D says the 1150 figure follows from eliminating year of birth, suffix, and middle name, and that rows with an effective collision probability of zero are excluded from the chart. It does not explain how the chart's other counts relate to the text.
  • Full SSN in the token field table. The IAL2 claim field table lists ssn_itin ("Social security number") as an optional token claim, while section IV.E says full SSN and full ITIN SHALL NOT be transmitted as part of matching queries. The specification does not say how the two fit together.
  • Validation population. Section VI.B says individual participants "are required to assemble a dataset of that size on its own in order to comply", which reads as inconsistent with the preceding sentence listing who may perform the validation.
  • Interrupted text. Section VI.A contains a sentence about the ONC dataset that is interrupted by two unrelated paragraphs, and section VI.B has a sentence that ends mid-clause ("SHOULD perform ecosystem-specific validation or").
  • Two tables about administrative restrictions. The table in section III.C.6 (Administrative Restrictions) and the table captioned Table 4 in section IV.D are separate tables. Only the latter is labeled Table 4.

Formatting repairs on this site

The specification pages reproduce the specification's wording without change. Two formatting repairs were made in References: reference 1's page range, which the source splits across two paragraphs, was joined, and reference 7's URL, which the source splits with only the first half linked, was joined and linked in full.