Clinical Audit Summary

An audit report only closes the loop if it ends in a named next action, not just a findings table. This skill structures raw audit data and notes against a stated benchmark, then drafts recommendations as a concrete next QI cycle rather than an open-ended wish list.

---

What this skill needs

• The standard or benchmark the audit measures against — ask if not stated:

  "What standard or target is this audit measuring against?"

• The raw findings: sample size, compliant/non-compliant counts, and prior cycle results if this is a repeat audit.

---

Step 1: State findings against the benchmark

For each measure, report the result against the named standard — percentage compliant, sample size, and trend if repeat data exists. Never characterise a result ("seemed low") without the number behind it.

Completion criterion: every finding names the benchmark it's measured against and the actual figure, not a qualitative impression alone.

---

Step 2: Draft recommended actions as a next PDSA cycle

For each gap, state what will change, who owns it, and when it will be re-audited — not a general "improve compliance" statement.

Completion criterion: every recommendation has an owner and a re-audit date or interval.

---

Output format

Findings table (measure, benchmark, result, trend) followed by a recommendations table (gap, action, owner, re-audit date), for the QI committee or M&M meeting.

---

Gotchas

• This doesn't judge clinical appropriateness itself — it only structures the data and comparison the auditor supplies.

---

Evidence base

• HQIP, Clinical Audit: A Simple Guide — backs the compliance-against- benchmark structure over a narrative-only findings summary.
• IHI, Model for Improvement — backs closing every audit with a PDSA-style next-cycle action rather than a static findings list.
• ACSQHC — backs re-audit as the mechanism that actually closes the quality loop in accredited Australian health services.

Incident Report Writer

An incident report is only useful if it reconstructs what actually happened clearly enough for someone who wasn't there to understand it — and keeps fact separate from judgement. This skill turns a free-text account into a factual, timeline-based report. It never assigns severity, blame, or root cause — those calls belong to the reporter and the review committee.

---

What this skill needs

• The free-text or verbal account of what happened.
• The facility's report template or fields, if there is one — ask if unclear.
• Patient/staff identifiers per your service's de-identification convention.

---

Step 1: Extract the factual timeline

Reconstruct a chronological sequence of what happened, who was involved (by role, not judgement — "the attending nurse," not "the negligent nurse"), and when each event occurred, using only what's stated. Mark timing as "approximate" rather than guessing precision the source doesn't have.

Completion criterion: every event in the account appears in the timeline in order, with uncertain timing marked as approximate.

---

Step 2: Separate fact from interpretation

Pull contributing factors out as neutral observations — "the call bell was out of reach" — not conclusions — "nursing was negligent." Anything that reads as a judgement rather than an observation gets flagged back to the reporter to confirm or rephrase.

Completion criterion: no sentence in the contributing-factors section assigns blame or names a cause; anything ambiguous is flagged rather than resolved.

---

Step 3: Draft the report

Use the facility's structure if supplied; otherwise: what happened, contributing factors, immediate actions taken, immediate risk mitigation, follow-up required. Leave severity rating and root-cause fields blank or marked for the reporter/reviewer to complete.

Completion criterion: the draft has no severity rating or causal conclusion the source account didn't already state.

---

Output format

Match the facility's template fields if supplied. Otherwise, the structure above — each section 2–5 sentences, timeline as a bulleted, timestamped list.

---

Gotchas

• Never assigns a severity rating, harm score, or root-cause classification — these require judgement and process (e.g. a formal root cause analysis) beyond what's in the raw account.
• Flags ambiguity in the account rather than inferring what "probably" happened.

---

Evidence base

• AHRQ Common Formats — backs separating factual event description from causal/severity judgement, and structuring by timeline plus contributing factors.
• ACSQHC — backs incident reporting as a systems-focused, non-punitive process; this skill supports that by keeping the factual write-up free of blame language.
• WHO Conceptual Framework for the ICPS — the distinction between a "contributing factor" (an observed fact) and a "root cause" (an analytical conclusion) that Step 2 relies on.

MDT Meeting Summary

