What data sovereignty actually requires

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.

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.

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.

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”.

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.