The waiting list measures how long. This is about what happens to the person during that time — being kept in touch with, offered help, and noticed if they get worse — the recovery the clock never covered, the referral and work-up that decide whether the wait should have started at all, the cancer clocks, and the eight national elective experience standards that make it something a board answers for.
Every elective system in the world measures the wait as elapsed time and manages it as a queue position. Both are necessary. Neither tells you whether the person waiting heard from anybody, got worse, or was offered any help at all — and the measurement stops dead at the moment of treatment, which is roughly halfway through what the patient would call the episode.
Waiting well, as the King’s Fund frames it, is the idea that the time somebody spends waiting for planned care should be used well: a better, safer, more equitable wait rather than only a shorter one. This document is about the surfaces that make that a working practice instead of a sentiment — and, in section 6, about the eight national standards that turn it into something a board is answerable for.
Each person carries a contact cadence, and going past it’s the trigger. What happens next is the part worth reading, because it’s where a well-meaning mail-merge does harm.
Three refusals are built into one send. Somebody marked do-not-contact is skipped before the message is composed. Somebody whose preferred channel is a letter gets a letter, and the column above shows the channel each message will take. And a row that can’t be resolved to a real patient is marked local-only and writes nothing, because a demonstration record has no business writing into a real person’s communications history. Everything that does send is written to the one communications record at /comms-crm, so the clinician who sees that person next can see they were contacted, when, and about what.
The default order of a waiting list is the date of listing. That’s fair in the sense of a queue and unfair in the sense that matters, because long waits don’t fall evenly.
Deprivation decile and the CORE20PLUS5 flag travel with the person, so the keep-in-touch list, the prehabilitation offer and the validation effort can be ranked by need as well as by date. Every tile above is clickable and lands on the tab listing exactly those people, filtered; a count you can’t open is a number nobody can act on. The ordering above is what this cohort says, and a production deployment computes it from whoever is on the list that day.
On the list · overdue a keep-in-touch · enrolled in prehabilitation · deteriorating · CORE20PLUS5 · validated. Every tile is clickable and lands on the tab that lists exactly those people, filtered — a count you can’t open is a number nobody can act on.
Days since last contact against the cadence set for that person, per-row channel override, and a cohort send to everyone overdue at once. Respects preferences, writes to the CRM.
Prehabilitation and health optimisation — exercise, weight, smoking, nutrition, pain, mental health — plus social prescribing for the parts of waiting that aren’t clinical. Arriving fitter is the one thing a long wait can be used for.
Their position, an expected timeframe and the RTT clock, in language a person can use. Most waiting-list anxiety isn’t about the length of the wait but about not knowing.
Symptom and outcome check-ins with a green/amber/red reading, so deterioration during the wait becomes a reason to expedite or re-triage instead of something discovered at the pre-op assessment. Also carries validation and patient-initiated follow-up.
Surgery → discharge to assess → community rehabilitation, with the therapies, the length of stay against target and the reason for any delay. The episode doesn’t end when the clock stops.
Splitting the wait from the recovery across two systems is how a person who was contacted every month for four months becomes invisible the week after their operation.
Ready for rehabilitation is recorded separately from discharged. They’re different facts, and conflating them is what produces a bedded rehabilitation place held by somebody who is waiting for a domiciliary care start and not for therapy. The length of stay runs against the target for the pathway, and where it is over, the row carries the reason.
Published as PRN02340_ii on 3 July 2026, the standards set out what every elective patient should experience from referral to care-complete. They aren’t a separate programme: seven of the eight are clocks and formats over data the organisation already records, which is why they were reflected in the product quickly — and why embedding them cost no new data entry.
| # | Standard | Where it is met | Status |
|---|---|---|---|
| 1 | Referral decision within 28 days A referral goes on a clock; the decision — accepted, rejected, more information, redirected — is due within 28 days, and recording it notifies the patient of the outcome and next steps in their required format. | /elective-clocks The page reads the clock live. Nothing has been decided against it on the demonstration instance, so the card shows the seeded figure and says it’s seeded until decisions are captured. | Demonstrated |
| 2 | Clear communication, in an accessible format Accessible Information Standard (DCB1605) correspondence formats captured per person, consented, attributed and audited, with a required-format banner every outbound letter must honour. | /comm-needs Live and wired; patients can self-declare through the portal. | Live |
| 3 | Information while you wait Position, expected timeframe, the RTT clock and what help is available — the Waiting Well surfaces this explainer is about. | /waiting-well Seeded cohort; the contact half is live. | Demonstrated |
| 4 | An update at least every 12 weeks A scheduled waiting update, sent through the communications record, honouring channel preference and the required format. | /comms-crm The CRM send is live; the cadence on the Waiting Well page is seeded. | Live |
| 5 | Reasonable adjustments NHS Reasonable Adjustment Flag adjustments captured alongside the DCB1605 formats, on the same spine, so one record answers both. | /comm-needs Live and wired, including portal self-declaration. | Live |
| 6 | Appointment information at least 21 days ahead Appointment detail issued in good time and in the required format. | /comms-crm · /appointments CRM and appointments are live. | Live |
| 7 | A cancelled appointment re-dated within 28 days Computed from operational timestamps against the 28-day standard, not typed in by anybody. | /referral-hub · /rtt-ptl The clocks exist operationally; the standards view of them is seeded. | Demonstrated |
| 8 | Care complete, and what happens next The breach worklist and the care-complete tile, with next steps notified in the required format. | /elective-experience-standards Seeded dashboard. | Demonstrated |
/elective-clocks live. On the demonstration instance nothing has been decided against
that clock, so the page shows the amber line above instead of a compliance figure — an empty
register is neither 0% nor 100%, and the number in the Standard-1 card stays seeded and labelled
until decisions are captured. That’s the honest state: the API is wired, the register is empty.The reason a national standard could be reflected quickly isn’t heroics. It is that the standards ask for clocks and a format, not for new information.
The decision clock, the 12-week update, the 21-day appointment notice and the 28-day re-date all compute from referral, waiting-list and appointment timestamps the organisation already records. Putting a referral on a clock adds nothing to capture — the timestamp exists.
Standards 2 and 5 need no new intake: the required format for every letter is read from the Communication Needs spine and the contact preferences already held — and a patient can self-declare through the portal, so the record maintains itself.
The standards surface is a display-and-clock layer over existing operational and communications data. That’s why it’s cheap to add and cheap to remove — and why the honest status of each row is visible not averaged into one number.
The cheapest wait to fix is the one that should never have started. Everything above assumes the right person is on the right list, and that assumption is where a lot of elective time goes missing. This section is the front of the pathway: the referral, the work-up, the advice that avoids a referral, and the one set of clocks where a slow wait is a clinical harm instead of an experience problem.
The clock starts at the referral and stays with it. The referral hub carries the 18-week referral-to-treatment clock per referral: when it started, days elapsed, days remaining, and a status that turns amber at 14 weeks and red past 18. Privately funded referrals are lifted into a separate queue, because the 18-week rules apply to NHS-funded pathways and counting anything else in them flatters the return. The counters at the top of that page for referrals pending, accepted and at risk on RTT are read from the referral store, and the breach-risk scoring is a real call against it. The per-patient clock table underneath is seeded, and the page puts a banner across it saying so instead of letting a buyer find out later.
The optimiser is the part that saves a whole outpatient visit. Each pathway carries a protocol and a list of pre-consultation investigations. From the referral you batch-order that work-up in one action, so the person arrives at the first appointment with results already in. It’s protocol-gated: if the pathway’s mandatory criteria aren’t met the order is refused, and the only way past is to record a reason, which is written into the order and travels with it. Pathways, referrals, waiting times and the ordering itself are live API calls. So is advice and guidance — the referral you don’t make. A clinician asks a specialist a question, the specialist answers, and the request can be escalated when the answer needs to become a referral; requests, responses, escalations and the outstanding urgent count are all real.
The tracking list, ranked by need instead of only by date. The patient tracking list holds the 18-week position, breach and at-risk RAG, specialty breakdown and validation. Its equity lens re-ranks by clinical priority and deprivation decile, showing the uplift it applied to each row, so two people of equal clinical priority aren’t separated by their postcode; CORE20PLUS5 travels with the patient. The same tab counts what could come off the list at all — stable follow-ups suitable for patient-initiated follow-up, pathways with no activity for a year that need validating, duplicates, people already treated elsewhere. The waiting swarm draws the same list as several hundred dots ageing towards the 18 and 52-week lines, coloured by wait, priority or deprivation. All of that’s a demonstration list, and each page says so on its face.
Cancer runs on its own clocks and they’re the ones that matter clinically. The cancer surface tracks the two-week wait, the 28-day Faster Diagnosis Standard, the 62-day treatment standard, multidisciplinary team meetings and systemic anti-cancer therapy. The Faster Diagnosis view is the useful one, because it shows the chain of dates instead of a percentage: referral, first appointment, investigations ordered, investigations done, MDT, diagnosis. When a pathway breaches you can see which link took the time, which is the only version of that number anybody can act on. This surface is seeded throughout.
The hub is a coordination layer over modules that already exist. It integrates /comms-crm /waiting-list /rtt-ptl /smart-triage /pifu /social-prescribing /discharge-hub /virtual-ward /comm-needs /referral-hub /referral-optimisation /advice-guidance /cancer-pathways /rtt-swarm and /esign — and duplicates none of them.
| Capability | Where | How | Status |
|---|---|---|---|
| Keep-in-touch send — one patient | /waiting-well | resolve person → POST /crm/patients/{id}/log | Live |
| Contact preference and do-not-contact | /waiting-well | GET /crm/patients/{id}/preferences | Live |
| Cohort update to everyone overdue | /waiting-well | POST /crm/cohort-send | Live |
| The communications record itself | /comms-crm | one timeline per person, every channel | Live |
| The waiting cohort on this page | /waiting-well | seeded — 6 illustrative patients | Demonstrated |
| The patient tracking list itself | /rtt-ptl | RTT clock, breach and at-risk RAG, validation — seeded 20-pathway demonstration list | Demonstrated |
| Prehabilitation and wait-well support | /waiting-well | seeded; links to social prescribing | Demonstrated |
| Expected timeframe shown to the patient | /waiting-well | seeded estimate — NOT a forecast model | Demonstrated |
| Symptom and PROM check-ins while waiting | /waiting-well | seeded | Demonstrated |
| Patient-initiated follow-up register | /pifu | read endpoints exist; the register page holds seeded content | Demonstrated |
| Recovery, discharge to assess and rehab | /waiting-well · /discharge-hub | seeded on this page; the discharge hub is the live surface | Demonstrated |
| Communication needs and reasonable adjustments | /comm-needs | DCB1605 formats + NHS Reasonable Adjustment Flag, on one spine | Live |
| Patient self-declares their communication needs | /portal/comm-needs | portal auth | Live |
| The 8-standard dashboard, breach worklist and board return | /elective-experience-standards | seeded dashboard; the board return is API-backed | Demonstrated |
| Board sign-off on the elective standards return | /elective-experience-standards | routed through commvita Sign | Live |
| Standard-1 referral-decision clock (28 days) | /elective-clocks | page reads the clock live; nothing decided yet, so the card stays seeded and says so | Demonstrated |
| Referral hub — queue counters and RTT at-risk count | /referral-hub | GET /orchestration/stats over the referral store | Live |
| RTT breach-risk scoring, worst first | /referral-hub | POST /ers/referrals/rtt-breach-risk | Live |
| The 18-week clock table and the private queue | /referral-hub | seeded — banner on the tab says so | Demonstrated |
| Referral optimiser — pathways, referrals, waiting times | /referral-optimisation | GET /ers/pathways · /ers/referrals | Live |
| Pre-consultation work-up, batch-ordered and protocol-gated | /referral-optimisation | POST /ers/referrals/{id}/order-diagnostics — refused unless the protocol is met or a reason is recorded | Live |
| Advice and guidance — request, respond, escalate | /advice-guidance | /ers/advice-guidance | Live |
| Equity ranking on the tracking list | /rtt-ptl | seeded; IMD decile and CORE20PLUS5 weighting, with the uplift shown per row | Demonstrated |
| List reduction — PIFU, validation, duplicates | /rtt-ptl | seeded counts; actions queue a task, never an automatic clock stop | Demonstrated |
| RTT waiting swarm | /rtt-swarm | seeded distribution, coloured by wait, priority or deprivation | Demonstrated |
| Cancer — 2WW, 28-day FDS, 62-day, MDT, SACT | /cancer-pathways | seeded — banner on the page says so | Demonstrated |
The waiting cohort on this page is seeded. Six illustrative patients, chosen to show the states the page reasons about. The patient tracking list at /rtt-ptl carries the RTT clock, breach and at-risk RAG, validation and the inequality-weighted ranking, and it’s that list a production deployment drives this from. On this instance it’s a seeded 20-pathway demonstration list, and the page says so.
The communications half IS live. The keep-in-touch send, the preference lookup and the cohort send are real API calls against the Communications CRM. That’s the part most easily faked in a demonstration and it’s the part that’s real here; the resolve-then-write gate exists precisely so the demonstration can’t cheat.
The expected timeframe shown to a patient is a seeded estimate, not a forecast. No model produces it. Showing a person a confident date the service can’t keep is worse than showing them a range and saying it’s a range, so a production deployment should bind this to its own capacity and demand figures before showing it to anybody.
Prehabilitation, the check-ins and the recovery board are representative. The clinical argument — that a long wait is an opportunity to optimise and a risk of deconditioning — is well evidenced. The wiring to a real prehabilitation service, a real PROM instrument and a real rehabilitation caseload is deployment work, and the live discharge surface is /discharge-hub.
The front of the pathway is a mixture, and the mixture is what matters. The referral store, the pathway protocols, the work-up ordering and advice and guidance are live API calls. The 18-week clock table, the patient tracking list with its equity ranking, the waiting swarm and the whole cancer surface are demonstration data, and every one of those pages carries a banner saying so. Binding them to a real referral and waiting-list feed is deployment work, and it’s the same work whichever system holds the list today.
Non-SaMD. This module surfaces recorded information and prompts a human to act. It doesn’t triage, doesn’t prioritise clinically and doesn’t decide who is expedited — a deterioration flag is a reason for a clinician to look, not a decision.