Overview

150,000 people were placed on home quarantine during the SARS outbreak in Taiwan alone, a country with a population of just 23 million. The SARS outbreak cost the world's airlines and global economy more than the attacks of 9/11, and health experts say SARS will come back. Ignorance regarding the nature of SARS was largely to blame for it's rapid spread, particularly within hospitals. This simulation attempts to help players determine what measures are most effective in containing an outbreak of SARS in a hospital while causing as little disruption as possible to routine hospital function.

Players are presented with a small hospital, and they must make decisions regarding how incoming patients are processed and how the hospital environment is managed. Players manipulate a wide range of variables regarding symptoms, patient routing, and the hospital environment. Players can create a quarantine area, and decide how patients are handled according to their symptoms.

Once the player is finished setting all the variables, the virus appears in a random location. As the virus spreads, the player can make adjustments to the environment and human variables in a desperate attempt to control the spread of the virus. But if the player applies draconian measures recklessly, organizational problems emerge.

Instructional Objective

This simulation is meant to show players how behavior, decisions and environmental design and management affect the spread of the SARS virus. The rapid spread of SARS in the spring of 2003 was largely due to ignorance regarding how to prevent and contain the virus. This simulation hopes to teach proper prevention, monitoring, and containment procedures. Players will learn how changes in daily routines and in handling suspected and confirmed SARS cases can contain the virus.

Learners

This simulation targets health care professionals, workers, and administrators. The simulation is primarily meant for those working in hospitals, clinics, and long-term care and assisted living facilities, but it could also be of value to public officials, students, and people involved in other situations that include a high degree of public contact.

Context of Use

This game is designed to be played within the context of a wider training program for SARS taking place in the health care facility. It could be played by individuals or groups; however, given the complexity of a health care environment and the variety of stakeholders involved, players would probably benefit most by playing with their coworkers, particularly with coworkers from a variety of disciplines. It is not a multiplayer game in principle, but it supports multiple scenarios using a database, so players can compare their results. The game is meant to be played more than once, with the player testing a variety of combinations of patient and environmental variables.

An introduction to how SARS is transmitted prior to the game could serve as an introduction to the game. However, the game could also itself serve as an introduction to a workshop on SARS. Given a group of players who know little about SARS, playing the game before the workshop would probably result in high transmission rates and generally poor performance in the simulation, thus increasing participant curiosity, interest, and motivation. Repeating the game during the workshop would then serve to reinforce and demonstrate the usefulness of learned material.

Scope

This game allows the player to set variables in an environment into which a virus is introduced, and then observe how the virus spreads. The length of the simulation is determined by the player. The player can choose to run a simulation lasting only a few minutes, but it could easily take over 15 hours to conclude a more involved simulation. In fact, the player can choose for the simulation to progress in 'real time', meaning it could last for days or even weeks.

The players have to set a variety of variables that affect the transmission of the virus. The interface breaks these variables down into two categories, those for the patient and those for the environment. The variables for the patient determine where the patient will go in the hospital, and those for the environment determine how the segments of the environment can be accessed.

Object of the Game

The object of the game is to contain the virus as completely as possible while causing as little disruption to normal hospital routine as possible. Before and after the virus appears, the player decides which containment measures to implement, and most of these measures place restraints of one sort or another on regular hospital activity. At the end of the simulation, the player is scored on two performances: the extent to which the virus was contained and the extent to which normal hospital activity was not impeded.

Design Details

Underlying Model

The primary model for the simulation is based on a StarLogo simulation for the SARS virus. The StarLogo model interacts with a case-based model that essentially determines if particular turtles may enter specific segments of the environment according to variables set by the player.

Initial Game State & User Input

User input
The user needs to define how patients are processed in the hospital, and how the hospital is managed and maintained. The user uses the forms to input these options.

The variables set for the patients direct the running of the StarLogo model, while the variables set for the environment call up the appropriate state-based model for that combination of variables.

Default settings
Incoming patients arrive at the hospital with a variety of symptoms, determined by the StarLogo model. Also driven by the StarLogo model are a number of people who come to the hospital and just roam around. Though the user does not change these defaults, they do come into play when the virus starts spreading. People must still receive their treatment, and the extent to which safety settings are set unnecessarily high and hospital efficiency thus needlessly reduced, the player will receive a lower score. On the other hand, variables set too low will allow the virus to spread among the population in the hospital.

