WHIS Academy
Menu
Courses/Clinical supervision/Designing a session/Case discussions and significant events

Module 1 · Designing a session

Case discussions and significant events

Reading · 12 min · Lesson 2 of 2

Case discussions and significant events

Case discussion is one of the primary tools of clinical supervision. Significant event review is its more formal cousin — used when something notable has happened (good or bad) and you want to extract learning from it.

Both methods are reflective rather than operational. The point is not to solve the case — that work happens in workplace supervision. The point is to learn: about the work, about the , about the system.

A simple case discussion structure

A reliable shape that fits in 20–30 minutes:

  1. Context. Briefly — anonymised. What kind of case, what's the presenting issue, what's the been doing.
  2. What stood out. Why has the brought this case to supervision? Surface this early — it shapes everything else.
  3. What's working / not working. From the 's perspective. Use open questions: "What feels stuck?" "What would 'better' look like here?"
  4. Reflection. This is the heart. "What do you notice in yourself with this person?" "What's it bringing up for you?" Resist the urge to skip past this — it's where the learning lives.
  5. Generalising. Is there a pattern beyond this one case? A skill to grow, a process to fix? Often the case the brought is the third or fourth example of something they hadn't yet named.
  6. Next. Concrete actions for the (try X, read Y, bring back Z). Anything for the supervisor (raise with the wider team, book another observation, escalate to safeguarding lead).

Significant event reviews

Use a significant event review when:

  • something went very well and you want to bottle the learning,
  • something went wrong, or
  • something could have gone wrong if it hadn't been caught in time (a "near miss").

A structured review covers five questions:

  • What happened? Factual, anonymised, in chronological order. Avoid evaluative language at this stage.
  • Why did it happen? Look at contributing factors at multiple levels — the (knowledge, skill, capacity), the team (handover quality, culture, supervision frequency), the system (referral pathway, IT, commissioning, training availability).
  • What was the impact? On the person being supported (foremost), on the , on the team, on confidence in the service.
  • What has been learned? Specific, actionable, in plain language. "We learned that …" — not "It is recommended that …".
  • What will change? Behaviour, process, training, escalation route, team conversation. With owners and timescales. A learning point with no change attached doesn't change anything.

If the event has wider service implications, agree how (and to whom) the learning gets shared without breaching confidentiality.

Confidentiality and privacy

Anonymise rigorously. Even within the supervision relationship. The exception is when there is a safeguarding or patient-safety dimension that requires identifiable detail — and even then, share the minimum necessary, and follow your local information-sharing policy.

If the supervision will involve identifiable case detail, agree this in advance, document why, and include it in the supervision record.

Document it

Brief notes for the supervision record:

  • Date, attendees, format.
  • A line on what was discussed (anonymised).
  • What was agreed, with owners.
  • Next steps and follow-up.

This is part of the audit trail and evidence of the 's . Use it alongside the Self-assessment and the Reflection tool to build a coherent picture of growth over time.

Loading progress…