Walk any ward with a stopwatch and you will find the same thing. There is the system the trust bought, and there is the system the ward actually runs on. The second one is 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 it. 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. It is not. It is a design failure with a clinical consequence, and it is the single most common reason health software fails its first real audit.
The workaround is the rational choice
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, and the timestamps in your audit log describe when somebody typed, not 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 is a safety property, not a nice to have
We treat latency in clinical systems the way you would treat a dosage calculation, because the failure mode is 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 not the average. 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, and an average response time of 600 milliseconds will report it as healthy.
So we measure the 95th and 99th percentile, and we measure them per interaction rather than per page. The relevant unit is not “the application”, it is “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.
What slow usually turns out to be
In our experience the cause is rarely the thing people expect. It is almost never the language or the framework. It is one of four things.
- 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. The reason they persist is that nobody owns the number. Speed is everybody’s concern and therefore nobody’s deliverable.
Designing so the fast path is the compliant path
The trick is not 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, not 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. And 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 one is worth dwelling on. 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 you actually want
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 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 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, not 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 not.
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 genuinely want rather than one compliance imposed on them.
A worked example
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 devices change every assumption
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.
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.
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, which is why it belongs in the first week of design rather than the month before go live.
What to ask for
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.
The uncomfortable part
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, and 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.