When the user adjusts the variables for the patient, these are applied to all patients entering the hospital. Patients will then continue to move in and out of the hospital according to their defaults. For example, a woman giving birth might stay for a few days, a person arriving for minor surgery might leave the same day, people coming for regular appointments will represent a steady flow, and occasional accidents will flood the emergency room.

The default setting for the sections is very low. There are no default protections. The virus will spread very quickly if the user does not create some physical 'roadblocks' for it using the environment variables. There is no default quarantine area because the simulation assumes a pre-SARS environment. The player can create a quarantine area by manipulating the segment variables.

User defined settings

The user defines patient and environment variables using the following map, legend, and forms.

SET SIMULATION VARIABLES

Variables for patients

IF ALL ANY of the following symptoms are present:

THEN send patient to segment 0 1 2 3 4 5 6 7 8 9 10

Variables for environment segments

Running of the simulation

When the simulation runs, patients, employees, and visitors to the hospital interact according to the StarLogo model and the variables set by the player.

Random appearance of virus

Once the simulation is started, a case of SARS appears in a random location. Sections of screen shots are used for the following sequence for the sake of clarity. Notice the 'red' patient in the first shot, indicating the first appearance of SARS.

From this point, SARS spreads according to the variables set. In our example, the player has not set the variables very effectively, so the virus spreads to nearby patients and employees, as demonstrated in the next screenshot.

Interaction of virus and variables

Though most of the infections are within the immediate proximity of the first one, notice that one case, an employee, has already migrated to the blood bank, certainly unaware that she is a carrier.

The initial case has since died, as indicated by the black square. Just as living patients that do not have SARS eventually leave the hospital, dead patients, regardless of how they died, eventually disappear as well.

Scoring

The scoring for the performance in the simulation is shown when the player stops the simulation. The scoring is based on two types of performance: how widely the virus spread, and how effectively containment measures were applied.

Technical Description

• Specific software needed to author the game
  • StarLogo, HTML, javascript, java
• Platforms
  • PC, MacIntosh, Linux
• Screen size and resolution of the game
  • 600 x 600, 72 dpi
• Bit depth and dimensions of graphics and sounds
  • 8 to 32 bit resolution of graphics
  • no sound
• File formats of graphics
  • jpgs
• Naming convention used to name all files
  • Database tables will use default prefix srs unless changed during installation
• Data structures for any files used to save the game state
  • MySQL

Competing Products

• http://www.hku.hk/rss/res_proj/sars/sars_projects.htm
  • http://www.hku.hk/rss/res_proj/sars/sars_projects.htm
  • http://www.hku.hk/cupem/hkugis/
  • http://facarts.hku.hk/geog/sars/

Motivational Issues

The most applicable motivation theory for this game is Keller's ARCS model. The game is clearly relevant to the player, assuming he or she is working in a health care environment. By giving the player control over the simulated environment, the game allows the player to build confidence by improving the outcome over the course of multiple simulations. Finally, the player experiences satisfaction by eventually halting the spread of the simulated virus and saving lives.

Design Process

The conceptual process was long and frustrating. I originally envisioned a much larger, more flexible simulation allowing for player created environments and all sorts of physical and behavioral variables to be set by the player. Dr. Dodge injected a needed bit of reality into my plans, in terms of identifying what is feasible and what isn't. I eventually narrowed the scope of the simulation to its present form. Once that definition was achieved, the rest fell into place fairly easily.

One interesting part of the process was that when I started putting together the interface for the simulation, I found that I had not thoroughly defined a number of elements. In other words, the process of designing the interface brought to light a number of weaknesses in my concept, and forced me to clarify a number of points. For example, prior to designing the interface, I had not carefully considered the relationship between different turtles (patients) and how they would interact with variables set by the player. I knew that I wanted the player to set variables that affected where the patients went in the hospital, but I hadn't considered the mechanics of that. Creating the interface forced me to identify and categorize variables into those affecting the StarLogo model and those affecting the case-based model.

I still need to learn a bit regarding the possibilities and limits of both StarLogo and case-based models, and if I were to pursue this or another simulation, I would start by sharpening my programming knowledge.

References

Books

• Aldrich, C. (2004). Simulations and the future of learning: An innovative (and perhaps revolutionary) approach to e-learning. San Francisco, CA: Pfeiffer.

Electronic

• http://www.gideononline.com/sars.htm
• http://dimacs.rutgers.edu/Workshops/Modeling/slides/Castioll-Chavez.ppt
• http://ide.ed.psu.edu/IDDE/ARCS.htm
• http://education.mit.edu/starlogo/
• http://www.npr.org/features/feature.php?wfId=1465576