I have been interested in the topic of preparing students for a patient death ever since we used to run an unsuccessful mock code with nursing students on the last day of their pediatric simulation rotation. This was done at the request of the pediatric faculty back in the days when we didn’t understand much about simulation education and training. She wanted the students to do the activity and then experience the sense of loss. She had come up through the ranks as a pediatric oncology nurse and wanted their first patient death to be in a controlled (as much as we could control things back then) environment. I did get the requesting person to accept my telling one student in the group ahead of time that it was going to be unsuccessful. I felt this was necessary to avoid the group feeling they “failed” and we were just not being honest about their incompetence. Having one of their own support us when we told them the truth was critical to regaining their trust on more than one occasion.
We have “evolved” since then; we no longer do any death scenarios with nursing students, but the memories and emotions of those exercises have stayed with me. Off and on over the years I’ve looked at the literature on the topic of simulation and training for death. While no expert on the matter, I have come to believe we are doing students a disservice by either (a) ignoring the subject of death in their training, (b) treating death as a certainty only in the elderly, or – in the case of resuscitation drills -- (c) making patient death equal to provider failure.
At the IMSH in 2016, I sat in on a panel discussion on the “death of the manikin”. The panelists were experts in the field of medical simulation and, while they agreed that manikin death was reasonable in end-of-life scenarios where the learners knew what was going to happen, the two groups disagreed when it came to learner performance in mock code drills. For the pro-death (YES) panelists, the manikin should be allowed to die if the actions of the learners warranted it. The people with the opposite position (NO) felt the scenario should be stopped prior to flat-line because the learning essentially stops or cannot proceed when emotions have taken over one’s intellect. The members of the YES group were adamant that if you were going to learn to do codes correctly, you had to suffer the consequences of not doing them correctly. Likewise, the NO group felt that when a code scenario was going south it should be stopped so people could discuss it rationally without the emotional burden of having watched the patient “die”.
Neither side in that debate considered the probability of a lack of success in a mock code. I know this because I asked this during the Q&A and was met with rather puzzled looks from both camps.
The probability of success in an in-hospital resuscitation is between 35 and 45%, depending upon whose numbers you use. If these are accurate estimates, over half of in-hospital code situations are unsuccessful. Does that mean over half the code teams in the world are failing to perform resuscitations adequately? I don’t think so. I think sometimes you can do everything right and the patient is still not going to survive.
I believe there is a better way to handle the issue of death in training healthcare providers. What if we set up our mock code drills such that the probability of success was factored in? Think of a simulation where you have ten envelopes containing ten index cards. Four cards are printed with “Successful” and six with “Unsuccessful.” This would approximate the real probability of a successful resuscitation. During the briefing, after the case has been laid out for the learners, ask one of the students to select one of the ten envelopes and hand it to the manikin operator. Then tell them the truth – they have a four in ten probability of success. Six out of ten times death is going to happen, no matter what they do. They are to do their best and practice what they have learned. Whatever happens will happen; either way, it will all be discussed in the debrief. Based upon what’s on that card, the operator will follow a specific flow. Regardless of the actions of the learners during the scenario, the operator would follow that flow to its conclusion unless directed by the facilitator to alter it. If the designated path is for success and a serious error is made, the facilitator could direct the operator to switch to the unsuccessful path. All things being equal, if the plan is for the patient to survive, the patient would survive. Similarly, if the participants are doing a great job on all the learning objectives, the facilitator can direct the operator to move to the successful path. Only at the end of the debrief do the learners see what was on the card. By that point in the simulation, the debrief should have covered any serious mistakes made during the exercise. The participants would understand what they did incorrectly and not be surprised at seeing that the patient should have survived. Similarly, after going over the events and working through any possible shortcomings in performance, if the card showed “Unsuccessful” the participants would be able to see that the lack of a successful resuscitation was preordained, not caused by anything they necessarily did or did not do.
My idyllic scenario makes several assumptions that may not be true. First, it assumes the facilitator would be able to catch a serious error or remarkable actions during the mock code and dispassionately direct the switch in the flow. Second, it assumes a level of debriefing expertise in the facilitator that may not exist. Third, it assumes the participants are sufficiently prepared and have sufficient expertise and maturity to objectively evaluate their actions. These are important factors in the success of any simulation. In a potentially unsuccessful resuscitation exercise, they are absolute necessities. Therefore, I do not recommend anyone embark on creating a probability-based mock code drill lightly. Rather, consider it as an idea for future growth in your program. If you were to use this method, would you have the requisite structure in place to make it successful?