How it works
Four decisions that are hard to add later.
Most of what separates hospital systems is not a feature list. It is a small number of architectural choices made early, which cannot be retrofitted once a product has shipped without them.
One
The ERP is not bolted on.
Issuing a box of gloves to a ward relieves stock at what those units actually cost and posts to the general ledger, in the same database, in the same transaction.
The alternative most of this market ships is a clinical system and a finance system with an interface between them, which means a nightly job, a reconciliation, and two numbers that disagree by the time anybody asks. Joining them afterwards is not an integration project. It is a rewrite.
Two
The ward round survives the network.
A device that cannot reach the server holds its ward, records what the nurse does, and sends it when the line comes back. That is the easy half. The hard half is what happens to the rules.
One ward, not the database
The working set is scoped to a ward because that is the unit a nurse works in, and because a phone left on a bus is the likeliest breach in this deployment. A device carrying the whole register is a breach waiting for somebody to be careless.
A check that cannot run says so
Safety rules exist on the server and on the device. A gate proves the two AGREE rather than merely that both exist, and a check needing the server reports that it did not run. A green tick meaning "not checked" is worse than no tick, because somebody trusts it.
Nothing silently merges
Facts append: two observations, neither wrong. Claims on shared state resolve loudly, either refused like a bed move or skipped and flagged like stock. A new kind of offline action must name which it is before it can be registered.
And the device records who is holding it. Not authentication, and the screen says so in those words: anybody with the device can pick any name, exactly as anybody holding a paper chart can sign any name. What it buys is that the record says who claims to have done it, which is what a paper chart has always said and a shared device previously could not.
Three
The record can be verified, not merely trusted.
Every audit entry carries a hash of its own contents and of the entry before it. A row edited outside the application no longer matches its own hash; a row deleted breaks the link between its neighbours. The chain is recomputed on demand.
Alongside it sits a rule most clinical systems never write down: every alert declares how loudly it is allowed to speak, and a gate enforces the budget. Alert fatigue is not an annoyance. It is the mechanism by which a safety system becomes a hazard, because the one that mattered gets clicked through with all the others.
Four
The codebase refuses things on its own.
Nearly two hundred of the tests do not check that a feature works. They check that the product cannot acquire a certain kind of fault: a screen nobody can open, a capability nobody can reach, an act nobody is named for, a permission that does not say what damage it can do.
Every one of them exists because that fault happened once. A rule that keeps being broken is not a rule, it is a missing gate, and each of these was written the day something got through.
What it runs on
Ordinary hardware, and a way out.
PHP 8.3, PostgreSQL 16, Redis
In containers, on a single modest server. No licence per seat, no per bed, and nothing that has to be bought from us to keep it running.
Speaks FHIR
Fifteen resource types served for read and search, so a partner system can ask the obvious question and get a whole answer rather than half of one.
A bulk export
Every record at once, in a standard format, without asking us. The export expires on a clock rather than only at the front door, because a copy of every patient record should not sit on a server for a year.
None of this is visible on a feature list.
Which is why the demonstration is a working system rather than a slide deck. Choose a seat, click around, and try to find the screen that does not open.