Patient-Message Triage Copilot
Sorts the patient inbox before it reaches a clinician — classifies each portal or email message, scores urgency, routes it to the right queue, and drafts a holding reply for staff to approve, while escalating anything that reads clinically urgent instead of answering it.
It reads each inbound message against your triage policy, proposes an intent / urgency / route, and drafts a grounded holding reply — then a person approves, edits, reassigns, or escalates before anything is sent.
Where this works well
The slow, invisible problem this makes visible is the undifferentiated inbox. Portal messages and emails arrive in the order they were sent, not the order they matter, and someone has to open every one to find the two that are urgent. The cost isn't the urgent message — it's the forty routine ones a clinician reads to find it. This pattern earns its keep when message volume is high enough that sorting is itself a job: a multi-GP practice, an aged-care service fielding family enquiries, anywhere a person currently triages the queue by opening each item.
It works best where you already have a written triage policy and a routing map — who handles repeat scripts, referrals, billing, records changes — and where the patient record it matches against is reliable. Given those, it does the reading and the first sort, surfacing intent, urgency, route, and a grounded holding reply, so reception and triage nurses spend their attention on the messages that need a human and on patient contact, not on the act of sorting.
Where it works badly
It works badly where the inbox isn't really an inbox. If patients phone instead of message, or if "messages" are scanned PDFs and faxes with no machine-readable text, there is nothing for it to classify well. It also degrades where your practice records are out of date: if it reports "active patient, matched — last script 6 weeks ago" and that record is stale, you get a confident classification built on a wrong fact, which is more dangerous than no classification at all.
The honest failure mode to watch for is a message that needs a clarifying question, not a routing decision. "I'm not feeling right since the new tablets" isn't a repeat-script request or a billing query — it needs a person to ask what "not right" means. The tool will flag it as a concern and escalate, which is correct, but if you were hoping it would resolve those, it won't. The test to apply to yourself: count last week's inbox and ask how many messages a competent receptionist could route in under ten seconds. If most need a back-and-forth with the patient, the sort isn't your bottleneck and this won't pay back yet.
What it doesn't do — and shouldn't
It surfaces a proposed classification, route, urgency, and a holding reply. It does not decide clinical urgency, send a clinical answer, approve a repeat script, or make a triage call that binds a patient's care. Those are human decisions and the boundary is deliberate. Under the RACGP Standards for general practices (5th edition, Criterion GP1.1), a person must triage urgency for same-day care and retain evidence of it; under AHPRA's standards the treating practitioner stays clinically responsible for the patient. The tool exists to get the right message in front of the right person faster — not to be the person.
The hardest line is the clinical-concern message. When it detects symptoms reported alongside a request, it is built to hold, not to help: no auto-reply, an escalation banner, and a same-day review prompt. That restraint is the point. A tool that confidently reassured Margaret her dizziness was nothing while it sent her repeat script would be worse than no tool. We accelerate the sorting; a clinician keeps the diagnosis.
What your data has to look like for this to work
Three things have to be in good shape, and most practices have only one or two of them. First, the messages need to be text the system can read — portal messages and email bodies, not images of letters. Second, the patient record it matches against has to be current and de-duplicated: an active-patient match, a current medication list, the date of the last script. If "last script 6 weeks ago" is wrong, every downstream judgement is wrong. Third, and most often missing, you need a written triage and routing policy specific enough to classify against — what counts as same-day, which clinical signals must escalate, who owns each queue — with clauses concrete enough to cite (the demo grounds its concern flag in "Triage Policy §3.2").
That third item is usually the real first job, and it is rarely about buying software. It is about writing down the triage rules your senior reception staff already carry in their heads, and getting the patient and medication records clean enough to trust. That is the work we help with, and on most engagements it is larger and more valuable than the AI layer that sits on top of it.
Could it give a patient bad advice, or tell someone a symptom is fine when it isn't?
It never gives medical advice and it never auto-answers a message with a clinical signal in it. When it detects symptoms reported alongside a request — like dizziness and headaches next to a repeat-script request — it holds the message, suppresses any reply, and raises an escalation banner for a same-day GP or nurse review. The only thing it drafts in those cases is a neutral holding reply ("a nurse will call you today") that a person reads and approves before it goes out. The safeguard is structural: a clinical concern routes to a human, it does not route to an answer.
Our patient messages are messy — wrong patient, half a sentence, three questions in one email. Does that break it?
Short, mixed, or ambiguous messages are normal and it is built to flag rather than guess. A message it can't match to an active patient record, or can't classify above your confidence threshold, is routed to a human queue rather than auto-handled. It will surface a confidence score (e.g. 91%) so reception can see when it is sure and when it isn't. What it can't fix is a message that genuinely needs a clarifying question back to the patient — that is a human reply, and it will route it as one.
Does this replace our reception or triage nurse?
No. It does the sorting — reading, classifying, routing, drafting — so your reception and triage staff spend their time on the messages that actually need judgement and on patient contact, not on opening every email to work out where it goes. Under the RACGP Standards a person still triages urgency and a clinician stays responsible for clinical decisions. The recaptured time goes back into care and into the queue that matters, not into a smaller roster.
How current does the patient and medication data need to be?
Current enough that the record it matches against is right today. If it tells a clinician "last script 6 weeks ago" or "active patient, matched", that is only safe if your practice records and medication history are up to date in the system it reads. Stale data is the main failure mode: a patient who changed medication last week, or merged duplicate records, will produce a confident-but-wrong classification. It reads your live practice system, so the freshness is whatever your front desk maintains.
Where does the patient data go — does it leave our practice or train an AI model?
It runs against your own systems (your patient records and Microsoft 365 mailbox) and the message content is sent to the language model only to classify and draft, not to train it. Health information is regulated under the Privacy Act 1988 and the Australian Privacy Principles, so before any deployment we map exactly what data is sent where, what is logged, and what is retained — and that boundary is set with your practice, not assumed. If your records are in My Health Record, the My Health Records Act 2012 applies to that source as well.
How do we know why it routed something the way it did?
Every classification cites its source — the message itself, your practice records, your triage rules, or a named clause of your triage policy (e.g. Triage Policy §3.2). The route, the urgency, the detected signals, and the holding reply are all visible and attributed before a person approves them. That audit trail is what lets a nurse or GP trust the sort without re-reading every raw message from scratch.
Estimated build: 3 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.