Offline Sync Conflict Resolution for Adult Family Home Records

An adult family home application may lose connectivity while staff are recording medications, daily notes, tasks, incidents, or vital signs. Offline support is safe only when the system can show what is stored locally, transmit it once, detect competing changes, preserve authorship, and require review when automatic reconciliation would be misleading.

This guide covers information-system design, not clinical judgment or a promise that every workflow should work offline. It was reviewed on August 8, 2026. Providers should define approved downtime procedures and verify current privacy, licensing, recordkeeping, delegation, and resident-specific requirements.

Decide which actions may occur offline

Start with an explicit capability matrix. For each module, define whether a user can view cached data, create a new event, edit an unsent event, amend a synchronized record, attach a file, or delete a draft.

High-consequence actions may need stricter rules. A medication administration recorded offline can be supported when the user has a verified current order and schedule snapshot. Creating a new active medication, accepting a pharmacy order, changing user access, or permanently deleting a document may require an online server check.

Display an unmistakable offline state and the time through which resident data is current. Do not let a green check imply server confirmation when an event exists only on the device.

Model offline work as events, not overwritten rows

Give every locally created action a cryptographically strong, device-generated event identifier before it is saved. Include:

• Resident and facility identifiers
• Record type and parent record
• Author and authenticated session
• Device identifier
• Event occurrence time
• Local entry time
• Base server version
• Payload schema version
• Sync state

On retry, send the same event identifier. The server should treat repeated submissions idempotently so a weak connection does not create two administrations or two notes.

Keep occurrence time, entry time, upload time, and server acceptance time separate. Backdating every offline action to its eventual sync time destroys the chronology.

Replace silent last-write-wins behavior

If two users change the same logical record, the latest upload is not necessarily the correct clinical fact. Compare the incoming base version with the current server version and classify the overlap.

Changes to different nondependent fields may be merged under a tested rule. Changes to the same value, status, resident association, order version, or medication outcome require review. Preserve both candidates and show:

• Original server value
• Offline proposed value
• Authors and event times
• Devices and upload times
• Fields in conflict
• Related evidence
• Permitted resolution actions

Never discard one side of a conflict from the audit trail. Resolution should create another event with the reviewer, reason, and retained value.

Treat medication records as a special case

A medication opportunity needs a stable identifier derived from the resident, effective order version, schedule, and intended occurrence. An offline “given” event must point to that opportunity rather than rely on medication name and clock time alone.

When another caregiver already recorded the opportunity as given, refused, held, or missed, the server should return the existing outcome and open a reconciliation view. It must not create a second dose record.

If evidence shows medication was administered but a prior missed status was entered, use an additive amendment. Retain the missed event, record the corrected outcome and actual administration time, identify the person making the correction, and preserve any required review. The missed medication correction guide describes this chronology in more detail.

Freeze the relevant reference snapshot

Offline forms should carry the version of the information used when the action occurred:

• Current medication order and directions
• Scheduled opportunity
• Resident status and absence
• Care-plan task definition
• Form schema and validation rules
• User role and facility assignment

After reconnection, the server can detect whether an order, resident status, or permission changed. Do not silently reinterpret the offline event under the newest version.

For example, if a medication was discontinued while a caregiver was offline, the event needs review against the actual effective times. The software cannot decide from upload order alone whether the administration preceded or followed discontinuation.

Enforce facility and resident boundaries on the server

A locally cached facility selection is not authorization. On every sync, verify that the user is still active, assigned to the facility, permitted to access the resident, and allowed to perform the specific action.

If access was revoked while the device was offline, stop new local access at the cached-session limit and quarantine pending events for authorized review. Do not reassign an event to a different facility simply because the user switched facilities after reconnecting.

Use a visible facility and resident banner in every offline form. Clear resident-specific cached views according to the approved device policy after logout, revocation, or expiry.

Design the sync queue for human understanding

Provide a queue with plain states:

• Saved on this device
• Waiting for connection
• Sending
• Confirmed by server
• Needs your review
• Rejected for authorization or validation
• Superseded by an amendment

Show the count and oldest pending item without flooding the dashboard. Each item should explain its resident, module, occurrence time, and next action. Do not use a generic spinning icon indefinitely.

Allow retry for transient failures and prevent retry for permanent validation failures until corrected. A user should never need to recreate a confirmed record because the queue lacks a receipt.

Keep a durable server receipt

For every accepted event, return and store:

• Server event identifier
• Client event identifier
• Accepted record version
• Server timestamp
• Outcome status
• Conflict or amendment relationship
• Validation version

