Part 2 request for a TPO restriction

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.26(a)(1) requires a Part 2 program to permit a patient to request a restriction on uses or disclosures for treatment, payment, or health care operations, including after the patient has signed consent for those purposes. Most requests are discretionary under paragraph (a)(2), while a request meeting every paid-in-full health-plan condition in paragraph (a)(6) must be accepted.

Consent does not eliminate the request right

Current 42 CFR 2.26(a)(1) requires a Part 2 program to permit the request even when written TPO consent exists. Capture the patient, requester authority, records, people or entities, purpose, dates, channels, urgency, and requested restriction in accessible language.

Route the decision correctly

Privacy staff can intake and clarify. The role authorized by policy and current law decides whether the program agrees, must agree, needs more information, or denies the request. Record the source and explain the outcome without promising that another entity is bound.

Build an implementable scope

The HHS fact sheet identifies this as a patient right now in effect. Translate an agreed restriction into precise EHR, release, billing, portal, exchange, workforce, vendor, and exception controls with a start time and verification test.

Make intake accessible and specific

Accept the request through supported patient, privacy, records, billing, and portal channels. Verify the patient or representative, preserve the original request, record receipt, and capture affected records, purposes, recipients, systems, date range, reason if offered, urgency, and requested outcome. Help the patient express the scope without requiring legal terminology.

An existing TPO consent does not remove the request right. Link the consent and any revocation separately so staff do not treat restriction and consent as the same control.

Triage the mandatory path first

Ask whether the requested recipient is a health plan, the purpose is payment or health care operations, disclosure is otherwise required by law, the record pertains solely to a particular item or service, and the patient or another person paid the program in full on the patient's behalf. Route financial and legal ambiguities to billing, privacy, and counsel.

Requests outside that narrow path still deserve a documented decision under approved criteria. Do not use a blanket statement that the program never accepts restrictions.

Develop an implementable scope

Map the request across the EHR, release of information, care coordination, claims, eligibility, prior authorization, payer portals, HIE, APIs, secure messaging, patient portal, analytics, vendors, paper, fax, email, and manual workflows. Identify records and future data, purposes, recipients, start time, duration, emergencies, required-by-law events, and non-TPO Part 2 permissions.

Offer a narrower alternative when the full request cannot be administered and the alternative addresses the patient's concern. Record whether the patient accepts it. Avoid promising that downstream entities are bound unless the applicable authority and notice support that conclusion.

Decide and communicate through authorized roles

Use defined criteria addressing patient concern, legal duties, clinical continuity, system capability, downstream dependencies, emergency treatment, operational risk, alternative safeguards, and consistency. The authorized decision-maker should record accepted, partly accepted, declined, mandatory, or pending, with rationale, scope, effective time, and escalation.

Give the patient an understandable response and complaint or review route. The HHS fact sheet identifies restriction requests as a current Part 2 right, unlike the separately tolled accounting provision.

Implement and prove the outcome

For an accepted restriction, configure structured controls and readable instructions, notify affected roles and vendors, block release routes, define exceptions, and test representative scenarios before closing the request. A banner or inbox note alone cannot control automated and manual disclosures.

For a denial, confirm that no system was inadvertently restricted, preserve the decision, and monitor complaints or changed facts. Audit mature requests for intake, mandatory-path classification, timing, decision consistency, communication, implementation, testing, and closure.

Example

Twelve requests reach decision. Nine have verified authority, defined scope, documented decision, patient notice, implementation owner, and test; three end at an inbox note. Decision completeness is 9 of 12 requests.

TPO-restriction-request checklist

• verify requester authority and capture records, purposes, recipients, systems, and timing;
• keep restriction and TPO consent as linked but distinct decisions;
• test every paid-in-full health-plan element before applying discretion;
• map clinical, billing, exchange, portal, vendor, paper, and manual routes;
• document decision criteria, rationale, patient response, escalation, and effective scope; and
• implement, test, audit, and correct each accepted restriction across real workflows.

The program must open a real decision path for the request. Acceptance depends on the rule and facts, with the paid-in-full route treated as mandatory when all conditions are met.