Healthcare & Disability/Document Generation interactive demofield guide · 9 min
No-Show Predictor
Scores each upcoming appointment for no-show risk from attendance history, SMS response and visit gaps, and flags the high-risk slots with the factors behind each — so the recall officer decides who to call before the slot is lost.
The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.
How it would work
Reads tomorrow's appointment book and each patient's attendance history, ranks every slot by no-show risk with the factors that drove the score, and surfaces the high-risk list for a receptionist to confirm before anyone is called.
Input01
Tomorrow's book + attendance history
The next day's appointment list from the practice software, plus each patient's prior attendance — visits, DNAs, cancellations, last-visit gap, and whether they responded to the SMS reminder.
Agent02
Scores and ranks the slots
Scores each appointment 0–100 from history and timing signals, sorts the book by risk, and tags the drivers — "missed last 2", "no SMS reply", "long commute" — so the score is never a bare number.
Output03
A ranked list, for a person to action
The flagged high-risk slots with their drivers, for the receptionist or recall officer to review and decide who to call, text, or offer to the waitlist. The tool ranks; the person decides and acts.
Where it works well
It reads the whole book the same way every morning — something no one has time to do by hand.
Best for a busy receptionist or recall officer triaging a full book — it turns "who do I call?" into a ranked shortlist with reasons attached.
Most useful at 50+ appointments a day with a 10%+ DNA rate, especially bulk-billing books where a DNA earns no Medicare rebate and can't be charged to the patient — a complete write-off.
The recaptured time goes into the calls that actually save a slot, not into scrolling the book deciding where to start.
The risk signals are already sitting in the practice software — two prior DNAs, no reply to yesterday's SMS, a four-month gap since the last visit — but no one scrolls the whole next-day book cross-referencing histories before the phones start. The pattern is visible; the time to look isn't.
Where it works badly
It ranks risk from the past — and the past is biased, thin, and not the same as a decision.
The signals encode who has had a rough run — casual work, no car, an unstable phone number, a long commute from a low-income postcode. A no-show score can quietly track disadvantage, and a confident-looking percentage hides that.
A thin history (new patient, recently merged records) gives a low-confidence score that looks identical to a well-evidenced one. It should say "not enough history", not guess.
It ranks who to *contact first* — it must never feed a "fire this patient" or "make them prepay" decision. Penalising a patient for a prediction is a clinical-access and equity call no model should make.
The honest test
If you would not be comfortable reading the reason for a patient's score back to them on the phone, that score should not be driving how you treat them.
A risk score is a base-rate guess, not a verdict. Patients with two prior DNAs do miss more often — but most flagged patients will still turn up, and a clean record is no guarantee. Treat the number as truth and you punish people for a probability.
What it doesn't do — and shouldn't
It ranks and explains. A person calls, decides, and never penalises on the score alone.
WHAT IT DOES
Ranks the next-day book by no-show risk
Shows the drivers behind each score (prior DNAs, no SMS reply, visit gap)
Flags the slots worth a confirmation call or a waitlist offer
WHAT IT WON’T
Call, text, or contact anyone itself
Decide to charge a fee, refuse a booking, or discharge a patient
Claim a flagged patient *will* miss — it states a probability
Decisions that ration access — a DNA fee, a "prepay or we won't book you", a discharge — affect a patient's care and sit under AHPRA and Medical Board conduct expectations, the practice's duty of care, and the practice's own DNA policy. A probability is not grounds to act against a patient. The accountable person stays on the decision because the consequence lands on the patient, not the tool.
What your data has to look like
Clean attendance history and a reliable feed from the practice software — most books have neither well.
Typical readiness
across orgs we see, before the first job
Attendance history per patient
Needs shaping
A live feed of tomorrow's book
Usual weak point
SMS reminder responses captured back
Usual weak point
A current contact number and last-visit date
Usual weak point
The practice's own DNA / recall policy, written down
Needs shaping
The real first job
The score is only as honest as the attendance data behind it, and in most practices DNAs are recorded inconsistently — sometimes a status, sometimes a note, sometimes nothing. Fixing how attendance and SMS responses are captured is usually the real first job — larger and more valuable than the scoring layer on top. A model fed thin or biased history just launders that bias into a confident number.
Right fit if…
You run a busy book — 50+ appointments a day — with a measurable DNA problem
A bulk-billing practice where every DNA is a full revenue write-off
You record attendance (visits, DNAs, cancellations) consistently in the practice software
You have a written recall / DNA policy a person applies to each flag
Walk away if…
You'd use the score to charge fees, refuse bookings, or discharge patients
Your DNA records are patchy free-text nobody could train a fair model on
Most of your patients are new, with no attendance history to score
You want a tool that decides who to drop, not one that ranks who to call
Open questions
The worried-buyer questions, answered straight
It can flag a patient who would have attended — a risk score is a probability, and most flagged patients still turn up. That’s exactly why it only ranks who to *contact first*; it never decides a fee, a refusal, or a discharge. A receptionist makes the call and the practice applies its own DNA policy. Acting against a patient on the score alone would be unfair and sits against AHPRA conduct expectations and the practice’s duty of care.
Only as well as those records. If a DNA is sometimes a status, sometimes a note, sometimes nothing, the model learns from gaps and gives confident scores built on thin evidence — it can’t tell a clean record from an unrecorded one. Getting attendance, cancellations and SMS responses captured as consistent fields in your practice software (Best Practice, Medical Director and the like) is the first piece of work, and it pays off across every morning after.
No. It removes the scrolling — the cross-referencing of every booking against its history — and hands back a ranked shortlist with reasons. The receptionist still makes the calls, reads the room, and decides who to reschedule, who to reassure, and who to offer the waitlist. The capacity it frees goes into the conversations that actually save a slot, not into deciding where to start.
Current to today’s book. The score has to read tomorrow’s actual schedule and each patient’s latest attendance — a yesterday’s export misses the overnight cancellations and new bookings, and a stale phone number breaks the “unreachable” signal. The honest test: does the score reflect the book as it stands this morning, or a snapshot from last week?
Attendance history, contact details and appointment data are health information — “sensitive information” under the Privacy Act 1988 and the Australian Privacy Principles, enforced by the OAIC. Any deployment runs against your own practice systems and data handling, not a shared pool — we scope where the data sits and who can see it as part of the build. The demo here runs entirely on fabricated data; James Chen is not a real patient.
It can, and that’s the honest risk. The signals that predict a DNA — casual work, no car, an unstable phone, a long commute from a low-income postcode — track disadvantage, so a score can quietly rank by hardship rather than intent. That is precisely why the tool only prioritises a friendly confirmation call and never a penalty: more contact for a higher-risk patient should mean more support, not less access.
What it takes to build
3–4weeks · 4 phases
Reused from template~70%
Bespoke to this skin~30%
stack · Claude · practice-software connector · scoring model · review list
What it would cost
Fixed scope, fixed price, fixed dates.
01
Bite-sized first piece
One contained change, low risk
02
Pilot build
Most builds land here
03
Embedded support
Scale on proof
Considering this for your practice?
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.
We use cookies and tracking technologies — including Meta Pixel and Meta Conversions API for advertising measurement, and Google Analytics for site usage — to understand how you interact with this site and to measure the performance of our advertising. You can accept all, deny all, or manage your preferences below. See our Privacy Policy for details.
Functional
Always active
Required for the site to work — secure browsing, session continuity, the shopping cart, and remembering your preferences. Cannot be disabled.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
Aggregate analytics about how visitors use the site, used to improve content and navigation. No personal advertising profile is built from this data.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
Used to deliver and measure the performance of our advertising. We use Meta Pixel and Meta Conversions API to attribute course signups and contact submissions to specific Meta ads, so we can manage spend efficiently. Personal data sent to Meta is hashed and limited to what is needed for measurement.
We use cookies and tracking technologies — including Meta Pixel and Meta Conversions API for advertising measurement, and Google Analytics for site usage — to understand how you interact with this site and to measure the performance of our advertising. You can accept all, deny all, or manage your preferences below. See our Privacy Policy for details.
Functional
Always active
Required for the site to work — secure browsing, session continuity, the shopping cart, and remembering your preferences. Cannot be disabled.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
Aggregate analytics about how visitors use the site, used to improve content and navigation. No personal advertising profile is built from this data.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
Used to deliver and measure the performance of our advertising. We use Meta Pixel and Meta Conversions API to attribute course signups and contact submissions to specific Meta ads, so we can manage spend efficiently. Personal data sent to Meta is hashed and limited to what is needed for measurement.