Part 2's record-identification test asks whether a record would identify a patient as having or having had an SUD directly, by reference to publicly available information, or through verification by another person. A record can therefore identify without displaying a familiar name. Classification should consider the data, context, recipient knowledge, linkage paths, and verification process together.
Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.
Current rule checkpoint
The live record restriction in 42 CFR 2.12(a)(1) applies to records that would identify a specified patient as having or having had an SUD directly, by reference to publicly available information, or through another person's verification, when the remaining program, information, date, and purpose conditions are met. eCFR displays the section as current through August 20, 2026 and last amended August 13, 2026. The HHS fact sheet confirms the February 16, 2026 compliance date for the amended Part 2 framework.
Identification includes three routes
The current 42 CFR 2.12 test covers direct identification, public-reference identification, and verification. Inventory names, contact details, dates, rare attributes, locations, program identifiers, URLs, images, free text, device data, and external lookup paths.
Context changes the result
A field may appear ordinary alone and become identifying beside a program name, appointment pattern, small cohort, public post, referral source, or known event. Test realistic recipient context rather than a field list in isolation.
De-identification needs separate authority
Removing names alone provides incomplete protection. Where HIPAA, Part 2, state law, contract, research, or statistical methods apply, use the governing standard and preserve the method, decision-maker, date, inputs, residual risk, allowed purpose, and restrictions.
Test the whole recipient context
Inventory direct identifiers, contact details, dates, ages, locations, rare events, program names, provider names, referral sources, images, voices, free text, device or network data, URLs, file names, metadata, small cells, and persistent codes. Then ask what the intended recipient and likely downstream users already know or can reasonably obtain.
A record may identify through public material or later verification even when common identifiers are removed. Program context, an appointment pattern, local news, a public post, a distinctive event, or a known referral can make ordinary fields revealing. Document the linkage path and recipient environment rather than relying on a checklist alone.
Keep the remaining coverage chain visible
Identification is one condition, not the complete Part 2 analysis. Record program status, federal assistance, SUD information, acquisition date, diagnosis, treatment or referral purpose, historical episode, holder, and proposed action. A nonidentifying extract may still be governed by another law, contract, research promise, or security duty.
When de-identification is the chosen route, identify the exact legal standard, method, data set, qualified reviewer, inputs, transformations, excluded fields, dates, geography, rare values, linkage environment, residual risk, purpose, recipient, and restrictions. Removing names or assigning a random identifier is not a documented conclusion.
Reassess derived and changing data
Scores, summaries, cohorts, dashboards, analytics, model input and output, images, and reports can reintroduce identifying context. Re-test after a new data source, smaller population, geography change, public event, recipient change, feature release, or external linkage. Preserve prior versions and decisions for releases already made.
Example
Fifteen extracts are assessed. Eleven have direct, public-linkage, verification, context, recipient, and purpose evidence; four were labeled anonymous after names were removed. Classification completeness is 11 of 15 extracts.
Record the release decision
Classify each extract as patient identifying, supported as de-identified under a named standard, limited to an approved recipient and context, or unresolved. State the full data set, transformations, recipient knowledge, linkage environment, purpose, method, reviewer, release date, and expiration or recheck trigger.
For unresolved or identifying output, restrict delivery and determine whether consent, another Part 2 authority, or a redesigned extract is appropriate. Preserve the rejected version so later users do not reproduce it from the same source.
After release, monitor changes in public information, population size, data sources, recipients, and downstream combination. Withdraw or revise access when the supported context changes, and retain the notification and corrective evidence.
Assign the monitoring interval, owner, escalation threshold, and next documented review date before delivery.
Patient-identifying-record checklist
- test direct identifiers, public linkage, third-person verification, context, and metadata;
- document recipient knowledge, data environment, purpose, and downstream access;
- keep program, assistance, SUD information, date, and treatment-purpose conditions separate;
- use a qualified method and reviewer for any de-identification determination;
- review derived output, rare values, small cells, files, images, and free text; and
- re-test after data, population, geography, recipient, or public-context changes.
This test does not decide the full Part 2 coverage chain or establish that a data set is safely de-identified. Current law, the actual record, recipient context, method, state rules, contracts, and proposed use require qualified privacy and legal review.
Related terms
Sources
Take the next step with clarity
Whether you are finding care, growing as a clinician, or building a stronger ABA practice, Finni brings the people, tools, and support together to help you move forward.
Start or grow your ABA practice with Finni