This sub-series documents how cases are actually built, because a case's educational value is decided in its design long before a candidate encounters it. The first entry covers the case type this launch's emergency-medicine tracks depend on most: an emergency that genuinely changes during the encounter.
Starting from what the examination tests
An evolving emergency case exists to test recognition of change, reassessment, reprioritisation, escalation and communication under pressure. The design begins by specifying which of these the case is primarily testing, since a case trying to test all five equally usually tests none well. A case built around escalation timing is designed differently from one built around reassessment after initial treatment.
Deciding what changes, and when
The change must be clinically plausible for the presentation, specified precisely in the case's source material, and timed against what the candidate does rather than a fixed clock alone. A patient who deteriorates regardless of appropriate initial management tests something different from one whose deterioration reflects a missed or delayed action, and the design must decide which the case is testing. Both are legitimate; conflating them produces a case that punishes correct management arbitrarily.
Planting the escalation point
The case specifies the point at which escalation is expected, the safety-critical action whose timing is assessed. Too early and the case cannot distinguish appropriate from reflexive escalation; too late and a candidate who escalates appropriately is not credited. The clinician reviewer checks this point against real practice, since an escalation threshold that would not hold in an actual department teaches the wrong instinct.
Specifying the information release
What the simulated environment volunteers and what it withholds until asked determines whether the case tests recognition or merely rewards being told. An evolving case that announces its own deterioration tests nothing; one that presents changed observations only when reassessment is performed tests exactly what the examination assesses.
Writing the feedback before the case is finalised
Each feedback point is drafted against the case's design: what a missed change looks like in a transcript, what delayed escalation looks like, what a vague escalation message looks like. Writing feedback first exposes cases where the design cannot actually produce the evidence the feedback would need, which is a design fault to fix before release.
Testing against unexpected candidates
Before release, the case is run against deliberately atypical approaches: a candidate who escalates immediately regardless, one who never reassesses, one who asks irrelevant questions, one who attempts to close the encounter early. The case must behave plausibly and the feedback must remain accurate across all of these, not only against the expected competent approach.
Clinician review and sign-off
The case then passes the seven-point review, clinical plausibility, examination fit, jurisdiction, marking domains, safety-critical design, feedback quality, and dated approval, with an emergency-medicine reviewer specifically. Only then is it released, across web and app together.
Why these notes are published at all
Most educational technology treats its content-creation process as proprietary and invisible to the end user, which leaves learners with no way to judge whether a case's design reflects genuine clinical and educational rigour or convenient narrative shortcuts. Publishing the actual design reasoning behind a case type, including the specific trade-offs and failure modes considered during construction, is a deliberate transparency choice consistent with the clinician-review methodology this cluster documents throughout, treating case design as a discipline worth showing its working for rather than a black box candidates are simply asked to trust.
What future entries in this sub-series will cover
Subsequent entries will work through the design challenges specific to other case types this cluster's articles describe: building a psychiatric station that avoids stereotyped portrayal while still testing structured risk assessment, constructing an examiner-challenge sequence for an oral-boards format that feels genuinely probing rather than scripted, and designing multi-domain CPSA cases that test consultation, interpretation and professional judgement together without any single station becoming unfairly overloaded. Each entry will follow the same honest structure this first one does, the design reasoning, the trade-offs actually considered, and the testing that happened before release, rather than presenting finished cases as though their design were self-evident.
Frequently asked questions
Why not make every emergency case deteriorate?
Because recognition is only tested when change is not guaranteed; a mix of evolving and stable cases means a candidate cannot assume deterioration and must actually assess for it.
How is plausibility of the deterioration checked?
By the emergency-medicine clinician reviewer against real practice, so the change, its timing and the expected escalation threshold reflect genuine departments rather than dramatic convenience.
What happens when a user reports an evolving case behaving implausibly?
The report enters investigation, clinician review, regression testing against the atypical-candidate set, and re-release, the process documented in the continuous-improvement article and reported in the monthly What's New series.