Part 2 intermediary disclosure-date field

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(b)(2) requires the date of each disclosure in the intermediary's response. The rule does not define the technical event for every delivery architecture. The intermediary should adopt an approved, route-specific definition of when disclosure occurred and preserve the source timestamps needed to defend that displayed date and the three-year-window result.

Use the actual disclosure event

Current 42 CFR 2.24 requires the disclosure date. Define successful release for each route, such as completed portal availability, accepted interface transmission, verified secure message, or documented manual handoff. Preserve failed attempts separately.

Handle technical complexity

One disclosure can have queue time, transmission time, intermediary receipt, participant receipt, retry, correction, cancellation, and acknowledgment. Choose the legally supportable event with privacy and technical owners, and retain every source timestamp.

Reconcile to consent and lookback

Use § 2.31 to confirm the general designation. Test the patient, intermediary, recipient, record, event, date, time zone, three-year inclusion, duplicate logic, correction, and displayed response.

Define disclosure for each transport

Map secure messages, direct interfaces, HIE or network exchange, portal release, API retrieval, file transfer, fax, mail, courier, and manual handoff. For each, distinguish preparation, queueing, availability, attempted send, acceptance, recipient retrieval, failure, cancellation, and correction. Privacy, technical, and records owners should approve which event represents disclosure.

Store timestamps in a stable underlying format with time-zone or offset information. Convert to the patient-facing date consistently while preserving the original value, source system, clock, and event semantics.

Separate retries from new disclosures

A transport may retry the same payload several times before one succeeds. It may also deliver a corrected or expanded payload later. Link attempt identifiers, message or batch identifiers, payload versions, recipient acknowledgments, and status transitions so the list neither inflates retries nor hides a distinct later disclosure.

Document how partial delivery, split files, multi-recipient batches, queued portal access, download expiration, and manual replacement are treated. Apply the rule consistently and flag facts outside the approved pattern for review.

Reconcile time across systems

Compare application logs, interface engines, vendor records, recipient acknowledgments, audit trails, message metadata, and manual evidence. Investigate clock drift, daylight-saving changes, UTC conversion, date-only fields, migrated timestamps, overwritten status dates, and systems that retain only the latest retry.

Use the source closest to the legally relevant event, supported by corroborating evidence where possible. Avoid substituting report-generation, note-signing, batch-creation, encounter, or consent date for disclosure date.

Apply the date to consent and lookback

Match patient, intermediary, recipient, general-designation consent, effective period, revocation, disclosure event, payload, and date. Then test the stable date against the three-year request boundary. A date correction can change whether the event belongs in the response and should trigger a documented recheck.

Keep historical consent and recipient data so a later request does not evaluate an old disclosure using today's configuration. Record reviewer, source, normalization, boundary result, and any uncertainty.

Present, verify, and correct

Use an understandable date format and explain time-zone or estimate handling when material. Before delivery, sample the response against raw events, particularly entries at the window boundary, after migrations, with retries, or involving corrections.

If a wrong date was reported, preserve the original response, investigate scope, issue a corrected list securely, notify the patient as appropriate, and repair the upstream clock, event mapping, migration, or interface control. Track repeat defects by source.

Monitor entries close to the three-year boundary and records whose source timestamp changed after a retry or correction. Require an independent review when a one-day difference changes inclusion, the evidence conflicts, or a system preserved only a local date. Keep the conclusion and supporting logs with the response.

Example

Nineteen list entries are sampled. Sixteen have a defined event, source timestamp, time zone, consent match, retry treatment, window test, and reviewer; three use batch creation date. Field completeness is 16 of 19 entries.

Disclosure-date checklist

• define the successful disclosure event for every electronic and manual route;
• preserve source timestamps, time zones, event status, identifiers, and semantics;
• distinguish failed attempts, retries, partial delivery, corrections, and new disclosures;
• reconcile application, interface, vendor, recipient, audit, and manual evidence;
• tie the date to patient, consent, recipient, payload, and three-year boundary; and
• verify patient-facing dates and correct both responses and upstream defects.

The displayed date is a legal and operational fact derived from an event. It should never be a convenient report timestamp.