Building for the NHS: What We Learned

When we started designing a remote patient monitoring platform for NHS virtual ward programmes, we thought the hard part would be the technology. Real-time observations, clinical scoring algorithms, automated alerts. Complex engineering, certainly, but engineering we understood. The real challenge turned out to be something else entirely.

Clinical workflows are not like business workflows

In a business application, a delayed notification is an inconvenience. In a clinical application, it could mean a deteriorating patient is not escalated in time. That difference shapes every decision you make as a builder. The tolerance for error is close to zero, and the consequences of getting it wrong are measured in patient outcomes, not lost revenue.

We learned quickly that clinical users think about software differently from other professionals. A nurse on a virtual ward round does not want options. They want the system to surface what matters, in the order it matters, with clear next steps. Every additional click is time taken away from patient care. Every unnecessary screen is a source of frustration in an already demanding role.

NHS Digital standards are there for good reason

Working to NHS Digital standards is not a box-ticking exercise. The standards exist because the healthcare system has learned, through painful experience, what happens when clinical software is built without rigorous interoperability, security, and accessibility requirements.

HL7 FHIR for data exchange, WCAG for accessibility, DTAC for digital technology assessment, DCB0129 for clinical safety. Each standard adds complexity to the build, but each one exists because someone, somewhere, was harmed by a system that did not meet it. Once you understand that context, compliance stops feeling like overhead and starts feeling like the bare minimum.

What the NHS actually needs from technology partners

The NHS is not short of technology vendors. What it lacks are partners who understand both the technical and operational sides of healthcare delivery. Too many platforms are built in isolation from the clinical teams who will use them. The result is software that passes every compliance check but fails the most important test: whether a clinician will actually use it under pressure.

We spent time with clinical staff before writing a single line of code. Watched how they managed virtual ward patients. Listened to what frustrated them about existing tools. Mapped their workflows not as we assumed they worked, but as they actually did, including all the workarounds and informal processes that no specification document captures.

Lessons we took forward

Build for the worst moment, not the average one. When a clinical user is making a time-critical decision, your platform should be invisible. It should present the right information without requiring the user to go looking for it.

Respect the domain. Healthcare has its own language, its own hierarchies, and its own risk profile. If you try to impose patterns from other industries, you will build something that looks modern but feels wrong to the people using it.

And test with real users, in real conditions. A clinician reviewing a demo on a Tuesday afternoon will tell you it looks fine. Put the same system in front of them during a Friday evening ward round, and you will get very different feedback.

These lessons shaped how we approach every healthcare project now. They also reinforced something we already believed from our procurement work: you cannot build good software for an industry you do not understand.