1What the platform is
Welnote is a secure, offline-first distributed care coordination platform. It connects three roles around one longitudinal patient record: field health workers who deliver care in the community, remote doctors who review cases asynchronously, and program supervisors who run the program.
This is not a telemedicine app or an EMR replacement. It is store-and-forward clinical coordination infrastructure that keeps a distributed team working from the same patient record—even when no one is online at the same time.
The clinical side of this is detailed under Care Model and Clinical Safety, and the privacy side under Data Ethics & Privacy. What follows is the engineering rationale that makes them work in the field.
2Why offline-first
In the field, connectivity is the exception, not the rule. So offline is not a degraded mode—it is the default. All clinical functionality must operate without internet access. A worker can register a patient, capture observations, classify urgency, and log a follow-up with no signal at all; the network only matters later, for reconciliation.
3Why sync architecture
Because the team is rarely online at once, the system is asynchronous by design: store-and-forward in both directions. Field observations move toward doctors and supervisors, while care plans, follow-up recommendations, and status changes move back toward the field.
- Local-first writes, delivered asynchronously with guaranteed eventual delivery
- Bidirectional sync — push to cloud, then pull doctor and supervisor changes back to the field
- Per-entity cursors so each table syncs independently
- Idempotent delivery via mutation keys — retries never duplicate records
- Optimistic concurrency via row versions — the server rejects stale writes and re-queues a merge
- Field-level conflict authority — each actor owns specific fields; observations are append-only
The sync engine is the most critical reliability layer in the system. It determines clinical continuity, data integrity, field usability, and scalability.
4Why program-based architecture
The program is the tenant and the security boundary. Every record belongs to a program; row-level security on every cloud table makes program membership the authorization boundary. This keeps each partner's data isolated and makes access decisions simple and auditable.
Access (what you can see) is program-scoped, while assignment (who is responsible for a case) is tracked separately—so visibility and responsibility never have to be the same thing.
5Why local ownership
The architecture reverses standard SaaS assumptions to keep authority where care happens.
The mobile device is the system of record. The cloud is a reconciliation layer.
Every actor works against a local database; the cloud reconciles those databases with one another. Patients are pseudonymous by default; a program can choose to sync real names, which row-level security keeps visible only to that program's own members—so local partners and communities retain ownership of the most sensitive data by construction.
6Why AI-assisted workflows (and where they stop)
AI is explicitly separated from clinical decision authority. Future capabilities act on structured data to reduce friction, never to make clinical calls.
- Case summarization
- Translation
- Triage suggestions
- Draft care plans for clinician review
- Population insights
AI acts on structured data, not raw decision authority. A licensed clinician always decides.
7System architecture
7.1 High-level architecture
Field devices (Flutter) — workers and doctors
→ Local database (SQLite / Drift) — source of truth
→ Bidirectional sync engine (push + pull)
→ Cloud reconciliation layer (Supabase)
→ Web portal (Next.js) — doctors, supervisors, admins
→ Program and population intelligence
7.2 Where care happens vs. where it is managed
Mobile is where care happens; the web is where the program is managed. Doctor case review is intentionally available on both—many field doctors only have reliable phone access.
8Data architecture
The data model is small, longitudinal, and append-friendly.
- Program — tenant and security boundary
- Patient — pseudonymous longitudinal entity
- Case — episode of care, with an assignment and status lifecycle
- Observation — append-only clinical data point
- Attachment — encrypted media evidence (EXIF/GPS stripped, AES-256-GCM)
- Care plan — doctor output
- Follow-up — temporal continuity node
- Case event — immutable activity and audit record
The unit of truth is the patient timeline, not the individual visit.
9Security principles
| Layer | Identity type |
|---|---|
| Device | Pseudonymous ID + optional real identity |
| Cloud | Pseudonymous ID; optional real identity (RLS) |
| Doctor | Pseudonymous by default; names if program-enabled |
| Supervisor / NGO | Aggregated data only |
- Program-scoped multi-tenancy with row-level security on every cloud table
- Role-based, least-privilege access (field worker, doctor, supervisor, admin)
- Pseudonymous identifiers by default; optional real names sync only when a program enables them, protected by row-level security
- Server-side audit log written on successful sync
- Program-scoped attachment encryption so authorized reviewers can decrypt field photos
- Remote device wipe if a phone is lost or seized
The full privacy rationale is on the Data Ethics & Privacy page.
10Thesis statement
This system is not:
- Telemedicine
- An EMR replacement
- An appointment system
It is:
A triage-driven, offline-first clinical coordination infrastructure designed for longitudinal care in resource-constrained environments—technology in service of continuity, not a substitute for it.