Station Review Guide

Table of Contents

• What station review is for
• Who should use it
• Required inputs
• How to interpret the output
• Good-review examples
• Common failure modes and caveats
• Safe edit and publication workflow
• Review checklist

What station review is for

Station review is a quality-assurance step for checking whether a station is publishable, coherent, and safe for simulation and evaluation. It helps reviewers spot weak schema content, weak persona definition, missing rubric signals, and obvious simulation risks before a station goes live.

Who should use it

• Station authors preparing new or revised content
• Clinical educators reviewing whether a station is teachable and assessable
• Content reviewers checking station completeness and consistency
• QA and publishing reviewers deciding whether a station is ready for release
• Admins responsible for approving stations before publication

Required inputs

Station review is strongest when you provide the full station JSON or an equivalent structured summary.

• Rubric with at least 3 meaningful competency items
• Non-empty key points
• Specific persona content, not a default placeholder
• Guardrails or station tuning where safety or scope matters
• Lead/opening line and enough synopsis detail for the reviewer to judge coherence

How to interpret the output

Treat the review as a structured second check, not an automatic approval system.

• Use review output as QA support, not sole publication approval.
• Confirm the rubric is complete and the competency items are measurable.
• Confirm the persona is specific, plausible, and non-default.
• Confirm key points are meaningful and non-empty.
• Confirm the station appears safe and behaviourally coherent for live simulation.
• Investigate low-confidence, generic, or incomplete review outputs before publishing.

Good-review examples

{
  "text": "Please review this station for publication readiness. Focus on rubric completeness, persona specificity, key points, and simulation safety.\n\n{\n  \"title\": \"ABUSE IN INTELLECTUALLY DISABLED PERSON - history\",\n  \"station_slug\": \"abuse-in-intellectually-disabled-person-history-taking\",\n  \"persona\": {\n    \"name\": \"Mrs Whitlock\",\n    \"communication_style\": \"anxious but cooperative\",\n    \"goals_concerns\": [\n      \"Wants her symptoms taken seriously\",\n      \"Worries she is losing control\"\n    ]\n  },\n  \"key_points\": [\n    \"timeline\",\n    \"functional impact\",\n    \"risk\",\n    \"ideas/concerns/expectations\"\n  ],\n  \"rubric_domains\": [\n    \"History structure and signposting\",\n    \"Focused symptom exploration\",\n    \"Risk and safety assessment\"\n  ],\n  \"guardrails\": [\n    \"Do not volunteer risk content unless asked clearly\",\n    \"Escalate if immediate harm is disclosed\"\n  ]\n}",
  "station_slug": "abuse-in-intellectually-disabled-person-history-taking",
  "category": "station-review"
}

{
  "text": "Please review this draft station before publication.\n\n{\n  \"title\": \"Untitled station\",\n  \"station_slug\": \"draft-station\",\n  \"persona\": {\n    \"name\": \"Patient\",\n    \"communication_style\": \"brief\"\n  },\n  \"key_points\": [],\n  \"rubric_domains\": [\n    \"Communication\"\n  ],\n  \"guardrails\": []\n}",
  "station_slug": "draft-station",
  "category": "station-review"
}

Common failure modes and caveats

• Missing or shallow rubric items make the review less meaningful.
• Default or generic persona text often leads to generic feedback.
• Empty or weak key points reduce both simulation and evaluation confidence.
• Review output may become generic if the source station is generic.
• Review output is not a substitute for clinical sign-off.
• A pass-like review does not guarantee live simulation quality in production.

Safe edit and publication workflow

Use three separate saves for a material repair. A material repair changes patient facts, the candidate task, disclosure rules, key points, or rubric domains. Set expert_reviewed false while content is inactive; set it true only after the repaired content receives recorded expert review.

1. Save 1 - inactivate. Add the inactive publication block below, click Save station once, then reload the station and confirm the inactive status and reason. If Save fails, do not edit further; correct the JSON or access error first.
2. Save 2 - repair while inactive. Change the station content without changing the inactive publication block, save again, inspect the new revision, and complete a station-specific candidate test. If the S3 archive link or read-back does not match the saved JSON, stop and investigate before publishing.
3. Save 3 - publish after approval. After human clinical/content approval and successful candidate testing, replace the inactive block with the published block below and save once. Reload the station and confirm the publication reason and current S3 object. If either differs, treat publication as failed.

Inactivate before repair

{
  "publication": {
    "status": "inactive",
    "reason": "Material repair - candidate retest pending",
    "expert_reviewed": false
  }
}

Publish after testing and approval

{
  "publication": {
    "status": "published",
    "reason": "Clinical review and candidate validation passed",
    "expert_reviewed": true
  }
}

Review checklist