Start with the performance, not the product
Simulation technology is useful when it lets learners practice a meaningful clinical action, see the consequence of a decision, or make their performance available for feedback. The product itself is not the learning activity. A manikin, virtual environment, monitor, or game engine is a setting and a set of capabilities; the educator still has to design the experience.
Use this sequence before selecting a platform:
- Name the educational gap.
- Write the learner behavior that would demonstrate the objective.
- Identify what the environment must sense, display, or allow.
- Choose the lowest-complexity approach that can do those things credibly.
- Decide how learners will receive feedback and how performance will be evaluated.
For example, if the objective is to apply a tourniquet correctly, the decisive technology feature is controllable bleeding and realistic limb compression. A full-body manikin’s heart sounds, speech, and physiologic model may add cost without helping that objective. If the objective is to lead a resuscitation, the important features may instead be a responsive monitor, evolving patient states, team roles, workload, and a reliable event log.
This is curricular fit: the objective, content, activity, technology, and assessment all point toward the same learner performance. Technology selected only for novelty or excitement can become busy work, add avoidable cognitive load, and compete with the measured curriculum.
Use precise language about fidelity
Terms such as high fidelity and low fidelity are imprecise because fidelity is a continuum and depends on the learner, the objective, and the function being represented. It is more useful to separate the technology from the experience.
| Term | Practical meaning | Design implication |
|---|---|---|
| Technology level | The complexity and capability of the tool or platform. | Describe the functions you need instead of using high or low as a product label. |
| Functional realism | How credibly a specific function behaves, such as chest recoil, bleeding control, airway anatomy, or monitor response. | Test the exact function tied to the objective; a long feature list does not establish realism. |
| Experiential fidelity | How convincingly the entire scenario represents the relevant practice for the learner. | Narrative, roles, cues, timing, and consequences may matter more than hardware. |
| Physical or environmental fidelity | How closely the body, equipment, or setting resembles the clinical environment. | Include only the realism needed for learner action and transfer. |
| Psychological or emotional fidelity | Whether the experience creates the attention, uncertainty, responsibility, or social pressure relevant to practice. | Build challenge deliberately without using surprise or threat as a substitute for good design. |
A monitor-only case with strong narrative and realistic decisions can create a highly credible experience with modest technology. An expensive manikin in a clinically incoherent scenario can produce the opposite. Describe what must be realistic and why rather than calling the whole simulation high fidelity.
Understand how the manikin will respond
The way a manikin changes during a scenario affects consistency, operator workload, and the risk of teaching an implausible physiologic relationship. Three operating approaches often overlap in current systems.
| Operating approach | How it works | Strength | Risk |
|---|---|---|---|
| Manual input, or running on the fly | The operator changes vital signs, rhythms, sounds, and other parameters as the case unfolds. | Flexible and quick when learners take an unanticipated path. | Responses depend on operator attention and knowledge; related variables may become inconsistent. |
| Physiologic modeling | A mathematical model changes linked variables in response to an intervention or altered parameter. | Can produce coordinated responses and reduce manual workload. | No model reproduces every patient accurately; the system may behave unexpectedly or make a target value difficult to produce. |
| State-based modeling, scripting, or a finite-state approach | The author defines patient states and transitions triggered by learner actions, time, or events. | Supports reproducibility and lets several parameters change together. | Quality depends on the author’s clinical logic, programming, testing, and handling of alternate learner actions. |
The safest plan is not necessarily the most automated one. Select the approach that supports the objective and that the team can run reliably. If using manual input, script expected physiologic relationships and assign an operator who can focus on the manikin. If using a physiologic model, test the full scenario rather than assuming the model will produce the desired course. If using states, define both expected and off-path transitions and be cautious about overriding a running script in ways that break its internal logic.
Prevent negative teaching
Technology can teach the wrong lesson when a function looks plausible but behaves incorrectly. Examples include chest compressions with unrealistic resistance, persistent blood pressure after prolonged apnea, or a treatment that produces an inappropriate monitor response.
Before learners use the case:
- Test every function that is essential to an objective.
- Walk through the expected learner path and at least one alternate path.
- Check that linked findings change together in a clinically coherent way.
- Confirm what the operator may change during runtime without breaking the model or script.
- Decide how the facilitator will narrate any limitation during the prebrief.
Distinguish a virtual setting from a designed experience
A virtual environment provides a digital place in which activity can occur. It does not create learning simply by existing. A designed experience adds a role, goal, relevant decisions, consequences, feedback, and a connection to the curriculum.
Related terms help clarify the design:
- Virtual simulation: A simulation that occurs primarily in a digital environment, such as a screen-based patient encounter, branching case, or immersive world.
- Game-based learning: Learning organized through rules, goals, challenge, feedback, and meaningful consequences within a game or game-like system.
- Gamification: Selected game elements, such as progress indicators or levels, added to a non-game activity. Points and badges alone do not create a meaningful simulation.
- Minigame or tutorial: A short embedded activity that teaches navigation, equipment use, or another prerequisite before the main clinical task.
- Metagaming: Use of resources outside the immediate game to support success. In clinical education, consulting a reference, diagnostic result, or team member may represent authentic information-seeking rather than cheating.
- Hybrid simulation: A learning sequence that combines modalities, such as virtual triage followed by management of the same patients with manikins or standardized participants.
The central question is what learners will do. A visually accurate emergency department without a purposeful task is a virtual tour. Add a clinical role, time-sensitive decisions, consequences, and feedback linked to an objective, and it becomes a designed learning experience.
Design for motivation without confusing fun with learning
Engagement is strongest when the activity feels relevant to the learner’s present or future practice. Game elements should support that intrinsic value, not cover weak alignment with rewards.
Ask:
- Does the activity represent a practice learners use now or will use later?
- Do learners make clinically relevant decisions rather than merely click through content?
- Do those decisions produce varied and appropriate consequences?
- Does the system provide timely, interpretable feedback?
- Does advancing in the experience represent increasing mastery rather than simple completion?
Orientation is part of the design. Learners should have a low-stakes way to learn controls, navigation, communication tools, and help systems before those mechanics affect clinical performance. When the objective is clinical reasoning, do not accidentally assess familiarity with a controller or interface.
Choose the modality by its affordances
No single technology is best for simulation. Match the modality to what it makes possible.
| Educational need | A useful starting modality | Required function to verify |
|---|---|---|
| Practice a discrete procedure | Task trainer or mixed physical-virtual trainer | Anatomical landmarks, tissue response, tool compatibility, and performance feedback |
| Manage an evolving unstable patient | Manikin plus monitor, or a screen-based patient | Coherent response to actions, observable decision points, and reliable state changes |
| Practice history, empathy, conflict, or disclosure | Standardized participant, conversational virtual patient, or hybrid format | Natural interaction, consistent role portrayal, and safe handling of emotional content |
| Rehearse team leadership and coordination | In-situ, manikin-based, virtual multiplayer, or hybrid simulation | Roles, communication channels, workload, shared cues, and team-level observation |
| Practice rare events across distance or asynchronously | Standalone virtual simulation or branching case | Clear instructions, access, compatibility, help, saved progress, and feedback without a live instructor |
| Orient learners to a location or workflow | Virtual environment, walkthrough, or short tutorial | Accurate spatial and process cues without irrelevant detail |
Mixed approaches can bridge gaps. Learners might triage a mass-casualty event asynchronously online, then receive the same patients in a team-based simulation lab and debrief the transition from scene decisions to emergency department care. The modalities should form one learning sequence rather than two unconnected activities.
Select and purchase for the whole program
The purchase price is only one part of a technology decision. A technically capable product can still fail if the program cannot staff, maintain, integrate, or schedule it.
Use this selection checklist:
| Domain | Questions to answer before committing |
|---|---|
| Educational fit | Which learners and objectives will it serve? Which exact functions are essential? How often will it be used? |
| Functional test | Have intended users tested those functions in a realistic scenario? Could any function teach an incorrect technique or physiologic relationship? |
| People | Who will design cases, operate the system, teach, maintain it, and cover absences? How much initial and ongoing training is included? |
| Infrastructure | What space, network, power, ventilation, gases, compressors, monitors, cables, accounts, licenses, or device integrations are required? |
| Content and data | Are scenarios included and editable? Can event logs or performance data be exported? What privacy, accessibility, and retention requirements apply? |
| Reliability | What commonly fails? Can staff repair it locally? What is the expected downtime and the replacement or loaner plan? |
| Support | What do the warranty and service contract cover? How quickly is help available? Who tracks renewals and manufacturer accounts? |
| Total cost | Include staff time, training, accessories, consumables, software, maintenance, repairs, upgrades, storage, and eventual replacement. |
See the product in use and test the exact scenario functions before purchasing. Speak with several current users, including technical staff, rather than relying only on a demonstration. If the purchaser is not the end user, document the required accessories, service terms, department owner, account contact, asset identifier, and renewal dates so responsibility does not disappear after the purchase.
Build the operating and failure plan
Technology-supported cases need two linked plans: how the system should respond when it works and how the teaching will continue when it does not.
Create an operator map before the session:
| Case event | Expected learner action | Technology response | Operator or trigger | Backup cue |
|---|---|---|---|---|
| Patient becomes apneic | Recognize respiratory failure and ventilate | Respiratory rate falls; oxygen saturation and heart rate trend appropriately | Scripted state or manikin operator | Facilitator announces absent respirations and trends the monitor manually |
| Learner gives treatment | Reassess response | Relevant findings improve, worsen, or remain unchanged | Sensor, operator input, or virtual rule | Facilitator provides a timed response card or verbal update |
| Team requests unavailable data | Seek additional information | Result appears through the expected clinical channel | Confederate or virtual interface | Facilitator supplies a printed result |
Test the primary plan in the actual room, on the actual network, with the actual accounts and accessories. Then test the backup. A backup is adequate when it preserves the same learner decision and debrief hook, even if it reduces realism.
During the prebrief, state limitations learners need to know. During a failure, pause, narrate, redirect, restart, or stop according to the risk to the objective and the learners. In the debrief, acknowledge technology problems directly so learners are not blamed for cues they could not perceive.
Evaluate the learning and the technology
Technology captures many events, but available data are not automatically useful evidence. Collect measures that answer whether the designed experience worked.
Evaluate at three levels:
- Learner performance: Did learners demonstrate the target behavior, make better decisions, improve with repetition, or transfer the skill to a later setting?
- Educational implementation: Could learners access and understand the activity? Did orientation, facilitation, feedback, and debriefing work as planned?
- Technology performance: Did the platform behave reliably and credibly? How much staff time, troubleshooting, downtime, and support did it require?
Useful virtual-simulation data may include decision paths, time in a state, resource use, repeated attempts, or time to resolution. Interpret those measures against the objective. A shorter completion time may reflect mastery, guessing, or familiarity with the interface. Pair system logs with observation, learner reasoning, and debrief findings when the distinction matters.
Treat implementation as iterative. After each run, decide what to keep, revise, or remove. Continued use should depend on learning value, reliability, access, and total resource demand, not on how much the program has already spent.
Working product
By the end of this module, create a one-page technology plan containing:
- The educational gap and learner objective.
- The observable learner action.
- The selected modality and the exact function it must perform.
- The fidelity that matters and the elements that can be simplified.
- The operating model, staffing, orientation, and test plan.
- The failure backup that preserves the decision point.
- One learner, implementation, and technology measure.
That plan turns a product choice into an educational design decision and gives the simulation team a shared basis for building, purchasing, testing, and improving the experience.
Sources Used
- Slone FL, Lampotang S. “Mannequins: Terminology, Selection, and Usage.” Chapter 3.2 in Defining Excellence in Simulation Programs.
- Bauman EB, Ralston-Berg P. “Virtual Simulation.” Chapter 3.7 in Defining Excellence in Simulation Programs.