Intensive Care Unit Soft Skills Tutorial
Overview
This concept project is a branching scenario intended for healthcare professionals who work in an Intensive Care Unit (ICU). The tutorial takes the learner through a difficult conversation with the family of a patient and introduces the learner to the SPIKES Protocol. SPIKES is a tested strategy for communicating bad medical news. The protocol can give ICU healthcare professionals a memorable guide during stressful conversations and when speaking with upset families. The tutorial was developed using Articulate Storyline and Twine and implements xAPI and JavaScript to track learner experience and behaviors.
The Client’s Problem
This concept project imagines a healthcare client, an integrated health system with multiple hospitals, who came to me asking for soft skills training for the following problem.
Healthcare professionals in ICU settings must often convey bad news to patients’ families. When done poorly, these conversations can increase family members’ grief, shock, or anger. These strong emotions can then lead the family to make suboptimal decisions.
ICU medical workers are reported to frequently break devastating news in a blunt, hurried manner. They do not adequately prepare the family or confirm the family’s understanding of the patient’s situation. Family members then react with anger or uncontrolled grief that begins to drive the family’s decisions.
Upset or shocked family members often center the conversation around their own emotions and make declarations like “I just can’t allow him to die” or “I’m not ready to let him go.” Then the meeting becomes about the family’s grief rather than the patient’s wishes and well-being. A cascade of medical interventions begin that ultimately bring more harm and suffering to the patient.
ICU healthcare professionals need to learn how to avoid escalating families’ emotions and how to defuse situations where a family member’s personal grief is steering decisions.
Solution
Several protocols and evidence-based conversation strategies for healthcare professionals already exist. In consultation with a SME, I selected SPIKES as the ideal starting point because the protocol centers on delivering bad news.
I decided that an eLearning solution provided an ideal solution to the problem. ICU workers need not only a strategy, but need to practice and get comfortable with that strategy. I considered in-person roleplaying activities as a strong solution, but the imagined client in this case did not want to budget for repeated Instructor-Led Training. Instead, the client wanted a solution that could be given to new employees whenever they were onboarded and that could be delivered to employees at multiple hospitals dispersed across the region.
eLearning, with its strong potential for branching scenarios and providing tailored feedback, seemed to offer the best solution. A scenario-based tutorial offers learners the opportunity to practice and to see the SPIKES strategy in action with on-the-spot feedback while also meeting the client’s budget.
Design Theory
Inspired by Cathy Moore’s “Map It” approach and in line with recommendations to enable learners to “learn by doing”, the course begins with minimal information and plunges the learner into the conversation scenario.
Feedback from the “family” during the scenario provides the learner with some sense of their mistakes and wise choices. Only at the scenario’s conclusion is a full description of the SPIKES protocol along with additional information presented. Learners can focus on areas where they had problems and then try the scenario again if they wish.
This story-driven approach puts the learner immediately into the “action.” It is more engaging than a traditional approach that would simply present the learner with information about the SPIKES protocol. Since medical workers will need to navigate conversations, not recite the definitions of the protocol, the scenario focuses on the actual behaviors and decisions that the client wants from the employees.
Course Feedback and Resources
Design and Development Process
Research: I conducted interviews with a Subject Matter Expert (SME) who has over a decade of experience working in an ICU. These interviews identified common conversation errors made by ICU staff as well as families’ common misunderstandings or flawed decision-making processes.
Script and Storyboard: I developed an initial script that was then reviewed by the SME. After incorporating the SME’s feedback, I developed a storyboard and then mapped out the branching scenario using the app Twine.
Twine app for tracking branching scenario choices
Development: I developed the final project in Articulate Storyline using Articulate assets and icons from flaticons.net.
Features:
Each choice by the learner shapes the family’s next reaction and can lead to different routes through the scenario.
The learner’s choices contribute to a hidden, overall score that determines the final outcome of the conversation.
The conclusion shows the user what parts of the conversation they did well in and where they need improvement.
Further information for each area of strength or weakness is provided as well as an opportunity to retry the conversation.
Sample of triggers and variables used to track and display the results of user choices
xAPI Implementation
xAPI tracking of learner behaviors supports the course’s instructional design and strengthens further iteration.
Tracking answers: Each time a learner selects an answer, an xAPI statement is generated. This enables me not just to see a final score and pass rate (typical of SCORM), but to be able to identify which questions are presenting the greatest challenge and even which distractor answer is proving to be the most distracting. This information can help to identify a question that needs to be made easier or more difficult or whether additional information or training on a topic may be required.
Time spent (or Duration): This course uses xAPI to track how long a learner spends on the course as a whole as well as how long the user spends on each individual question. This information provides further insights into how challenging the course is, whether users are engaged, whether particular questions require significantly more reflection than others, and whether users are failing certain questions because they are rushing.
Resources consulted: An xAPI statement is sent to the LRS each time a learner consults one of the course’s optional resources. Additionally, a statement is generated when a learner opts to “re-take” the course after consulting the selection of resources on the final feedback page. This information allows me to analyze whether users are consulting resources, possible connections between resource usage and users’ scores and/or specific incorrect answers, and whether consulting resources and trying the scenario again improves a learners’ scores.
xAPI Statements generated by this course
Browser focus: The course tracks when users minimize the course, switch to another window, or switch to another tab. This helps to reveal pain points in the course where users’ attention may be flagging or where they have to find and consult resources on their own. In turn, this enables further refinement of the course and indicates sections where additional resources or engagement may be necessary. I have written a tutorial for implementing this code.
User ID: Each learner is given a unique, anonymous, random ID associated with their browser cache. This facilitates tracking multiple users who might be using the course simultaneously as well as enabling the analysis of user behavior across multiple sessions.
Summary: Taken together, my xAPI implementation enables me to track precisely how users are navigating through my course. It also makes possible insights into how specific learner behaviors and choices correlate with learners’ scores, individual answers, resources consulted, and time spent on the course.