Search Index Authorization and Rebuild Verification for AFH Software

Search makes adult family home software fast only when every result respects facility, resident, role, record status, and current access. An index can leak deleted documents, return a resident from the previous facility, or omit new medication records after a failed rebuild even when the primary database is correct.

This guide covers search engineering, not which records a user is entitled to access. It was reviewed on August 8, 2026. Organizations should apply current privacy, record, workforce, contractual, and operational requirements to index design and support access.

Inventory indexed content

Document each index and its fields:

• Residents and contacts
• Caregivers and assignments
• Medication names and orders
• Pharmacy submissions and refill requests
• Documents and metadata
• Appointments, tasks, and incidents
• Notifications and support cases
• Public articles or terminology

Classify whether the index stores full text, selected fields, embeddings, prefixes, or only identifiers. An external service holding resident names or notes is another protected data store, not a harmless cache.

Treat authorization as a query prerequisite

Resolve tenant, role, resident permissions, and allowed record classes before the search request. Apply mandatory filters inside the search engine or use isolated indices that make cross-tenant retrieval impossible.

Do not query all facilities and remove unauthorized hits after ranking. Counts, snippets, timing, and suggested text can leak data even if rows are hidden later.

The cross-tenant authorization testing guide explains direct object, cache, file, queue, and search boundary tests.

Include authorization metadata

Each indexed document should carry protected fields such as:

• Tenant and facility
• Resource and parent IDs
• Resident relationship
• Record class
• Active, deleted, or historical status
• Allowed visibility group when used
• Source version
• Indexed time

These values come from the authoritative database, not browser input. Do not include broad role names without a versioned policy mapping.

Authorization at result open remains mandatory even when filtering is correct.

Separate public and protected search

Public blog, help, and medication terminology search can use dedicated indices without resident context. Protected resident and facility search should never share a query endpoint or cache namespace that can return public-style unfiltered results.

Recent prescribers, local compounds, pharmacy orders, and resident contacts are facility-specific even if they resemble reference data.

Keep public search crawlers and analytics away from protected endpoints.

Index the minimum necessary text

Ask which fields users need to find the record. A resident search may need name and approved identifiers, not every daily note. A document search may need title, class, date, and verified metadata rather than full OCR text.

Minimization reduces exposure, index size, and stale content. Store the source record ID and retrieve details after authorization.

Avoid indexing Social Security numbers, tokens, complete medication directions, incident narratives, or document bodies unless a documented use and stronger control require them.

Propagate changes reliably

Use a transactional outbox or change stream so database commits produce durable index work. Give every indexing event a stable ID and source version.

Workers process create, update, delete, restore, tenant move, role-policy change, and document reprocessing idempotently. A late older version cannot overwrite a newer indexed document.

Record source version, event ID, attempts, and final provider receipt for reconciliation.

Handle deletion and restore

When a record is soft-deleted, remove it from ordinary search or mark it deleted inside a separate authorized index path. A permanent disposal job must remove index documents, snippets, vectors, synonyms derived from protected text, and replicas according to policy.

Restore revalidates tenant, parent, current version, and authorization before reindexing. It must not revive an outdated child record or duplicate the result.

Search cleanup is part of the soft-delete and legal-hold workflow, including post-backup reconciliation.

Prevent stale facility switching

When a user changes facilities:

• Cancel in-flight searches
• Increment context version
• Clear suggestions and recent items
• Change tenant filter
• Discard late prior responses
• Reauthorize opened results

A result from Facility Alpha cannot render after the page displays Beta. Include tenant context in request and cache keys and verify it again on response handling.

Build safe autocomplete

Autocomplete leaks before a user clicks. Apply the same authorization to suggestions, counts, highlighting, typo correction, and recent history.

Require a meaningful minimum query for protected names where appropriate, limit results, and do not use empty search to return every resident.

Announce loading and result counts accessibly without exposing hidden counts from other tenants. Keyboard focus should not auto-select the first resident.

Plan a versioned rebuild

A rebuild should create a new index version beside the active one:

1. Freeze schema and mapping version.
2. Read source records by tenant with checkpoints.
3. Transform and index idempotently.
4. Validate counts and representative queries.
5. Run authorization tests.
6. Compare active and candidate results.
7. Switch the alias atomically.
8. Monitor and retain rollback briefly.

