Frequently asked questions.

All Pathways patient data is stored in AWS Sydney (ap-southeast-2). Patient information is not transferred outside Australia in storage, processing or backup. Data is encrypted in transit using TLS 1.2 or above and at rest with keys managed in AWS KMS.

Data sovereignty is a procurement gate for most Australian health services, so it is worth being precise about the boundary. The Australian region covers the full lifecycle: primary storage, processing during an assessment, and backups. There is no cross-region replication of patient information.

No. No personally identifying information is sent to model providers. Extraction and reasoning operate on de-identified clinical content, and patient information is never used to train models. The safety-critical screening rules are deterministic code rather than model output, so they do not involve a model provider at all.

This is two separate guarantees, and they are worth separating because they fail in different ways.

The first is about identity: the content that reaches a model provider is de-identified, so a model provider never receives a named patient record. The second is about training: patient information is not used to train models, by anyone, at any point.

Underneath both sits a design decision that removes the question for the parts that matter most. The rules that protect patients — the SGLT2 withholding check, the glycaemic control threshold, the OSA screen — are deterministic, versioned code. They are not a model output that happens to be reliable; they fire every time their conditions are met and cannot be argued out of 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.

Socrates Pre-Op is the Pathways voice agent that takes a structured anaesthetic history from a patient by phone. It is delivered as a secure, time-limited SMS link — no app, no login, no paper questionnaire — and covers 12 clinical domains conversationally, producing structured, severity-tagged findings that feed the risk engine directly.

It is a purpose-built anaesthetic variant rather than a generic intake bot. The distinction matters in practice: a general-purpose intake tool collects answers to the questions it was given, whereas an anaesthetic interview needs to follow up on a positive family history of anaesthetic problems, probe functional capacity when a patient says they are “fine”, and recognise when a described medication is worth photographing.

Completion is tracked, and a finished interview automatically triggers a fresh risk analysis.

How this compares with the two methods it usually replaces — paper questionnaires and telephone pre-assessment — including where each of those still wins.

Yes. The interview opens by identifying Pathways as an automated assistant working on behalf of your practice or hospital, and tells the patient that a clinician will review everything discussed. Patients can ask to speak to a person at any point rather than continue with the assessment.

Disclosure is not a compliance box here, it is what makes the answers usable. A patient who thinks they are filling in a form gives form-shaped answers; a patient who understands they are being interviewed, and that a clinician will read it, tends to volunteer the thing that matters — the stent nobody recorded, the sleep study that was never followed up.

Telling them a clinician reviews the result is also simply accurate. Pathways issues no orders and clears no patients; the summary is a draft until someone qualified signs it.

The Socrates Pre-Op interview covers 12 domains — surgical context, presenting symptoms, prior anaesthetics, systems review, functional capacity and frailty, airway assessment, medications and allergies, social and risk factors, implanted devices, pre-op investigations, a red-flag screen, and safety and shared decisions.

Every domain produces structured, severity-tagged findings rather than free text, which is what allows the risk engine to screen on them directly instead of re-parsing a narrative.

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.

Pathways has three tiers. Consultant is $125 per clinician per month excluding GST, or $1,250 a year billed annually, for anaesthetists running their own lists. Business and Enterprise are quoted per site or by procedure volume. There is no per-patient charge and no setup fee for a standalone deployment.

A solo anaesthetist and a public health service are buying different things — one is buying back the pre-operative phone call, the other is restructuring a pre-admission service. That is why only the Consultant tier carries a list price: it describes a single, well-defined unit of work. Above it, the price tracks the size of the pre-admission workload rather than a seat count.

For private settings the arithmetic that usually decides it is cancellation cost: a single prevented day-of-surgery cancellation typically covers several months of the platform.

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.

Yes. On the Consultant tier, paying annually gives you two months free — $1,250 per clinician per year instead of $1,500, excluding GST. That works out at $104 per clinician per month. Annual agreements are standard at Business and Enterprise.

The Business and Enterprise tiers are annual by default rather than by discount: they involve configuration, protocol design and clinician training, and a monthly commitment does not leave room to do that work properly.

Pathways is clinical decision support intended for use by qualified clinicians within Australian clinical governance frameworks. It is clinician-in-the-loop by design — it issues no automated orders, and every recommendation is reviewable and auditable. The treating clinician remains solely responsible for all clinical decisions.

The positioning is deliberate and is reflected in the architecture rather than only in the terms of service. Pathways produces risk flags with severity tiers, the evidence that triggered them, a guideline reference and a recommended action. It does not place orders, it does not clear patients, and it does not route anyone to theatre on its own authority.

