Part 2 known-information request rule

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Current rule checkpoint

Live 42 CFR 2.13(b) states that Part 2 restrictions apply even when the lawful holder believes the person seeking information already has it. Section 2.13(c)(2) separately requires an impermissible response to avoid affirmatively revealing that an identified person has been or is being diagnosed or treated for an SUD. eCFR displays section 2.13 as current through August 20, 2026 and last amended August 13, 2026. The HHS fact sheet confirms the February 16, 2026 compliance date.

Confirmation can itself disclose

The unconditional-compliance provision expressly addresses a requester who believes it already has the information. Treat verification, correction, denial, elaboration, dates, program names, patient status, and record existence as possible disclosures.

Do not test the requester's knowledge

Staff should avoid asking for extra SUD detail simply to see what the requester knows. Collect only what is needed to authenticate, classify the request, identify the claimed authority, route review, meet a deadline, and send an approved response.

Use a nonconfirming workflow

Provide a role-approved script, centralized intake, privacy escalation, request log, secure legal-process channel, and response review. Where the rule allows a general explanation or copy, keep it detached from the identified person.

Identify every form of confirmation

A yes, correction, denial, transfer, date, program name, appointment detail, patient-presence statement, “wrong facility” response, record search result, call-back pattern, or statement that Part 2 governs the named person can reveal status. Review words, silence, routing, metadata, caller identification, and automated behavior from the requester's perspective.

Do not ask for treatment facts merely to test what the requester knows. Collect only identity and contact details needed for authentication, the claimed authority, request scope, purpose, deadline, and safe routing. Keep sensitive detail out of broad tickets and notification previews.

Use a consistent nonconfirming response

Give staff a role-approved script that neither confirms nor denies whether the identified person is or was a patient. Explain only the general request process or provide general regulatory information when appropriate. Move valid legal process or consent materials to a secure channel without acknowledging record existence.

Apply the response across phone, voicemail, email, fax, portal, in-person, media, payer, employer, family, government, and vendor contacts. Design transfer and escalation behavior so different outcomes do not reveal whether a matching record exists.

Handle mistakes and repeated inquiries

If staff confirmed, denied, corrected, or exposed status, preserve the request and response, contain further communication, notify privacy and security, assess incident or breach obligations, contact the recipient as directed, and correct scripts or systems. Do not delete the only evidence.

Track repeated or coordinated requests, but keep fraud, harassment, safety, and legal responses in their own authority paths. Test the repaired workflow with a requester who confidently states detailed prior knowledge.

Example

Eleven prior-knowledge requests are reviewed. Nine have authentication, authority review, neutral response, escalation, and audit evidence; two received informal confirmation. Control completion is 9 of 11 requests.

Record the response decision

Classify each contact as authorized for a defined disclosure, routed for secure authority review, answered neutrally, denied, or unresolved. Record requester, prior-knowledge claim, patient named, information sought, purpose, channel, deadline, decision-maker, exact response, and follow-up.

For unresolved requests, give staff a safe holding statement and named escalation owner. Keep the request out of subject lines, shared queues, and notifications that would expose the same protected fact internally or externally.

When a mistake occurs, record what the requester could infer, which patient and program facts were exposed, who received them, whether they were repeated, and what containment was attempted. Complete incident and breach analysis under current rules.

Close remediation only after testing the original channel and a second channel. Verify that scripts, routing, caller identification, auto-replies, portals, and staff behavior remain nonconfirming.

Known-information request checklist

• treat words, denial, correction, transfer, silence, metadata, and routing as possible confirmation;
• collect only authentication, authority, purpose, scope, deadline, and safe contact details;
• use a consistent response that neither confirms nor denies identified-patient status;
• separate secure process instructions from any acknowledgment that records exist;
• preserve and review mistaken confirmation, denial, or revealing system behavior; and
• test every channel with a realistic prior-knowledge claim.

This rule does not make all responses identical or decide a request's underlying authority. Current Part 2, facility context, consent or order, state law, safety facts, and exact wording require qualified review.