Skip to content

product

· · 3 min read

Open-Source Clinic Management That Survives a Power Cut

Most clinic software assumes always-on broadband and steady power. Nyuchi Medical does not. Here is how a Mutare clinic prints a dispense slip during a 36-hour load-shed and reconciles when the lights come back.

By Bryan Fawcett

The clinic in Mutare we work with loses mains power for half the day, on average. Diesel generators cover the rest, when there is diesel. The internet is a 4G dongle that drops to 2G at peak load. Patients are still patients. Records still need to be kept. Prescriptions still need to print. The software cannot be a reason any of this breaks.

This post describes the architectural choices that make Nyuchi Medical — our clinic-management product — work in that environment. None of these choices are novel on their own. They are unusual in combination, and the combination is what frontier infrastructure actually means.

1. Reads from a local replica, always

Every Nyuchi Medical install carries a local SQLite replica of the patient roster, the dispensary catalogue, the appointment book, and the previous month of records. Opening a record is a local file read. The clinic does not see a spinner because there is no network round trip on the read path.

2. Writes append to a local journal first

A registration, a vital-signs reading, a prescription — every write appends to an on-device, append-only journal with a deterministic ID. The UI confirms immediately. The dispense slip prints immediately. The journal flushes to the central record system when there is network and power.

This is not novel — it is how every offline-tolerant system works. What is unusual is committing to it as the default, not the edge case.

3. Conflict resolution favours the clinic

When the journal flushes and the central system has diverged (because another device wrote a conflicting record), we do not auto-merge by last-write-wins. We surface the conflict to the senior clinician at the affected clinic. The clinic owns the patient record. The central system holds the canonical copy but does not arbitrate clinical conflicts.

4. Print first, sync second

The dispense slip is the legal artefact. If the printer is online and the network is not, we print. If the network is online and the printer is not, we display a queued slip and wait. Either way the patient leaves with what they came for; the digital record catches up.

5. Open-source, repo-watchable

The whole thing lives in the open at github.com/nyuchi. A clinic that suspects a bug can read the code. A clinic that wants a tweak can fork. A clinic that wants to host the central layer themselves can do that — sovereignty by default, not an enterprise feature gate.

6. POPIA / Zimbabwe DPRA compliant by construction

Patient data resides on regional infrastructure aligned with the clinic's jurisdiction. The data residency is a setting, not a sales upsell. Audit logs are append-only and tamper-evident. We can show you the data flows; nothing happens off-camera.

Why we built this

There is a particular tone in healthcare software vendor pitches that treats the local environment as a problem to be educated away. We take the opposite stance. The environment is fixed; the software has to bend. A clinic that loses power for 18 hours is not an edge case in Mutare or Manila — it is the median day. Software that survives that is not heroically engineered; it is just honest about where it is deployed.

Try it

If you operate a clinic, lodge, school, or any other venue where the power and the network are not assumptions, we'd like to talk.

Back to blog