One platform, not three separate tools.

Pooled, comparative prioritisation

All pending requests are assessed together, not one at a time, so the most clinically urgent patient is always seen first, regardless of when they joined the queue.

Priority ranking model (XGBoost)

Trained on the surgery's own confirmed patient orderings, not a generic dataset, so the model reflects how this specific surgery actually prioritises, and improves as more data accumulates.

No-show risk model

Trained on each patient's historical attendance pattern from EMIS/SystmOne, so staff get an early signal on attendance risk without waiting for the patient to simply not show up.

Rule-based scoring engine (day-one fallback)

A simple ranked list is available before any ML model has enough data to train, so the surgery is never left without a working priority list while the ML model is still learning.

Iterative CutOff sessions

The surgery can re-run prioritisation as new requests arrive, with full version history, so a wrong or outdated ranking can be rolled back to a previous version rather than being permanent.

Automatic periodic CutOff

A scheduled run (e.g. every weekday at 08:15) requires no manual action, so staff never have to remember to run the prioritisation themselves.

No-show risk shown as advisory band

Low/medium/high risk displayed next to each patient, not used to auto-decide, so staff get the extra information without the system silently overriding clinical judgement.

Model governance log

Every model version recorded with sample size, training loss, and active/inactive status, so any prioritisation decision can be traced back to exactly which model version produced it.

Minimum sample threshold

ML model only goes live once a configurable minimum sample size is met (default 50), so an undertrained, unreliable model never becomes the primary decision-maker in production.

Three-tier allocation model

Confirmed, tentative, and standby slot counts are defined separately per session, so the surgery controls exactly how much certainty vs. flexibility it offers across its capacity.

Tentative slot expiry policy

Defines when and how a conditional offer lapses, so no slot sits in limbo indefinitely; unclaimed capacity is reclaimed automatically.

"No slot opens" fallback rule

Defines what happens if a tentative patient never gets offered a slot: auto-confirm tomorrow, push to next session, or manual review, so ambiguous situations are handled by a rule the surgery already agreed to, not improvised on the day.

"Attends today" fallback rule

Defines what happens to a tentative patient's slot for tomorrow if they're seen today, so no unnecessary duplicate booking, or intentional retention, exactly as the surgery prefers.

Standby notification timing

Controls whether standby patients are notified immediately, within hours, or manually, so the surgery balances speed of fill against staff workload on its own terms.

Guaranteed confirmed slot for urgent patients

Urgent patients always receive a confirmed slot regardless of predicted no-show risk, so the system never lets a no-show prediction push a genuinely urgent patient into an uncertain slot.

Automatic upgrade for overdue patients

Patients who exceed their urgency window are automatically raised in priority, so a patient who has waited too long is caught by the system, not only by chance.

Flexible-patient preference for uncertain slots

Tentative and standby positions are offered first to patients who declared flexibility, so patients with rigid schedules aren't disproportionately exposed to uncertain slot positions.

Tiered alternative-slot counts

Highest-urgency patients get more alternative slot options offered (default 3) than lower-urgency patients (default 1), so urgent patients aren't left with a single take-it-or-leave-it option; low-priority requests don't overload the system with unnecessary choice.

Session compatibility mapping

Defines which request types are allowed into which session types, per surgery, so a request never gets matched to a clinically inappropriate session type.

Allocation window controls

Governs how many days ahead to search, how far an urgency window can be exceeded, and the flexibility window, so the system searches within realistic, surgery-approved bounds rather than an arbitrary range.

Overbooking ceiling

A management-set maximum overbook percentage per session type, so overbooking to offset no-show risk is possible, but can never exceed a safe, centrally agreed limit.

Full offer lifecycle tracking

Every offer's status (sent, delivered, read, accepted, declined, expired) is timestamped, so there is always a provable answer to "did the patient actually see this offer."

Immutable offer audit log

Every receipt event or status change is logged and cannot be altered afterwards, so the complete sequence of events can be shown in full for an NHS audit or a dispute.

Automatic fallback when receipts fail

If delivery/read receipts don't arrive, a scheduled check still activates standby, so a technical hiccup (e.g. a missed WhatsApp webhook) never leaves a slot stuck indefinitely.

Direct ITU routing bridge

