Part 2 third-party-payer recipient 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

The live 42 CFR 2.12(d)(2)(i)(A) applies Part 2 restrictions to defined third-party payers for records disclosed by Part 2 programs or under the general recipient designation in section 2.31(a)(4)(i). The current section 2.11 definition excludes a HIPAA-defined health plan and focuses on payment through a contract with the patient or family member or eligibility for government benefits. eCFR displays Title 42 as current through August 20, 2026 and last amended August 13, 2026.

Confirm that the recipient fits the defined role

Current 42 CFR 2.12 applies its restrictions to third-party payers for records received through the named routes. Record payer, product, member, program, sender, disclosure basis, purpose, record set, recipient endpoint, date, and notice.

Payer events remain separate

Track eligibility, benefit, network, authorization, utilization review, claim submission, acknowledgment, adjudication, appeal, remittance, and payment independently. A disclosure receipt or authorization number provides evidence only for its stated event and period.

Control payer-facing workflows

Use approved endpoints, role access, disclosure logs, source preservation, minimum scoped submissions, correction history, deadline ownership, government-demand routing, incident response, and retention rules. Verify payer contracts and state law separately.

Classify the legal recipient and product

Identify the legal entity, product, funding arrangement, administrator, member, patient, program, service, and transaction. Document why the recipient fits the Part 2 third-party-payer definition instead of a HIPAA health plan or a different role. The same organization may administer multiple products with different classifications.

Trace the payment basis to the contract with the patient or family member or to eligibility for federal, state, or local benefits. Preserve effective dates, responsible parties, coverage period, service, payment terms, and authoritative evidence. Separate the funder from a claims processor, network, utilization reviewer, employer, intermediary, vendor, or QSO.

Match the disclosure to its authority

Record sender, receiving endpoint, patient and member identifiers, product, purpose, consent or other authority, records, dates, minimum fields, notice, secure route, receipt, and person responsible. For consent-based disclosures, check the current elements in section 2.31 and the notice and consent-copy or scope-explanation requirements in section 2.32.

Review SUD counseling notes separately under the current consent rule. Do not send a full chart because a payer requested “all records” or because an authorization, claim, or appeal is pending. Narrow the submission to the supported transaction and preserve what was actually sent.

Keep payer decisions and record uses distinct

Track eligibility, enrollment, benefit, authorization, utilization review, claim, denial, appeal, remittance, payment, recoupment, and collection as separate states. A favorable decision cannot cure an unsupported disclosure, and a valid disclosure does not establish coverage, medical necessity, or payment.

Govern recipient access, retention, redisclosure, proceeding use, legal demands, corrections, and incidents. Reassess when product, administrator, contract, benefit, endpoint, purpose, data, or patient authorization changes, and preserve earlier decisions for older transactions.

Example

Fourteen payer disclosures reach review. Eleven have a verified payer role, member, product, purpose, authority, record scope, endpoint, and receipt; three lack product-level evidence. Completeness is 11 of 14 disclosures.

Decide and verify each payer transaction

Classify the requested disclosure as approved for the named product and event, narrowed to fewer records, denied, or pending recipient or authority evidence. Record the member, service, payer role, product, purpose, consent, notice, dates, fields, endpoint, sender, and deadline. Preserve the denial or narrowing reason so operational pressure does not bypass it later.

After sending, confirm delivery, compare the payload with the approved record set, and capture the payer's acknowledgment and transaction outcome. Correct wrong member, product, endpoint, record, or date errors through privacy and incident procedures, not only through the billing queue.

Review denied claims and appeals for scope creep. A payer's request for more records begins a new disclosure decision even when it concerns the same authorization or claim.

Third-party-payer restriction checklist

• classify the legal recipient, product, payment basis, member, and service;
• distinguish the third-party payer from health plans, administrators, vendors, and QSOs;
• verify disclosure authority, consent elements, notice, minimum records, and endpoint;
• track authorization, coverage, claim, appeal, payment, and recovery separately;
• preserve the submitted version, receipt, payer response, corrections, and incidents; and
• recheck recipient restrictions after product, contract, purpose, or data changes.

This rule does not determine coverage, medical necessity, payment, or appeal rights and does not authorize every payer request. Current Part 2, HIPAA, state law, benefit terms, contract facts, and the specific disclosure need qualified review.