Never clear the production index before a replacement is verified.

Reconcile source and index

Compare independently:

• Source records eligible for indexing
• Indexed documents by facility and class
• Missing source IDs
• Orphaned index IDs
• Version mismatches
• Deleted records still searchable
• Restored records absent
• Tenant-field conflicts
• Indexing events exhausted after retry
• Search results whose open authorization fails unexpectedly

Use counts and sampled hashes without exporting resident text into the operations report.

Verify relevance without weakening security

Use synthetic queries, expected result sets, and human evaluation for exact name, partial name, spelling, medication, date, document class, and status searches.

Relevance tuning occurs after authorization. Do not widen tenant or role filters to improve recall.

Keep query analytics pseudonymous and avoid retaining protected terms unless necessary and approved. A search string can reveal a resident or condition.

Protect external search providers

If an external provider hosts the index, evaluate encryption, regions, access controls, subprocessors, retention, backups, incident response, logging, and deletion.

Use tenant-scoped credentials or filters and restrict administrative dashboards. Support staff at the provider should not receive unrestricted resident text.

Rotate keys and test that revoked credentials cannot query old replicas. Do not embed administrative search keys in browser code.

Design an operations console

Show:

• Active and candidate index versions
• Last successful event and rebuild checkpoint
• Queue age and failures
• Source/index count differences by tenant
• Missing, orphaned, stale, and deleted mismatches
• Alias switch and rollback history
• Authorization regression status
• Provider health

Use opaque IDs in the default view. Opening protected record detail requires a case and facility-authorized access.

Test search boundaries and rebuilds

Make the index switch reversible and observable

Elasticsearch's aliases documentation describes using aliases to direct operations to one or more indices and supports atomic alias changes. Whatever search engine an AFH product uses, keep the public index name separate from a versioned physical index. Build the candidate beside production, freeze its configuration, reconcile source IDs and versions, run tenant-authorization tests, and switch the application pointer only after the complete acceptance record passes.

Observe the candidate before and after the switch. Track eligible source count, indexed count, missing and orphaned IDs, update lag, authorization denials, empty-result rate, query latency, and errors by index version without logging resident search text. Retain the prior verified version only for a bounded rollback window and replay subsequent source events before moving back. If a validation fails, leave the active alias untouched and quarantine the candidate for diagnosis. This approach prevents a partial rebuild or mapping error from silently weakening facility isolation, while allowing search maintenance without a long outage.

Use synthetic tenants to verify:

1. Beta user cannot find Alpha resident by exact name.
2. Partial and misspelled queries preserve isolation.
3. Empty query reveals nothing unauthorized.
4. Autocomplete and counts use tenant filters.
5. Late Alpha response is discarded after switch.
6. Deleted record leaves ordinary search.
7. Restored record appears once.
8. Old update arrives after a newer source version.
9. Orphaned index record is removed.
10. Rebuild resumes from checkpoint.
11. Candidate index count matches source.
12. Authorization suite passes before alias switch.
13. Failed candidate leaves active index untouched.
14. Rollback restores prior verified alias.
15. Revoked provider key cannot search.
16. Query telemetry contains no synthetic protected text.

Test direct provider queries as well as the application interface.

Frequently asked questions

Is filtering results in the browser enough?

No. Apply authorization before retrieval and ranking; snippets, counts, suggestions, and timing can leak protected data.

Should the index contain full resident notes?

Only with a documented need and appropriate controls. Prefer minimal searchable metadata and retrieve full records after authorization.

Can a rebuild overwrite the current index?

Build and verify a separate version, then switch an alias atomically. Keep a bounded rollback path.

What happens when a record is deleted?

Remove it from ordinary search, retain protected lifecycle evidence as required, and purge every derived index artifact at permanent disposal.

How do we prove the index is complete?

Reconcile eligible source records against indexed IDs and versions, test authorization and representative queries, and monitor change-event lag.

Make fast search respect every care boundary

Safe AFH search minimizes indexed content, authorizes before retrieval, versions change events, handles deletion, isolates autocomplete, rebuilds beside production, and reconciles source and index continuously.

Explore AFH Manager to test resident search isolation, facility switching, deleted records, versioned rebuilds, source reconciliation, provider keys, and authorization regression with synthetic data.