Web & Frontendlow risk
clinical-case-report
Structured medical case presentation for clinical rounds, conferences, and documentation. Generates SOAP-format or narrative case reports with physiologically accurate vitals, labs, and evidence-based plans. Use when the brief mentions "case report", "case presentation", "SOAP note", "clinical case", "ward rounds", "case summary", or "patient presentation".
nexu-io/open-design·design-templates/clinical-case-report/SKILL.md
61/ 100おすすめ度
この Skill を導入
coding agent を選び、プロジェクト用または個人用コマンドをコピーします。
プロジェクトに導入.agents/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a codex -y個人環境に導入~/.agents/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a codex -g -yプロジェクトに導入.claude/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a claude-code -y個人環境に導入~/.claude/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a claude-code -g -yプロジェクトに導入.agents/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a github-copilot -y個人環境に導入~/.copilot/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a github-copilot -g -yプロジェクトに導入.agents/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a cursor -y個人環境に導入~/.cursor/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a cursor -g -yプロジェクトに導入.agents/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a gemini-cli -y個人環境に導入~/.gemini/skills/clinical-case-report
npx skills add https://github.com/nexu-io/open-design/tree/7533db3f4342d09b27368fa5d907ebd3cdb93b75/design-templates/clinical-case-report -a gemini-cli -g -yNative Gemini CLI
gemini skills install https://github.com/nexu-io/open-design.git --scope workspace --path design-templates/clinical-case-report⚠ インストールには open-source skills CLI を使用します。実行前にソースと権限を確認してください。
Skill の指示
GitHub で元ファイルを表示 ↗# 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
2. `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
3. **Differential diagnosis** — exactly 3 to 5 items, each with one
sentence of supporting or refuting evidence
4. **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 `<table>` elements
- 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:
```html
<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 `<artifact>`, run every P0 item in `references/checklist.md`.
All P0 items must pass. Fix any failures before emitting.