Part 2 public-health recipient gate

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.54(a) requires the no-consent public-health disclosure to be made to a public health authority as defined in Part 2. That definition cross-references the HIPAA definition. The program should verify the destination's official public-health responsibility and any person or entity acting under the authority's grant, contract, or other agency relationship rather than relying on a project label.

Classify the actual destination

Current 42 CFR 2.54(a) points to the Part 2 definition of public health authority. Record the entity, agency or authority relationship, statutory or delegated function, requestor, agent or contractor role, purpose, legal source, effective date, and qualified reviewer.

Trace intermediaries

If a platform, health information exchange, contractor, researcher, or data processor sits between the program and authority, map every recipient and transfer. Determine whether each entity acts for the authority and which contracts, security duties, notices, or separate permissions apply.

Recipient status clears one gate

The record content must also satisfy the de-identification requirements cross-referenced in 45 CFR 164.514(b). A correct public-health recipient does not make identifiable Part 2 records eligible for the § 2.54 no-consent route.

Identify the legal entity and function

Record the recipient's legal name, government or delegated relationship, official mandate, public-health responsibility, requesting unit, authorized contact, purpose, legal source, effective dates, and reviewer. Match those facts to the cross-referenced definition and the actual request.

A government email address or letterhead helps authenticate a request but does not by itself prove that the particular unit, person, or function falls within the public-health-authority role.

Verify agents and contractors

When a platform, contractor, university, laboratory, researcher, HIE, or nonprofit acts for the authority, preserve the grant, contract, memorandum, purchase order, or other evidence establishing the relationship and public-health function. Identify who directs the work, who receives data, permitted uses, systems, locations, subcontractors, retention, and return or deletion.

Do not assume that every party in a government-funded project is part of the qualifying recipient chain. Independently analyze parties using information for their own purpose.

Authenticate the complete destination

Verify requester identity, authority contact, official route, account, endpoint, certificate, environment, and any intermediary. Use independent confirmation for new or changed requests and protect against spoofed government identities. Preserve the request, verification, routing test, approval, transmission, and acknowledgment.

If an authority directs delivery to a third-party service, map that transfer rather than treating the authority as the only recipient.

Keep the data gate separate

Even a correctly classified authority can receive records without patient consent under section 2.54 only when the disclosed content is de-identified under 45 CFR 164.514(b) and leaves no reasonable basis to believe it can identify a patient. Verify the exact release output and method before transfer.

If the request seeks identifiers, detailed dates, rare combinations, narrative, images, linkage keys, or a re-identification mechanism, stop this route and obtain qualified analysis of another authority.

Govern recurring requests

Set effective dates, approved datasets, purpose, frequency, contacts, route, output method, and review triggers for recurring disclosures. Reconfirm after organizational, statutory, contractual, technical, personnel, or purpose changes. Do not let an old approval cover a new program or data use.

Audit active and inactive recipient chains, agent evidence, authentication, data outputs, renewals, changes, denials, and incidents. Investigate stale contacts, unsupported contractors, unexpected recipients, and data sent beyond the approved public-health function.

Ask the requesting authority to separate required data, optional data, technical transport, intended users, retention, and public-release plans. The answers support both recipient and output review and can expose a contractor or secondary purpose that the initial request omitted. Record changes through a controlled amendment or new request. Operational familiarity with a long-standing registry should not substitute for current evidence that the same entity and function remain within the approved authority relationship.

Example

Fifteen recipient chains are reviewed. Twelve document the authority, legal function, requestor, agent roles, contracts, data path, de-identification dependency, and reviewer; three list only a project name. Recipient evidence is complete for 12 of 15 chains.

Public-health recipient checklist

• identify the legal entity, official mandate, unit, function, and public-health purpose;
• preserve evidence for each agent, contractor, researcher, platform, and intermediary;
• authenticate the requester, authority, endpoint, account, environment, and route;
• keep recipient qualification separate from de-identification of the exact output;
• time-limit and revalidate recurring requests after legal or operational change; and
• audit recipient chains, renewals, denials, misroutes, unsupported uses, and incidents.

The recipient gate follows the real authority relationship and data path. A public project name is not a substitute for that evidence.