← Back to project catalogue
GP-CS-0ENSQ23Computer ScienceOpen for request

Offline-first rural service case management

An offline-first case-management system that allows field teams to record, update, and synchronise service cases when network connectivity is unreliable.

  • Nuxt
  • Vue
  • FastAPI
  • PostgreSQL
  • IndexedDB
  • Python
  • Docker

Project definition

Problem statement

Field teams working in rural areas may lose connectivity while recording visits, updating cases, or collecting supporting evidence. A conventional online system can block work or lose partially submitted information.

The engineering problem is to keep the application usable offline, preserve a reliable local history, synchronise only the required changes, and resolve conflicting updates without silently overwriting data.

Project objectives

  • Allow case creation, updates, notes, and task completion without a network connection.
  • Store offline changes in a durable queue that survives application restarts.
  • Synchronise records efficiently when connectivity returns.
  • Detect concurrent edits and apply a documented conflict-resolution policy.
  • Measure data integrity, bandwidth use, synchronisation time, and recovery behaviour.

System design

System modules

01

Offline case store

Stores assigned cases, forms, notes, and pending changes locally with transaction and schema-version controls.

02

Case capture

Validates field forms, records timestamps, stores attachments, and marks incomplete records for later review.

03

Change queue

Records each local mutation as an ordered operation with retry state, dependency information, and idempotency keys.

04

Synchronisation engine

Transfers changes in batches, resumes interrupted work, and downloads only records changed since the last successful sync.

05

Conflict resolver

Compares record versions, identifies incompatible edits, and applies automatic or manual resolution rules.

06

Audit and test subsystem

Records synchronisation events and runs controlled network, retry, duplication, and conflict scenarios.

Methodology

System workflow

  1. 01
    Load assigned work

    The device downloads authorised cases, reference data, and form definitions while a connection is available.

  2. 02
    Work offline

    The field user records visits and updates cases against the local data store.

  3. 03
    Queue changes

    Each accepted local change is written to an ordered queue with its base record version.

  4. 04
    Synchronise

    The client sends queued operations, receives server changes, and safely retries interrupted requests.

  5. 05
    Resolve and verify

    Conflicts are resolved, acknowledgements are stored, and the local and server states are checked for consistency.

Demonstration scenario

A field worker downloads assigned cases, disconnects the network, records two visits, updates a case, and attaches evidence. Another user changes the same case on the server. When connectivity returns, the queued changes resume, the compatible updates merge, and the conflicting field is presented for resolution without losing either version.

Engineering

Technical architecture

Client application
Nuxt and Vue with a progressive web application shell, local IndexedDB storage, and explicit online and offline states.
Application API
FastAPI endpoints designed around idempotent mutations, version checks, incremental updates, and resumable attachment transfer.
Server database
PostgreSQL for case data, record versions, assignments, audit events, and synchronisation checkpoints.
Conflict strategy
Field-level comparison with deterministic rules for safe merges and a manual review path for incompatible edits.
Failure simulation
Controlled latency, packet loss, duplicate request, interrupted upload, and concurrent-edit test scenarios.
Delivery
Container-based server setup and installable client documentation for repeatable testing on desktop and mobile browsers.

Testing

Evaluation

Evaluation measures

  • Successful offline completion rate across the prepared case workflows
  • Data-loss and duplicate-operation rate after interrupted synchronisation
  • Conflict detection and resolution correctness
  • Bandwidth used for initial and incremental synchronisation
  • Time required to recover after different network failures
  • Consistency between local and server records after repeated test cycles

System boundaries

  • The demonstration uses synthetic people, locations, and case records.
  • The system is not designed for emergency dispatch or clinical decision-making.
  • Conflict rules are limited to the documented case schema and test scenarios.
  • Production identity verification and government-system integration are outside the project scope.

Included

  1. 01Offline case capture and task interface
  2. 02Local data store and synchronisation queue
  3. 03Conflict detection and resolution module
  4. 04Prepared network-failure tests and synchronisation results
  5. 05Complete source code in a private GitHub repository
  6. 06Complete project documentation with synopsis, abstract, methodology, data-flow diagrams, test results, screenshots, and conclusion

Project record

No buyer information is collected on this page.

Permanent project ID
GP-CS-0ENSQ23
Catalogued
21 Aug 2026
Completed
Pending
Verified
Pending
Demonstration
Added when ready

Handover

After purchase

  1. 01
    Payment is confirmed

    The project is marked unavailable and cannot be purchased again.

  2. 02
    Repository access is granted

    The buyer's submitted GitHub account receives access to the private repository.

  3. 03
    The purchase record is delivered

    The certification sheet is prepared from the reviewed buyer details and sent privately by email.