Walk any ward with a stopwatch and you will see two systems at work.
One is the system the trust bought. The other is the system the ward actually runs on: a whiteboard, a group chat, a printed list folded into a pocket, and a nurse who remembers which consultant prefers to be paged rather than messaged.
Nobody planned that second system. It grew because the first system was too slow to use during the work, and people had patients to see.
This is usually filed as an adoption problem, which makes it sound like a training issue. That framing misses the failure. Slow clinical software is a design failure with a clinical consequence, and it is the single most common reason health software fails its first real audit.
People work around slow systems because they have to keep care moving
Imagine a system that takes eleven seconds to load a patient record. That sounds tolerable in a demo. Now put it in a clinic where somebody sees thirty patients in a session and touches the record four or five times each.
Eleven seconds becomes something closer to half an hour of standing still, and standing still is the one thing that session cannot afford.
So people adapt. They open the record once at the start and leave it open. They write on paper and enter it in a batch at six o’clock. They ask a colleague rather than looking it up.
Every one of those decisions is locally sensible and individually defensible. Together they mean the record is no longer a live account of what happened. The timestamps in your audit log describe when somebody typed, rather than when somebody decided.
That distinction matters enormously the day an incident is reviewed. The question is never "what does the database say". It is "who knew what, and when did they know it". A batch of entries all made at 18:04 cannot answer that question, and no amount of retrospective note-taking will reconstruct it.
Speed belongs in the safety conversation
We treat latency, the delay a person feels while the system responds, in clinical systems the way you would treat a dosage calculation. The failure mode has the same shape: it does not announce itself, and by the time it is visible the damage is historical.
The number we care about is the slow end of the experience. Averages hide exactly the cases that cause workarounds.
If your record loads in 400 milliseconds most of the time and eleven seconds when a patient has a long history, then your slowest, most complex, highest risk patients are the ones whose care is documented worst. That is precisely backwards. An average response time of 600 milliseconds will report it as healthy.
So we measure the 95th and 99th percentile, which show how slow the slow cases are, and we measure them per interaction rather than per page. The useful unit is the action the clinician is trying to complete.
Those actions include:
- Opening a record.
- Adding an observation.
- Acknowledging a result.
Each of those has a budget. If a budget is exceeded, that is a defect, and it goes in the same queue as a wrong result.
Slow systems usually fail in ordinary places
In our experience the cause is rarely the thing people expect. The language or the framework is almost never the reason. The cause is usually one of four ordinary engineering problems.
- The record is assembled from too many places at request time. Six integrations, each with its own timeout, called in sequence, and the page waits for all of them. One slow partner and the whole record is slow.
- Everything is loaded whether or not it is looked at. Ten years of history rendered on open, when the clinician wanted the last two encounters and the current medication list.
- Authorisation is checked late and repeatedly. A permissions call per widget, each one a round trip, when the answer was known before the page started rendering.
- The network in the building is not the network in the datacentre. Wifi on a ward, on a device that has been awake for nine hours, is not the connection your test suite runs on.
None of those are exotic. All of them are ordinary engineering, and all of them are fixable without replacing the system.
They persist because nobody owns the number. Speed is everybody’s concern and therefore nobody’s deliverable.
The fastest way to work should produce the right record
The trick is to make people care about the audit trail. They already care, and telling them again will not buy you anything. The trick is to make the quickest way to do the work also the way that produces a correct record.
Practically that means a few things.
- Capture happens where the work happens, on the device in the room, instead of at a workstation down the corridor.
- The interaction that records an observation is the same interaction that displays it, so there is no separate documentation step to be deferred.
- Anything that can be derived is derived rather than typed.
- When the system genuinely cannot complete something immediately, it says so and queues it, rather than sitting there spinning while a person decides whether to wait.
That last case matters. A system that is honest about being busy is far less corrosive than one that is silently slow. People will tolerate "saved, syncing" indefinitely. They will not tolerate a spinner that might mean anything.
The audit trail has to answer what happened at the time
Most systems can tell you what a record contains. Far fewer can tell you what it contained on a given Tuesday, who looked at it, and on whose authority.
The second answer is what an investigation needs, and it has to be designed in from the start, because you cannot reconstruct it later.
We build these as append-only event logs, where clinically meaningful actions are added as permanent entries, rather than as a mutable row with a history table bolted alongside. Every clinically meaningful action becomes an immutable entry with an actor, a timestamp taken at the point of action, and the authority under which it was taken.
The current state of the record is a projection of those events, while the events remain the source of truth. It costs more up front, in storage and in thinking. It is the difference between being able to answer the question and being unable to answer it.
It also has a pleasant side effect. Once the log is the truth, showing a clinician what changed since they last looked becomes trivial, and that is a feature people actually want rather than one compliance imposed on them.
A referral delay showed where the real wait was
A referral pathway we picked up had a median time to first appointment of twenty four days. The client believed the problem was capacity. The log said otherwise.
Of those twenty four days, seventeen were spent in a state nobody owned: referred, received, not yet triaged. Nothing was wrong. Nobody was idle. The referral simply sat in a queue that no dashboard displayed, because the queue was not a concept in the software. It was an emergent property of two systems that did not agree on whose problem the referral currently was.
We did not add capacity. We made the queue a real object with an owner, an age, and an alert when the age crossed a threshold the clinical team chose.
We also cut record load time at the 95th percentile from nine seconds to under a second, which meant triage could happen in the gaps between other work rather than requiring a dedicated session.
Time to first appointment went to nine days. The staffing did not change. What changed is that the waiting became visible, and the software became fast enough to use in the moments when people actually had a moment.
Shared ward devices break common software assumptions
Most clinical software is designed as though one person owns one device. On a ward, six people share four devices, and the person holding it changes every few minutes. That single fact breaks a surprising number of ordinary decisions.
Timeouts create the wrong trade-off
Session timeouts are the obvious one. Set them long and you get entries attributed to whoever logged in first that morning. Set them short and you have people typing a password thirty times a shift, which is exactly the friction that produces a shared login written on a sticky note.
Neither option is acceptable, and picking between them is the wrong exercise. What works is fast re-identification: a tap of a badge to switch actor without tearing down the context, so the record follows the person rather than the hardware.
Drafts have to belong to the right person and patient
Then there is state. If a device is handed over mid-task, the next person must not inherit a half-filled form pointed at the previous patient.
We treat any unsaved draft as belonging to an actor and a patient jointly, and switching either one puts it away rather than carrying it forward. It sounds paranoid until you have seen the alternative, which is an observation recorded against the wrong person by somebody who did nothing careless at all.
None of this is expensive to build. It is expensive to retrofit, because it touches how identity and drafts work everywhere. That is why it belongs in the first week of design rather than the month before go live.
Ask vendors about the work, not the feature list
If you are buying or reviewing a clinical system, the questions that separate a serious answer from a demo are not about features.
- What is the 95th percentile time to open a record for your largest patient, on the hardware and network we actually use?
- What happens to an entry made when the device has no connection, and how would we know it had not synced?
- Can you show me, for a record of your choosing, everyone who viewed it last month and under what role?
- When an integration partner is slow, what does the clinician see?
- Which actions are recorded with the timestamp of the action rather than the timestamp of the save?
A vendor who has thought about this will answer quickly and specifically, and will probably volunteer the cases where their answer is weak. A vendor who has not will talk about their roadmap.
Workarounds are defect reports
We have been on the wrong side of this. An early system of ours was fast on every screen we tested and slow on exactly one, the medication history for patients on more than about a dozen concurrent items.
That is a small fraction of patients and a large fraction of risk. It took a nurse telling us plainly that she had stopped using that screen for us to find it, because our own monitoring was reporting averages and the average was fine.
We changed two things after that.
- We report percentiles per interaction, never averages.
- We treat "somebody has developed a workaround" as a defect report with a severity, not as feedback.
The second change found more real problems than the first.
The general principle holds well beyond healthcare, but healthcare is where the cost of ignoring it is highest. Software that is slow does not fail loudly. It fails by being routed around, quietly, by competent people doing their best, and the first time anyone notices is when somebody asks what happened and the record cannot say.
More on how we approach this sector on our healthcare page, and on the method we use to get there in how we work.
