Could you imagine sitting at a lecture at a meeting and the presenter was typing the information to create the slides while theydelivered the lecture? I believe it would be maddening, particularly if the person didn’t type very well! Well folks, that is akin to what you are doing when you run your SimMan scenarios “on the fly”. Actually it is likely worse. I am writing this post in the context of SimMan because that is the system of which I have the most hands on expertise, but this story applies to almost all of the commonly available computerized patient simulators available at the present time.
Begin by asking your self, why do I create a PowerPoint to use during my presentation ahead of time, instead of in front of an audience? The answer is because you want to pre-populate, or preprogram frames of information grouped together to help your audience understand what is going on. The information that you are likely pre-populating your slides with is likely to complex, or at least too cumbersome to type out in front of the audience. In addition, you likely save your PowerPoint presentation so you can use it again and deliver the same or similar presentation with some consistency, I would ask you to realize, that this same thought process could be applied to the preprogramming of the simulator presentation during a scenario.
When you use a computerized simulator during a scenario, you are asking the participant to look at the frames of information that you are presenting to them. The individual vital signs, perhaps a sound or some other visual aid may all be part of what you want them to see. They begin to interpret your story usually in the context of a clinical situation requiring their interpretation, analysis and treatment or decisions.
As you allow the story to evolve in response to their actions or inactions, the simulator may changes states. For instance, in response to a proper treatment, you may want the vital signs to improve. Think of this as when you want to tell something different in your presentation you witch to another PowerPoint slide. Why? Because you want to present the next frame of information to the audience.
No matter where I travel in the world there is a common theme that I hear regarding SimMan scenarios. That is to say that people say “we tried programming and that didn’t work, so now we do run them on the fly.” When I ask for more details the story is usually the same. Participants always do things that we aren’t expecting and we need to “take over” is a common response. There is a feeling that when you are in a preprogrammed scenario as a simulator operator that you are trapped. Guess what? This feeling may be valid depending on the style of programming that is employed.
Also think of it from a different angle, one of my previous blog post points out the complexity of vitals sign changes that need to change during a course of worsening hypoxia. I argue that it is essentially impossible to change everything in the same way every time a scenario is run. So in essence, you lose the ability to generate consistency in running your scenarios. This consistency, or reliability is important to achieve when using scenarios as assessments.
What is the problem? The Trainees? The Operator? The Software? The Programmer? I would submit that the software systems that accompany most patient simulator these days are quite sophisticated with very deep capabilities. Most of us only learn them superficially at best. Further, those who take classes usually learn from a representative of the company who sold the equipment and there style of programming often doesn’t match reality.
Well the first lessen is participants ALWAYS do something unexpected, or at least almost always. So therefore if your scenario programming STYLE boxes you into a corner when the unexpected happens, you should change your ways, not abandon the work!
One of the best ways to get started with a comfort zone of using programmed scenarios is to use the software to create your initial set of vitals. If you think about it, just setting vitals alone causes a significant amount of task loading at the beginning of the scenario. If a patient is in shock, you would likely at a minimum, change the heart rate, pulse rate, resp rate, oxygen sats, End tidal CO2 and on and on. All of this if of course depending on the complexity and depth of clinical information you are trying to control for a given scenario.
I think of the example above every time I get to drive my wife’s car. I sit in the drivers seat and push a button labeled ‘[Driver] 2’. When I do this, the seat moves, backwards, reclines slightly, the steering wheel moves away from me and down a bit, and the mirrors adjust to where I had them previously. Brilliant! Pushing one button set so many things that I may have to adjust manually. This saves time and ensures a consistency in my experience when driving her car.
The properly pre-programmed scenario offers you quick set up (like my wife’s car), flexibility, consistency in presentation, ways to deal with unexpected, and maybe most importantly, helps allow you to observe the scenario more closely and worry about the simulator less.
This can be accomplished through an increased understanding of what the software can do, and a realistic application to your scenario objectives. Start by unlinking your changes in the vital signs or condition changes to the events playing out in front of you. Create menu items that have the simulator presentation get worse or get better, that you can trigger based on what you think should be happening based on the action or inactions of the participant(s).
Think about taking some small steps into embracing the pre-programmed scenario into your armamentarium of simulation tools. Do yourself a favor and take a simulator programming course from someone who is not a hardware company rep. Done properly, I promise you it will expand your capabilities as a simulation educator. It will also allow more flexibility in your scenario designs and increase the consistency when you run a given scenario.
Lastly, changes in the simulator condition is just part of the power of the software that you already own if you have a Laerdal Simulator. There is so much more to talk about in trying to convince you of the power that lurks inside your SimMan! I haven’t even begin to cover other technological assistance that can help with debriefing accuracy, structure and consistency, automating data collection and on and so much more!
With just a small investment in time and perhaps an adjustment to style, you can significantly boost the productivity of your Simulation program. So fear no more, take the deep dive and learn more………
5 responses to “Running Scenarios “On-the-Fly” is Like Typing PowerPoint Slides in Front of a Live Audience”
I’ve always said the pure “on the fly” approach was like writing the play as you staged it. Programming doesn’t constrict you, it provides the framework to allow those beautiful moments of necessary improvisation to shine!
So well stated…. Lah.
Essentially agree with much of what you have stated. To not use the simulator to its various possibilities and functions can be very detrimental, and also time-wasting as well as wasting the resource that is a highly functioning simulator. (note, I am deliberately stating simulator since the same principle applies in computer-based sims, VR, etc) Where I think I might add some thoughts to complement what you have stated is that I believe there to be a need to be able to diverge and go ‘on the fly’. Just as one part of theatre is improv (Christine’s example) and one part of teaching using ppts is to diverge and discuss a question that comes up, there is value in recognizing where learners–especially the advanced ones, take a track that is unexpected and often surprising to us as the educators/operators of the simulator. Essentially, on-the-fly is a version of a stochastic mode of using simulators (pertaining to a process, model, or variable whose outcome, result, or value depends on chance). Given the unpredictable nature of the human system, advanced learners can have curves thrown at them based on the goals and objectives of the session (not every human reacts the same way when given 1 mg of Epi for instance), especially if the goals/objectives are about teamwork, critical thinking, clinical decision-making etc. Additionally, chance applies to your learners as well when they do something like giving atropine for an SVT. So I very much like the on-the-fly as an option. IF, and yes, a big IF, I have done my preparation and preprogrammed so that my adaptions are not made up/improper. No, I can’t predict everything, so I still can make things up if absolutely needed. BUT, I can learn how to program, how to adapt, and how to use the full abilities of the simulator. NOTE–for earlier learners, I am much more likely to go deterministic–preprogrammed/stick to the script.
I am convinced that most divergences from our expectations of learner decisions and actions can indeed be anticipated. If the objectives are clearly identified, the most common mistakes are already known by the experienced educator. In my observations of the proponents of “on the fly” method of scenario implementation or operation the reasons for doing so, are not the real reasons that they don’t pre-program. I know that sounds rather presumptive, but after talking to hundreds of sim educators, primarily in nursing schools, when I make a case for being able to anticipate learner actions, the real reasons come forth. The primary reason stated for NOT pre-programming is time. The second reason is the complexity of the programming itself. I know it takes about 70 hours to program a relatively complex scenario. Then a validation process begins.
On the fly operation is the lesser of the two methods when research relies upon clearly identified variables. This takes time and energy. I am not saying that there isn’t a place for on the fly operation. However, until we are honest about why we prefer one method over another, I think we are figuratively using a hammer when precision instruments are called for.
Michael, in general I agree with the comments of your post, certainly respect your work. However I do take exception with the 70 hour go quote on programming scenarios. We find with careful
Discussions between subject matter experts and talented programmers, combined with a standard methodology for programming we greatly reduce the time commitment to programming and increase the quality of our results.