SIRS Incident Triage Assistant
Reads each incident note against the eight reportable-incident categories, surfaces the likely category, priority and notification deadline, and drafts the notice for a clinician to approve — so a night-shift under-call doesn't quietly blow the 24-hour window.
It reads the incident report — handwritten or typed — against the SIRS reportability criteria, flags what's missing, and drafts a Priority 1 notice your Quality Manager signs off.
Where this works well
The slow, invisible problem this makes visible is the under-call: a 2am note written by a tired PCA, logged as "both settled, review with RN in the morning," that is in fact an unreasonable-use-of-force incident with an unauthorised chemical restraint — a Priority 1 that has to reach the Aged Care Quality and Safety Commission within 24 hours of any staff member becoming aware. The clock is already running while the report sits in a queue waiting for someone to read it properly.
It earns its keep where incident volume is high enough that reports bank up overnight and over weekends, and where reporting still depends on whichever RN or Quality Manager next gets to the pile. It is most useful to the clinical governance lead or Quality Manager in a residential facility who is accountable for the 24-hour and 30-day windows but can't personally read every incident note the moment it's written. It reads the free-text — including handwritten scans — tests it against the eight reportable-incident categories, and surfaces the likely category, priority and hours-left so the reportable ones rise to the top instead of waiting their turn.
Where it works badly
It is only as good as what made it into the report. If the night note says "resident had a fall" and omits that another resident pushed them, the tool reads what's on the page — it will triage it as a fall, not a use-of-force incident, because the use-of-force fact was never written down. It surfaces under-documentation; it can't recover a fact nobody recorded. If your real problem is that staff aren't writing down what happened, the triage layer is premature — the documentation work comes first.
It will also be confidently wrong at the edges of legibility and abbreviation: a smudged drug name, an unusual local shorthand, a dose written ambiguously. And it cannot adjudicate the genuinely borderline calls — whether a particular bruise crossed the "injury requiring treatment" line, whether a one-off raised voice was "psychological abuse" — those are clinical judgements, and it should only ever hand them to a clinician with the evidence laid out, never resolve them. The honest test: if your incident reports already capture what happened clearly and consistently, this saves you real time; if they don't, fix the reports first.
What it doesn't do — and shouldn't
It does not decide reportability and it does not lodge anything. It drafts. The line is deliberate: under the Serious Incident Response Scheme the provider is accountable for the notification, and that accountability cannot sit with a model. So the tool surfaces the category, the triggered criteria and the deadline, drafts the ACQSC notice, and stops — your Quality Manager approves, edits, or sends it back to the RN to confirm.
That boundary matters most exactly where the tool is most useful: the high-consequence Priority 1 call. A drafted notice that goes out unread is worse than no tool at all, because it launders an unchecked judgement into an official notification. The drafting saves the reviewer the blank-page time and the deadline arithmetic; the decision to lodge stays a human act, on the record, with a name against it.
What your data has to look like for this to work
The thing most providers underestimate is how much rides on the incident report itself. For this to be worth anything, the free-text has to actually describe what happened — who was involved, the mechanism (a fall versus a push), the injury and whether treatment was given, and any medication administered with its dose and time. The Banksia example only works because the note recorded the PRN lorazepam 0.5mg at 02:30; strip that line and the chemical-restraint flag never fires.
The high-value adjacency is the records the tool checks against: a current behaviour support plan and restrictive-practice authorisation it can read at triage time, so a "consent not on file" gap is real rather than a stale-data false alarm. Most facilities have these somewhere but not consistently legible, not consistently linked to the resident, and not consistently current. Getting incident notes to reliably distinguish a mechanism from an outcome, and getting plan and consent records into a form the triage step can actually read, is usually the bigger and more valuable piece of work — and it's mostly about how information is captured at the point of care, not about buying a tool. That's the part we help with first.
What stops it from telling us something is reportable when it isn't — or worse, waving through something that is?
It never lodges anything. Every assessment lands in front of a clinician with the SIRS category, the criteria it triggered, and the wording from the report that triggered them — so you can see why it made the call before you approve, edit, or send it back. The confidence figure and the line-by-line criteria table are there precisely so a borderline case gets a human read, not an auto-decision. A wrong flag costs you a few minutes of review; a missed Priority 1 costs you a breach, which is the failure mode it's built to catch.
Our night staff write incident reports by hand, and the handwriting is rough. Does that break it?
Handwritten and scanned reports are the main thing it's built for — the demo runs on a handwritten night-shift note. It will still misread a smudged word or an unusual abbreviation, which is exactly why the extracted facts are shown back against the original report for the reviewer to check. If a report is so illegible that key facts can't be read, it flags that rather than guessing — an unreadable field is surfaced as missing, not invented.
Does this replace our Quality Manager or clinical governance lead making the reportability decision?
No. The reportability decision under the Serious Incident Response Scheme stays with your Quality Manager. The tool does the reading and the first-pass triage so that decision is made on a complete, deadline-aware draft instead of a 2am note that got logged as routine. It recaptures the time your clinical lead spends hunting through reports, and redirects it to the judgement call that has to stay human.
How current does the data have to be — does it know if a behaviour support plan was updated yesterday?
It is only as current as the records it can read at the moment of triage. If it checks a resident's behaviour support plan or restrictive-practice authorisation, it reads whatever your clinical system holds then; a consent form signed and filed an hour ago but not yet in the system won't be seen. That's why a flagged consent gap is raised for the reviewer to confirm against the live record, not treated as settled.
Where does the resident's data go — is it sent off to some external AI service?
That's a deployment decision made with you, not a default. Incident reports contain identifiable resident health information, so the build is scoped around where that data is allowed to sit — what stays in your environment, what (if anything) calls an external model, and what's logged. We'd rather have that conversation up front than hand you a tool that quietly ships clinical notes somewhere your privacy obligations don't permit.
We already log incidents in our clinical system. Why do we need this on top?
A logging system records that an incident happened; it doesn't read the free-text and tell you the night note that says "both settled, review in the morning" is actually a Priority 1 use-of-force with an unauthorised chemical restraint. That gap — between what was written and what's reportable — is where under-reporting lives, and it's the gap this closes before the 24-hour clock runs out.
Estimated build: 3–4 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.