Guides · Minnesota

A 245D incident report template you can use today.

Every field a compliant incident report needs, laid out on this page so you can copy the structure into your own form. No download, no email gate.

The short answer: a usable 245D incident report captures who was involved, when and where it happened, a factual description of the event, any injuries, what staff did in response, every notification made and when, an internal review section, and documented follow-up actions. All fields below are ungated. Your agency’s written incident policy is what actually governs; treat this as a starting structure to adapt, not a substitute for it.

Why the structure matters more than the form

Minnesota’s 245D licensing statute (Minn. Stat. ch. 245D) requires agencies to respond to and document incidents, and licensing reviewers read incident files closely because they show whether your agency actually does what its policies say. A reviewer is rarely bothered by the fact that an incident happened. They are bothered by reports that are vague, late, missing notifications, or missing any evidence that anyone reviewed them afterward.

That means the value of an incident report is in its completeness and its timeline, not its formatting. Whether you use a paper form, a spreadsheet, or software, the same fields need to exist and the same sequence needs to be visible: event, response, notification, review, follow-up. The sections below walk through each block of the template in order.

Block 1: the person and the basics

Start with the identifying facts. These sound obvious, but incomplete basics are one of the most common gaps reviewers find, especially the precise time and the discovery-versus-occurrence distinction.

Name of the person receiving services involved in the incident
Date of the incident, and the time it occurred or was discovered (note which one it is)
Location of the incident: the site, and where at the site (bedroom, vehicle, community outing)
Names and roles of staff present or on shift at the time
Names of any other people involved or witnessing (other persons served, family, public)
Type of incident, matching the categories your incident policy defines
Name and role of the person completing the report, and the date and time it was written

The last item matters more than it looks. The gap between when an incident happened and when it was written up is one of the first things a reviewer checks, so date-stamp the report itself, not just the event.

Block 2: the event and any injuries

This is the narrative core of the report, and it should be written by the staff person who witnessed or discovered the incident, in their own words, as soon as practical.

A factual, chronological description of what happened: what was observed, what was said, in what order
What was happening immediately before the incident, if known
Any injuries, described specifically: what, where on the body, observed or reported by the person
Whether medical attention was sought, from whom, and the outcome
Condition of the person after the incident, in observable terms

The rule for this block is observation over interpretation. Write what was seen and heard, not conclusions about motive or fault. “He was aggressive” is an interpretation; “he threw the cup and it struck the wall” is a fact a reviewer, a nurse, or an investigator can actually use.

Block 3: staff response and notifications

After the event itself, the report must show what your agency did about it, starting with the immediate response and continuing through every notification your policy requires.

Immediate actions staff took to keep the person and others safe
First aid or emergency response provided, and by whom
Each notification made: who was notified, by whom, by what method, and the date and time
Typical notification targets to consider: legal representative, case manager, designated coordinator or manager, licensor where required
Whether a maltreatment report was made through the state's centralized intake (MAARC for vulnerable adults), and when
If a required notification was not made, the reason documented

External reporting deserves its own emphasis. If the incident involves suspected maltreatment of a vulnerable adult, it is reportable to the Minnesota Adult Abuse Reporting Center within the timelines the law sets, and those timelines are short and strict. This page deliberately does not restate the exact hours; check the statute and your agency’s policy, and build the current requirement into your form so staff never have to remember it under stress.

Block 4: internal review and follow-up

A report that ends at the notification log is half a report. The section reviewers most often find empty is the one showing that someone with authority looked at the incident afterward and did something with it.

Reviewer's name and role (typically the designated coordinator or designated manager) and date of review
Whether the incident is part of a pattern for this person or this site
Whether the support plan, safety plan, or environment needs a change as a result
Specific follow-up actions assigned: what, who owns it, and by when
Confirmation that each follow-up action was completed, with a date
Whether staff training or a policy change is indicated

Follow-up items with an owner and a due date are what separate a filing exercise from an actual incident response process. If your form has one improvement to make, it is usually this block.

Common documentation mistakes

These are the failure patterns that show up again and again when incident files are reviewed:

Vague narratives: opinions and labels instead of observable facts in time order
No timestamps on notifications, so nobody can show the required timeline was met
The report written days later, or with no date on the report itself
Notifications made by phone but never logged, leaving no evidence they happened
An internal review section that exists on the form but is left blank
Follow-up actions written as intentions with no owner, due date, or completion record
Reports edited after the fact with no record of what changed, which undermines the whole file
Incident categories on the form that don't match the categories in the agency's written policy

Common questions

Do I need a special form, or can I build my own?

You can build your own. Minnesota's 245D statute (Minn. Stat. ch. 245D) sets requirements for what your agency must do about incidents; it does not hand you a form. Most agencies either buy a policy package from a consultant, adapt a template like this one, or use software with a built-in incident workflow. Whatever you use, your written incident policy governs, and your form should match it field for field.

When does an incident have to be reported outside my agency?

Suspected maltreatment of a vulnerable adult or minor must be reported through the state's centralized intake process (MAARC for vulnerable adults) within the timelines the law sets. Other incident types trigger notification to the person's legal representative, case manager, or licensor depending on severity and your policy. Do not rely on this page for the exact clock: check the statute and your own policy, because the timelines are strict and reviewers check them.

Who should write the incident report?

The staff person who witnessed or discovered the incident should write the factual description, as close to the event as possible, in their own words. A supervisor, designated coordinator, or designated manager then completes the notification log, internal review, and follow-up sections. Keeping authorship split this way preserves the firsthand account and makes the review trail obvious to a licensor reading the file later.

How long do incident reports need to be kept?

Retention is set by the statute and your records policy, not by this page, so confirm the requirement with your licensor and write it into your policy. The practical answer for a review: keep every incident report retrievable by person and by date range, with its notifications and follow-up attached. A reviewer who asks for all incidents for one person over a period expects a complete, ordered set, not a folder hunt.

Where ClientCentric fits, plainly

ClientCentric is operations software for 245D and HCBS agencies, and incidents are one of its built-in record types: structured incident entries tied to the person’s record, with notifications, review, and follow-up captured in the workflow and an append-only audit history behind every entry, so nobody can quietly edit a report after the fact. If you are managing incidents on paper today, this template works fine on paper too. The software earns its keep when you need every incident retrievable, reviewed, and provable at a licensing review.

Explore the interactive demo Book a walkthroughNo signup. Fictional data. Everything resets on refresh.

Keep reading

Written and maintained by the ClientCentric team from the working product. Last reviewed 2026-08-31. Based on Minn. Stat. ch. 245D and Minnesota maltreatment reporting requirements. This is a starting structure, not legal advice; your agency's written incident policy and the current statute govern. Confirm reporting timelines with your licensor.