Pathways screens each case with deterministic, versioned rules referenced to perioperative guidelines. Every flag carries a severity tier, the clinical rationale, the triggering evidence, the guideline reference and a recommended action, plus the rule version that produced it. The same inputs always produce the same flags, months later.

Screening covers the domains that drive perioperative outcomes: unstable cardiac symptoms, marked hypertension, diabetes control and SGLT2 management, obstructive sleep apnoea, frailty, malnutrition, functional capacity, smoking and discharge support.

Pathways also states what it does not know. Missing investigations and unconfirmed timings are listed explicitly on every profile, and extraction confidence is shown rather than hidden — a profile that is 86% confident about a patient-reported HbA1c says so.

Yes. Pathways keeps org-wide and per-patient audit logs with full workflow tracing on every risk analysis — the inputs used, the rule version that fired, the output produced, and the human who reviewed it, all timestamped. Logs are exportable for governance committees, M&M review and accreditation.

Because the safety-critical rules are deterministic and versioned, an audit is reproducible rather than merely archived: re-running a case against the rule version recorded at the time produces the same flags. That is the property that lets a decision made in March be examined in September without argument about whether the system “would have said something different”.

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.

The tracker shows exactly where they stopped — sent, opened, part-way through, or expired — and automated reminders go out without anyone chasing. A link can be resent in one click. Because the status is visible per patient rather than inferred from silence, an incomplete assessment becomes a task on a list instead of a discovery on the day of surgery.

Non-completion is normal and expected — it is why the tracker exists. The failure mode worth designing against is not the patient who does not finish, but the service that does not know they did not finish until the pre-admission clinic.

Patients who genuinely cannot complete a remote assessment are then a known, named group who can be routed to a phone call or a clinic slot deliberately, rather than turning up unassessed.

They are identified as a group rather than missed. The assessment needs only a phone that receives SMS and opens a link — no app, no login, no account. Patients who cannot complete it that way show as incomplete on the tracker, so the service can route them to a telephone assessment or a clinic slot deliberately instead of discovering the gap later.

The design point is that remote assessment does not have to work for every patient to be worth doing. It has to work for enough of them that the clinic’s finite capacity can be pointed at the ones it does not work for — which includes patients without a suitable phone, patients who need an interpreter, and patients who would simply rather come in.

What Pathways changes is that this group is visible in advance and small enough to plan around, instead of being indistinguishable from everyone else on the list.

Access is role-based. Booking staff, nurses and anaesthetists each see what their role requires and nothing more, and every view and action is written to the audit log. Access is scoped to your organisation — Pathways staff do not browse patient records, and there is no shared or cross-organisation view.

Two questions usually sit behind this one.

Internally, the answer is role-based access plus a complete audit trail. Who saw what, and when, is a recorded fact rather than an assumption, which is what allows the access model to be reviewed rather than merely asserted.

Externally, patient data does not leave your organisation’s scope. It is stored in AWS Sydney, it is not pooled across customers, and the content that reaches model providers is de-identified.

Most of a Socrates Pre-Op interview is conversational rather than form-filling, and patients complete it from home in their own time rather than in a clinic slot. It can be paused and resumed, and photographing medications happens during the conversation rather than as separate homework. Duration varies with how complex the patient's history is.

The comparison that matters is not against a stopwatch but against what it replaces: a paper questionnaire that arrives in the post and comes back incomplete, or a phone call at a time that suits the service rather than the patient.

Complexity drives length, which is the correct behaviour — a patient with a long medication list and several prior anaesthetics has more to cover than a healthy patient presenting for a day case, and a structured interview should spend the time where the information is.

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.

It says so, on the profile. Extraction confidence is shown rather than hidden, anything uncertain is flagged for human review, and missing investigations and unconfirmed timings are listed explicitly. A profile that has not been told about an outstanding echocardiogram is not presented as a clean profile — the gap is part of the output.

This is deliberate, and it is the property that separates a screening tool from a reassurance tool. A system that presents uncertain extractions with the same visual weight as verified ones is making a clinical judgement it has no standing to make.

So a patient-reported HbA1c appears with its confidence attached and “gap: recent HbA1c” recorded alongside it, rather than being silently promoted to a result. The clinician can then decide whether the gap matters for this patient and this procedure — which is the decision that was always theirs.

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.

It is yours and it is exportable. Org-wide and per-patient audit logs and assessment records can be exported for your own systems and record-keeping obligations. Retention follows the treating provider's obligations and applicable health records legislation, and the specifics are set out in your services agreement.

This matters more than it might appear, because assessment records form part of the clinical record. A platform that makes its data hard to retrieve is not a commercial inconvenience; it is a records-management problem for the provider that remains responsible for those patients.

Exportability is also the same capability the governance and accreditation requirements rely on, so it is exercised routinely rather than only on exit.