Soft Delete, Restore, and Legal Hold for AFH Records

Delete buttons in adult family home software should remove mistakes and clutter without destroying evidence that must remain available. A recoverable deleted state, controlled restore, retention schedule, and legal or administrative hold allow records to leave daily views while preserving confidentiality, chronology, and required access.

This guide supports information lifecycle design, not legal advice or a universal retention schedule. It was reviewed on August 8, 2026. Providers should verify current Washington requirements, litigation and investigation duties, contracts, employment rules, billing obligations, and facility policy before disposal.

Classify records before defining deletion

Create lifecycle classes for:

• Resident profile and care records
• Medication orders and MAR events
• Incidents and investigations
• Assessments and negotiated care plans
• Resident and facility documents
• Caregiver personnel and credential records
• Financial and subscription records
• Pharmacy submissions and receipts
• Technical logs and support attachments
• Drafts and temporary uploads

Each class needs an owner, retention source, active period, closed period, allowed deletion states, hold behavior, restore permission, and disposal method.

Do not implement one global “delete after 30 days” rule.

Distinguish draft deletion from record correction

An unsubmitted draft with no downstream references may be deleted or recovered simply. A signed medication administration, accepted order, incident, or care note is historical evidence and normally requires amendment, void, or supersession rather than deletion.

Use precise actions:

• Delete draft
• Move to deleted items
• Mark entered in error
• Supersede with a new version
• Amend historical entry
• End active status
• Dispose after retention

Do not label all actions “Delete.” Users need to understand the effect before confirmation.

Use a tombstone record

Soft deletion should preserve a protected tombstone containing:

• Record and tenant identifiers
• Record class and parent relationship
• Original creator and time
• Deleting user and time
• Reason when required
• Lifecycle policy version
• Recovery deadline
• Hold status
• Prior version reference
• Final disposition state

Remove the item from ordinary searches and active workflows while keeping authorized deleted-item and audit views.

Do not expose deleted resident names in notifications or broad administrator lists unnecessarily.

Make deletion transactional

Before deletion, identify references such as MAR events, reports, attachments, tasks, pharmacy messages, counts, notifications, and child records.

For a draft parent with draft children, delete the graph according to a previewed rule. For historical records, block destructive deletion and offer the correct amendment or inactive-state workflow.

Commit the tombstone, search removal, active-state change, and audit event atomically. A failure should not leave the record visible in one module and missing in another.

Design a useful deleted-items view

Use filters for facility, resident, module, deleted date, deleting user, recovery deadline, hold, and final disposition.

Show record type, safe identifying context, original date, deletion time, reason, dependencies, recovery eligibility, and primary action. Do not make users navigate a separate mobile-style wrapper or side menu.

The secure document upload guide explains versioned files, deleted views, and protected delivery for resident documents.

Deleted items must remain subject to facility and resident authorization; deletion is not declassification.

Restore into the correct context

Before restore, verify current facility, resident, parent record, schema, permissions, and conflicts. Preview:

• Exact record and version to restore
• Current conflicting record
• Children and attachments
• Active workflows that will or will not resume
• Search and report visibility
• Notifications or schedules affected

Restoring a deleted draft medication should not activate an order. Restoring a document should not overwrite a newer version.

Create a restoration event with reviewer and reason and retain the deletion event.

Prevent cross-facility restoration

The server derives tenant context from current grants and validates the tombstone's facility. A multi-facility manager cannot restore a Facility Alpha record while operating in Facility Beta merely by changing an ID.

Storage files, thumbnails, search indexes, queues, and backups must all retain tenant scope. A restored object gets the same protected ownership, not the currently selected facility by default.

Test deleted-item URLs and bulk restore directly against APIs.

Apply legal and administrative holds

A hold suspends scheduled disposal for records within a defined scope. Capture:

• Hold identifier and authority
• Matter or reason
• Facilities, residents, users, dates, and record classes covered
• Issued and effective times
• Issuer and approver
• Notification and acknowledgement
• Review date
• Release authority and time

Apply holds to active, deleted, archived, exported, and backup copies according to the approved process.

Do not reveal confidential matter names broadly. Users need a disposal-blocked status and authorized contact.

Handle overlapping holds

A record may be covered by several holds. Disposal remains blocked until every applicable hold is released.

Evaluate holds through deterministic scope rules and save the matched hold IDs on each disposal decision. Changing a hold must trigger reconciliation for affected records.

