Desk Profile Logout

Offline Architecture Sketch

The PMIS URS makes offline capability important for dispensing and stock transactions. This page sketches the realistic architecture choices, the conflict risks, and the safest recommended delivery path for ERPNext and pharmacy_app.

Full offline dispensing is possible, but it is not a simple ERPNext configuration item. The hard problem is safe stock synchronization, especially for FEFO batch selection, controlled medicines, and simultaneous dispensing during network loss.

Offline Scope

Core offline scope should be limited to patient lookup, prescription retrieval, dispensing capture, stock deduction intent, and local receipt printing.

Main Risk

The biggest risk is stock and batch integrity when two sites or two devices dispense overlapping stock before synchronization.

Recommendation

Use an offline queue with conflict review first. Avoid pretending offline stock is final until the central server reconciles it.

URS Drivers

These two requirements from the signed PDF are the real drivers for offline design. The architecture sketch below is an implementation interpretation of these exact requirements, not a replacement for them.

NFR-R01
The system shall support offline operation for core dispensing and stock transactions in the event of internet connectivity loss, synchronizing with the server when connectivity is restored.
NFR-R02
No data entered offline shall be lost in the event of a synchronization conflict; conflicts shall be flagged for manual review.

Option A: Browser PWA With Local Queue

Highest Operational Risk

A browser-based offline web app stores transactions locally in the device and syncs them when connectivity returns. This looks attractive because it reuses the web UI, but it creates difficult multi-device consistency problems and stronger local-device security requirements.

Pros

  • Reuses web delivery model
  • No separate server at each site
  • Can support fast local capture

Cons

  • Hardest to secure on shared devices
  • Weakest stock consistency model
  • Difficult FEFO and controlled-drug controls

Fit

  • Only acceptable for narrow capture workflows
  • Not ideal for multi-user pharmacy counters
  • Not my recommended first choice

Option B: Site Local Node With Deferred Sync

Recommended

Each site runs a small local node that continues serving pharmacy operations during internet loss. Transactions are written to the local node first, then synchronized to the central server when the connection returns. This is the safest realistic offline design for PMIS.

Pros

  • Better multi-user support within a site
  • Centralized local cache per site instead of per device
  • Cleaner security and audit controls

Cons

  • Extra infrastructure at each site
  • Sync service and conflict workflow required
  • Still needs careful reconciliation logic

Fit

  • Best balance of resilience and control
  • Supports site-level outage handling well
  • Strongest candidate for a real rollout

Option C: Assisted Offline Mode

Lowest Build Risk

The system stays online-first, but adds contingency workflows for outages: cached read-only views, printable pick lists, manual temporary registers, and later controlled re-entry into the system. This is not full offline operation, but it is the fastest low-risk resilience layer.

Pros

  • Fastest to deliver
  • Lowest technical complexity
  • Good for pilot and fallback operations

Cons

  • Not true transactional offline mode
  • More manual reconciliation after outage
  • Less convenient for staff

Fit

  • Good interim phase if timeline is tight
  • Useful even if Option B is later adopted
  • Strong candidate for phase one fallback

Decision Comparison

This view is meant to help us organize implementation, not just describe architecture. Option B is the only path here that looks credible for true multi-user pharmacy operation.

Option Offline Depth Build Effort Operational Risk Best Use Recommended Phase
A. Browser PWA Device-level offline capture with local browser storage High Very High Narrow single-user capture only Do not use as primary target
B. Site Local Node Site-level transactional continuity with deferred sync Very High Medium to High Real branch pharmacy continuity Pilot after online-first core is stable
C. Assisted Offline Read-only cache plus controlled outage procedures Medium Low to Medium Phase-one resilience and fallback Start here immediately

Recommended Delivery Path

The safest route is to avoid jumping straight into full device-level offline. Build this in stages so the pharmacy can validate process and reconciliation before deeper technical complexity.

Step 1: Clarify Rules

Define exactly what must work offline, who can do it, which documents are authoritative, and how conflicts are approved.

Step 2: Build Assisted Fallback

Introduce outage procedures, cached views, printable artifacts, and controlled recovery workflows first.

Step 3: Pilot Site Node

Implement a local-site queue and sync service at one site, with conflict review screens and strong audit logging.

Step 4: Expand Scope Carefully

Only after pilot success should offline stock, dispensing, and controlled-drug logic be expanded to both sites.

Implementation Workstreams

If offline is important enough to plan now, it should be organized as a dedicated workstream with separate product, technical, and control deliverables.

1. Scope and Process Define which transactions can start offline, what must stay read-only, which users can approve conflicts, and how controlled medicines are handled during an outage.
2. Data and Sync Model Design queue payloads, idempotent replay, sync checkpoints, stock reconciliation rules, and the exact difference between local committed and centrally reconciled transactions.
3. Security and Audit Add node authentication, encryption at rest, signed sync batches, device hardening, backup and restore rules, and supervisor approval for critical conflicts.
4. Pilot and Rollout Start with one site, rehearse outage and recovery, measure conflict rates, and only then decide whether to widen the scope to full dispensing and stock posting.

Minimum Technical Design For Option B

Practical Baseline

If we pursue real offline capability, the minimum architecture should include: a site local node, encrypted local storage, transaction queueing, signed sync batches, replay protection, conflict review, and a ledger that separates local committed from central reconciled stock effects.

Core Components

  • Site-local application node
  • Local database with encryption at rest
  • Sync queue and retry scheduler
  • Conflict review and approval screen

Conflict Cases

  • Same batch dispensed in two places
  • Price or formulary changed while offline
  • Prescription edited centrally during outage
  • Controlled-drug stock discrepancy on sync

Controls

  • Immutable local and central audit logs
  • Device and node authentication
  • Encrypted backups and recovery process
  • Mandatory supervisor review for critical conflicts
Open the implementation matrix | Open the exact register | Back to index