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.
It surfaces the note that reads like a reportable incident and puts it in front of a person while there is still time to assess and lodge it.
Where this works well
The slow, invisible problem this surfaces is the signal that never gets escalated because nobody had time to read every note. A 100-participant provider can generate 600 to 800 progress notes, shift logs and incident forms a week. The reportable ones — a death, a serious injury, abuse or neglect, unlawful sexual or physical contact, sexual misconduct, an unauthorised restrictive practice — do not always arrive labelled "reportable". They arrive as a sentence in a night-shift log: "found M.T. on the bedroom floor, unable to stand, complaining of pain in the right hip". A human reading all 800 notes might catch it. A human reading the few that got flagged by hand will miss some.
This earns its keep for the quality and safeguarding lead, and the incident manager, at any provider running supported independent living or high-frequency community supports — the settings where notes are dense and incidents are time-critical. It reads the full flow, quotes the exact wording that looks reportable, rates how confident it is, and puts that in front of a person while the 24-hour notification window from when key personnel become aware is still open. The value is recaptured attention: your reviewers spend their time assessing real candidates instead of skim-reading everything.
Where it works badly
It is only as good as what the support worker wrote. 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 cannot catch an incident that never reached the page. It will also produce false positives: a note describing a near-miss, or a participant who was "upset" about a late bus, can read like a candidate and land in the queue. That is by design — it leans toward over-surfacing — but it means a reviewer still has to clear the borderline ones.
The honest test: pull last month's notes and ask whether a reasonable reader could tell, from the words alone, that something reportable happened. If your incidents are consistently written so the event is visible in the text, this will lift them reliably. If half your serious events are buried in euphemism or recorded a day late, fix the capture first — the tool will surface late or not at all, and a late flag against a 24-hour clock is close to useless.
What it doesn't do — and shouldn't
It does not decide that an incident is reportable, and it does not lodge anything with the NDIS Commission. It surfaces a candidate, quotes the text it relied on, rates its confidence, names which of the six categories it might fall under, and routes it to your Authorised Reportable Incidents Approver. The judgement — does this meet the threshold under the NDIS reportable-incidents rules, and do we notify — stays with that person, and the submission through the Commission Portal stays with them too.
That boundary is deliberate and it matters here more than almost anywhere. A wrong "not reportable" call is a compliance breach and a safeguarding failure; a notification carries serious weight for the participant and the worker named in it. Those are human calls with legal and ethical consequence, made by an authorised person who can read the full context. The tool buys that person time and the exact wording to assess. It does not assess, and it does not submit on its own — the demo shows the escalation banner saying exactly that.
What your data has to look like for this to work
It reads three things: the daily progress notes and shift logs your support workers write, the incident forms (the F2-style internal report) they complete, and enough of the participant's support plan to attach the right person and place. For the flag to be trustworthy, those notes have to describe what actually happened in plain language — an injury named as an injury, a fall named as a fall, a restrictive practice named as one — and they have to be entered the same day, because the notification clock runs from awareness, not from the next weekly sync.
Most providers have only some of this in good shape. Notes exist, but the quality swings by worker and shift, and timeliness is patchy. That is the real first job, and it is usually a matter of how incidents get captured at the point of care — a tighter note template, a prompt that asks the worker to state what happened plainly — not a new piece of software. That capture work is the part RMAI actually helps with, and on most engagements it is bigger and more valuable than the AI layer sitting on top of it.
Could this push us to report something that isn't actually reportable — or worse, tell us something is fine when it isn't?
It never makes the reportable/not-reportable call — it flags candidates and a person decides. The real risk it manages is the false negative: a note that should have been escalated and wasn't. It is tuned to over-surface rather than under-surface, so your Approver 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 the reviewer can dismiss a weak one in seconds.
Our progress notes are inconsistent and some support workers barely write a sentence. Will this still work?
Partly, and honestly that gap is usually the first thing worth fixing. The tool can only flag what a worker actually wrote down — 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 it does not invent facts that never reached the page. We often find the bigger win is tightening how incidents get captured at the point of care, not the AI layer on top.
Does this replace our incident manager or our Authorised Reportable Incidents Approver?
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 rules, and the decision to lodge with the Commission, stays entirely with your Approver. The tool gives them time and the exact wording to assess; it does not assess.
How current does the data need to be for the 24-hour clock to mean anything?
It needs to read notes within the same day they are written, because the 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 window may already be closing. It works best wired to the live note flow in your client-management system, not a weekly export.
Where does our participant data go, and who can see it?
The notes are processed to produce a flag and a quote, and the queue stays inside your environment — Microsoft 365 and your review tool — not a public service. Participants in the demo are de-identified ("M.T.") and the same applies in practice: it reads what is needed to triage and routes it only to the people authorised to handle reportable incidents. We scope data handling, retention and access with you before anything reads a real note.
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.