Slot allocation and clinician/speciality routing decisions happen through the same pipeline, so slot allocation and clinician assignment aren't two disconnected systems guessing independently.

Structured, type-specific request flow

A short WhatsApp Flow adapts its questions to the request type (referral, fit note, letter, test results), so patients give exactly the information needed the first time; nothing has to be chased up afterwards.

eMED3-compliant fit note generation

Generated to the exact S39 field structure the NHS requires, so no manual reformatting or compliance risk before the document reaches the patient.

Four-column clinician decision screen

Pulls EMIS history and OC engine suggestions into one view alongside NFW/MFW status and key dates, so the clinician approves in seconds with everything already in front of them, instead of switching between systems.

Secure document delivery

A one-time link, opened only after WebAuthn/PassKey biometric verification, streams the PDF, so sensitive documents can't be intercepted or reopened later by someone else.

Independent per-service toggle

Referrals, fit notes, doctor's letters, and repeat prescription can each be switched on or off separately, so a surgery can adopt only the admin services it wants, at its own pace.

Doctor's Letter request flow

A dedicated structured request, with its own question set, decision screen, and secure delivery, separate from fit notes, so a letter request is never handled with the wrong template or the wrong clinical context.

Doctor's Letter direct question capability

The clinician can ask the patient a bespoke follow-up question mid-review, without leaving the decision screen; the answer writes straight to the EMIS clinical note, so the clinician isn't limited to what the patient originally wrote; they get exactly the extra detail they need before approving the letter.

Fit Note request flow

A dedicated structured request for fit notes, producing an eMED3-compliant document end to end, so fit notes follow their own compliant path rather than being forced through a generic document process.

Fit Note direct question capability

The clinician can ask the patient a bespoke follow-up question mid-review, without leaving the decision screen; the answer writes straight to the EMIS clinical note, so a fit note is never approved on incomplete information when a quick clarifying question would settle it.

Test Results request and retrieval

Patients can request and receive their test results through the same structured Admin flow, so patients get results through a channel they already use, without a separate portal login.

Direct EMIS/SystmOne integration

Notification triggers (results, reminders, alerts) are generated from live clinical system events, not a separate manual list, so reminders and alerts are always based on what's actually true in the clinical record, not a stale export.

Periodic / scheduled sends

Recurring notification batches (e.g. regular reminder cycles) can be scheduled rather than triggered one-off, so routine communication happens on autopilot, without staff manually starting each round.

Three-state delivery tracking

Every message is tracked as delivered, read, or failed, at the individual patient level, so staff know for certain whether a patient actually saw a reminder or result, not just that it was sent — something SMS and most NHS-focused competitors cannot report at all.

Interactive quick-reply buttons

Patient responses (confirm/cancel/reschedule) return as structured, machine-readable data, so a reply becomes usable data instantly; nobody has to read and interpret a text message by hand.

Unmatched message tracking

Any request that hasn't been picked up is visible as its own workflow risk metric, so nothing quietly falls through the cracks; staff can see exactly what's been sent but not actioned.

Auto-triggered clinical alerts

Appointment reminders, results, and clinical alerts fire automatically from underlying events, so no manual reminder process for staff to maintain.

Direct EMIS/SystmOne integration

Target patient groups for a campaign are pulled directly from clinical system data (e.g. all patients due a review), not a manually built list, so campaigns reach exactly the right patients based on real clinical criteria, with no manual list-building error risk.

Periodic / scheduled campaigns

A bulk send can be scheduled to repeat on a recurring basis (e.g. seasonal flu campaign every year), so recurring outreach doesn't need to be rebuilt and relaunched manually every time.

Message chaining

A sequence of related messages (e.g. reminder, follow-up nudge, final notice) can be linked as one chain rather than separate unrelated sends, so patients experience a coherent conversation instead of disconnected one-off messages, and staff can track where in the sequence a patient is.

Approved template messaging

Pre-approved message templates (e.g. flu jab invitations) sent to a segmented patient group in one action, so a campaign reaches the right patients without manual list-building each time.

Response-time SLA tracking

Percentage of requests responded to within one working day, against the NHS contractual standard, so the surgery has a live, auditable answer to "are we meeting our SLA," instead of finding out from a complaint.

Media attachments in templates

