← Projects

Clinique Sainte Blandine

Architect & developer · Health · 2026

Taking a private clinic in Bangui off paper: one patient record from reception to discharge, running on the clinic's own network.

  • TypeScript
  • Electron
  • React
  • NestJS
  • WebSocket
  • PostgreSQL
  • Python
  • Shell
  • pnpm
  • Biome

The brief

Clinique Sainte Blandine, in Bangui's 4th arrondissement, runs general and emergency consultations, seven specialities from paediatrics to cardiology, a laboratory, a maternity ward, a pharmacy, inpatient rooms and an ambulance.

All of it runs on paper registers, with one Excel workbook in accounting. The same piece of information is written down four or five times on its way through the clinic: at the cashier, by the nurse, by the doctor, at the laboratory, then again in accounting. That means typing errors, lost time, patients who are hard to follow from one service to the next, and figures that reach the President days late.

There was a second constraint, just as important. Staff change all the time: night rotations, visiting doctors, people leaving and arriving. Whatever I built had to keep working when the people did not stay.

So I started on site, not in an editor. I interviewed each service, mapped the patient's journey and the information that moves between services, and collected every paper form in use: the consultation sheet, the prescription pad, the lab bulletin, the cash journal, the insurers' claim forms. That became a specification of thirteen modules, submitted to the President for sign-off before any development.

What I'm building

Map of the clinic's services, laid out like the building, with the patient's path numbered from 1 to 6 Module 0 · Shared foundation Single patient record · Staff accounts and roles · Settings · Printing ADMINISTRATION CARE AND RECEPTION Module 12 Direction the President Module 7 Hospitalisation rooms, night shifts 5 Module 8 Maternity midwives 5 Module 9 Ambulance transfers Module 11 Accounting and payroll Module 3 Nursing vitals and care 3 Module 4 Consultations doctors 4 Module 5 Laboratory tests and results 5 Module 10 Insurers and agreements Module 1 Reception routing, appointments 1 6 Module 2 Cashier payments 2 Module 6 Pharmacy medicines 5 Patients come in
The thirteen modules, laid out like the clinic. Numbers follow the patient: reception, cashier, nursing, consultation, then the care that was prescribed, and out through reception.
  • One patient record, opened once at reception and followed to discharge. Every service reads it according to its role; nobody keeps a parallel register.
  • Each piece of data is entered once, by the service that produces it. The paper registers become lists the system prints on demand.
  • The cashier bills from what was prescribed. The cashier never retypes a prescription, the insurer's share is split out automatically, and every shift closes with the counted cash set against the expected total.
  • A laboratory without a typing pool. Today a dedicated team retypes the biologist's notes into a finished bulletin. Instead, the biologist fills a structured form for each type of test, and the system produces the signed bulletin in the clinic's own layout.
  • Insurers billed without the shoebox. The claim form fills itself as the patient moves through the clinic, and one invoice per insurer is generated each month.
  • Payroll from the facts. Doctors' and midwives' shares are computed from the acts they recorded, and accounting sees the amounts without ever seeing a patient's name.
  • Built around posts, not people. Access comes with the post (cashier, nurse, biologist), so a newcomer gets a working screen in minutes, a departure is one switch, and the history stays attached to whoever entered it. Tariffs, doctors and schedules are settings the Direction changes itself.
  • Familiar documents. Every printout mirrors the form the staff and the insurers already know, which does more for adoption than any training session.

How it is built

From prescription to result: each step is entered once by the service that does it, and every other service reads it Doctor prescribes a test consultations Order created test, urgent or normal Charge at the cashier patient share, insurer share Paid receipt with a unique number Laboratory sample, results form Biologist signs bulletin in the clinic's layout emergency: care first, pay after Audit trail every step: who, when, which record Prescriber's share for payroll, without patient names Insurer's care sheet then one invoice per insurer a month Cash journal to accounting, every day Same route for medicines, rooms, maternity and ambulance Doctor and President notified as soon as it is signed
One route, many readers: what a service enters is what every other service uses.

The heart of the system is that one route: prescribe, charge, pay, deliver. It encodes the clinic's own rule, that a service is paid for before it is given, and its one exception: in an emergency, care comes first and payment follows, with the exception recorded.

Each service works in a desktop app built with Electron, React and TypeScript, installed on its workstation. The apps talk to a NestJS API on the clinic server, and WebSockets push every change the moment it happens: a patient joining the queue at reception, a payment that unlocks a lab test, a result the biologist has just signed. Nobody refreshes a screen to find out. Python and Shell scripts run the jobs around it, such as backups and importing the existing Excel files. The whole codebase is one pnpm monorepo, linted and formatted with Biome.

Around it sit the rules that make a clinic's data trustworthy. Every action records who did it, when and on which record. A receipt can only be cancelled with a reason and a manager's approval. Each service sees what its work requires and nothing more, which matters most for medical records.

How it runs on site

Deployment on the clinic's own network: workstations, server, printers and tablet behind one switch, and a router as the only way out to the internet Clinic's local network: works without internet Reception Cashier Nursing Doctors Laboratory Pharmacy Maternity Accounting workstations running the desktop app (Electron) Switch wired network Wi-Fi access point Clinic server API: NestJS WebSocket: live updates Database: PostgreSQL Jobs: Python, Shell Print service Audit log UPS External disk nightly, encrypted Printers A4 and A5 President's tablet live dashboard over Wi-Fi Router and firewall the only way out Internet, when it is available Off-site backup encrypted, restore tested SMS gateway reminders, optional
Deployed on the clinic's own network: daily work never waits for the internet.

The clinic cannot depend on a connection that comes and goes, so the system lives on site. One server in the clinic answers every workstation over the local network and drives the existing printers in A4 and A5. The President follows the live dashboard on a tablet over the clinic's Wi-Fi.

The network equipment:

  • Router and firewall, the only way in or out of the clinic's network
  • Network switch, linking the server, the workstations and the printers by cable
  • Wi-Fi access point, for the President's tablet
  • Server, behind a UPS, with an external backup disk
  • Workstations in each service, and network printers in A4 and A5

Power cuts are part of the design, not an incident. The server and the network equipment sit behind a UPS so a cut never leaves the database half-written. Every night the server makes an encrypted backup to an external disk. Whenever the internet is up, it also sends an encrypted copy off site, and the restore procedure is tested rather than assumed. The internet is only ever needed for that copy and for the optional SMS appointment reminders.

Next

The rollout is split in three phases so the clinic never stops working:

  1. The patient journey: the shared foundation, reception, cashier, nursing, consultations, laboratory, and a first dashboard for the President.
  2. Complete care: pharmacy, hospitalisation, maternity, insurers and agreements.
  3. Management: accounting and payroll, the ambulance, and the President's full reports.

Each phase goes through the same steps: configuration, migrating the useful existing data, training each service, a period running alongside paper, and only then does paper stop for that service.