Elective Waiting-List Validation

The waiting list, validated.

A patient-facing pathway that asks one clinical question — do you still need this procedure? — and returns clean, auditable answers to the trust. Recover capacity. Get RTT data you can trust. And patients who report deterioration are escalated for clinical review, not dropped — the pathway is fail-closed, by design.

What I'm asking fora trust to host a first study View the live demosynthetic data · read-only

Fail-closed: Deterioration escalates for clinical review. Non-response never removes a patient. No automated discharge — ever.
Single-use links: Each patient gets a unique tokenised link. No login, no app, no password. Built to WCAG 2.2 AA.
Audit-ready: Every response, escalation and staff decision is logged and attributable. Clean data back to the PTL.

CH.01 The problem

Stale lists cost theatres.

Elective waiting lists carry a material proportion of patients who no longer need their listed procedure — treated elsewhere, symptoms resolved, moved away, or simply unreachable. Nobody planned for them to still be there.

Every stale entry distorts RTT reporting, absorbs pre-op assessments and outpatient slots that produce no operation, and pushes genuinely waiting patients further down the list. Validation by text is already routine — which is exactly why how it is done matters.

Trusts already ask. Validation exercises remove around 3% of the national waiting list every month. But Healthwatch England, reporting in December 2025, found that people contacted this way are “offered no updates or support while waiting, other than the request to confirm they still need treatment” — which “leaves people feeling forgotten and isolated”.

So the question isn't whether to validate. It's whether validation can be done safely, accessibly and at scale — without a single patient being lost in the process, and without the asking itself becoming another way to feel forgotten.

CH.02 The pathway

Four steps. One question. Zero silent removals.

The trust selects a PTL cohort

Validation runs against an exported cohort. Nothing writes back to source systems without clinical sign-off.
Each patient receives a single-use link

Unique, tokenised, no account needed. NHS number integrity is enforced end-to-end (Modulus-11 checks). Built to WCAG 2.2 AA.
The patient answers a short, plain-language check

Still required · no longer required · or "my condition has worsened" — with an accessible emergency interrupt directing anyone in immediate danger to 999.
Clean, auditable worklists return to the trust

Removals are decided by hospital staff — never automatic. Deterioration reports are flagged for clinical review. Non-responders stay exactly where they are — and the fact that they never answered is recorded for the trust, not discarded.

Routing schematic — the escalation branch is the design's centre of gravity

CH.03 Clinical safety

Fail-closed, by design.

The dangerous failure mode of any validation tool is silent removal — a patient dropped from a list because a form was misread, a link expired, or a database defaulted the wrong way. This system is engineered against that mode, not merely tested for it.

A report of worsening symptoms flags the patient for clinical review, and an accessible emergency interrupt directs anyone in immediate danger to 999 before anything else. No response is never treated as consent to remove — a non-responder's position on the list does not change. And every removal requires a decision by hospital staff, leaving an attributable audit trail. Being safe is not the same as being reached, and this tool does not reach everyone. Every validation link that expires without a response is now recorded, and the staff console lists those patients for the trust as “no response recorded”, never as a choice. The system records when a link was issued, not whether a message arrived, so an undelivered message looks identical to a decision not to reply.

Development runs under a DCB0129-aligned clinical-safety process with a maintained hazard log; formal sign-off completes with a named Clinical Safety Officer at pilot stage.

Honest status: this is a working prototype. It has never held real patient data — it runs on a UK-sovereign synthetic environment, verified by 130 automated tests, pending the formal assurance work a pilot deployment requires.

CH.04 Standards & sovereignty

Built inside the NHS rulebook, not retrofitted to it.

DCB0129: Clinical-safety process with hazard log from day one. Fail-closed escalation architecture. CSO sign-off scoped for pilot.
DTAC-aligned: Built against the Digital Technology Assessment Criteria; formal assessment pending pilot engagement.
WCAG 2.2 AA: The patient pathway is built to WCAG 2.2 AA — the patients most likely to be stale on a list are the hardest to reach.
UK-sovereign: All patient data hosted and processed in the UK (London region). No cross-border transfers of patient data.
NHS number integrity: Modulus-11 validation enforced end-to-end. Malformed identifiers cannot enter the system.
Synthetic data only: Zero real patient data held today. The live demo and all 130 automated tests run on synthetic cohorts.

CH.05 Status

Working prototype, seeking its first clinical partner.

BUILT
Live prototype: patient portal, staff console and validation engine, running end-to-end on a synthetic cohort with 130 automated tests.
NOW
Seeking a named NHS clinical partner — a trust or ICB team — to scope a localised pilot on a single specialty PTL cohort.
NEXT
SBRI Healthcare Phase 1 feasibility application, to be submitted once the clinical partner is named. Non-dilutive — no software cost to the partner trust.

Patient validation — live demosynthetic data · read-only Patient hub — guided demomock session · sample data Staff console — guided demomock session · sample data

CH.06 What I'm asking for

A trust to host a first study.

Not a purchase and not a procurement. What this needs next is a research partnership — an NHS trust research department willing to host and sponsor a small feasibility study, and to help answer the questions I cannot answer from outside the NHS.

