NPP availability on request

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

The requester category is broad

45 CFR 164.520 says the notice must be available on request to any person. Staff should not require the requester to prove patient status before providing a public notice. A separate privacy-right request may need identity or authority verification.

Design intake for an individual, caregiver, advocate, prospective patient, vendor, researcher, member of the public, or another person asking for the notice. Ask only which covered entity or plan and which accessible format or language is needed. Product or coverage-period facts may be necessary when the entity maintains several notices, but a diagnosis, treatment history, or explanation of purpose is not.

Publish more than one usable route

Provide a public web route and practical phone, office, or mail options that fit the entity. Explain how to request paper, another language, large print, accessible electronic content, or communication support. Route staff should know that the NPP is public and avoid sending the person into identity verification simply because the organization uses the same portal for protected records.

Each channel needs an owner, hours or response expectation, current source, fallback, and test. Monitor voicemail, shared mailboxes, web links, reception stock, portal pages, and vendor-hosted copies. During an outage, preserve the original request time and use an approved alternate route.

Public access still needs version control

Offer a clear web path, phone or office route, and paper or accessible format where appropriate. Each channel should pull from the approved notice inventory. Remove retired versions from active routes while preserving them in the documentation archive.

Use a notice-selection process when several entities, plans, products, jurisdictions, or effective periods exist. Record the limited facts used, selected version, requester format, delivery route, and result. If the relevant notice remains uncertain, provide trained review and explain the available options. Do not send a generic current notice solely to close the request.

Keep archives clearly separated from public current files. Search engines, old printed links, shared drives, and vendor storage can make a retired notice appear active. Use redirects and labels carefully so historical evidence remains retrievable without confusing the requester.

Follow the request through delivery

Useful states include received, clarification needed, notice selected, fulfilled, failed, returned, alternate format pending, and closed with supported disposition. Preserve the content or version delivered and time. A generated email or print job is an attempt; known transmission failure, returned mail, or empty pickup holder needs follow-up.

Sample responses for timeliness, current version, correct entity, language, accessibility, and safe route. Review duplicate or repeated requests as a possible sign that delivery or explanation failed rather than treating them as misuse.

Example with request channels

A practice tests six request paths: website, portal, phone, reception, mail, and accessible-format intake. Five return the current notice; the portal links to a retired version. Current-route availability is 5 of 6 channels. The portal stays open until corrected and retested.

The owner replaces the portal file, searches for the retired checksum across other public properties, and reviews requests made during the affected period. It completes a test request from discovery through delivery and records the version, format, and timestamp. Historical copies remain in a controlled archive.

Availability checklist

• Let any person request the public notice without unnecessary verification.
• Ask only for facts needed to select the entity, notice, and format.
• Offer tested web, phone, office, paper, and accessible routes.
• Pull every response from the controlled current-version inventory.
• Preserve request, selection, delivery, failure, and fallback evidence.
• Separate public notice provision from individual-right requests.
• Retest after notice, contact, portal, site, or vendor changes.

Owner controls

The HHS notice guidance outlines the availability requirement. Use a public request script, current-version registry, role ownership, language and disability access, route testing, response log, fallback, and correction deadline.

Monitor route availability, requests fulfilled, selection questions, old versions delivered, format needs, failures, aging, and recurring contacts. Audit from public channels into response evidence and from delivered notices back to the current source and applicable entity. Keep request data limited and protect contact preferences even though the notice itself is public.

Create a continuity package with current source files, approved print copies, contact scripts, language and accessibility instructions, alternate fulfillment vendors, and a manual request log. During an outage, assign a temporary owner and reconcile every logged request after systems return. Retire the manual copies when the current notice changes so emergency readiness does not become a source of obsolete delivery.