An MDT meeting has done its job when every patient discussed leaves with a clear, owned next step — not just a record that they were talked about. This skill turns a transcript, dictation, or rough notes into a per-patient summary built around decisions and actions, not a general discussion log.

---

What this skill needs

• The transcript, dictation, or notes from the meeting.
• The list of patients/cases covered, if not obvious from the notes.

---

Step 1: Segment by patient

Break the raw notes into one block per patient discussed, in the order they came up.

Completion criterion: every patient named in the source material has their own block.

---

Step 2: Capture discussion, decision, and action

For each patient, extract:

• Discussion — a one- to two-sentence summary of what was covered.
• Decision — what the team actually decided, stated plainly.
• Action — what happens next, who owns it, and by when.

Completion criterion: every patient block has a stated decision (or "no decision reached") and, where a decision was made, an action with an owner.

---

Step 3: Flag unresolved cases

Where a patient was discussed without a clear decision or action, mark it for follow-up at the next meeting rather than inventing a plausible-sounding outcome.

Completion criterion: no patient block shows a decision or action that wasn't actually stated in the source material.

---

Output format

One block per patient: Patient | Discussion | Decision | Action (owner, by when).

---

Gotchas

• This documents what the team decided — it does not make or suggest clinical decisions itself.

---

Evidence base

• ACSQHC, Comprehensive Care Standard — backs documenting a clear, owned care-plan action per patient rather than a discussion record.
• NHS England, Multidisciplinary Team guidance — backs the decision-plus-action-plus-owner structure as the actual point of MDT documentation, not the discussion itself.
• WHO, Framework on Integrated People-Centred Health Services — backs continuity across disciplines as the reason a structured hand-off from the meeting to the ward matters.

Patient Letter Writer

A patient letter has done its job only if someone reads it once and knows exactly what happened and what to do next — regardless of their health literacy or first language. This skill turns clinical or administrative notes into a plain-language letter, and treats "what does the patient need to do" as the one thing that can never get lost in simplification.

This is distinct from a clinical handover note (see shift-handover-note) — that's written for clinicians; this is written for the patient.

---

What this skill needs

• The letter type: appointment summary, discharge instructions, results explanation, or referral notice.
• The clinical/administrative notes to draft from.

If not already clear, ask:

"What's this letter for, and who's it going to — the patient directly, or a family member/carer?"

---

Step 1: Pull out every required action

Before drafting, list every action the patient needs to take from the source notes — medication changes, follow-up appointments, warning signs to watch for, who to contact and when. Nothing patient-facing goes out without these being explicit.

Completion criterion: every action item present in the clinical notes appears in this list before drafting begins.

---

Step 2: Draft in plain language

Short sentences, common words, active voice, one idea per sentence. Define or avoid jargon rather than assuming familiarity. Use "you" directly rather than passive or third-person clinical phrasing.

Completion criterion: no sentence carries more than one instruction or idea, and no undefined clinical term appears.

---

Step 3: Close with a clear action list

End with a short "What you need to do" list restating every item from Step 1, plus who to contact with questions and how.

Completion criterion: every action from Step 1 appears in this closing list — none silently dropped for brevity.

---

Output format

Short paragraphs, then a bulleted "What you need to do" section, then contact details. Keep to one page where the content allows it.

---

Gotchas

• This is a draft for the clinician's review before sending, not a substitute for their judgement on what to disclose.
• Never soften or omit a safety-relevant instruction (e.g. "seek urgent care if X") for the sake of brevity or tone.

---

Evidence base

• CDC, Clear Communication Index — the plain-language criteria applied in Step 2: short sentences, common words, one idea per sentence.
• AHRQ Health Literacy Universal Precautions Toolkit — backs assuming variable health literacy for every patient by default, not just those flagged as low-literacy, and writing with teach-back-level clarity.
• Australian Digital Health Agency — health literacy guidance for Australian patient-facing materials, consistent with the same plain- language standard.

Clinical Policy Briefing

A policy briefing is only trustworthy if every line traces back to the actual policy text — not to what a standard "usually" says. This skill needs the source document itself; it never drafts clinical policy content from memory.

---

What this skill needs

• The actual policy, guideline, or standard text — or the specific sections that changed.
• The prior version, if this is an update and the diff matters.

