Module 4 · SOW §4
Interoperability & Offline-Readiness Architecture
The adapter/gateway pattern for external systems, and the offline-first / sync / conflict-resolution specification.
Design only in Phase 1. Working offline synchronisation and live national-system connectors are Phase 3 (see Roadmap). What follows is the specification the Phase-1 data model already accommodates, so building it later doesn't require a redesign.
Adapter / gateway pattern
External systems never talk to the core directly. Every integration — a future national patient registry, a laboratory system, an insurer, an SMS gateway — connects through a configurable adapter that translates the external protocol into FHIR calls against the same API the provider interface uses. Adding a new external system means writing a new adapter, not modifying the core.
Offline-first sync — conflict-resolution state machine
Specified now so the data model already carries what offline needs: every record change is versioned and idempotent, so a queued write can be replayed safely and a conflict is always detectable rather than silently overwritten.
What's specified now
- Offline-first local data approach on the clinical device
- Queued, idempotent write replay (safe to retry)
- Conflict-detection on record version, not last-write-wins by default
- Critical-field conflicts (e.g. allergy data) always route to staff review, never auto-merge silently
What's built in Phase 3
- The actual offline client storage + queue implementation
- Background sync triggers and retry/backoff behaviour
- The conflict-review UI for staff
- Field-level merge rules tuned from real usage data