Summarising incidents for reports and reviews

Most services collect incident records diligently and analyse them rarely. The records exist, the monthly review is meant to happen, and the pattern that was visible across twenty-three separate paragraphs never quite gets spotted.

This is a genuinely good use of AI, with two firm boundaries around it.

The two boundaries

One: AI never touches the original incident record. The record written at the time is evidence. It may be read years later by a safeguarding review, a coroner or a regulator. It is written by the person who was there, in their words, and it stays that way. Do not let AI write it, rewrite it, or tidy it.

Two: the data is anonymised before it goes anywhere. You are looking for patterns across incidents, which does not require names.

How it works

You take a set of anonymised incident descriptions for a period, and ask for a summary under agreed headings: how many, what kinds, when, where, what recurred.

The output is a starting point for the conversation a manager was going to have anyway, with the counting already done.

Where it helps

Counting. Humans are bad at counting across twenty-three free-text paragraphs and good at judging what the counts mean. Splitting the task that way plays to both.

Time and place patterns. “Six between 6pm and 8pm” is the kind of thing that leaps out of a summary and hides in a folder.

Board reporting. Trustees and directors need a readable picture. See our board briefing template.

Consistency of format, so this month can be compared with last month.

Where it goes wrong

Severity flattening. This is the one to watch. In a list of twenty-three incidents, a serious injury becomes one row. The summary is numerically accurate and gives entirely the wrong impression.

Fix: always read the serious ones in full, separately, and never let them reach the board only as a number.

Patterns in small numbers. With twenty-three incidents, almost any split will look meaningful. Nine falls in two rooms may be a genuine finding about those rooms, or it may be that those rooms house the two people most likely to fall. AI will report the pattern either way, with the same confidence.

Fix: treat every pattern as a question, not a conclusion. The manager who knows the service decides what it means.

Missing what is absent. A quarter with no medication errors recorded might be a quarter with no medication errors, or a quarter where nobody reported any. A summary of what was recorded cannot see the second possibility.

Anonymisation in a small service

This deserves more thought than it usually gets.

Removing a name is not anonymising when the service has eleven residents and the incident involved the only person who uses a particular chair. Anyone reading it internally knows exactly who it is, and so does anyone who leaves and takes a copy.

For genuinely aggregate reporting you can strip a lot: no names, no room numbers, no dates of birth, generalised times, and descriptions reduced to type. If an incident is so distinctive that it cannot be described without identifying someone, leave it out of the AI step and handle it by hand.

How to trial it

Take three months you have already reviewed. Run each through the tool. Compare what it found with what you found.

Two questions: did it surface anything you missed, and did it miss anything you caught? Both answers are useful. If it consistently misses severity, use it only for counting and keep the judgement entirely manual.