Work/Healthcare
Fikacare
A hospital system that keeps working when the internet or power fails.
In pilotBuilt and in pilot with its first hospital; the Windows app is released and installable.
WindowsWeb
The problem
“When the internet drops, we go back to paper and lose track.”
Hospitals in Nigeria run on unreliable power and unreliable internet. Many hospital systems are web applications that stop when the connection drops, or desktop systems that keep one database on one machine and lose everything when it fails. Staff fall back to paper registers, handwritten receipts and drug cards. Then nobody can say what money came in, which drugs left the pharmacy, whether the receipt book has missing numbers or how many patients were seen yesterday. Where totals exist, they cannot be traced to records, so nobody trusts them.
Who had it
- Owners and managersSee money, drugs, patients and staff each morning, even from another country.
- Nurses and clerksStop re-typing paper into screens after every outage.
- CashiersIssue receipts during an outage with numbers that are provably complete.
- PharmacistsSee whether a prescription has been paid before dispensing.
What the answer had to survive
- Power and internet fail often
- Care must never stop for a billing or network problem
- Staff should see only the data their work needs
- Hospital PCs are ordinary Windows machines
- Every figure must be traceable to a record
What we built
A hospital system that treats no internet as the normal case.
Every computer in the hospital keeps an encrypted copy of what it needs and keeps working when the network, the power or the central machine fails. It then catches up on its own. One computer acts as the hub, a second stands by to take over, and the rest are stations. Every action is a permanent, signed entry. Receipt numbers are reserved in advance, so cashiers keep issuing them offline. The owner's daily brief leads with what is wrong, and each figure opens down to its records. A lapsed subscription never locks a device.
What it does
Works offline
- No screen waits on the networkWork that needs the cloud is queued and shown as queued. Nothing blocks the person at the desk.
- Hub, standby and stationsA standby copy takes over if the hub is silent for about 90 seconds.
- Sync that climbs a ladderA station tries the hub, then the cloud, then other machines, then queues locally.
- Visible data ageScreens showing shared data say how old it is. Allergy and critical-result views cannot be dismissed.
Trusted records
- Records are never editedEach action is a signed entry. A correction is a new entry that points at the original.
- Encrypted on every machineLocal databases are encrypted. A lost or stolen machine can be blocked and wiped remotely.
- Staff see only their sliceA machine receives only the data its work area allows. Pharmacy never sees billing.
- Reads are auditedAccess to clinical records is logged for everyone, managers and owners included.
Patient care
- Registration and cardsPatient registry, personal and family hospital cards, QR wristbands. The card fee never blocks care.
- ConsultationQueue tickets, triage, signed notes with coded diagnoses, orders and prescriptions.
- Laboratory and radiologyRequests to results, specimen labels, and critical results that must be acknowledged on record.
- Wards, theatre and maternityBed board, nursing notes, delivery records, immunisation schedules and public-health registers.
Money and stock
- Receipts with no hidden gapsNumbers are reserved ahead. A continuity report lists every gap and every void.
- Pharmacy stock as a ledgerBatches, first-expiry-first-out dispensing, expiry tracking and counts with explained variances.
- Ledger and financeMoney is held in whole kobo. Petty cash, approvals, period close and bank reconciliation.
- Insurance claimsHMO and NHIA claims prepared from visit charges and tracked to settlement.
For the owner
- Exceptions-first daily briefLeads with variances, receipt gaps, overdue claims and expiring drugs, not vanity totals.
- Every figure opens upEach number drills down to the records behind it, on the floor and in the portal.
- The hospital's own brandingThe app carries each hospital's name, logo and colours on screen and on printed documents.
A day with it
- 1
Register the patient
Reception finds or registers the patient, who takes a personal or family card. The fee never blocks care.
- 2
Open a visit
The patient is sent to a department and a queue ticket prints.
- 3
See the doctor
The nurse triages. The doctor writes a signed note with coded diagnoses and orders.
- 4
Tests and results
Lab or radiology results return. Critical results stay flagged until someone acknowledges them.
- 5
Pay and dispense
The cashier issues a numbered receipt. The pharmacy sees the prescription is paid and dispenses from stock.
- 6
Owner reads the brief
Next morning the owner opens the portal. Exceptions come first, and every figure opens to its records.
How it works inside
Each hospital computer holds an encrypted database and runs a small server. Stations sync with the hub on the hospital network, and the hub syncs with the cloud. If the hub is out of reach, a station tries the cloud, then other machines, then queues its work.
Cut the network to see what this system does without it.Internet links are down. Everything on the device and inside the building carries on, and queues its changes.
On the device
- Station appWindows app with an encrypted local database and embedded server
- Local outbox queueHolds work until something can be reached
Inside the building
- Hub machineHolds the hospital's full copy and relays between stations
- Standby hubSecond full copy; takes over if the hub goes silent
Our cloud
- Fikacare cloudApproves devices, holds reference data and receives events
- Cloud databaseStores events and reports data
- Owner portalBrowser view of the daily brief and oversight pages
- Patient portalRemote-consultation booking; built, not yet switched on
Outside services
- Payment providerOnline booking and bill payment; awaiting setup
- SMS providerReminders and messages to patients and staff
Every part and every link, as text
- Station app — Windows app with an encrypted local database and embedded server (on the device)
- Local outbox queue — Holds work until something can be reached (on the device)
- Hub machine — Holds the hospital's full copy and relays between stations (inside the building)
- Standby hub — Second full copy; takes over if the hub goes silent (inside the building)
- Fikacare cloud — Approves devices, holds reference data and receives events (our cloud)
- Cloud database — Stores events and reports data (our cloud)
- Owner portal — Browser view of the daily brief and oversight pages (our cloud)
- Patient portal — Remote-consultation booking; built, not yet switched on (our cloud)
- Payment provider — Online booking and bill payment; awaiting setup (outside services)
- SMS provider — Reminders and messages to patients and staff (outside services)
- Station app → Hub machine: Sync on hospital network (works offline)
- Station app → Local outbox queue: Queue when nothing reachable (works offline)
- Hub machine → Standby hub: Keeps second full copy (works offline)
- Standby hub → Hub machine: Takes over after silence (works offline)
- Hub machine → Fikacare cloud: Events, reference data, releases (needs internet)
- Station app → Fikacare cloud: Direct sync if hub is down (needs internet)
- Fikacare cloud → Cloud database: Store events (works offline)
- Owner portal → Fikacare cloud: Read reports (needs internet)
- Patient portal → Payment provider: Online payment (needs internet)
- Payment provider → Fikacare cloud: Payment confirmation (needs internet)
- Fikacare cloud → SMS provider: Reminders and messages (needs internet)
The hard parts
The simulator that found what unit tests could not
- The situation
- Any machine can be offline, reinstalled or replaced mid-sync. That gives too many cases to test by hand.
- What we did
- We built a simulator that runs a hub, standby, stations and cloud over a virtual network with outages, crashes and clock skew. After each run it checks fixed rules, such as no gaps and a balanced ledger. Failures replay exactly.
- The lesson
- Offline sync is attacked by thousands of random outages before it reaches a hospital.
Receipt numbers that survive a power cut
- The situation
- A cashier must keep issuing receipts offline, yet the owner needs proof that none is missing or duplicated.
- What we did
- Numbers come from blocks reserved in advance, inside the same transaction as the thing they number. Money is a ledger in whole kobo, voids need an authoriser, and a continuity report lists every gap.
- The lesson
- The owner can trust cash figures even when the internet was down all day.
Reports that match the floor
- The situation
- The portal and the app gave different answers for the same report, because each counted some items differently.
- What we did
- Report definitions became shared contract files, read by both the device and the cloud. Each figure drills down to the events behind it.
- The lesson
- The owner abroad and the manager on the floor read the same number.
Pharmacy that never sees billing
- The situation
- Machines receive only the data their work area allows, so a pharmacy station cannot see whether a prescription was paid.
- What we did
- The pharmacy gets its own copy of the prescription. The cashier sends a payment notice across the boundary, and arrival in any order is handled.
- The lesson
- Staff see only what they need, and the workflow still flows.
The stack
- Apps
- Flutter (Windows)DartInno Setup installer
- Backend
- LaravelPHP 8.3Shared JSON contracts
- Data
- SQLCipher (encrypted local database)MySQLRedis
- Infrastructure
- UbuntunginxSigned releases
- Testing
- Multi-device simulator in DartPHPUnitDart test
How it came together
- 1Specification firstThe specification and decision register were written before any code.
- 2The offline foundationDevice enrolment, the encrypted database and the offline sync fabric were built.
- 3Clinical and billing coreThe core was driven in the packaged app, and the cloud and website went live.
- 4Installable and self-updatingThe Windows download page and the in-app updater went live.
- 5Department by departmentLaboratory and radiology came next, then maternity, theatre, finance, claims, workforce and telemedicine.
- 6Patients and cardsThe patient portal and hospital cards were built, and release 0.22.1 published.