Referral-to-treatment targets remain one of the most scrutinised metrics in the NHS. Trusts that lack real-time pathway visibility routinely breach the 18-week standard — and every breach represents a patient waiting longer than they should.
The 18-week referral-to-treatment standard requires that at least 92% of patients on incomplete pathways should have been waiting no more than 18 weeks from referral. Despite this target existing since 2008, Trusts across England consistently struggle to meet it. The root cause is rarely a lack of clinical capacity alone — it is a lack of operational visibility into where patients sit on their pathways and which clocks are approaching breach.
Many Trusts still rely on a patchwork of PAS extracts, spreadsheets, and manual validation to track RTT pathways. Pathway coordinators spend hours each week reconciling data across systems, chasing clinicians for outcome codes, and manually identifying patients at risk of breaching. When a patient is referred between services or moved between consultants, the pathway status can become ambiguous, leading to clock errors that only surface during retrospective validation.
The consequences of poor RTT tracking extend beyond regulatory scrutiny. Patients who breach the 18-week target experience longer waits, worse outcomes, and greater anxiety. Trusts face reputational damage, potential contractual penalties from commissioners, and the operational cost of managing a growing backlog. SwiftCase currently tracks over 50,700 active healthcare cases, and the organisations achieving the strongest RTT performance are those with real-time, automated pathway visibility.
Effective RTT management requires a shift from retrospective reporting to proactive pathway tracking. Rather than discovering breaches after they have occurred, Trusts need systems that continuously monitor every incomplete pathway, flag patients approaching the 18-week threshold, and surface the actions required to keep clocks on track.
A structured workflow approach to RTT tracking connects referral receipt, triage, clinic booking, diagnostics, and treatment decisions into a single auditable pathway. Each step updates the pathway clock automatically, removing reliance on manual data entry and reducing the risk of clock errors. When a patient pathway stalls — because a diagnostic result is pending, a clinic slot is unavailable, or an inter-provider referral has not been acknowledged — the system escalates immediately.
This approach does not replace clinical judgement or existing PAS systems. It sits alongside them, providing the operational intelligence layer that pathway coordinators and waiting list managers need to intervene early and allocate capacity where it will have the greatest impact on breach prevention.
Follow these steps to build a pathway tracking system that gives your Trust real-time RTT visibility and prevents breaches before they occur.
Begin by mapping every system that contributes to RTT pathway data — your PAS, e-referral system (e-RS), radiology information system, and any departmental booking systems. Document where clock start events are recorded, how clock stops and pauses are captured, and where data gaps exist. Pay particular attention to inter-provider referrals, where clock continuity is frequently lost.
For each specialty, map the typical patient pathway from referral receipt through to first definitive treatment. Identify the key milestone events — triage decision, first outpatient appointment, diagnostic request, diagnostic result, treatment decision, and treatment date. Assign a responsible team or role to each milestone so that accountability for pathway progression is clear.
Build rules that automatically start, pause, and stop RTT clocks based on pathway events. A clock starts when a GP referral is received; it pauses when a patient actively chooses to delay (and only in defined circumstances per NHS England guidance); it stops when first definitive treatment begins or a clinical decision not to treat is made. These rules must align precisely with the NHS England RTT rules suite.
Configure automated alerts that trigger at defined points before the 18-week threshold. A typical escalation model alerts the pathway coordinator at 14 weeks, the specialty manager at 16 weeks, and the divisional director at 17 weeks. Each alert should include the patient details, current pathway status, the reason for delay, and the specific action required to prevent breach.
Create a real-time dashboard that shows incomplete pathway volumes by specialty, weeks-waited distribution, patients in each breach risk band, and the top reasons for pathway delays. This dashboard becomes the single source of truth for weekly PTL (Patient Tracking List) meetings, replacing static spreadsheet extracts that are out of date before the meeting begins.
When patients are referred between providers — for example, from a district general hospital to a tertiary centre — the RTT clock continues. Configure your system to track outbound referrals, confirm receipt by the receiving provider, and monitor onward pathway progression. This is one of the most common sources of RTT data loss and breach.
Schedule weekly automated validation runs that check for common data quality issues: pathways without a clock start date, pathways with implausible wait times, duplicate pathways for the same patient and condition, and pathways where the recorded status conflicts with activity data. Flag anomalies for manual review by the data quality team.
Beyond weekly PTL meetings, conduct a monthly strategic review that examines RTT performance trends by specialty, identifies systemic causes of breaches (capacity shortfalls, diagnostic bottlenecks, theatre availability), and tracks the effectiveness of improvement actions. Use this forum to make resource allocation decisions based on data rather than anecdote.
RTT tracking should drive daily clinical and operational decisions, not simply produce retrospective reports. The most effective Trusts embed pathway coordinators within specialty teams and use live data to inform clinic scheduling, theatre allocation, and diagnostic prioritisation.
Retrospective clock validation — cleaning data after the fact — is time-consuming and error-prone. Design your workflow so that clock events are validated at the point they occur, with mandatory fields and business rules that prevent incorrect entries from being saved.
Inconsistent outcome coding is a leading cause of RTT data errors. Provide clinicians with a simple, standardised set of outcome options at each appointment type, and ensure these map directly to RTT clock actions. Avoid free-text outcome fields wherever possible.
When breaches occur, investigate the root cause rather than simply recording the breach. Was it a capacity issue, a diagnostic delay, a data error, or a patient choice? Categorising breaches systematically reveals the structural issues that need addressing to prevent recurrence.
Clinicians who understand how their decisions affect the RTT clock — and why accurate recording matters — produce better data and make more pathway-aware decisions. Include clinical leads in pathway governance forums and provide specialty-specific RTT performance feedback.
e-RS, GP letters, inter-provider referrals, and internal referrals are captured with clock start dates.
Shows incomplete pathways by specialty, wait band distribution, and breach risk.
Lost referrals, delayed specialist appointments, and communication gaps between GPs and consultants are avoidable failures. Referral automation eliminates the manual handoffs where patients fall through the cracks.
healthcare operationsCQC inspections should not be a scramble to gather evidence. Organisations that embed compliance into their daily workflows are always inspection-ready — because meeting the standards is simply how they operate.
See how SwiftCase helps NHS Trusts and healthcare providers track every patient pathway in real time, escalate at-risk cases automatically, and meet the 18-week RTT standard consistently.
