Part 2 paid-in-full health-plan 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)(6) requires a program to agree to a patient's restriction request when the disclosure would be to a health plan for payment or health care operations, is not otherwise required by law, and the record pertains solely to an item or service paid in full by the patient or someone other than the health plan on the patient's behalf. Every condition matters.

Test every element

Current 42 CFR 2.26(a)(6) requires agreement only when its conditions are met. Record patient request, recipient health plan, purpose, required-by-law check, exact item or service, charge, adjustments, full-payment source, posting time, refund state, and record scope.

Resolve mixed financial episodes

One encounter can include several services, discounts, deposits, bundled charges, secondary coverage, refunds, or later balances. Confirm that the restricted record pertains solely to the fully paid item or service. Route ambiguous allocations to privacy, billing, and legal owners.

Block the correct pathways

The HHS fact sheet identifies this restriction right as part of the current rule. Test claim creation, eligibility, prior authorization, payer portals, remittance follow-up, statements, collections, exchange feeds, analytics, and manual disclosure queues.

Capture the request before billing activity proceeds

Give patients a clear route to request the restriction and understand payment timing. Verify identity and authority, item or service, dates, rendering program, intended health plan, purpose, billable charges, discounts, adjustments, deposits, payment source, balance, and requested scope. Alert billing and privacy owners before a claim, eligibility inquiry, or payer workflow is initiated.

Document whether another person paid on the patient's behalf and confirm that person is not the health plan. Avoid exposing SUD information while resolving payment.

Test all four legal conditions

First, confirm the recipient is a health plan. Second, confirm the disclosure purpose is payment or health care operations rather than treatment or another purpose. Third, determine whether another law requires the disclosure. Fourth, establish that the record pertains solely to the fully paid item or service.

Use current financial and legal evidence. A patient statement, zero account balance, payment receipt, or self-pay flag may be relevant but does not alone resolve every condition.

Resolve complex financial episodes

Review bundled services, multiple dates, deposits, discounts, financial assistance, secondary coverage, coordination of benefits, prior authorization, capitation, refunds, charge corrections, recoupments, credit-card disputes, payment plans, and later balances. Separate restricted and unrestricted items only through an approved, auditable allocation.

If a record covers both the paid service and another service, determine whether it “pertains solely” to the paid item before restricting. Route ambiguity to billing, privacy, and counsel rather than applying a whole-account label.

Block every health-plan route in scope

Control claim creation, clearinghouse queues, eligibility, authorization, utilization review, payer portals, remittance follow-up, coordination, statements sent to plans, collections involving plan data, interfaces, analytics, vendors, exports, faxes, and manual release. Map the exact records and purposes covered so treatment or other legally supported routes are not unintentionally blocked.

Notify affected staff and vendors using minimum necessary information. Restrict overrides and preserve reasons, approvals, dates, and release evidence.

Monitor change without silently ending protection

Track refunds, reversals, new charges, corrected coding, payer involvement, legal requirements, and patient communications. Changes require qualified review of the restriction and termination rules; a later billing event should not automatically clear the control.

Audit mature requests for receipt, full-payment proof, all four conditions, mixed-record analysis, implementation, testing, patient response, overrides, and incidents. Correct both the financial workflow and privacy control when a claim or disclosure occurs improperly.

Example

Ten paid-in-full requests mature. Seven verify all legal and financial elements, activate route controls, notify the patient, and pass a release test; three omit the required-by-law or sole-record check. Readiness is 7 of 10 requests.

Paid-in-full checklist

• capture the request, item or service, dates, health plan, purpose, charges, and payment source;
• prove payment in full and confirm the payer was not the health plan;
• test required-by-law status and whether the record pertains solely to the paid service;
• resolve bundles, deposits, refunds, secondary coverage, corrections, and mixed records;
• block claims, payer portals, interfaces, vendors, analytics, and manual disclosure routes; and
• review later financial changes, overrides, incidents, patient notices, and termination authority.

This mandatory restriction is narrow but consequential. An account-level self-pay flag is not a substitute for element-by-element evidence and route controls.