PROGRAMMING PEOPLE: PART 1
Apologies for the delay in the (planned) fortnightly article, pesky minor inconveniences such as parenthood, and holding down a job in a foreign land have been tickling my procrastination bone.
And apologies in advance to all Charlies and Kims out there…
In this article we are going to begin to look at ways that simulators can be programmed.
Programmed you say? Well yes, I’m going to be using the word programming a *lot* in this article, and I make no apologies for doing so.
I am NOT a programmer. Real programmers use real programming languages, I’m just using the software as provided by the simulator manufacturer.
However, I’m using the software to generate a nested series of IF>THEN>ELSE loops and triggers in order to change the simulated patient’s condition.
The simplest example I can give is this, in the case of a patient struggling with an unspecified breathing problem
IF (Oxygen is applied) THEN (Raise Saturation) ELSE (Do nothing)
We can make this more sophisticated by asking how much oxygen is applied. By which method? And when in the scenario? But the principle remains the same.
THEN (Alter the patient’s condition),
ELSE (Do nothing, or further deteriorate the patient)
Well, it looks like programming and smells like programming and…oh, delicious, this programming is beautifully cooked! It also works like programming, which is a bonus.
In my own simulation environment, where we don’t have the time, space or resources available to moulage or make up the patients and rooms, we need to try and introduce quality into our simulations in other ways. Programming the physiological responses of the simulator is one of these ways.
Much more on this later. Woo!
PROGRAMMING IS A DIRTY WORD
Traditionally and sadly currently, programming is seen as a substitute for medical knowledge and experience. I believe that when used effectively it can only augment and strengthen the delivery of medical simulation.
Operators; those that “drive” the simulators, respond verbally as the patient, and manage the physiological parameters of the patient via the software, fall veeeery broadly into two distinct camps.
- Experienced healthcare practitioners (HCP) that have “seen everything”
- Non medically qualified technicians/engineers/IT nerds/weirdos
And programming the simulator has itself traditionally taken one of the following forms
- Start parameters, lung and heart sounds etc. are set up for the beginning of the scenario and any changes or interventions are handled live “On the Fly”
- The patient moves from one hard wired state/set of parameters to another after a specific time, specific intervention or at the direction of the session leader. We’ll call this “Storyboarding”
“THERE IS NO SUBSTITUTE FOR EXPERIENCE”
Let’s call our experienced HCP Kim, for gender neutralities sake, and because I don’t know anyone called Kim. Kim has worked in emergency medicine and on the intensive care wards for many years, they have seen just about every simulatable situation there is. Kim trusts in their knowledge and experience, we trust in Kims knowledge and experience and many patients have trusted in Kims knowledge and experience. Kim prefers to drive the simulator “On the Fly”, because of the wealth of anecdotal knowledge available to them. Kim doesn’t like to Storyboard their simulations, they know what a Septic Shock looks like, and they have seen Septic Shock many times and are happy to trust themselves to manage the numbers and patient responses without relying on programming. After all, it’s received knowledge that we don’t know which interventions the participants are going to perform, or in which order.
However, from day to day, and from session to session, Kim remembers a different Septic Shock on a different patient, in a different place with a different level of care, with different vocal responses and demeanor on behalf of the patient. These inconsistencies play a part in making the rest of the team unsure as to how the session is going to go, especially when it is a session that is likely to be repeated or even run in parallel, or when the other instructors aren’t familiar with Kim. It’s pretty much all down to Kim (but Kim likes this!) They may even feel threatened or slighted by the idea that their expertise isn’t being called upon if the simulation relies on programming (but they shouldn’t)
When the goal of the simulation part of the teaching session is to illicit some sort of Crew Resource Management based teamwork that can be discussed during a structured debrief, it can be an advantage to have some idea of how sick the patient is going to be that’s not based on the whim of the operator. Additionally, despite Kim’s wealth of experience, they are likely at some point to make a mistake. CRM debriefing a group of participants is challenging enough without then folding their arms and thinking, “Well, medically, that was bullshit, so why are we taking it seriously?”
A TEXTBOOK EXAMPLE
Let’s introduce our Technical Wonk, and let’s call them something gender neutral and non-familiar like Charlie.
Charlie doesn’t trust in their medical knowledge and feels sure they are going to miss something if they drive “On the Fly”, Charlie, however has consulted patient cases and textbooks and has constructed a Storyboard in the programming that matches exactly that patient on that day in that textbook as treated at that time by that team.
Patient presents as sick, patient gets worse, the team works, patient gets better. That’s the plan and generally speaking it’s a sound one. The physiological parameters fit the disease state, the simulator can be programmed to have a deteriorating condition over time and at the click of a button, the patient improves to a point where we are satisfied that the learning goals of the session are met and nothing is missed. After all, it is documented medical fact which interventions should take place for a particular disease state, and in which order.
This case can be repeated with the same results across multiple dates, across parallel sessions with predictable consequences.
However, this approach assumes a lot, not least of which is that the participants come to a specific diagnosis and the correct treatment plan. As the physiology is “hard-wired” in obvious stages (Sick, deteriorating, recovering) it can leave participants feeling that they didn’t really participate in a way that affected the patients’ recovery directly, rather than the patient became better in some semi arbitrary manner after an amount of time had passed, or enough treatment boxes where ticked. Challenging enough to CRM debrief a team without participants crossing their arms and saying “That may as well have been numbers on a screen, and I don’t feel part of a team”
Clearly, I’m oversimplifying things to emphasize my own point of view (It’s my blog and I’m allowed to!) But we’ve all worked with individuals that remind us of Charlie or Kim and recognize and appreciate the strengths and weaknesses of their own approach to simulation even if they don’t.
And again, there are many more ways to program simulators and simulation, I’ve just taken two of the most recognizable examples which, handily, happen to be polar opposites of each other.
But they don’t need to be.
As outlined in a previous article, we run an absurd amount of simulation, across multiple and parallel sessions with huge cohorts of students. What we know is that the participants crave consistency, they talk to each other before and after and compare their experiences, even when we ask them not to, y’know?
It is UNFAIR for one group of participants to suffer a poorly executed simulation session when the poor execution is entirely avoidable and down to inbuilt inconsistencies or inflexible programming.
Our simulated patients can’t be based on Kims anecdotes, as there is only one Kim.
Our simulated patients can’t be That patient in That case study treated by That team as it’s not That team.
In each of our sessions it is always This patient in This room treated by This team (But also, This patient in That room treated by That team)
So how do we do that?
I’m splitting this article in two, it is long enough already.
So, in the next exciting installment of The Simulated Man I’ll be introducing the approach to programming that I’ve developed here at Akademiska University Hospital
In the meantime,