Clinic & Pharmacy Management Systems
Two more deployments of the offline-first desktop platform behind the hospital and café systems — a clinic system covering patients, doctors, appointments and procedures, and a pharmacy variant built on the same core.
The same server-plus-client Electron architecture as the Hospital Reception and Cafe POS systems, taken into two further verticals. The pharmacy system shares the clinic system's core, rebranded and adapted rather than rebuilt.
Case study
How this was built, in the order I'd walk someone through it.
- 01
Problem
Small clinics and pharmacies need the same things a district hospital needs — patient records, billing, stock, day-end reporting — at a fraction of the scale, and on the same unreliable power and connectivity. Building each from scratch would be the obvious way to lose money on every deployment.
- 02
Users
Clinic owner / adminDoctorsReception & counter staffAccountant - 03
Architecture
The established pattern: an Electron server app holding the local database and an Express API, plus a thin client app for additional terminals over the LAN.
- 04
My responsibility
Built both systems on the shared desktop platform.
- 05
One important feature
One platform, four verticals
Hospital reception, café point of sale, clinic and pharmacy all run on the same offline-first desktop core. The interesting engineering isn't any single system — it's that the shared substrate (local-first storage, LAN server/client split, role-scoped UI, day-end reporting, packaged Windows installers) made each new vertical an adaptation rather than a rebuild.
- 06
How it works internally
The clinic domain is modelled with dedicated controllers for patients, doctors, appointments, procedures, diseases, products, categories, distributors, refunds, expenses and expense categories, plus reporting and settings — the same controller-per-concern layout used across the platform.
