Version 1 to version 2

I was watching *Pulss*, the Finnish hospital drama shown on Estonian television, when the story suddenly stopped feeling like television. The hospital had introduced a patient information system called Paavi. Doctors struggled to use it, queues grew, mistakes became more likely, and management treated the disruption as if it were mainly a problem of staff attitude. The system technically existed. It opened. It accepted information. Presumably someone had already signed off on it.

But it did not work in the sense that matters.

There is a habit in technology to separate usability from seriousness. Security is serious. Infrastructure is serious. Compliance is serious. UX is what happens later, when someone adjusts the spacing, rewrites a button label, or asks users whether the dashboard feels intuitive.

Healthcare makes this separation difficult to maintain. When a clinician misunderstands a field, misses an alert, selects the wrong medication, or believes that an order has been sent when it has actually disappeared, the interface is no longer a layer of presentation. It has become part of the treatment.

Some of the most disturbing medical software failures are not dramatic crashes. The screen does not turn red. The computer does not announce that it has lost control. The system remains calm.

At the US Department of Veterans Affairs, clinicians using a new electronic health record could choose service locations from a dropdown menu that the system could not properly process. The option was visible. It could be selected. The order appeared to go through. Behind the interface, however, it could be routed into an unknown queue and never reach the intended service.

This is a very specific kind of failure. The user did what the product asked. The product accepted the action. The product then failed without telling the user.

More than 11,000 orders were not delivered during the period reviewed by the VA's inspector general. Clinical reviewers identified 149 patient-harm events connected to the unknown queue. One case involved follow-up psychiatric care for a patient identified as being at risk of suicide. The interface did not look broken. That was the problem.

A visible error creates friction, but it also creates knowledge. A silent error creates confidence.

This pattern appears repeatedly in medical systems. In one case documented by the US Agency for Healthcare Research and Quality, a two-year-old child's height and weight were entered into the wrong fields. Her actual weight of 15.8 kilograms became 96 kilograms, while her height became 15.8 centimetres. The electronic record accepted the values and used the incorrect weight to calculate a medication dose.

An alert appeared because the child's recorded weight had changed dramatically, but the alert was cleared. The pharmacy dispensed the dose and a nurse administered it. The child received much more methylprednisolone than intended and was admitted for monitoring, though no adverse effects were identified.

It is easy to blame the person who entered the numbers or the clinician who cleared the warning. It is harder to explain why a system responsible for weight-based dosing treated a 96-kilogram two-year-old as an ordinary data point.

Healthcare software often seems to be designed around a strange model of the user. The user is imagined as attentive, unhurried, uninterrupted, fully trained, emotionally neutral, and willing to carefully inspect every field and warning.

The real user may be halfway through a night shift, speaking to a frightened family member, answering a colleague, receiving a phone call, and trying to remember why the patient in the next room suddenly became unstable.

In that environment, telling people to be more careful is not a design strategy.

The Therac-25 radiation accidents are an older and more extreme example. Operators could encounter cryptic messages such as "Malfunction 54" after the machine entered a dangerous state. The interface did not clearly explain what had happened or what risk the patient faced. The display suggested that only a small fraction of the requested dose had been delivered, even when a massive overdose had occurred.

Operators had been led to believe that catastrophic overdoses were impossible, so the software's vague feedback was interpreted inside a larger atmosphere of trust. The machine was treated as more reliable than the person using it. When the machine and the person disagreed, the person learned to doubt themselves.

This relationship between software and authority still feels familiar. Complex systems often present their outputs with a confidence that exceeds their actual understanding. The interface turns incomplete information into a clean number, a green confirmation, a completed status, or a professionally formatted report. The user sees the polish and assumes the reasoning behind it must be equally solid.

In Panama, radiotherapy planning software produced dangerously incorrect treatment times after staff changed how they entered shielding blocks to work around a system limitation. The equipment itself was correctly calibrated. The problem emerged in the interaction between the software's input rules, an undocumented or poorly understood edge case, and a workflow that had moved beyond the system's intended constraints.

Twenty-eight patients were affected. The calculations were not independently questioned because the printed output appeared plausible. The software did not look confused, even when it was wrong.

That may be one of the deepest design problems in high-stakes software. We have become good at making systems look certain.

The Paavi storyline is fictional, but it reflects a real anxiety around hospital information systems. It also appears to echo public criticism of Finland's Apotti system, although I have not found a statement from the programme's creators confirming that Paavi was directly based on Apotti. Research into physicians' experiences with Apotti has described a sharp mismatch between the system's logic and the realities of clinical work.

Calling this a usability problem can still make it sound minor. It may be more accurate to say that the software and the clinical work do not fully understand each other.

A hospital is not a collection of forms. It is a moving network of handovers, interruptions, exceptions, incomplete information, time pressure, legal responsibility, professional judgement, and human vulnerability. When software is inserted into that network, it changes the network. It changes what people notice, what they forget, what they document, what they delegate, and what they assume someone else has already done.

A badly designed medical system does not only slow down a doctor. It can create new work for nurses, push staff toward unofficial workarounds, change which patients are seen first, and make responsibility harder to trace when something goes wrong.

This is where the usual language of UX starts to feel inadequate. "Easy to use" is not enough. A medical system can be easy to use and still make the wrong action dangerously easy.

The stronger questions are different.

Does the system make unusual conditions visible? Does it distinguish a routine warning from a critical one? Does it prevent impossible values rather than politely accepting them? Does it show what it calculated and why? Can the user tell whether an order was delivered, received, delayed, rejected, or lost? When people create workarounds, does the organisation treat that as disobedience or as evidence?

These questions belong partly to design, but also to operations, safety, management, procurement, and accountability. This is why I keep returning to product assurance as a possible direction for HAAM. The point would not be to arrive after launch and make a hospital dashboard prettier. It would be to examine whether the whole product remains understandable, trustworthy, and working inside the conditions where it is actually used.

"Working" is the difficult word.

A system may pass acceptance testing and still fail nurses during a busy shift. It may satisfy procurement requirements and still hide clinically important information. It may have no downtime and still quietly lose orders. It may record every click while making it impossible to understand what happened.

Most digital products are evaluated in clean conditions. High-stakes products should be evaluated in messy ones.

What happens when someone is interrupted halfway through the task? What happens when two medications have similar names? What happens when an alert appears for the fiftieth time that day? What happens when the network briefly disconnects? What happens when a clinician believes they completed an action but the next system in the chain never received it?

The most dangerous interface may not be the one that looks obviously broken.

It may be the one that accepts the input, closes the window, displays a green checkmark, and lets everyone continue.

Source note

The Paavi episode descriptions come from Finnish and Estonian television listings for *Syke* season 16. The medical cases are drawn from the US Department of Veterans Affairs Office of Inspector General, the Agency for Healthcare Research and Quality's PSNet, the International Atomic Energy Agency, and Nancy Leveson's account of the Therac-25 accidents. The possible Paavi and Apotti connection remains an interpretation, not a confirmed statement from the programme's creators.

Connected reading

- [Digital Product Assurance](/blog/digital-product-assurance) - [The System Around the Medical Model](/blog/the-system-around-the-medical-model) - [The Product Is Becoming an Organization](/blog/the-product-is-becoming-an-organization) - [The Interface Is Now Part of the Answer](/blog/the-interface-is-now-part-of-the-answer)

AI authorship note

This essay began with Kris Haamer noticing the Paavi storyline while watching *Pulss* on Estonian television, then asking whether similar interface failures had caused real problems in medicine. AI supported source research, drafting, fact checking, editing, and implementation. Kris chose the framing, connected it to HAAM's product-assurance direction, and approved the article for publication.