Verbum HealthVerbum Health

Overview

Our Lady of Fatima Catholic Hospital in Bwari, Abuja ran on paper. Not partially: admissions, prescriptions, lab results and billing, all of it on forms and in ledgers. They had tried software before. It was a PHP application served from a machine on site, built to somebody else's idea of how a hospital works, and general enough that staff spent their time bending their own processes to fit it. Eventually they stopped, and went back to paper. Verbum Health is the system that replaced the paper. Ten staff roles each open a different application: a receptionist admits a patient and assigns a bed, a doctor consults and prescribes, a pharmacist dispenses against stock, a lab scientist returns results, an accountant bills and prepares the insurance claim.

My role

Head of the web and software development department at Verbum Networks, leading a three-person design and development team on the engagement. My own work was the architecture, the flow and feature planning, and the frontend build, along with the backend for specific features. How the system was shaped, how a patient moves through it, and which role sees what, was mine to decide.

The problem

The hospital was running entirely on paper. A patient record was a physical folder, a prescription was a slip carried down a corridor, a bill was assembled by hand, and an insurance claim meant reconstructing what had happened from several different books. That is slow, but the sharper cost is that nobody can see the whole picture at once. Which beds are free right now. Whether a drug is in stock before it is prescribed. What a patient already owes. They had been here before with software, and it had gone badly. The previous system was a PHP application served locally, and the complaint was not that it did too little but that it did too much, generically. It was built for hospitals in the abstract rather than for this one, so using it meant working around it. Trust was the first thing that needed rebuilding. There is also a constraint nobody states out loud about hospital software. It has to be fast. A nurse with a queue in front of her will abandon a system that makes her wait, and go back to the paper that never does.

The solution

The system was built around how this hospital actually works rather than how hospitals work in general, with the flows checked against the real thing before they were fixed in place. Ten roles each get their own application. The same patient appears differently to a receptionist, a doctor, a pharmacist and an accountant, because each of them needs something different from the record and should not have to wade through the rest. It covers the whole journey: admission and bed allocation, consultation and vitals, prescriptions dispensed against real pharmacy stock, lab tests and results, antenatal records, the mortuary, and billing with deposits, running balances and insurance claims. And it updates live. When a doctor writes a prescription the pharmacy sees it without refreshing anything, and when a bed is released it frees up on the admissions screen immediately. That is what makes a browser feel like software rather than a website, and it is a large part of what persuaded staff to put the paper down.

Key features

• Admit a patient, assign a bed, and see at a glance which beds are free, occupied or being prepared, with a history of who has occupied each one.
• Consult, record vitals, and write a prescription that reaches the pharmacy the moment it is written, with nobody carrying a slip down a corridor.
• Dispense against real stock, so a drug cannot be prescribed and then found to be unavailable, with every movement in and out of the pharmacy recorded.
• Order lab tests and have the results come back into the same record the doctor is already looking at.
• Keep antenatal records through a pregnancy, and run the mortuary, both of which this hospital does and most software ignores.
• Bill as treatment happens rather than reconstructing it afterwards, with deposits, running balances, and claims prepared for the patient's health insurance provider.
• Print an invoice or receipt generated by the system, which matters in a building where the paper trail is still the legal one.
• See only what your role needs. Ten staff roles each open a different application built from the same system.

Architecture & engineering

A React single-page application on Vite, with Material UI and its data grid carrying most of the dense tabular work that hospital software is largely made of, over an Express API on MongoDB with Mongoose. Twenty-three data models and fourteen API modules sit behind 199 React screens and components, which gives a sense of the ratio. A hospital is not a complicated thing to model so much as an enormous one to present. Real-time behaviour runs over Socket.IO, with a Firebase channel for push notifications so an alert reaches someone who does not have the tab open. Authentication is JWT over bcrypt-hashed credentials with Helmet on the API, and uploads go through Multer. Documents are generated in the browser: invoices and receipts rendered as PDFs and printed straight from the application, because the hospital's own record is still the printed one. Roughly 44,000 lines across the two halves.

The hardest problem

The hardest requirement was that a web application had to feel like a native one. Hospital staff are not patient with software, and they are right not to be. A nurse with a queue in front of her will abandon anything that makes her wait, and the paper process she is being asked to give up never spins. So every action that mattered had to be immediate, and every change had to appear wherever it was relevant without anyone pressing refresh. The real-time layer is not a feature sitting on top of the system; it is the thing that makes it credible at the counter. The second hard part was not technical. We planned the flows from what the hospital told us, then sat in the building during deployment and watched what actually happened. Patients do not move through a hospital the way an organisational chart suggests, departments borrow each other's steps, and the order of things shifts with the time of day. Features were adjusted on site, mid-deployment, against the real thing rather than the description of it.

Results

Deployed and in use at Our Lady of Fatima Catholic Hospital in Bwari, Abuja, replacing a fully manual paper operation. Workflow efficiency at the pilot institution improved by around 40 percent and stationery costs fell by about 60 percent, which in a building that ran on forms and ledgers is a fairly direct measure of how much paper stopped being printed. It was also built to be more than one hospital's system. Verbum Health was intended as a product foundation: a hospital management system that could be fitted to another institution's own operations rather than imposing a generic one, which is precisely the failure that had sent this hospital back to paper in the first place.

Key learnings

The system this one replaced was not under-built. It was over-general. It tried to be right for every hospital and ended up awkward for this one, and the staff did the rational thing and went back to paper. Generic software is not the safe default it looks like in an operational business; it is a different bet, and sometimes a worse one, than building for the place you are actually in. The second lesson was about where requirements really come from. We planned carefully and still got things wrong, and the only reason we found out was that we deployed on site and watched real patients move through real departments. An hour in the building was worth more than a week of specification. And speed is a feature in a way that is easy to underrate. Everything we did to make the application respond instantly served one simple fact: the thing we were replacing was paper, and paper is never slow.