1. Motivation
Cervical cancer studies in low-resource settings often face the same challenge: unreliable connectivity and unstable power. Conventional “online-first” software fails under these conditions—leading to blocked workflows, lost or inconsistent data, and ultimately patient risk.
OncoPath takes the opposite approach: an offline-first architecture. Every device acts as the immediate system of record. Data entry and sample tracking continue seamlessly without requiring an internet connection. Synchronization with the central study server happens later, automatically and deterministically, as soon as connectivity allows.
This design is driven by a simple goal:
No blocked field work. No lost data. A complete, auditable study record—independent of connectivity.
2. Context and Requirements
OncoPath is used as a tool for executing and monitoring cervical cancer studies. It supports the end-to-end workflow: participant engagement, sample collection, laboratory analysis, and triage follow-up. The system must function reliably across diverse environments, from well-connected clinics to rural field sites with intermittent or absent network coverage.
Actors
-
Study Leads manage study configuration, field agent assignments, and oversight. They typically operate in stable connectivity contexts.
-
Field Agents collect participant data and samples in remote areas, often working offline with tablet devices.
-
Lab Workers process samples, update results, and feed back into the study pipeline.
-
Nurses use triage data to follow up on participants and coordinate care.
Operational Requirements
-
Offline operation: Core functionality must remain available without internet connectivity.
-
Data durability: Field-collected data must be stored locally and preserved until successfully synchronized.
-
Synchronization: Once connectivity is restored, the system must reconcile local and server states efficiently and without data loss.
-
Installability: The application must provide a native-like user experience on tablets to facilitate adoption by field agents.
-
Security: Authentication must support intermittent connectivity while ensuring data confidentiality and integrity.
3. System Architecture Overview
OncoPath uses a layered architecture: a Rails API backend, a React-based PWA frontend, and a synchronization layer that bridges local and server state. The design isolates presentation, synchronization, and persistence so core workflows remain functional under poor connectivity. The PWA runs as a single-page application with client-side routing in an installable shell. It boots from cached assets and reads and writes to a local data store, treating the device as the system of record while offline. User actions append durable mutations to a queue for later reconciliation. The backend exposes stateless JSON endpoints for domain resources and dedicated synchronization routes. This yields eventual consistency without blocking local work.
OncoPath Architecture \@2025. PAICON All Rights Reserved
Authentication is token-based and stateless to support intermittent connectivity. Protected routes verify tokens server-side, while the PWA shell remains navigable offline. When connectivity exists, real-time channels broadcast updates to connected clients; when absent, the application degrades gracefully and continues from local state. Like other applications at PAICON, OncoPath is containerized with Docker to standardize runtime environments and simplify deployment.
4. Offline-First Design
The application treats the device as the primary system of record during field work and shifts responsibility to the server only when connectivity is available. The PWA is installable through a web app manifest so agents can launch a fullscreen shell that boots from cached assets and does not depend on the network to start. A service worker intercepts fetches and applies a network-first strategy for freshness while guaranteeing a cache fallback for application shell and critical data paths. This allows continuous operation when the network is slow, captive, or absent.
All domain entities required for field workflows are persisted in IndexedDB as structured stores. The UI and business logic read from these stores synchronously, and user actions create append-only mutation records that are written to a durable queue. The queue encodes intent with idempotent client-generated identifiers, operation types, and minimal payloads to mitigate Power loss, tab eviction, and browser restarts. The UI is optimistic and reflects state immediately. Later reconciliation transforms optimistic records into confirmed server state.
Reconnection triggers a synchronization cycle that drains the queue through authenticated API calls and then refreshes local state with incremental server changes. Sync is chunked to respect bandwidth and memory limits and is resumable after interruptions. The client tracks a high-water mark for each logical dataset to bound pull scopes and reduce transfer size. The server maintains an append-only change log to compute these deltas and to support replays. Conflict handling is deterministic and favors preserving captured field data. When a client mutation targets a record that has diverged on the server, the client applies a last-writer-wins policy based on server timestamps by.
5. Data Synchronization
A synchronization algorithm preserves local-first operation while ensuring eventual consistency across devices and the server. The client records every mutation as an idempotent operation with a stable client identifier (UUIDv4), a target model and key, a verb, and a minimal payload. Mutations append to a durable queue in IndexedDB and are applied optimistically to the local state. The queue drains when connectivity, authentication, and basic health checks succeed.
Push uses batched requests with retry, exponential backoff, and per-item acknowledgments so a single failure does not block the batch. The client guarantees at-least-once delivery; the server guarantees idempotent application using client identifiers and a change log. Server writes emit immutable change records with a monotonically increasing watermark to support incremental pull. The client advances its local high-water mark only after successful synchronization with the server.
Conflict handling follows a deterministic policy with domain overrides. For fields where overwriting could impact participant safety or sample chain of custody, the server applies domain-specific merge rules and returns a structured conflict object. The client renders conflicts in a review queue and applies the resolution outcome as a normal mutation, preserving a single audit pathway.
6. Authentication and Security
Authentication is stateless to tolerate intermittent connectivity. Tokens are stored in HTTP-only cookies, and protected APIs verify them on each request. The PWA shell remains usable offline while privileged actions defer until validation succeeds. A refresh occurs only when a network is available and never blocks local entry. Authorization is role based with least privilege, and client gating mirrors server checks while the server remains authoritative. All transport uses TLS, privileged responses are not cached by the service worker, and sensitive local data resides in IndexedDB with selective purge on logout or reassignment. The sync protocol avoids secrets in payloads, signs writes within the token context, and uses idempotency keys to prevent replay. The client records privacy-preserving mutation events, and the server maintains an append-only change log, with identifiers for tracability. Noncompliant devices can be quarantined by invalidating refresh tokens preventing clients from modifying any server state after the short-lived access token has expired.
7. Conclusion
OncoPath demonstrates how an offline-first design can deliver resilient clinical research tools. By making the device the primary source of truth, every patient interaction and every field entry is preserved, even in regions with limited infrastructure. Synchronization protocols reconcile local and server state reliably, while maintaining auditability and security.
The result:
-
Resilient operations in rural and low-connectivity regions.
-
Data integrity and patient safety, ensured by deterministic conflict handling.
-
Scalable design that can be extended beyond cervical cancer studies to other diseases and geographies.
In practice, this means that critical health research no longer depends on stable networks. OncoPath enables study teams to focus on science and care—while the system guarantees that no data, and no patient, is ever left behind.
