Hospital management
Patients, admissions, orders, results, beds, pharmacy and the record that ties them together — one system, used by clinical staff who cannot stop to work around it.
Talk about scopeFour things that are hard here and nowhere else
- A patient record is the one thing in a hospital that must never be ambiguous. The same person arrives through outpatient, through emergency, and as a scheduled admission, often with a different spelling each time — and every one of those routes has to resolve to one record before a clinician acts on it, not after.
- Almost nothing in the building happens in a single step. An order is placed, a sample is taken, a result comes back, someone acts on the result. Software that models each of those as a saved form loses the thing that matters, which is that a step is outstanding and somebody is waiting on it.
- The record has to be readable years later by someone who was not there. That means storing why a decision was made alongside what was recorded, and never overwriting a clinical entry in place — corrections are appended, and the original stays legible.
- Access has to be tight and fast at the same time. A clinician needing a record at 3am cannot be blocked by a permission model, and an audit six months later has to show exactly who opened it. Those two requirements pull against each other, and resolving them is a design decision, not a setting.
What we would build
One patient, arriving four different ways
Outpatient, inpatient, emergency and scheduled admission are four different front doors to the same person. Identity resolution belongs at the door rather than in a cleanup job afterwards, because a duplicate record created at admission is discovered at the worst possible moment — when someone is looking for an allergy that was recorded against the other one.
Orders that stay open until someone closes them
A lab order, an imaging request and a prescription are all the same shape: raised by one person, executed by another, and not finished until a result comes back and is seen. The state worth modelling is "outstanding, and this person is waiting" — a system that only records the request and the result cannot tell you what has been sitting unread since Tuesday.
Beds, theatres and the things there are only so many of
Scheduling in a hospital is allocation of scarce physical resources under constant interruption. An emergency admission takes a bed that was promised to an elective on Thursday. The software has to make that trade visible and reversible rather than silently accepting the last write, which is how two patients end up assigned the same bed.
A record that is appended to, never overwritten
Clinical entries are corrected by adding a correction, not by editing the original — the earlier reading is part of the history of the decision, and deleting it destroys the reason anyone acted. This is the same append-only audit spine every system we build carries, and it is the reason the schema is worth arguing about before the first screen is drawn.
Pharmacy and stock, against a live prescription
Dispensing moves stock, and stock has batches and expiry dates that a general inventory model does not carry. A batch is dispensed to a named patient, which means a recall has to be answerable in the other direction: given this batch, who received it. That question is easy to answer if the link was designed in and effectively impossible to answer if it was not.
Fast at 3am, accountable six months later
Emergency access cannot wait on an approval chain, and an audit cannot accept "everyone could see everything". The workable answer is break-glass access that is granted immediately and flagged loudly — the clinician is never blocked, and the opening is a record somebody reviews rather than a silence.
The state worth modelling
Not “requested” and “resulted”, but “outstanding, and this person is waiting on it”.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.
More platforms
Other sectors we can build for.