The client should remove an item from the pending queue only after persisting that receipt. If the application closes between server acceptance and local acknowledgement, the same client identifier lets the retry return the original receipt.

Use checksums for attachments and large payloads. Verify that resumed uploads contain the same bytes before associating them with a resident record.

Recalculate alerts from synchronized evidence

Medication-round, documentation, and task alerts should derive from authoritative server events. A newly synchronized administration should recalculate the related scheduled opportunity and resolve a due alert when all requirements are satisfied.

Do not mark an alert complete merely because an offline request was attempted. If the event conflicts, lacks required follow-up, or was rejected, the alert should state the remaining issue.

Publish a data-through time on dashboards and reports so managers can see whether one device still holds pending records.

Prepare for prolonged unavailability

The ONC SAFER Contingency Planning Guide addresses recommended practices for planned or unplanned electronic health record unavailability. An AFH system can adapt that resilience mindset by defining:

• How staff identify downtime
• What minimum information remains available
• Which paper or local process is authorized
• How leadership and support are contacted
• How restored records are reconciled
• Who verifies completeness
• How drills and lessons are documented

Offline mode is one contingency tool, not the entire continuity plan. Power loss, lost devices, expired sessions, corrupted local storage, or a broad service outage may make it unavailable too.

Protect cached resident information

Encrypt locally stored records using platform-supported secure storage and minimize the content retained. Avoid long-lived browser storage for unnecessary attachments or entire resident histories.

Use short offline authorization windows based on risk, device controls, and operational need. Require reauthentication after the limit. Prevent backups from copying plaintext resident caches into consumer cloud accounts.

Remote revocation, screen-lock requirements, application timeout, and device inventory reduce exposure. When HIPAA applies, evaluate the workflow under the organization's security risk analysis; do not assume offline storage is exempt from safeguards.

Handle schema and application updates

An older client may submit a payload after the server schema changes. Version every offline payload and maintain explicit migration or rejection rules. Never guess the meaning of an unknown field.

Stage application releases so active clients can synchronize before an incompatible cutoff. If a required safety update cannot wait, show the user which pending records need assisted recovery.

Test service worker upgrades, cache deletion, database migrations, and multiple open tabs. A new service worker must not erase unsynchronized events while claiming a successful activation.

Report sync health without exposing content

Operations reporting should include:

• Devices with pending records
• Oldest unsynchronized event
• Retry and rejection rates
• Duplicate submissions prevented
• Conflicts by module and cause
• Access-revoked events quarantined
• Average time to server confirmation
• Cached data older than policy
• Reconciliation cases awaiting review

Limit managers to their facilities and authorized residents. Technical logs should use opaque identifiers and avoid medication directions, notes, or resident names unless a protected support process genuinely needs them.

Test real disconnection sequences

Use a demonstration environment to verify:

1. New note saved before a connection drops.
2. Same event retried several times but accepted once.
3. Two caregivers record different outcomes for one medication opportunity.
4. Missed outcome later amended with evidence of administration.
5. Order changed while one device is offline.
6. Resident transferred or discharged before sync.
7. User access revoked during the offline window.
8. Facility switched before pending events upload.
9. Attachment upload interrupted and resumed.
10. Device closes after server acceptance but before local receipt.
11. Old application schema reconnects after an update.
12. Service worker activates with pending records.
13. Alert count recalculates after confirmed sync.
14. PDF report identifies its data-through time.
15. Prolonged outage invokes the documented contingency process.

Verify both the final resident record and the complete rejected, duplicate, conflict, and amendment history.

Frequently asked questions

Should every AFH feature work offline?

No. Approve offline capabilities by risk and workflow. Access changes, destructive actions, or medication-order activation may require a live server check.

What prevents a duplicate medication entry after retries?

A stable client event ID and server-side idempotency. Repeating the same request should return the existing receipt, not create another administration.

Can the latest upload automatically win a conflict?

Not for competing facts that affect care records. Preserve both versions and require an authorized, audited resolution when a tested merge rule is not safe.

What should staff see while offline?

They should see an obvious offline indicator, cached-data timestamp, permitted actions, pending count, and the confirmation state of each submitted event.

How long should resident information remain cached?

Use the shortest period that supports the approved continuity workflow, based on risk, device management, law, and facility policy. Reauthentication and secure deletion should be tested.

Make offline records observable and reconcilable

Reliable offline support preserves event identity, order and schema versions, authorization boundaries, timestamps, server receipts, and every conflict decision. It tells staff exactly what is local and what the server has confirmed.

Explore AFH Manager to test offline indicators, idempotent medication events, conflict resolution, revocation, alert recalculation, and data-through reporting with controlled demonstration records.