10w nexu-io

clinical-case-report Skill

面向临床查房、会议和病历文档的结构化病例展示。生成 SOAP 格式或叙述式病例报告,包含符合生理学真实的生命体征、化验结果和循证方案。当需求提到“病例报告”、“病例展示”、“SOAP note”、“临床病例”、“查房”、“病例摘要”或“患者汇报”时使用。

安装方式:把技能目录放入 ~/.claude/skills/(Claude Code)或在 claude.ai 设置中启用;也可复制右侧安装命令一键添加。

查看源码

技能指令原文(SKILL.md)

Clinical Case Report Skill

Generate a structured medical case presentation for clinical rounds,
conferences, or documentation. The output follows standard medical
formatting conventions used in hospital settings worldwide.

What you will produce

A single-page HTML case report (index.html). Content varies by format
(see references/case-formats.md — selected in Step 0):

SOAP / Conference format:

  • Patient identification — age, sex, chief complaint
  • History of Present Illness (HPI) — chronological narrative with

pertinent positives and negatives

  • Past Medical History, Medications, Allergies
  • Review of Systems
  • Physical Examination — systematic findings by system
  • Vital Signs — formatted table with reference ranges and flags
  • Investigations — laboratory results and imaging findings
  • Assessment — primary diagnosis and differential (3–5 items)

with clinical reasoning for each

  • Management Plan — evidence-based, organised by problem

Brief Rounds format (daily review, ward round, handover, ICU, post-call):

  • ID line — age, sex, day of admission, primary problem
  • Interval events / current status — what has changed since last review
  • Active problems — numbered list
  • Plan-by-problem — concise actions for each active problem
  • Full HPI and systematic physical examination are not included

Step-by-step workflow

Step 0 — Load reference files

Before starting, read both reference files:

  1. references/case-formats.md — use this to choose the correct output

format (SOAP, Conference, or Brief Rounds) based on the user's context

  1. references/checklist.md — keep P0 gates in mind throughout; you

must pass all P0 items before emitting the final artifact

Step 1 — Parse the brief

Read the user's prompt and extract:

  • Patient age and sex
  • Chief complaint or presenting problem
  • Any vitals, labs, or imaging the user has provided
  • Clinical context: ED, ward rounds, conference case, outpatient, etc.
  • Specialty context: cardiology, emergency, internal medicine, etc.

If the chief complaint or presenting problem is missing:

  • SOAP / Conference: ask one clarifying question before proceeding. Do not proceed without it.
  • Brief Rounds: if the admission problem or ID line is already available (e.g. "day-3 ICU review for septic shock"), proceed directly — a separate chief complaint is not required.

Step 2 — Build the clinical narrative

For SOAP / Conference outputs: write the HPI as a continuous prose
narrative in standard clinical style:

"This is a [age]-year-old [sex] with a history of [relevant PMH] who
presents with [chief complaint]. Symptoms began [timeline] and are
characterised by [quality, severity, radiation]. Associated symptoms
include [list]. Pertinent negatives include [list]."

The HPI must be chronological. Include timeline markers
("2 hours prior to presentation", "onset yesterday morning").

For Brief Rounds outputs (daily review, ward round, handover, ICU,
post-call): skip the full HPI and examination. Instead produce:

  • ID line: "[Age][sex], Day [N] of admission, [primary problem]"
  • Interval events / current status: what has changed since last review
  • Active problems: numbered list
  • Plan-by-problem: concise action for each active problem

Step 3 — Generate physiologically consistent clinical data

If the user has not provided specific values, generate values that are
internally consistent with the diagnosis:

Consistency checks (typical patterns):

  • A patient in shock typically has: HR >100, SBP <90, raised lactate,

impaired capillary refill — but medications (beta-blockers), age, or
shock type (neurogenic, spinal) can alter this pattern

  • Pneumonia typically presents with raised WBC, raised CRP,

temperature >38°C — but afebrile pneumonia exists, especially in
the elderly or immunocompromised

  • A STEMI typically shows ST elevation in contiguous leads and raised

high-sensitivity troponin — but early presentations may have initially
normal troponin; CK-MB is not universally required

  • Sepsis typically shows raised or low WBC, raised lactate >2,

temperature abnormality — but compensated early sepsis may present
with normal vitals

  • Lab units must match convention: creatinine in µmol/L or mg/dL

(state which), glucose in mmol/L, haemoglobin in g/dL

Critical rule — preserve user-provided data:

  • Never overwrite a value the user has explicitly stated
  • If a user-provided value is atypical for the diagnosis, keep it and

note the atypical presentation in the assessment rather than
forcing canonical numbers

  • Never generate a value that contradicts the stated diagnosis

Step 4 — Write the assessment

The assessment section must contain:

  1. Primary diagnosis stated clearly on the first line
  2. Clinical reasoning — one sentence explaining why this is the

most likely diagnosis

  1. Differential diagnosis — exactly 3 to 5 items, each with one

sentence of supporting or refuting evidence

  1. Risk stratification — include a validated clinical score where

applicable (TIMI for ACS, GRACE for ACS, Killip class + Shock Index
for STEMI/cardiogenic shock, CURB-65 for pneumonia, qSOFA for sepsis,
Wells for PE, etc.). Killip class and Shock Index together are
accepted as sufficient risk stratification for STEMI/cardiogenic shock cases.

Step 5 — Write the management plan

The plan must be:

  • Specific: write drug names, doses, routes, and frequencies.

Do not write "start antibiotics" — write
"Piperacillin-Tazobactam 4.5g IV q8h for 5 days"

  • Organised by problem using numbered headers
  • Evidence-based: management must reflect current standard of care

for the diagnosis

  • Complete: include investigations to order, monitoring parameters,

consults to request, and disposition

If you are uncertain about a specific dose, write
"[drug name] — dose per local formulary/protocol" rather than
inventing a dose.

Important — Prescribing Safety

Generated plans must:

  • Be marked as educational/simulated, not a substitute for clinician judgment
  • Use "per local formulary/protocol" language when required patient variables

(weight, renal function, allergies) are missing from the brief

  • List key contraindications and unknowns before medication recommendations

when relevant patient data has not been provided

  • Never claim a plan is "definitive" or "standard of care" without full

patient context (allergy status, renal/hepatic function, pregnancy
status, weight, anticoagulation/bleeding risk)

  • Include a disclaimer footer in the HTML output stating the case is for

educational and documentation purposes only

Step 6 — Write index.html

Requirements for the HTML output:

  • Professional medical document typography

(Georgia or system serif font preferred)

  • White background, dark text — suitable for printing
  • Vital signs and lab results in HTML
  • Critical findings (ST elevation, raised troponin, low BP, etc.)
  • highlighted in a visually distinct callout box with red left border

    • @media print CSS rules so the document prints cleanly on A4/Letter
    • Tag every major section with data-od-id for comment-mode targeting:
    <section data-od-id="hpi">...</section>
    <section data-od-id="vitals">...</section>
    <section data-od-id="pmh">...</section>
    <section data-od-id="examination">...</section>
    <section data-od-id="investigations">...</section>
    <section data-od-id="assessment">...</section>
    <section data-od-id="plan">...</section>

    Step 7 — Self-check against references/checklist.md

    Before emitting , run every P0 item in references/checklist.md.
    All P0 items must pass. Fix any failures before emitting.

    elements