The ask: A research department to host and sponsor a feasibility study on a single elective specialty cohort — a first study that establishes whether a full study could run, not one that sets out to show the tool works. The design is a proposal, to be rewritten by whoever leads it.
Already done: The Health Research Authority decision tool was run on 31 August 2026 and returns research requiring Research Ethics Committee review. That result is held, alongside a draft Data Protection Impact Assessment, a hazard log and the standards work above. You would inherit work rather than paperwork.
Not yet in place: No sponsor and no academic partner — that is the ask. No Integrated Research Application System number either, because one cannot be raised before a sponsor exists.
No patients involved yet: Nobody has been consulted so far. Healthwatch Surrey was approached on 2 September 2026 to arrange a session with people who have been on an elective waiting list, paid at national rates. Nothing is agreed. I would rather say so here than write it in the future tense in an application later.
Not asking for: No purchase, no procurement, no real patient data, and no exclusivity. The software, the hosting and the governance groundwork come at no cost to the trust.

Stage, plainly: prototype, synthetic data only, no site, no funding. The discipline this sits in is implementation science, and the hard part looks organisational rather than technical — how something like this works in a service where waiting-list processes differ by specialty, and sometimes by department within one trust.

CH.07 Questions

The questions worth asking first.

These are the questions clinicians, commissioners and researchers actually ask, answered at the current stage of the work rather than at the stage we would like to be at.

Is this being used in the NHS today?

No. It is a working prototype and it has never held real patient data. Everything demonstrated here runs on a synthetic environment. SVN OS is an independent company and is not affiliated with or endorsed by the NHS.

What happens if a patient never replies?

Nothing happens to them at all, and that is deliberate. Silence is never treated as consent to be removed. Their place, their priority and their waiting time are untouched, because the system takes no action on a non-response — the trust's existing post and telephone routes carry on covering them exactly as today.

The limit of that, stated honestly: the system now keeps a record of every validation link it issued that expired without a response. The staff console lists those patients for the trust as “no response recorded”, never as a choice. It records when a link was issued, not whether a message was sent or delivered, so it cannot tell an undelivered message from a decision not to reply. What the trust should do about the people on that list is one of the things a first study should look at — because the people least likely to answer a text message are often the people least able to advocate for themselves.

What if a patient says they no longer need the procedure?

It is never actioned automatically. There are two deliberate barriers. The patient's device asks them to confirm, so a single mis-tap cannot send an irreversible answer. Then a member of hospital staff decides whether to confirm the removal or reinstate the patient, leaving an attributable audit trail.

The software records an intention. A person makes the decision.

What if a patient reports their symptoms have got worse?

The report is recorded and flagged for clinical review on the staff console. The patient is told plainly, on the same screen, that the service is not monitored in real time, and is directed to their general practitioner, NHS 111, or 999 in an emergency.

The tool makes no clinical judgement about what the report means. It does not assess, triage or score anybody.

Couldn't patients just report worsening symptoms to be seen sooner?

It is a fair question and worth answering directly. Reporting worsening symptoms does not book anything and does not move anyone up the waiting list -- the tool cannot change a clinical priority or a waiting-time position, and a clinician decides what happens next. Each invitation link works once, so it is one answer per invitation rather than something that can be pressed repeatedly.

The more important question is the one underneath it: what proportion of a real waiting list reports worsening, and does review capacity match that volume? If too many reports arrive for a team to work through, the genuine deterioration is harder to find, not easier -- which would defeat the point. That is a question about a service rather than about software, it cannot be answered from synthetic data, and measuring it is one of the things a first study is for.

Is it a medical device?

The validation function is administrative -- it asks a question, records an answer and routes it to a person -- and on that basis is positioned as a non-medical device.

Optional symptom-tracking and acuity features that could attract a Software as a Medical Device classification are deliberately held out of scope pending a formal classification review. We would rather raise that early than discover it late.

What about patients without a mobile phone?

The text-message route is an additional channel, not a replacement. Anyone who cannot or does not use it stays on the list and is reached the way they are reached today. The patient pathway is built to WCAG 2.2 AA.

A digital route that quietly widens the gap for people already hardest to reach would be a worse outcome than the problem it set out to solve, so who the design misses is treated as a first-order question rather than an afterthought.

Is it DTAC approved?

No supplier can be. The Digital Technology Assessment Criteria is completed by the buying NHS organisation for a specific deployment -- it is not a certificate a company holds, and any supplier claiming otherwise has misunderstood it.

The system is built against the criteria, and the formal assessment happens with a partner organisation at pilot stage.

What evidence is there that it works?

None clinically, and we will not imply otherwise. There are 130 automated tests showing the software behaves as specified on synthetic data. That is build assurance, not clinical evidence, and the two are routinely confused.

An internal review is also not an independent one. Generating real evidence needs an NHS partner, real data and an evaluation designed by people who do not work for us. A Health Research Authority decision tool, run in August 2026, indicates that a first study of this kind would be research requiring Research Ethics Committee review.

What are you actually looking for?

An NHS clinical partner -- a trust research department or an academic group -- willing to host and sponsor a small feasibility study, and to help answer the questions above with real data rather than assumptions.

The interesting problem is organisational rather than technical: how something like this works inside a service where waiting-list processes differ by specialty and sometimes by department. That is not a question that can be answered from outside the NHS.

CH.08 The walkthrough

The whole system, in ten slides.

The same story end-to-end — the problem, the patient journey, clinical safety, the architecture, and an honest status. Use the arrows or swipe through.