Part 2 consent expiration date or event

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

The boundary must be interpretable

42 CFR 2.31 permits a date or qualifying event. Define event ownership and evidence before using phrases such as end of treatment or end of study. “None” should be presented as an intentional patient choice in the applicable TPO context.

Offer approved options that fit the consent purpose and explain them before signature. A calendar date should include a clear date convention. An event should be tied to the patient or use or disclosure purpose and understandable without an internal code. Avoid vague terms such as “when no longer needed” unless qualified review confirms a reliable, patient-facing and operational meaning.

Define each event before the form is released

For end of treatment, identify the program or episode, clinical or administrative event, responsible source system, corrections, readmission, transfer, and closure owner. For end of study, identify the protocol, study status, database or repository activity covered, sponsor or investigator source, early termination, extension, and archive implications. For another event, record exactly who determines it and what evidence closes it.

Use a versioned event dictionary with patient-facing wording, normalized code, source, effective time, owner, update frequency, fallback, and test cases. Do not rely on a manual field that no team owns.

Systems need event resolution

Record consent start, expiration text, normalized event, date when known, source system, patient or study status, revocation, reliance, and release decision. Recalculate after corrections and prevent a batch job from using stale consent state.

Create one authoritative consent state that considers signature, start, expiration, revocation, deficiency, and later corrections. Propagate expiration events to EHR, HIE, portal, API, vendor, research, billing, paper worklists, and scheduled exports. Preserve event acknowledgments and exceptions. A central expired flag is insufficient when a downstream batch remains active.

Revocation can end future consent-dependent action before the stated expiration. Keep revocation receipt, effective state, and propagation separate from the expiration event. Prior actions taken under valid consent remain in history. Do not change the expiration date to simulate revocation.

Validate immediately before every use or disclosure

Compare the actual event time with consent start, expiration wording, resolved event, revocation, request, record scope, purpose, recipient, and discloser. Recheck long-running jobs and recurring feeds for each event or approved batch. A consent active when a job was scheduled may be expired when records leave.

Use a hold for unknown event state, stale source, conflicting dates, reopened episode, extended study, identity correction, or unconfirmed “none” choice. Qualified owners decide the next step and patient communication. Never assume an unknown event means active.

Keep “none” and research language controlled

Where the rule permits “none” or similar language for TPO, present it as a deliberate scope choice with revocation explanation and no hidden default. Record the exact language and patient's selection. Review state or other limits and downstream systems.

For research, align consent language with the study and any database or repository creation or maintenance. Changes to study end, repository purpose, investigators, or use may need renewed analysis and consent. Do not let a broad research event become permanent authority for unrelated secondary use.

Example with expiration checks

Twenty consents reach release review. Eighteen are active; one treatment episode ended and one research end event occurred. Active-consent readiness is 18 of 20 consents.

The program blocks both expired requests, confirms source events, and checks for scheduled downstream jobs. It preserves the original consent and event evidence and provides a new-consent route if appropriate. No expiration date is overwritten.

Expiration checklist

• Use a date or event that the patient and system can interpret.
• Define event source, owner, effective time, correction, and fallback.
• Present TPO “none” as a deliberate choice, not a default.
• Align research end events with study and repository scope.
• Combine expiration with revocation and defect states accurately.
• Recheck state immediately before disclosure and recurring batches.
• Preserve original terms, event evidence, holds, and corrections.

Owner controls

The 2024 final rule supports the updated consent structure. Use controlled options, patient-facing explanation, event feeds, alerts, manual review, immutable history, revocation coordination, and audit samples.

Monitor active, expired, unknown, revoked, and corrected consents; event-feed age; downstream propagation; blocked jobs; and held disclosures. Audit from disclosures back to active state and from event sources into every dependent workflow. Retest after program, research, consent, vendor, or system changes.