PDF, image, or video can be attached to an approved template message, so a single message can carry the full instruction, not just a link the patient has to follow elsewhere.

WhatsApp pricing-model compliance

Message dispatch respects WhatsApp's conversation-based pricing rules automatically, so no unexpected messaging costs or policy violations from manual bulk sends.

Structured medication and dose capture

A dedicated form collects exactly which medication and dose is being requested, so no ambiguity or back-and-forth about what's actually needed.

Automatic ready-for-collection notification

Patient is notified automatically once the prescription is ready, so patients don't need to call and ask; the surgery doesn't need to remember to tell them.

Pharmacy delivery preference

Patient's preferred collection or delivery pharmacy is captured as part of the request, so the prescription ends up where the patient actually wants it, first time.

Adaptive, personalised question flow

Each answer updates a live probability distribution over likely conditions (Bayesian engine), rather than following a fixed script, so patients answer only what's actually relevant to them, not a generic fixed form.

19 SNOMED CT-coded clinical entry points

Cough, fever, headache, chest pain, palpitations, and more, each with its own question set, so clinical coding is consistent and structured from the first patient answer, not added later by a human.

Independent red flag detection engine

Runs separately from the differential diagnosis, so an urgent symptom is caught even if it's not the leading probability, so a dangerous symptom is never missed just because it wasn't the statistically most likely explanation.

Urgency-tiered red flag display

Emergency-level triggers a full-screen warning with a 999 call button and no diagnosis list; urgent-level shows an amber warning with partial summary, so the patient sees exactly the right level of alarm and instruction for their actual situation, no more, no less.

Supplementary Questions

Surgery-specific extra question sets, ordered before or after the core consultation, drawn from a ready library or built from scratch, so each surgery can capture the extra detail that matters to them, without changing the core clinical engine.

Three-layer management model

Patient (WhatsApp), Surgery (practice portal), and App Management (WACure clinical team) each have distinct, separate control, so a receptionist can't accidentally change a clinical risk parameter; a surgery can still control what's shown to its own patients.

Editable question and option management

Surgery staff can add, edit, reorder, or deactivate questions for their own entry points, so a surgery wanting to add a locally relevant question doesn't wait on a developer.

Per-surgery red flag visibility setting

Controls whether a triggered red flag is shown to the patient directly or only to clinical staff, so surgeries that prefer not to alarm patients directly can still ensure the clinical team is alerted.

Manual clinician-triggered follow-up (Push OC)

Clinician can request more detail directly; the answer writes to the EMIS clinical note automatically, so the clinician isn't stuck with only the original answers if something needs clarifying.

Live Red Flag Monitor

Every triggered red flag appears in a live, timestamped, auditable feed, so clinical safety leads can confirm nothing urgent has been missed, from a single screen.

Integration with Appointment Service

A completed consultation can flow directly into slot booking, using the urgency and speciality it already determined, so the patient doesn't repeat themselves in a separate booking step; the urgency that was just established actually drives what slot they're offered.

Full context handed to the clinician

The clinician receives the ranked differential, urgency classification, and red flag reasoning together with the case, not just a raw transcript, so the clinician opens the case already knowing what the system found and why, instead of re-reading a wall of patient answers from scratch.

One-tap WhatsApp booking confirmation

Distinct button types for accepting a confirmed slot vs. keeping an existing tentative one, each with its own downstream logic, so the patient experience stays a single tap while the system handles the slot consequences correctly behind the scenes.

Attendance outcome recording

Attended, DNA, cancelled-by-patient, and cancelled-by-surgery are recorded per booking and feed the no-show model, so the no-show prediction gets more accurate for that surgery over time; it learns from what actually happens, not a static rule.

Configurable confirmation messages

Message content (date, time, clinician, surgery details) is drawn from a surgery-set template, so every practice keeps its own communication style without a developer changing anything.

Proxy booking support

A parent or carer can book on behalf of a linked patient, so booking for a child or dependent works the same way as booking for yourself.

Configurable reason, urgency, and availability lists

Appointment reason, declared urgency, and availability options are surgery-defined, not a fixed global list, so the options a patient sees actually match how that specific surgery organises its services.

Four-stage dispatch pipeline

