Adult family home data export and backup serve different purposes. An export gives an authorized person a usable copy of selected records; a backup allows the system to recover from loss or corruption. A folder of PDFs is not a full database backup, and an encrypted backup is not automatically a readable resident-record handoff.
This guide supports continuity and software evaluation, not legal advice or a universal backup schedule. It was reviewed on August 8, 2026. Providers should verify retention, confidentiality, resident access, contracts, disaster recovery, and operational requirements.
Define recovery objectives
For each system and record class, set:
- Recovery point objective: acceptable data loss measured in time
- Recovery time objective: acceptable restoration time
- Minimum continuity capability
- Responsible owner
- Dependencies
- Verification method
Medication and current resident records may need tighter objectives than public marketing content. Do not publish one platform-wide promise without testing every critical module.
Include authentication, facility assignments, files, search, queues, audit records, configuration, and encryption keys—not only database rows.
Inventory authoritative systems
Map:
- Primary database and replicas
- Object storage and documents
- Authentication provider
- Payment and subscription provider
- Pharmacy integration events
- Email and notification status
- Search indices
- Background queues
- Analytics and technical logs
- Source code and deployment configuration
Identify which data can be rebuilt and which is authoritative. A search index can be regenerated; signed MAR history cannot.
Document external provider export and recovery dependencies.
Separate user export from system backup
A facility export may include resident profiles, medication lists, MAR reports, care plans, documents, caregiver records, and audit manifests in readable or structured formats.
A system backup preserves internal IDs, relationships, versions, timestamps, permissions, and application state for restoration.
Do not give every facility administrator raw multi-tenant database dumps. Do not claim portability from an opaque encrypted snapshot only the vendor can read.
The report authorization guide explains query scope, redaction, rendering, and expiring delivery.
Design authorized facility exports
Let users select facility, residents, record classes, date range, file formats, and purpose. Preview counts and sensitive fields.
Verify role and resident scope before query and again before delivery. Use step-up authentication for full-facility exports and record requester, approval, template version, data-through time, checksum, downloads, expiration, and disposal.
Generate a manifest listing files, record counts, versions, and hashes. Do not email a permanent public archive link.
Choose interoperable formats
Provide clean PDFs for human review and structured CSV or JSON for appropriate tabular and relational data. Include a data dictionary, schema version, timezone, identifier rules, and relationship keys.
Preserve original text and normalized values where both matter. Maintain leading zeros in NDC, NPI, and local identifiers.
For documents, include original files when authorized plus a manifest of class, date, resident, version, checksum, and status.
Do not flatten amendments or order versions into one unexplained current row.
Encrypt backups and exports
Encrypt transport and storage with managed keys, limited identities, rotation, and audited access. Separate backup administration from ordinary application roles.
For downloadable archives, use authenticated expiring access; add archive encryption only with a workable secure key-delivery and recovery process.
Do not place passwords in the same email as the archive or log encryption keys in job output. Verify restored data can be decrypted after key rotation.
Use multiple failure domains
Keep recovery copies separated from the primary environment by account, region, storage control, or other architecture appropriate to risk. Protect against accidental deletion, ransomware, provider outage, and administrator compromise.
Replication alone is not backup: corruption or deletion can replicate instantly. Preserve versioned or immutable recovery points under a documented retention schedule.
Monitor backup job completion, size anomalies, encryption, replication, and expiration.
Back up tenant and authorization context
A restored resident record without its facility, role, and document permissions can become exposed or unusable. Preserve tenant relationships, user assignments, record ownership, lifecycle states, and audit history.
After restore, default the environment closed until authorization and tenant-isolation tests pass. Do not open access because row counts look correct.
The cross-tenant regression testing guide provides direct API, cache, file, queue, and report boundary cases.
Preserve deletion and legal hold state
Backups may contain records later disposed from the active system. Maintain disposal tombstones or a ledger that restoration reconciliation can reapply before access.
Legal holds may require retaining selected records beyond ordinary backup rotation. Track hold scope and release without copying confidential matter names into broad dashboards.
Do not let disaster recovery resurrect a soft-deleted document into normal search or erase an amendment chronology.
Make backups application-consistent
Coordinate database, files, queues, and external references around a recovery point. A database snapshot that references documents captured hours later may be inconsistent.
Use transaction logs, object versions, checkpoints, and manifests to establish the data-through boundary. Pause or account for writes where required.
Record backup ID, start, completion, component checkpoints, software and schema versions, encryption version, counts, checksums, and verification.
Test restoration, not only backup creation
Restore into an isolated environment on a schedule. Measure actual recovery point and time.
Verify:
- Database integrity and counts
- Resident-facility relationships
- Medication orders, schedules, and MAR history
- Documents and checksums
- Deleted and held states
- User roles and session invalidation
- Search rebuild and tenant filters
- Background queue reconciliation
- Reports and exports
- Audit chronology
A green backup job without a tested restore is weak evidence.
Protect production during drills
Use isolated accounts, networks, domains, notification sinks, payment test mode, and pharmacy simulators. Disable real email, webhooks, and scheduled medication notifications.
Replace sensitive production data with synthetic or protected copies when possible. If production data is necessary for a controlled recovery test, restrict access and dispose of the environment afterward.
Never let the restored environment accept live caregiver writes.
Plan provider and regional outages
Document dependencies and alternatives when authentication, database, storage, email, or pharmacy services are unavailable. Maintain emergency contacts and escalation.
Offline capability is one continuity method, but it may fail during device loss or power outage. Keep approved downtime instructions and reconcile records after restoration.
The offline sync guide explains stable event IDs, pending queues, server receipts, and conflict review.
Support vendor exit and facility portability
Define how a facility requests a final export, verifies completeness, receives it securely, and retains access during transition. Include data dictionary and manifest.
State which formats, documents, audit history, and versions are included; how long export access remains; and when vendor copies are disposed under contract and law.
Do not make facility records dependent on printing every website page manually.
Monitor and report backup health
Track:
- Last successful recovery point by component
- Backup age and size anomaly
- Failed or partial jobs
- Immutable-copy status
- Key and restore-readiness status
- Last successful restore test
- Actual recovery time and data loss
- Reconciliation exceptions
- Expiring recovery points under hold
- Export jobs awaiting delivery or disposal
Alert on missed recovery objectives and verify the monitoring path itself.
Test complete failure scenarios
Base continuity decisions on a maintained recovery plan
NIST SP 800-34 Rev. 1 describes contingency planning through business impact analysis, preventive controls, recovery strategies, plan development, testing, training, exercises, and maintenance. Translate that lifecycle into named AFH responsibilities. The product operator may restore infrastructure, but a facility leader still needs to validate resident rosters, current orders, recent administrations, caregiver access, pharmacy relationships, documents, and notifications before normal work resumes.
Write a recovery acceptance sheet that records the backup identifier, encryption key version, restore environment, last recoverable event time, missing components, tenant-isolation results, sample record checks, delayed integrations, and the person authorizing return to service. Exercise it after material architecture changes and on a defined calendar. Include a communications path for facilities when recovery objectives are missed. A successful database command is only a technical milestone; recovery is complete when authorized users can safely resume resident care, outstanding offline or pharmacy events reconcile once, and the evidence explains any remaining gap.
Use synthetic data to verify:
- Accidental resident record deletion.
- Database corruption discovered after replication.
- Missing document objects.
- Authentication provider outage.
- Primary region unavailable.
- Encryption key rotation before restore.
- Backup contains later-disposed records.
- Legal hold overlaps expiration.
- Search index rebuild preserves isolation.
- Offline event arrives after recovery.
- Pharmacy webhook is replayed safely.
- Restored environment sends no real notifications.
- Full-facility export excludes other tenants.
- PDF and structured counts reconcile.
- Final vendor-exit package validates checksums.
- Recovery objectives are measured and reported.
Document failures and repeat the drill after corrections.
Frequently asked questions
Is exporting PDFs the same as backup?
No. PDFs support human use; backups preserve internal relationships and system state needed for restoration.
Is database replication enough?
No. Replication can copy deletion or corruption. Keep versioned recovery points in separate failure domains and test restore.
Should backups include deleted records?
Historical recovery points may, but restoration must reapply deletion, disposal, and hold state before reopening access.
How do we know a backup works?
Restore it in isolation, verify components and tenant authorization, reconcile records, and measure actual recovery time and data-through point.
Can a facility receive its data when leaving the vendor?
Plan a secure, authorized, documented export with readable and structured formats, files, manifests, checksums, and clear delivery and disposal timelines.
Make recovery and portability provable
Strong continuity separates exports from backups, maps authoritative systems, encrypts across failure domains, preserves tenant and lifecycle state, tests restoration, and delivers facility data through verified manifests.
Explore AFH Manager to test facility exports, backup manifests, isolated restore, tenant validation, deletion reconciliation, offline recovery, and vendor-exit portability with synthetic records.