Offline-first Health Architecture: Local Authority + Safe Sync
Health and medical-adjacent apps have the worst possible combination of requirements: highly sensitive data, high-stress use, and real harm when systems fail. Offline-first is necessary — but not sufficient. Protective Computing adds the constraints that make offline-first safe.
The goal
Build a system that remains useful when the network disappears and remains safe when the context becomes adversarial. That means two explicit properties:
- Local Authority: the user can complete essential tasks locally with predictable behavior.
- Exposure Minimization: the system limits what it collects, stores, and reveals by default.
Reference architecture (minimal, protective)
A protective offline-first health app typically has these layers:
- Local store (encrypted-at-rest where possible) holding the working set.
- Operation log of user-intent actions (not raw UI events) to support sync and reversibility.
- Sync engine that uploads only what’s necessary, when safe, and handles conflicts deterministically.
- Remote store treated as a replica, not the authority (the app must still function without it).
Protective requirements you can enforce
Offline-first gets you availability; Protective Computing gets you controlled failure. These are the high-leverage constraints:
- Reversibility: destructive actions must be undoable with explicit recovery windows.
- Exposure Minimization: avoid analytics by default; keep a minimal schema; prefer local computation.
- Local Authority: ensure essential tasks are possible without an account, without support, without the cloud.
- Degraded Functionality: define safe behavior when battery/CPU/storage are scarce.
- Coercion Resistance: consider device seizure and forced unlock; make “safe failure” explicit.
Sync: the failure modes that matter
Sync is where offline-first systems leak data or destroy user trust. A protective sync design should explicitly address:
- Conflict resolution: deterministic, auditable merges; no silent overwrites.
- Partial uploads: never require uploading the entire dataset to complete a local action.
- Retry storms: exponential backoff; avoid battery and bandwidth exhaustion.
- Coercive contexts: avoid creating a “single place” an attacker can demand to export everything.
Example: PainTracker mapping
The reference implementation mapping shows how protective requirements translate into concrete design decisions for a small, local-first health tracker.