Design a complete scenario

Build a runnable scenario by connecting learning objectives, patient information, learner decisions, and debriefing. Use supported schema fields for executable behavior.

Learning target: state what the learner will actually do, under which conditions, and what an observer should see. Replace “understand handoff” with “give the receiving colleague the pending task, its owner, and the escalation plan.” Tie each objective to a decision, observable response, and debrief question. A completed branch is evidence of a selected action, not proof of competence.

Case premise: describe the setting, learner role, reason the encounter starts now, prior events, and available time. Write an opening brief that gives enough information to act without revealing the answer. Keep the diagnosis and teaching explanation in facilitator material where appropriate; the format's note labels alone do not guarantee concealment in every output.

Patient story: provide a coherent timeline, baseline function, relevant history, medications, allergies, symptoms, and examination findings. Distinguish information volunteered at the start from information revealed after a question or examination. “Not assessed,” “unknown,” “not relevant,” and an explicit negative have different meanings; do not fill missing information with normal findings.

Starting conditions: specify the initial patient appearance, authored vital values, equipment already connected, interventions already performed, outstanding results, and people in the room. State what a monitor shows and what requires an examination. Include only demographic details that support the fictional person's story or learning intent; do not use a demographic attribute as an unexplained proxy for a clinical finding.

Environment: describe room layout, available and unavailable resources, substitute equipment, preparation steps, and reset requirements. Give actors a role, opening statement, knowledge boundaries, emotional presentation, response to useful questions, and escalation cue. Current actor briefs and requirement strings can hold these instructions; they do not execute actor behavior automatically.

State design: for each phase specify entry conditions, visible patient findings, facilitator observations, available decisions, expected response, alternative response, and exit condition. Give states meaningful names such as “Ownership unclear” and “Follow-up agreed.” Use enough detail that a different facilitator can run the case without reconstructing the author's intent.

Branches: include a useful approach, a plausible incomplete approach, and a recovery opportunity when they serve the objective. Describe the consequence of inaction explicitly with a timed edge if progression is required. Do not create arbitrary penalties merely to make the graph larger. Every reachable branch needs an intentional route to a conclusion.

Results and interventions: describe what was requested, what information or response returns, how long it takes, and how it changes the next decision. For a consultation, specify the service's initial response and what information it asks for. For a procedure, document the observable completion criteria and facilitator response. Current generic objects carry text and vital effects; they do not evaluate procedure technique or treatment appropriateness.

Timing: distinguish scenario duration, time since entering a state, time since requesting a result, setup time, and debrief time. In Suite, authored duration is planning metadata. Scheduled edges and delayed results use the simulated clock. Describe the facilitator's clock-advance plan and rehearse both action-before-timer and timer-before-action paths.

Cues and recovery: write the least revealing cue that helps a stalled team move forward, the condition for offering it, and how to record that help. Current tutor notes can contain a manual cue ladder. Automated conditional hints, cue counters, and adaptive assessment are format elements whose current runtime support is documented separately.

Completion: define a satisfactory stopping point, an incomplete or alternative endpoint where useful, and a facilitator stop condition. Reaching a conclusion ends the run; it does not calculate a score. Debrief should ask what the team noticed, how it interpreted the information, why it chose its response, and what it would transfer to practice.

Worked authoring plan — “A clear handoff”: the outgoing colleague provides an incomplete summary; the learner must identify the pending update and name its owner. A focused question leads to clarification. Reviewing the summary leads to a waiting phase, with an update after 30 simulated seconds. The facilitator asks for a read-back before ending. An incomplete response receives the cue “Who is following this up?” and another chance to clarify. Record cue use in facilitator observations; the current example does not implement automatic cue tracking or scoring.

Review before sharing: walk every path with someone other than the author. Check that briefs, findings, results, and consequences agree; that every result has a meaningful interpretation in the case; that no branch traps the learner; and that the debrief addresses the stated objectives. Review clinical facts and media against named, dated sources appropriate to the intended audience. Structural validation cannot establish educational or clinical validity.