Building the foundations of healthtech, starting with the hospital

A written version of the keynote I gave at the Digital Health World Congress in London, for everyone who couldn't be in the room, and for everyone who was there and asked me to put it on paper.

By Evelina Arushanova, Ph.D. — Senior Product Designer at elmeas

Last week I stood on a keynote stage in London and made a claim I've been quietly arguing for years: most digital health products fail in hospitals not because the technology is bad, but because they were never designed to live in a hospital in the first place.

That sentence got nods from people I expected to disagree with me, and pushback from people I expected to nod. The questions afterwards were sharper than anything I'd prepared for. Two clinicians stayed forty minutes to walk me through where elio, the product I work on every day, still falls short.

This is the part of the talk that didn't fit in twenty-five minutes on a stage. It's also the part I think the industry needs most.

Where healthtech is actually built

Open any healthtech startup's office and you'll find designers, engineers, product managers, sometimes a clinician-in-residence. What you usually won't find: the wards, handover rooms, and night shifts where the product will eventually be used. The closest most teams get is user research ; a few interviews, a couple of observation sessions, maybe a usability test in a sterile room.

That's not the same as being there.

In a controlled test, the user is focused on your software. On a real ward, the user is focused on a patient who just deteriorated, a colleague calling out for help, a phone that keeps ringing, an alarm two beds over. Your software is one of fifty things competing for their attention and most of those fifty things have higher stakes than yours.

Software designed for the calm of a testing room behaves badly under that pressure. Workflows get bent to fit the screen instead of the other way around. Clinicians develop workarounds. The product is technically deployed. It is functionally invisible.

What "starting inside the hospital" actually means

At elmeas, the question we kept coming back to wasn't "what features should elio have?" but "what does this clinician need to do, in this moment, when no one is looking?"

That sounds soft. It isn't. It changes everything about how the product gets built.

It means writing user stories with a nurse at the bedside, not a product manager in a meeting. It means asking "what was the last thing that made you swear at your screen this shift?" and treating the answer as a roadmap item, not anecdote. It means designing for tired hands at 3 a.m., not rested hands at 10 a.m.

It also means accepting that some of the most important workflows in healthcare are the ones nobody can fully describe. They're carried in heads, learned through years of shifts, and only made visible when someone new joins the ward and gets it wrong. If you can't see those workflows, you can't design for them. And if you can't design for them, the best you can build is software that almost works.

The "almost-worked" problem

This is the failure mode I think we under-discuss in healthtech.

Most digital health products don't fail loudly. They don't crash, they don't expose data, they don't make the news. They quietly never get used the way they were supposed to. A nurse opens the app to log one thing, then goes back to the paper chart for everything else. A doctor uses it in clinic but bypasses it on the ward. The deployment is successful on paper. The behaviour change isn't.

"Almost-worked" software is harder to learn from than failed software, because nobody calls it failure. It sits on dashboards as adoption metrics that look fine until you ask what people are actually doing with it. And the longer it sits there, the harder it is to replace, because every hospital remembers the disruption of the last roll-out.

The cost of almost-worked isn't only the wasted licence fee. It's the trust the next product has to rebuild before it even ships.

Things that didn't work for us, either

I want to be careful not to make this sound like elmeas figured it all out. We didn't.

Some of what we built early on was wrong. We over-trusted prototypes. We designed for the smartest, fastest clinician on the ward and discovered that the smartest, fastest clinician isn't the bottleneck , the new starter on a night shift is. We assumed that the way a workflow looked in a procedure document was the way it actually happened. (It rarely is.)

A clinician at the Congress told me about a feature in elio she finds genuinely useful, then immediately listed three places where she still works around it. That's not failure. That's the honest state of any product trying to live inside a real hospital. We treat that list as the next quarter's most important roadmap input.

What the next five years look like

If I had to bet on which healthtech teams will matter in the next five years, I wouldn't bet on the ones with the best AI demos. I'd bet on the ones doing the boring work.

Embedding designers and engineers inside hospitals for weeks at a time. Sitting through night shifts. Asking dumb questions in the wrong rooms until someone explains what's actually happening. Making peace with the fact that the workflow you thought you understood has six edge cases nobody told you about.

That work isn't glamorous. It doesn't fund-raise well. It doesn't show up in a feature comparison sheet. But it's what separates software that gets used from software that gets deployed. And in a sector where every hour of clinician attention is precious, used and deployed are not the same word.

An open invitation

The most useful sentence I heard at the Congress wasn't from a slide. It was from a nurse at a coffee break: "I don't need software that's faster. I need software that doesn't punish me when I have to look away."

That's the bar. I'd rather build for that than for any benchmark in any pitch deck.

If you're building healthtech and any of this resonated, or if you think I'm wrong about parts of it, I'd love to hear from you. Some of the sharpest feedback we've ever received on elio came from people who disagreed with us in public first. The conversation matters more than the consensus.

See you next year, on the next stage.