Start with the provider’s process
The Commission’s incident management guidance describes recording, response, responsibility, participant involvement and corrective action. Registered providers also have separate notification duties for reportable incidents; use the current definitions and timeframes when designing the process.
Ask your responsible reviewer to define the required workflow before the demo. A software label or countdown does not decide a real incident’s category or replace the provider’s obligations. Immediate safety and emergency responses must not wait for a software task.
Give the vendor a fictional end-to-end test
| Stage | Evidence to request |
|---|---|
| Worker report | A worker can record known facts, uncertainty and immediate actions without being forced to invent details. |
| Receipt | The intended reviewer receives a visible report; failed delivery and absent-reviewer arrangements are explained. |
| Review | An authorised person can record decisions and reasons while preserving the original account. |
| Notification record | The system distinguishes a draft, an internal action and evidence of an actual external submission. |
| Follow-up | Named actions, due dates and supporting records can be followed through. |
| Retrieval | An authorised reviewer can retrieve the record, changes, decisions and attachments. |
A vendor may support some steps through another system. Record the boundary and handoff rather than assuming one product does everything.
Test corrections and permissions, not only submission
Fictional example: a worker enters an incorrect time and later corrects it. Ask the vendor to show the original entry, the correction and who made it. Then test whether an unrelated worker can see the report. A successful save and a dashboard total do not answer those questions.
Try an interrupted connection or a return to an unfinished draft. Establish whether the report was saved, submitted or left on the device. Ask how duplicate submissions are handled and how the person knows which record is authoritative.
Challenge automated or AI claims with observable evidence
If a vendor offers automatic classification, drafting or escalation, ask what it actually does, which source or rule version it uses and what remains for an authorised person. Test an ambiguous fictional case and inspect the explanation. Keep unknown facts visible.
Ask how a reviewer can correct an output and retain the original evidence. Do not evaluate with identifiable participant information in an unapproved trial. A plausible generated paragraph is not proof that an external report was submitted or that a decision is correct.
Connect incident work to quality improvement
After the immediate response, test whether follow-up work has a named owner and a clear completion check. Can the reviewer find the evidence and explain what changed? Can a recurring issue be reviewed without exposing unnecessary personal information?
Assess ProviderQMS against the specific quality and evidence tasks you need; this guide does not promise autonomous reportability decisions or Commission submission. Use the switching checklist before moving records and the cost calculator before accepting the quote.
Incident software evaluation worksheet
Use business requirements and internal references only. Entries stay in this page and are lost when you leave or reload. Print or download your brief before leaving.
Source: https://ndiscompliant.com.au/marketplace/incident-reporting-software-checklist/ · 3 October 2026
Sources and editorial approach
Source pages checked 3 October 2026. Linked official guidance and vendor statements are identified separately from our suggested evaluation methods. Examples are fictional. Research and drafting used AI assistance; this guide does not claim practitioner approval or independent vendor testing.