Part 2 intermediary three-year list window

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.24(a) limits a patient's written intermediary-list request to disclosures made within the past three years. The population is narrower than every disclosure involving the patient: it consists of records the intermediary disclosed under the general designation in the patient's consent. Section 2.31(a)(4)(ii)(B) supplies that consent route.

Lock the calculation

42 CFR 2.24(a) sets the past-three-years limit. Record request-receipt timestamp, applicable calendar method, start and end instants, time zone, and handling of the boundary date. Counsel should resolve unusual date disputes.

Filter by the right disclosure population

Include disclosures made by the named intermediary pursuant to the patient's general designation. Do not mix direct named-recipient consents, other exceptions, internal uses, access logs, or disclosures outside the window into the list.

Preserve source completeness

Use the consent framework to match the designation. Reconcile active and legacy systems, interfaces, vendors, archives, corrections, recipient changes, and missing periods. Explain verified limitations instead of silently shortening the window.

Fix the window before searching

Record the written-request receipt date and time, governing time zone, approved calendar method, exact start and end boundary, and reviewer. The text uses “within the past 3 years,” so counsel should resolve leap-day, date-only, time-zone, and inclusive-boundary questions and document a consistent rule.

Keep the original window stable when identity, authority, consent matching, or scope clarification takes time. A later search date should not silently move the lookback forward and exclude earlier disclosures.

Build the right disclosure population

Identify the patient, intermediary, operative consent, general designation, participant class, treating-provider relationship where applicable, consent effective period, revocation, and every disclosure made under that route. Exclude direct named-recipient consents, patient access, internal activity, unrelated accounting events, legal-process disclosures, and other Part 2 exceptions unless they also fit the section 2.24 definition.

Use one stable disclosure identifier across event logs, recipient records, payload evidence, corrections, and the response. This prevents the same event from appearing twice merely because several systems handled it.

Search all systems that cover the period

Inventory active and retired applications, interfaces, HIE or network services, secure messaging, release modules, manual logs, recipient directories, archives, acquired systems, vendors, subcontractors, backups used for retrieval, and paper evidence. Record each system's coverage dates, owner, search method, result, limitation, and reconciliation status.

Investigate missing intervals, migrations, clock changes, renamed recipients, merged entities, retry storms, failed transmissions, corrected payloads, and unmatched events. Explain a verified source limitation to the patient when appropriate rather than shortening the window without disclosure.

Decide which events count

Define successful disclosure for each route. Separate queue creation, attempted transmission, acceptance, availability, download, correction, cancellation, and acknowledgment. Failed attempts usually need different treatment from records actually disclosed; technical and privacy owners should approve the mapping and retain source timestamps.

A corrected disclosure may be another reportable event or a correction to an existing entry depending on what occurred. Preserve both the source facts and the final presentation rule.

Review, respond, and retain evidence

For every in-window entry, verify recipient entity, disclosure date, brief information description, consent match, evidence link, and correction state. Review the window calculation and exclusions before secure delivery. Keep enough protected evidence to reproduce why an event was included or excluded.

Audit mature responses for full three-year source coverage, stable boundaries, correct designation, duplicate logic, verified limitations, required fields, and the 30-day response deadline. Correct the list and underlying data controls when an omission surfaces.

Set log retention and migration controls so a request received today can be reconstructed for the entire applicable period. Test recoverability after system retirement, vendor exit, merger, or archival format change instead of assuming stored data remains searchable.

Example

Twelve list searches are audited. Nine lock the as-of date, three-year start, consent, sources, legacy coverage, exclusions, reconciliation, and reviewer; three omit an acquired-system year. Completeness is 9 of 12 searches.

Three-year-window checklist

• lock receipt, time zone, start, end, calendar method, and boundary treatment;
• keep the window fixed while identity, consent, and clarification work proceeds;
• limit the population to disclosures under the patient's intermediary general designation;
• inventory and search every active, legacy, acquired, manual, archive, and vendor source;
• resolve successes, failures, retries, corrections, duplicates, and missing periods; and
• verify required fields, exclusions, delivery, corrections, and reproducible evidence.

The three-year rule is both a date boundary and a source-completeness obligation. A correct calculation cannot compensate for a missing system year.