Tech blog

Field notes on software, commerce, healthcare systems, and the decisions that make digital products useful.

A RealUpp engineering team reviewing system architecture and code on a large monitor
Featured note

No filler. Only useful notes from the work.

We publish what we learn while building. This first piece is about the field with the highest stakes: what information technology actually contributes to healthcare, and how to tell useful contribution from expensive noise.

Digital healthcareAugust 20269 min read

Tech contributions to the medical field, and why they matter here.

Health systems do not run on software. They run on information: who the patient is, what has already been done, what is in stock, and what it costs. Information technology earns its place in medicine wherever it makes that information arrive faster and more reliably than paper managed. This is a note on where it genuinely does, where it does not, and why the answer looks different in a district facility than in a teaching hospital abroad.

A clinician in a mask and gloves talking with a patient across a desk in a clinic, with a workstation behind her
The consulting room is where a health system is judged: what the clinician can see, in the minutes they actually have.

Health IT is infrastructure, not equipment

It is easy to picture health technology as devices: the scanner, the monitor, the analyser. Those are the visible purchases, and they are the ones that get announced. But what usually determines whether a facility runs well is far less visible: whether information moves between the people who need it, in time to be useful.

That puts information technology closer to plumbing than to equipment. Nobody is impressed by it when it works. Everybody feels it when it does not: the patient asked the same three questions at every desk, the test repeated because the first result cannot be found, the queue that forms at the cashier because charges were written down somewhere else. The World Health Organization now frames digital health as part of health system strengthening rather than as a separate innovation agenda, and that framing is the right one. Software in a hospital is not a parallel project running alongside care. It is either supporting the clinical work or getting in its way.

What the technology actually changes

Strip away the marketing and the contribution comes down to a handful of unglamorous things.

It shortens the distance between a question and an answer. A clinician wondering whether a patient is already on a medication, whether a test was ordered last month, or whether an allergy was ever recorded should be able to find out in seconds rather than by sending somebody to look for a folder.

It makes the record durable and legible. Paper degrades, gets misfiled, and travels badly between departments. Handwriting is a genuine clinical risk. A digital record is searchable and attributable, and a properly backed-up one survives a flood, a fire, or a filing error.

It closes loops. A request that leaves the consulting room as data can be tracked; a request that leaves as a slip of paper often cannot. The same is true of a referral, a prescription against real stock, and an invoice that nobody has chased.

And it makes patterns visible. One clinician sees one patient at a time. A system sees attendance, case mix, stock movement, and revenue across months, which is what a facility needs in order to plan instead of react. None of this is exotic. Collectively it is the difference between a facility that is busy and a facility that is functioning.

The value compounds beyond one building

The case for health IT gets considerably stronger the moment you look past a single facility. Routine health information systems aggregate what individual facilities record into something districts and ministries can act on, and DHIS2 is the platform most widely used for this across Africa. Outbreak detection, immunisation coverage, and where to send scarce staff all depend on data first captured by somebody at a desk during an ordinary consultation.

Financing works the same way. Claims that begin life as structured data are cheaper to process and far easier to audit than claims reconstructed from handwriting, which matters everywhere insurance reimbursement is part of how a facility stays open. So do medicine supply chains, which fail in a specific and preventable way: stock expires in one facility while another runs out, because nobody can see both at once.

Connectivity extends reach as well. Teleconsultation and remote reporting do not replace a clinician, but they change who can get a second opinion and how far a patient has to travel for one. This is the part that disappears when health IT is discussed as a purchase for one hospital. A record captured well in a consulting room is also a public health asset.

Relevance for facilities in Ghana and West Africa

A system designed for a well-funded teaching hospital elsewhere often assumes things a district facility cannot rely on: uninterrupted power, permanent bandwidth, a dedicated IT department, and staff who can be pulled off the floor for a fortnight of training. Designing against those assumptions rather than around them is most of the work.

In practice that means software that stays usable on modest hardware, tolerates the network dropping mid-shift, and shows each role only the screens that role needs, so a new records officer is productive in a morning rather than a month. There is also an advantage worth naming. Where mobile money and mobile-first services are already ordinary, patients and staff are not being asked to accept the idea of doing something important on a phone. That argument is already won. It is a real head start, and it is why lifting a workflow straight from a Western hospital's desktop software is usually the wrong move.

A woman looking something up on a tablet, holding it in one hand
Adoption is settled by whether the person holding the device can get what they need without being trained into it first.

Where health IT goes wrong

Digitising a bad process produces a faster bad process. That is the most common failure by some distance, and it is a design failure rather than a technical one: the workflow was mapped as the policy manual describes it, not as it is actually performed on a Tuesday afternoon.

The second is fragmentation. A facility ends up with one system for the laboratory, another for pharmacy, another for billing, none of which speak to each other, and the staff quietly become the integration layer, retyping between screens and reconciling by hand. Whether systems can exchange data is a question worth asking before signing, not after.

The third is assuming adoption follows installation. It does not. If a nurse can finish the task faster on paper, the paper wins, and it deserves to. That is useful feedback about the software, not about the nurse.

Running underneath all of it is the obligation that comes with patient data. Least-privilege access, encrypted transport, restores that have actually been tested rather than backups that are merely configured, and an audit trail that can answer who saw what. Ghana's Data Protection Act sets expectations here, but the practical reason to get it right is simpler than compliance: a facility that loses control of its records loses something it cannot buy back.

What good looks like

The systems that survive tend to share the same unfashionable qualities. They match the work as it is actually done. They hand each role a small number of screens. They degrade gracefully when the power or the network does. And they can be changed as the facility changes, without a rewrite.

That is the standard we hold our own work to. CAREMS covers hospital-wide operations, while RealUpp Dental gives dental facilities a smaller, focused workspace, deliberately two products rather than one, because a four-chair practice does not need theatre scheduling and should not have to look at it. But the principle is not ours and does not depend on our software. A health facility does not need a clever system. It needs one that is running on a Monday morning when the queue is long, the power has just come back, and the clinician has four minutes with a patient. Everything technology contributes to medicine is judged in that four minutes, whoever built it.

The short version

Useful healthcare technology removes steps between a clinician and a decision. If a feature does not do that, it is decoration, and decoration is expensive in a hospital.

More notes

Shorter thoughts from current builds.

Building software

Architecture that survives the second year

Most systems are not defeated by launch day. They are defeated by the twelfth change request. Boring, well-separated modules keep that change cheap.

Commerce systems

Checkout is an operations problem

A storefront converts when payment, stock, and fulfilment agree with each other. Verified payment webhooks and per-variant stock do more for conversion than another banner.

Data stewardship

Patient data deserves a boring answer

Least-privilege roles, encrypted transport, tested restores, and an audit trail. Nothing fashionable, which is exactly why it holds up under scrutiny.

Have a project question worth unpacking?Ask RealUpp