Every hospital system looks capable in a demonstration. The presenter moves calmly through registration, booking and consultation, and everything responds. The demonstration is not the test. The test is a Sunday morning with a full waiting area, three clinics running behind, a queue at reception and a member of staff who has been in post for two weeks.
Systems that fail that hour usually fail for the same handful of reasons, and none of them are about features.
The interface is optimised for the wrong user
Most clinical interfaces are designed to be understood by someone seeing them for the first time. But the people using them see them for the ten-thousandth time. Those are different design problems with different answers. A first-time user wants explanation; a daily user wants the field to be in the same place every time, keyboard-reachable, and to accept input at the speed they can type.
When we design registration screens, the measure is how many keystrokes a competent receptionist needs, not how self-explanatory the screen looks to a visitor.
The permission model does not match the department
Access control in healthcare is not a technical setting. It is a description of who is responsible for what, and it has to match the department rather than an idealised organisation chart. Get it slightly wrong and one of two things happens: either staff cannot do their job and start sharing accounts, or they can see far more than they should.
Shared accounts are the more common outcome, and they are worse than they look — they destroy auditability quietly, and nobody reports them because the workaround is working.
Peak load was never really tested
- Concurrent users at the busiest hour, not the average hour
- Search across a record set that has grown for several years, not a seeded test database
- Reporting queries running while operational work continues
- Integrations responding slowly rather than failing outright
The last one is the most frequently missed. A device or third-party integration that fails cleanly is easy to handle. One that takes eleven seconds to answer, intermittently, is what makes a system feel broken.
The exceptions were treated as edge cases
Every hospital has cases that do not follow the standard path: the patient without documentation, the emergency that skips registration, the referral that arrives by phone. Staff handle these constantly. If the system treats them as exceptions to be handled outside it, the informal process re-establishes itself immediately — and the data becomes unreliable.
The exceptions are not edge cases. They are a meaningful proportion of a normal day, and they belong inside the system.
What we do differently
- Spend time at reception and in the department before designing anything
- Design the busiest screens for repeated use, then check them with the people who will use them
- Model permissions against actual departmental responsibility
- Load-test against realistic data volumes and slow integrations, not just failures
- Bring the informal exception handling inside the system rather than around it
None of this is sophisticated. It is mostly a willingness to look at the operation before writing the specification — which is, in our experience, the single largest determinant of whether a clinical system is still being used properly two years later.