NDIS & Disability /Customer-service agent live field guide · 8 min

Reportable-Incident Signal Triage

Reads the daily progress-note flow, quotes the plain-language wording that looks like a possible reportable incident, rates its confidence, and routes it to your Approver against the 24-hour clock — flagging, never lodging.

Open the live demo

theater/demos/ndis_reportable-incident-signal-triage.html · sandbox · read-only

Open

FIG. 1

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 the day's progress notes against the six NDIS reportable categories, quotes the exact wording, rates its confidence, and routes a candidate to your Authorised Reportable Incidents Approver to assess and lodge.

Input 01

The day's note flow

Daily progress notes, night-shift logs and the F2 incident form your support workers write, plus enough of the participant support plan to attach the right person and place.

Agent 02

Scans, quotes, rates

Reads each note for the six reportable categories, quotes the exact text it relied on, extracts the structured fields, rates its confidence, and starts the 24-hour clock.

Output 03

A flagged candidate, for the Approver

A confidence-rated, quote-backed candidate in a ranked queue for your Authorised Reportable Incidents Approver to assess, edit or reassign — and lodge with the Commission. The tool never submits.

Where it works well

It reads every note, every day — so a reportable signal does not sit unseen because nobody had time.

A 100-participant provider can generate 600 to 800 progress notes, shift logs and incident forms a week — too many to read, easy to miss the one that matters.
Best for the quality and safeguarding lead and the incident manager at SIL or high-frequency community-supports providers, where notes are dense and the clock is short.
The recaptured capacity goes into assessing real candidates and tightening capture at the point of care, not skim-reading everything.

The slow, invisible failure is the note that should have been escalated and wasn't — a fall written into a night-shift log as a single sentence, lost in the week's flow because no one could read all of it.

Where it works badly

It can only flag what a worker wrote down — and a late flag against a 24-hour clock is close to useless.

It leans toward over-surfacing, so a near-miss or a participant "upset" about a late bus can land in the queue — a reviewer still has to clear the borderline ones.
If notes are batch-entered two days late, the signal surfaces late and the notification window may already be closing.
If half your serious events are buried in euphemism, fix the capture first — the tool reflects your notes, it does not improve them.

The honest test

Pull last month's notes: could a reasonable reader tell, from the words alone, that something reportable happened? If not, this surfaces late or not at all.

If a fall is logged as "M.T. settled well overnight" with no mention of the floor or the pain, there is no signal in the text and nothing to surface. The tool does not invent facts that never reached the page.

What it doesn't do — and shouldn't

It flags a candidate and quotes the wording. A person assesses and lodges. That boundary is deliberate.

WHAT IT DOES

Quotes the exact note text it flagged and names the likely reportable category

Extracts the fields — participant, when, where, injury, witnessed, action taken — each tagged to its source document

Rates classification confidence and starts the notification clock from awareness

WHAT IT WON’T

Decide that an incident meets the reportable threshold

Lodge a notification with the NDIS Commission

Present a provisional, unwitnessed cause as settled fact

A wrong "not reportable" call is a compliance breach and a safeguarding failure under the NDIS reportable-incidents regime; a notification carries serious weight for the participant and the worker named in it. The decision to notify the NDIS Quality and Safeguards Commission stays with an authorised person, because the consequence lands on them — not the tool.

What your data has to look like

Progress notes that name the event in plain language, entered the same day they happen.

Typical readiness

across orgs we see, before the first job

Progress notes and shift logs as live text

Needs shaping

Notes that name the event plainly

Usual weak point

The F2-style internal incident form

Usual weak point

Enough of the support plan to attach person and place

Usually ready

A wired feed from your client-management system

Needs shaping

The real first job

The real first job is capture: how incidents get written at the point of care — a tighter note template, a prompt that asks the worker to state plainly what happened, and same-day entry. That work is usually bigger and more valuable than the AI layer on top, and it is the part RMAI actually helps with — the tool is only as good as what reaches the page.

Right fit if…

You run SIL or high-frequency community supports with dense daily notes

Your notes are wired to a client-management system you can read live

Your workers name the event plainly — a fall as a fall, an injury as an injury

A named Authorised Reportable Incidents Approver owns the assess-and-lodge call

Walk away if…

Half your serious events are buried in euphemism or recorded a day late

Notes are batch-entered weekly, so a flag would always land late

You want a tool that decides reportability or lodges for you

Your incident capture is the real gap and you would rather skip fixing it

Open questions

The worried-buyer questions, answered straight

It never makes the reportable/not-reportable call — it flags candidates and your Authorised Reportable Incidents Approver decides. The risk it manages is the false negative: a note that should have been escalated and wasn’t, so it leans toward over-surfacing. You will see borderline notes that turn out to be nothing, and that is deliberate. Every flag carries the exact quoted text and a confidence rating so a reviewer can dismiss a weak one in seconds.

Partly — and that gap is usually the first thing worth fixing. The tool can only flag what a worker actually wrote: if a fall is recorded as “settled for the night” with no mention of the floor, there is no signal to catch. It lifts the notes that do contain a signal but never invents facts that didn’t reach the page. The bigger win is usually tightening how incidents get captured at the point of care, not the AI layer on top.

It replaces neither. It does the reading — working through 600 to 800 notes a week so a signal does not sit unseen — and hands the judgement to your people. Whether an event meets the threshold under the NDIS reportable-incidents rules, and the decision to lodge with the NDIS Commission, stays entirely with your Approver. The tool gives them time and the exact wording to assess; it does not assess.

It needs to read notes within the same day they are written, because the NDIS notification clock runs from when your key personnel become aware. If notes are batch-entered two days later, the tool surfaces the signal late and the 24-hour window may already be closing. It works best wired to the live note flow in your client-management system, not a weekly export.

The notes are processed to produce a flag and a quote, and the queue stays inside your environment — your Microsoft 365 and review tool, not a public service. Participant data is sensitive personal information under the Privacy Act and the NDIS Code of Conduct; the demo participant (“M.T.”) is de-identified and fabricated. We scope data handling, retention and access with you before anything reads a real note.

It marks the classification provisional and says so plainly. An unwitnessed fall is flagged as a likely serious-injury candidate pending clinical and management assessment — it is never presented as a settled cause. The Approver sees the quoted text, the “not witnessed” field, and a caution beat before deciding whether and how to notify the Commission.

What it takes to build

3–4 weeks · 4 phases

Reused from template~70%

Bespoke to this skin~30%

stack · Claude · Airtable/Retool review queue · Microsoft 365

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

Embedded support

Scale on proof

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. The incident-capture work usually comes first.

Book a call How we work