commvita
Connected care platform
Elective care

Waiting well, the eight standards, and coming back afterwards

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, and the eight national elective experience standards that make it something a board answers for.

Live vs demonstrated: Live — real, API-backed platform logic (wired end-to-end today) Demonstrated — representative control surface with seeded data / illustrative UI mock-up

1The problem, stated plainly

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 rather than a sentiment — and, in section 6, about the eight national standards that turn it into something a board is answerable for.

ReferralDecision to refer,triage, listingThe waitWeeks to months.Deconditioning, anxiety,symptoms changingTreatmentThe operationor procedureRecoveryDischarge to assess,community rehab,getting function backWhat the RTT clock measures — elapsed timeNobody's job by defaultWhether the person heard from anyone, got worse, or got any help at allOff the clock entirelyThe clock stops at treatmentA shorter wait is a good thing. It is not the same thing as a better wait, and it says nothing at all about what happens afterwards.
Waiting Well is about the two unmeasured spans. It does not replace the waiting list — the patient tracking list, the RTT clock and the breach management sit where they always did, at /rtt-ptl. This is the layer that treats the wait as something that happens to a person rather than as a duration to be reported, and carries the pathway on through recovery.
The design premise. A shorter wait is a good thing and nobody should pretend otherwise. But a person who waits eleven weeks and is contacted twice, offered prehabilitation, and told what to do if things change has had a materially different experience from a person who waits nine weeks in silence — and only one of those two is visible in the returns.

2Keeping in touch — and the gate before the send

Each person carries a contact cadence, and going past it is the trigger. What happens next is the part worth reading, because it is where a well-meaning mail-merge does harm.

Cadence exceededdays since last contact> the cadence set for themResolve the personthe seeded row id is NOTa patient id — resolve firstDo-not-contact?checked BEFORE composing,not after sendingTheir channelportal · SMS · email · letterWhatsApp · phoneOne recordwritten to theCommunications CRMDo-not-contact → nothing is sentand the row is not silently marked as contactedUnresolved → marked local-demo, and NO live write happensA demo row that cannot be matched to a real person does not get to write to a real communications record.
Three refusals are built into one send. A person marked do-not-contact is skipped before the message is even composed. A person whose preferred channel is a letter gets a letter, not an SMS. And a row that cannot 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.

3Who you contact first

The default order of a waiting list is the date of listing. That is fair in the sense of a queue and unfair in the sense that matters, because long waits do not fall evenly.

Days waited, by deprivation decile — illustrative shape, not a national figure1321Most deprived119210138846454764473883392910Least deprivedCORE20PLUS5 cohort — ranked first for contact and for prehabilitation, not simply by date of listing
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. This is the same inequalities lens the elective recovery module applies to the tracking list itself — here it is applied to who gets a phone call and who gets offered help. The shape above is illustrative; the real distribution is whatever your own list says, and the page computes it from the cohort in front of it.

4The six surfaces

Dashboard

What needs doing today

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 cannot open is a number nobody can act on.

Keep in touch

Proactive contact

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.

Wait-well support

Do something with the time

Prehabilitation and health optimisation — exercise, weight, smoking, nutrition, pain, mental health — plus social prescribing for the parts of waiting that are not clinical. Arriving fitter is the one thing a long wait can be used for.

Personalised information

Told, not guessing

Their position, an expected timeframe and the RTT clock, in language a person can use. Most waiting-list anxiety is not about the length of the wait but about not knowing.

Proactive monitoring

Getting worse, on a list

Symptom and outcome check-ins with a green/amber/red reading, so deterioration during the wait becomes a reason to expedite or re-triage rather than something discovered at the pre-op assessment. Also carries validation and patient-initiated follow-up.

Recovery & rehab

After the operation

Surgery → discharge to assess → community rehabilitation, with the therapies, the length of stay against target and the reason for any delay. The episode does not end when the clock stops.

5Recovery, and why it belongs here

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.

After the operation — the pathway continuesEach patient carries a pathway, whether they are ready for rehabilitation, their therapies, their length of stay against target, and — if delayed — the reason.1Pathway 1 — Home with supportSimple discharge home with a restart or a new package of care. The largest group, and the one most often delayed by something administrative.2Pathway 2 — Home with rehabShort-term rehabilitation or reablement at home, therapy-led, with a goal and a review date rather than an open-ended service.3Pathway 3 — Bedded rehabA bedded setting for rehabilitation or assessment where home is not yet possible. The smallest group and the most expensive.A block reason is recorded as text on the person — “awaiting domiciliary care start”, “swallow assessment pending” — because a delayed discharge with no stated cause cannot be acted on.
Ready for rehabilitation is recorded separately from discharged. They are different facts, and conflating them is what produces a bedded rehabilitation place held by somebody who is waiting for a domiciliary care start rather than for therapy.

