Part 2 named-registry and known-program consent

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.34(a)(3)(i) requires written consent meeting section 2.31 and listing the name and address of each central registry and each known withdrawal-management or maintenance-treatment program to which disclosure will be made. Paragraph (a)(3)(ii) separately permits a consent designation for qualifying unnamed programs within 200 miles.

Capture each known recipient

Current § 2.34(a)(3) requires names and addresses for the registry and known programs. Preserve legal or operating name, address, recipient type, directory source, effective date, patient-facing display, signed value, and later corrections.

Keep the signed record intact

When a recipient changes name, address, ownership, interface, or program type, determine whether the original consent still supports disclosure. Store normalized routing separately from the signed text and route material changes for a new consent or qualified review.

Validate the full consent

The special fields sit alongside 42 CFR 2.31. Check patient, authorized discloser, record description, recipient, purpose, revocation, expiration, signatures, date, applicable warnings, and any authority required for a minor or representative.

Build a verified recipient directory

For every central registry and known program, preserve legal or operating name, physical or official address, program and recipient type, site identifier, status, directory source, effective dates, data-sharing participation where relevant, routing identifiers, and owner. Distinguish a program site from its parent entity, vendor, pharmacy, HIE, or billing address.

Use the directory to support consent preparation and release validation. Do not let the directory silently rewrite the patient-signed document.

Present known recipients accurately

Show the patient the names and addresses required by section 2.34 in understandable form. Preserve the exact signed value, consent version, presentation date, accessibility support, and any patient questions. Avoid using only an interface alias, acronym, or national corporate address when it does not identify the receiving program.

For the unnamed-program option, use the specific within-200-mile language and keep it distinct from the known recipients already identified. A generic all-providers or all-networks designation is too broad for this route.

Validate every ordinary consent element

Confirm patient name; authorized discloser; specific and meaningful records; recipient designations; purpose; revocation right and method; expiration; signature and date; required minor, capacity, or deceased-patient authority; and other applicable section 2.31 statements. The special registry and program terms supplement rather than replace those elements.

Check consent currency at the treatment event and release time. Record revocation, expiration, reliance, and any materially false or deficient information.

Govern recipient changes

When a program moves, changes name, merges, closes, changes program type, or leaves a registry network, preserve history and determine whether the consent still identifies the intended recipient. Route material changes for new consent or qualified privacy and legal review. Do not merely update the destination behind the signed text.

Prevent disclosure to a newly known program under the unnamed designation without confirming it qualifies, sits within the radius, and fits the signed wording. Once known, document how future consent will present it.

Test consent-to-route matching

At release, compare the signed name and address or valid unnamed class with the actual destination, program type, location, 200-mile result where applicable, trigger, payload, purpose, and secure route. Preserve the matched values, reviewer, timestamp, and evidence.

Audit consents and transmissions for missing addresses, aliases, stale sites, undisclosed recipient substitutions, broad designations, expired forms, and routing that reaches a different entity than the patient saw.

Provide language and disability access throughout consent. Record interpreter or accommodation support without pressuring the patient, and verify representative authority when someone else signs. A technically complete recipient list still needs an informed and valid patient decision.

Example

Twelve consents naming known recipients are audited. Ten preserve signed names and addresses, recipient type, directory source, consent version, and route test; two show only a vendor alias. Field completeness is 10 of 12 consents.

Named-recipient consent checklist

• maintain verified registry and program names, addresses, types, sites, and effective dates;
• preserve the exact patient-signed values without silent directory substitution;
• distinguish known recipients from the qualifying unnamed-program 200-mile option;
• validate every section 2.31 element, authority, revocation, expiration, and date;
• route moves, mergers, ownership, closure, and program-type changes for review; and
• match consent to the actual trigger, recipient, location, payload, purpose, and route.

Consent should let the patient understand the known destinations. Technical aliases and backend routing cannot replace that patient-facing specificity.