Continuity check, red flag override, speciality auto-dispatch, then rule-based dispatch, evaluated strictly in order, so every case reaches the right person through a consistent, predictable process, not ad hoc judgement calls.

Continuity-of-care routing

If a patient already has an open task with a clinician at the surgery, new cases go to the same person, so patients don't have to repeat context to a different clinician each time.

DCB0129-assessed red flag override

Urgent cases route straight to the duty GP, architecturally guaranteed to be evaluated before any configurable rule, so a misconfigured practice rule can never suppress a genuinely urgent case, this is a structural safety guarantee, not a setting.

Speciality auto-dispatch

The system infers the right speciality from the case itself (e.g. back pain routes to MSK physiotherapy), so cases reach a relevant specialist automatically, without a member of staff manually triaging every request.

History-aware rule engine

Surgery-defined dispatch rules can include conditions like "more than 5 consultations in 30 days routes to duty GP.", so frequent attenders or complex cases can be automatically flagged for closer attention.

Rota-based resolution

Rules can resolve to a duty role (e.g. "GP") rather than a named person, using the day's rota, so routing keeps working correctly even as who's on duty changes day to day.

General inbox fallback

If no pipeline stage resolves an assignee, the case lands in a configured general inbox instead of being lost, so no case ever silently disappears due to a gap in configuration.

Resilient clinical system writes

If writing the task to EMIS/SystmOne fails, the system retries automatically (up to 3 times) and alerts on exhaustion, so a momentary integration hiccup doesn't lose a case; staff are alerted if it truly can't be filed.

38 production-ready reports across 10 categories

Covers all five NHS DSIC reporting epics (E00028 to E00032), so whatever an ICB or NHS audit asks for already exists as a report, not a data request that takes weeks.

WhatsApp delivery funnel on every messaging report

Sent, delivered, read, and failed tracked as standard axes, with time-to-read, so this level of delivery visibility isn't available on SMS or NHS App-based competitor platforms at the individual message level.

Patient-level data with IG suppression built in

Detailed rows are available where needed, with NHS Information Governance suppression rules applied automatically, so detail is there when required, but patient privacy is never exposed by accident.

Demographic and equality reporting

Age, sex, language, deprivation, and digital engagement, an area competitor dashboards don't cover, so the surgery and ICB can see who isn't engaging digitally, not just whether messages went out, directly relevant to NHS health inequality reporting.

Practice-level access without ICB login

Surgeries see their own data directly; PCN managers get a PCN-level rollup, so the people who run the surgery see their own numbers without waiting on someone else's dashboard permissions.

Response-time SLA reporting

Tracks percentage of requests responded to within the NHS one-working-day standard, so contractual compliance is visible and provable at any time, not just when questioned.

Template button response analytics

Structured tracking of how patients respond to interactive template buttons, so patient responses to clinical prompts become measurable, structured data instead of anecdote.

Practice-side relationship configuration

Proxy relationships are set up in EMIS/SystmOne itself, following the practice's own identity verification (per RCGP guidance); WACure reads the result via IM1, so wACure never becomes the weak link in who's allowed to act for whom; that governance stays exactly where the NHS already expects it.

Four-level escalating access model

L0 Public, L1 Routine, L2 Clinical, and L3 Proxy, each requiring a different authentication bar, so a low-stakes task and a request for someone else's test results are never protected by the same weak check.

NHS Login step-up for proxy specifically

Acting for another patient requires NHS Login verification, beyond the standard demographic check used for self-access, so the bar for acting on someone else's behalf is deliberately higher, matching the real-world risk.

Independent session, slot, and access-type tracking

Clinical purpose, slot purpose, and delivery channel (in person/phone/video/home visit) are tracked as three separate dimensions, so the calendar can represent real clinical scheduling accurately, instead of forcing every appointment into one generic type.

Automatic access-preference matching

A patient's declared preference (e.g. phone only) is matched automatically against available slots, so a patient is never offered an appointment format they specifically said they didn't want.

Recurring session templates

A session marked as a template generates recurring clinics automatically across a date range, so a practice sets up its regular weekly clinic once, not by hand every single week.

Granular calendar permissions

Read, Book, Edit Sessions, Admin, and Owner levels assignable per user, so a receptionist can book patients in without being able to change how a session template is configured.