6The eight elective experience standards

Published as PRN02340_ii on 3 July 2026, the standards set out what every elective patient should experience from referral to care-complete. They are not 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.

#StandardWhere it is metStatus
1Referral 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
API built and tested (ElectiveReferralDecision), but the page does not call it — the compliance figure on screen is seeded while a working API sits behind it.
Built, not wired
2Clear 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. PatientCommNeed; patients can self-declare through the portal.
Live
3Information 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
4An 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
5Reasonable 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
6Appointment 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
7A cancelled appointment re-dated within 28 days
Computed from operational timestamps against the 28-day standard rather than typed in by anybody.
/referral-hub · /rtt-ptl
The clocks exist operationally; the standards view of them is seeded.
Demonstrated
8Care 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
One row is rated “built, not wired”, and that is the honest reading. The Standard-1 28-day decision clock has a model, endpoints and tests — and the page does not call it. Measured: /elective-clocks has zero references in the API client or in the standards page. So the Standard-1 compliance figure a board reads is seeded, while a working API sits behind it. An earlier version of this explainer rated that row Live. It was wrong, and rating it Live is exactly how a gap survives a board meeting.

7Why this needed no data-collection programme

The reason a national standard could be reflected quickly is not heroics. It is that the standards ask for clocks and a format, not for new information.

The clocks are already there

No new capture

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.

The format is already held

One spine, two standards

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.

A lens, not a system

And reversible

The standards surface is a display-and-clock layer over existing operational and communications data. That is why it is cheap to add and cheap to remove — and why the honest status of each row is visible rather than averaged into one number.

Ships in the Community Edition — £1 per instance (optional paid support). The standards work reuses the operational and communications data already in the platform, so there is no per-seat data cost attached to meeting them.

8Where each part lives

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 and /esign — and duplicates none of them.

CapabilityWhereHowStatus
Keep-in-touch send — one patient/waiting-wellresolve person → POST /crm/patients/{id}/logLive
Contact preference and do-not-contact/waiting-wellGET /crm/patients/{id}/preferencesLive
Cohort update to everyone overdue/waiting-wellPOST /crm/cohort-sendLive
The communications record itself/comms-crmone timeline per person, every channelLive
The waiting cohort on this page/waiting-wellseeded — 6 illustrative patientsDemonstrated
The real patient tracking list/rtt-ptlRTT clock, breach RAG, validationLive
Prehabilitation and wait-well support/waiting-wellseeded; links to social prescribingDemonstrated
Expected timeframe shown to the patient/waiting-wellseeded estimate — NOT a forecast modelDemonstrated
Symptom and PROM check-ins while waiting/waiting-wellseededDemonstrated
Patient-initiated follow-up/pifulive moduleLive
Recovery, discharge to assess and rehab/waiting-well · /discharge-hubseeded on this page; the discharge hub is the live surfaceDemonstrated
Communication needs and reasonable adjustments/comm-needsDCB1605 formats + NHS Reasonable Adjustment Flag, on one spineLive
Patient self-declares their communication needs/portal/comm-needsportal authLive
The 8-standard dashboard, breach worklist and board return/elective-experience-standardsseeded dashboard; the board return is API-backedDemonstrated
Board sign-off on the elective standards return/elective-experience-standardsrouted through commvita SignLive
Standard-1 referral-decision clock (28 days)/elective-clocksAPI built and tested — the page does NOT call itDemonstrated

9The honest edges

The waiting cohort on this page is seeded. Six illustrative patients, chosen to show the states the page reasons about. The live patient tracking list is /rtt-ptl — RTT clock, breach and at-risk RAG, validation, inequality-weighted ranking — and it is that list a production deployment drives this from.

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 is the part most easily faked in a demonstration and it is the part that is real here; the resolve-then-write gate exists precisely so the demonstration cannot 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 cannot keep is worse than showing them a range and saying it is 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.

Non-SaMD. This module surfaces recorded information and prompts a human to act. It does not triage, does not prioritise clinically and does not decide who is expedited — a deterioration flag is a reason for a clinician to look, not a decision.

NHS England Minimum Standards of Patient Experience — Electives (PRN02340_ii, 3 Jul 2026)Accessible Information Standard (DCB1605) · NHS Reasonable Adjustment FlagThe King's Fund — waiting wellCORE20PLUS5 · IMD 2019 · RTT Rules 2023Best Practice Discharge Framework — pathways 1, 2, 3Community Edition — £1 per instance (optional support)Non-SaMD — surfaces information, does not triage
© 2026 Commvita Digital Health Solutions Ltd. All rights reserved.