NDIS Incident Report Writing: A Practical Guide for Support Workers and Coordinators
What to include in an NDIS incident report, how to write the narrative section, and how AI tools can help with the first draft while keeping the record accurate.
What is an NDIS incident report?
An NDIS incident report is a formal record of an event that occurred during the delivery of a support that caused, or had the potential to cause, harm to a participant or worker.
The NDIS Quality and Safeguards Commission requires registered providers to have a documented incident management system. That system must include:
- A process for identifying and recording incidents
- A process for responding to incidents
- A process for reporting certain incidents to the Commission (reportable incidents)
- A process for reviewing incidents and implementing improvements
Not every incident is reportable to the Commission. But every incident that meets your organisation's internal definition must be recorded in your incident management system.
What counts as an NDIS incident?
Your organisation's policy defines this, but typical categories include:
- Physical injury to a participant (falls, burns, cuts, medical events)
- Behavioural incidents (participant to participant, participant to worker)
- Medication errors (wrong dose, missed dose, wrong medication)
- Property damage
- Participant missing or absconding
- Allegations of abuse, neglect, or exploitation
- Restrictive practice use (planned or unplanned)
- Near-misses that had serious potential consequences
NDIS reportable incidents (which must be notified to the Commission within 24 hours for serious incidents) include things like death, serious injury, abuse, neglect, and unlawful sexual or physical contact.
The two parts of an incident report
Every incident report has two distinct components. Both are necessary.
Part 1: Structured fields
The structured fields are the factual backbone of the report. They include:
Incident type -- Select from a defined list. Do not leave this as "Other" if a more specific category fits.
Severity -- Most systems use a scale (minor, moderate, major, critical). When in doubt, rate higher and revise down with coordinator review.
Date and time -- The time the incident occurred, not the time it was reported. If the exact time is unknown, record an estimate and note that it is an estimate.
Location -- Where the incident happened. Include the full address if it occurred at the participant's home.
Parties involved -- The participant's name and identifier. Any witnesses. Any workers involved.
Immediate actions taken -- What was done in response before this report was written.
These fields are the official record. They must be accurate. Do not leave them blank and rely on the narrative to carry the information.
Part 2: The narrative section
The narrative is a written account of what happened, in chronological order, in plain English. Good narratives include:
- What the worker was doing with the participant immediately before the incident
- What happened and how quickly it escalated
- The participant's presentation and any relevant behaviour prior to the incident
- Exactly what the worker did in response and in what order
- The participant's condition at the end of the incident
- Any communication with other workers, family, or services
Poor narratives are vague, missing context, or written in shorthand that only makes sense to someone who already knows the situation.
How to write a good incident narrative
Write it as soon as possible. Memory degrades quickly after a stressful event. Even a rough draft written immediately is more accurate than a polished narrative written hours later.
Use chronological order. Start from what was happening before the incident, then describe the incident itself, then describe the response.
Be specific about time. "At approximately 2:15 pm" is better than "in the afternoon". "Within approximately 30 seconds" is better than "quickly".
Use plain English. Avoid jargon, abbreviations, and anything that might be ambiguous to a reader outside your organisation.
Stick to observed facts. Describe what you saw and heard, not what you assumed or interpreted. "The participant was shouting and striking the table repeatedly" is a fact. "The participant was having a meltdown" is an interpretation.
Do not assign blame. Describe what happened. Separate reviews will determine cause.
How AI can help with incident report writing
Several NDIS workforce platforms now offer AI narrative generation. The concept is straightforward: a worker fills in the structured fields, and the AI drafts a narrative paragraph or two based on those fields.
This removes the blank-page problem. Many support workers find writing prose under stress, after a difficult incident, genuinely hard. An AI draft gives them something to react to, edit, and correct rather than starting from nothing.
In CareOS, the AI incident narrative generator produces a draft in real time as you fill in the structured fields. The draft appears in the narrative text area and is fully editable. The worker reviews it, makes corrections, and submits.
AI is not appropriate for determining incident severity, deciding whether something is NDIS-reportable, or replacing any part of the clinical review process. It is a writing tool, not a compliance tool.
After the report is submitted
Incident reports are the start of a process, not the end. After submission:
- A coordinator or manager should review the report for completeness within your organisation's timeframe (often within 24 hours for serious incidents)
- If the incident meets NDIS reportable thresholds, it must be reported to the Commission within the required timeframe
- A formal review should be completed to identify contributing factors and any system or practice changes needed
For more on managing incident documentation in CareOS, book a demo or sign up free to try it with your team.