Every cancelled case is a cost you can see. Now prevent it.

Pathways screens every patient at the moment of booking rather than at the pre-admission clinic, so the findings that cause cancellations — unwithheld SGLT2 inhibitors, poor glycaemic control, undiagnosed sleep apnoea, missing discharge support — surface weeks ahead, while the list can still be optimised, rescheduled or backfilled.

The lever is timing rather than thoroughness. In almost every cancelled case the determining fact existed weeks earlier; it simply had not reached the anaesthetist while there was still time to act on it.

That also means the screening has to cover every booked patient, not the ones who look complex on paper. The patients who cancel lists are by definition the ones whose risk was not visible in advance.

No. Pathways runs standalone from day one. The SMS-driven workflow needs no patient management or EMR integration to start, so a service can screen its next elective list without an IT project, an interface engine, or a change window. Integration is available later but is not a precondition.

This is usually the difference between a deployment measured in days and one measured in quarters. Most of the value — screening every booked patient early enough to act — does not depend on a bidirectional interface, so requiring one up front only delays the point at which the first cancellation is prevented.

When you do want it, integration is HL7 or FHIR against your patient administration and EMR systems: automated list ingestion from theatre scheduling in one direction, and write-back of the signed pre-operative summary to the patient record in the other. That is an Enterprise capability, available on Business, and it is scoped after the standalone deployment is running rather than before it.

Days rather than quarters. Because Pathways runs standalone over SMS with no PMS or EMR integration required, a service can begin sending assessments on its next elective list. There is nothing for patients to install and no software to deploy on hospital workstations — the platform runs in a browser.

Per site or by procedure volume, so the figure tracks the size of your pre-admission workload rather than a seat count. A short scoping conversation about your lists produces a fixed annual figure. Business is an annual agreement, invoiced yearly in advance.

Seat-count pricing does not describe this workload well. A pre-admission service might have three anaesthetists and eleven nurses, or the reverse, and the number of people who log in says very little about how many patients are being assessed. Volume does.

It also means adding a coordinator to the roster does not change what you pay, which removes a small but real disincentive to putting the right people in front of the queue.

They proceed. Every completed profile carries a triage recommendation — anaesthetist review, pre-admission clinic, telephone review, or no further assessment — so clinic slots go to moderate-risk patients and anaesthetist time goes to red flags. Low-risk patients are not routed into a clinic appointment they do not need.

This is the throughput argument, and it runs in both directions. A pre-admission clinic booked out three weeks ahead with mostly healthy ASA 1 patients is not short of capacity so much as misallocating it. Screening every patient at booking makes the queue orderable by risk rather than by whoever called first.

No. Patients receive a signed, time-limited SMS link and complete the assessment in their phone's browser. There is no app, no login and no password. Links expire, and expired links are visibly dead rather than silently reusable.

Links are signed with HMAC-SHA256 and time-limited. The visible-expiry behaviour matters more than it sounds: a link that silently still works is a data exposure, and a link that fails with no explanation generates a phone call to the practice.

No. It decides who should be in it. Every completed profile carries a triage recommendation — anaesthetist review, pre-admission clinic, telephone review, or no further assessment — so clinic slots go to the patients who need them. The clinic keeps doing the same work, for a different and better-chosen set of patients.

Most pre-admission clinics are not short of clinical capability. They are short of a mechanism for allocating their capacity, so slots fill in the order bookings arrive — producing a clinic of largely well patients while a frail patient with poor functional capacity gets a short phone call.

Screening every booked patient early makes the queue orderable by risk. The clinic’s capacity does not change; what changes is who is in it.

Yes, and it is the usual way to start. Because Pathways runs standalone over SMS with no integration required, a pilot can be a single upcoming list or a single surgeon's patients rather than a whole-of-service programme. That makes the question answerable in weeks with real patients instead of in a demo environment.

The reason a narrow pilot works here is the absence of an integration project. Where a platform needs an interface built before it can do anything, a pilot carries most of the cost of a full deployment, so services quite reasonably resist starting one.

A list-level pilot also produces the number that actually decides the purchase: what the screening found on real patients, early enough to act on, and what would otherwise have surfaced on the morning of surgery.