Do not permanently mark a record held based only on a copied boolean. Preserve the relationship and version so reviewers can explain why it was protected at a point in time.

Implement retention from authoritative sources

WAC 388-76-10315 requires resident records to be kept for three years after the resident leaves the home or dies, along with confidentiality, protection, availability, and access duties.

Other record classes or circumstances may have different or longer periods. Store the rule source, version, triggering event, calculated eligibility date, and overrides.

Do not calculate resident retention from the upload date when the rule begins at discharge or death.

Keep backups consistent with disposal

Encrypted backups may retain disposed records until backup expiration. Document this behavior, prevent ordinary restoration from resurrecting disposed data, and apply hold controls to backup rotation.

Maintain a disposal ledger or tombstone set that post-restore reconciliation can reapply. After disaster recovery, verify active, deleted, held, and disposed states before reopening access.

Do not claim immediate physical erasure from immutable backups when the actual process is expiration plus access exclusion.

Protect permanent disposal

Require a scheduled job or authorized workflow that checks:

• Retention eligibility
• No active holds
• Correct tenant and record class
• No unresolved required relationship
• Approval when policy requires it
• Backup and derivative handling
• Disposal method

Use a preview manifest and stable disposal job ID. Record counts, exceptions, object checksums or protected references, start, completion, and verifier.

Permanent disposal should not be reversible through the application. Explain that clearly before approval.

Preserve audit evidence appropriately

The system may need a minimal non-content record proving that a protected item existed and was disposed under an authorized policy. Define exactly which metadata remains and why.

Do not retain the resident narrative or document contents inside the audit event after claiming disposal. Keep opaque identifier, record class, policy, eligibility, approvals, timestamps, and outcome when appropriate.

Protect disposal ledgers from alteration and restrict access.

Manage search, reports, and alerts

Deleted records should leave active search results, counts, reminders, and workflows. Authorized reports may include deleted or restored states when explicitly filtered.

A deleted medication draft should not generate schedule opportunities. A voided historical MAR event remains represented through its amendment or void chronology rather than disappearing from the audit report.

Show active filters and data-through time. Do not count a restored item twice during search-index synchronization.

Support safe bulk actions

Bulk delete and restore need a preview manifest grouped by facility, record class, eligibility, dependencies, holds, and blocked items.

Limit batch size, require reauthentication for high-impact actions, and use idempotent item IDs. A retry should return prior results rather than deleting a restored record again.

Never allow a broad selection such as “all records” to cross facilities without a specific platform-authorized process.

Test the lifecycle

Use demonstration records to verify:

1. Unreferenced draft moves to deleted items.
2. Signed MAR event blocks destructive deletion.
3. Entered-in-error workflow preserves chronology.
4. Deleted document retains private authorization.
5. Restore conflicts with a newer version.
6. Cross-facility restore is denied.
7. Recovery deadline uses the correct policy.
8. Resident retention begins at discharge or death.
9. Hold blocks scheduled disposal.
10. Two overlapping holds require two releases.
11. Released hold triggers recalculation.
12. Bulk job skips ineligible items.
13. Retry is idempotent.
14. Backup restore reapplies disposal tombstones.
15. Permanent disposal removes derivatives.
16. Minimal disposal ledger contains no record content.

Inspect primary data, search indexes, files, reports, backups, and audit history after each scenario.

Frequently asked questions

Can a signed care record be soft-deleted?

Use amendment, void, or supersession when the history must remain. Reserve deletion for states and record classes where policy permits it.

Does a deleted record remain confidential?

Yes. Deleted items, files, tombstones, and restores retain tenant, resident, and role authorization.

What does a legal hold do?

It suspends disposal for a defined record scope until every applicable hold is released by authorized people.

Can permanent deletion remove immutable backups immediately?

Not always. Document backup expiration and access exclusion honestly, prevent resurrection on restore, and honor holds.

Should restore reactivate workflows automatically?

Only when the record class and reviewed restore plan require it. A restored draft or historical item must not silently create schedules, alerts, or access.

Make deletion recoverable and disposal defensible

Strong lifecycle controls classify records, separate correction from deletion, preserve tombstones, authorize restore, evaluate overlapping holds, enforce retention, and verify disposal across files, indexes, and backups.

Explore AFH Manager to test deleted-item tabs, protected restore, record amendments, retention calculations, legal holds, bulk previews, and disposal reconciliation with demonstration data.