If no source document has been provided:

"Can you paste or attach the policy or guideline text, or the specific sections that changed?"

Do not proceed to drafting without it.

---

Step 1: Confirm the source

Check that the supplied text is specific enough to brief from — a title or summary alone ("new infection control guideline") isn't sufficient; the actual requirements are.

Completion criterion: every claim the briefing will make can be pointed to a sentence in the supplied source.

---

Step 2: Extract what changed

If a prior version is available, identify what's new, removed, or tightened. If not, extract the requirements as if briefing them for the first time.

Completion criterion: every "what changed" line names the specific requirement, not a paraphrase of the policy's general intent.

---

Step 3: Draft the briefing

Structure: What changed / Why (cited to the source) / What to do differently / Effective date / Who to ask.

Completion criterion: every "what to do differently" line traces to text actually supplied, not inferred from what a similar policy elsewhere typically requires.

---

Output format

One page, five short sections as above, plain language, no more than one screen of reading per section.

---

Gotchas

• Recalled-policy risk: never draft a briefing about clinical policy content from memory alone. If no source document is available, ask for it rather than guessing at what a standard "probably" says — a plausible-sounding wrong briefing is worse than an unfinished one.

---

Evidence base

• ACSQHC, National Safety and Quality Health Service Standards — accreditation standards this skill helps translate into staff-facing action.
• The Joint Commission — the same source-document discipline applies to US accreditation updates; both back requiring the actual text over a recalled summary.

Shift Handover Note (SBAR)

Poor handover communication is one of the most consistently cited contributing factors in preventable clinical incidents. This skill turns rough notes, dictation, or a partial handover sheet into a complete SBAR handover — Situation, Background, Assessment, Recommendation — so the incoming shift has everything it needs to pick up each patient safely.

---

What this skill needs

• The patient identifier convention your service uses (bed number, initials, MRN — never record identifying detail beyond what your service's own handover process already uses).
• Rough notes, dictation, or a partial handover sheet for each patient.
• Working mode: one patient at a time, or a full ward list in one pass.

If any of this isn't already established:

"How many patients are we handing over, and do you have notes for each, or would you like to talk through them one at a time?"

---

Step 1: Sort the raw notes into SBAR

For each patient, map whatever was provided into:

• Situation — who the patient is, why they're here, current status in one line.
• Background — relevant history, admission reason, treatment so far.
• Assessment — current clinical picture: vitals trend, response to treatment, active concerns.
• Recommendation — what the incoming shift needs to do, watch for, or escalate, and by when.

Completion criterion: every patient has content in all four sections, or an explicit flag on the ones that don't.

---

Step 2: Flag the gaps

If the source material doesn't cover one of the four sections for a patient, don't invent it. Mark it clearly instead:

[Recommendation not specified — confirm with outgoing shift before handover]

This is the point of the exercise — a handover that silently drops a missing recommendation is worse than one that visibly flags it.

---

Step 3: Produce the handover sheet

Output one SBAR block per patient, in the order the outgoing shift will hand over.

Completion criterion: every patient in the list has a labelled SBAR block, and every flagged gap from Step 2 is visible in the output, not silently dropped.

---

Output format

One Markdown block per patient, headed by bed/identifier, with the four SBAR labels bolded. Keep each section to 1–3 lines — a handover note is a prompt for the verbal handover, not the full chart.

---

Gotchas

• This drafts the handover note only. Clinical judgement — what's actually urgent, what can wait — stays with the clinicians handing over and receiving care.
• Don't paste patient-identifying information beyond what your service's own handover process already uses.

---

Evidence base

• WHO Patient Safety Solutions, Communication During Patient Hand-Overs (2007) — backs SBAR as the structure, and names incomplete or inconsistent handover communication as a leading contributor to preventable harm.
• Institute for Healthcare Improvement, SBAR Tool — the structure this skill outputs to.
• ACSQHC, National Safety and Quality Health Service Standards — Communicating for Safety standard, backs complete, structured handover as an accreditation requirement in Australian health services.
• The Joint Commission, National Patient Safety Goals — handoff communication requirement, backs flagging gaps rather than leaving them implicit.