Book text is in a living document format, licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. In other words, you are free to share this work for non-commercial purposes as long as you don't create derivative works of this material, attribute me as the author, and keep this license notice intact. For more information about this Creative Commons license, please visit: http://CreativeCommons.org.

Chapter 9

Systems simulation for understanding society

The third case study in this book contributes yet another level of complexity to crafting our simulation approach to understanding. We attempt to simulate human behavior as a feedback loop when coordinating human efforts of emergency response. Emergency response planners coordinate humans in emergency response scenarios through identifying and training roles deemed appropriate for necessary activities. Since those roles are negotiated among emergency response organizations (police, fire, medical, etc.), the roles are well defined in advance so cooperation among humans can be anticipated and practiced. Some difficulty comes when a new person is given a key role in the community. They have to learn the role and be able to coordinate their roles with others. All the other role players have to adjust their expectations appropriately. Simulating those relationships though simulation of cooperative role behaviors provides valuable insight in anticipation of possible community crises. As seen in chapters seven and eight, we can gain tremendous insights when we perturb interactive software built to simulate natural systems. As we get a better sense of how evolution affects life systems (chapter seven) or how physics drives hydrological systems (chapter eight), we can begin to anticipate how our human interaction with natural systems is likely to change system equilibriums. We prefer certain plants because they look more beautiful or produce desirable food varieties — as a result, there are more of those plants existing in the world. We dam a river to generate hydropower or produce a lake for recreation — as a result, the hydrology of the area changes dramatically. As we try to create reservoirs in a river system to control the amount of flooding and water availability throughout a year, we also try to avoid clobbering the ecosystem that thrives there.

There are no technological reasons why we can't include our human actions within the scope of the software we build and perturb those simulations to understand the world around us. Humans behave within a very wide range of potential actions — given both rational and irrational reasons. Adding human interaction to our systems simulation often complicates the perspective significantly. But at the same time, it allows us to gain insight into the relationship of natural and man-made phenomena as we get a sense of where our actions might provide the best shared results. I often find myself thinking there must be quite a few situations where no human action leads to the best outcome. I find those to be ideal ones for simulation since we can test potential actions without perturbing the natural world in unfortunate ways. Should we find a human action that leads to a better equilibrium, the simulation can be used to verify the potential and then plan for implementation.

This chapter provides a case study in building and perturbing simulation software for human interaction with natural and man-made systems. The domain is the often-considered domain of emergency response to community-wide crisis events. The case study starts with a personal perspective gained through experience.

I began attempts at including human interaction in simulation software as soon as I started searching out potential involvement with emergency response scenario analysis and training opportunities. My first exposure to a countywide emergency operations center (EOC) came via a meeting of technologists who were invited there to discuss where technology might help improve crisis-wide emergency response overall. EOCs are routinely set up to coordinate activity in small and large communities and are usually supported by recommendations through government involvement. As one of many possible definitions, an EOC is a central command and control facility responsible for carrying out the principles of emergency preparedness and emergency management, or disaster management functions at a strategic level in an emergency situation, and ensuring the continuity of operation of a company, political subdivision or other organization.

Those EOC workers who met regularly at the first emergency operations center that I ever visited supported a county of 800,000 residents within 1,806 square miles. Preparedness in anticipation of crisis and emergency management in times of crisis were definitely the two most important orders of business. First responder representation from police, fire, medical, and coast guard (the county has a long coastline) organizations attended as did the media and communications command and control personnel.

Just before I made my first visit, life for the county's citizens had returned to typical non-emergency living in the county as a major wind event that had taken place four months prior. A series of wind gusts had ripped through the county as part of a storm that had left no rainwater damage behind. The November gusts had been sporadic and yet had arrived with very high wind speed (up to 120 kilometers an hour) in short succession. 205,000 homes had been left without power as a result of downed power lines. Because the gusts seemed localized and not a part of any named storm, residents fully expected their power to be restored at least as quickly as usual as previous power outages in the region.

I immediately realized that I was very privileged to have access to a career incident commander from the county. He had retired before the November winds with a honorable, multi-decadal reputation of having done an excellent job of emergency preparedness and response management in the county. He had decided to return as a consultant to the response team since the team was getting a bad rap for their management of the storm events. Although the county was quiet and all power had been restored, the ex-incident commander ranted to us with a red-faced expression and sense of urgency as if we were still in the middle of a crisis.

I could imagine a variety of reasons why he might be upset. Perhaps he felt guilty that his EOC had gotten a recent vote of non-confidence. Perhaps he was irritated that he had to come out of retirement to help with damage control. Perhaps he was not a big fan of technology solutions to complex social dynamics and yet here he was, talking to technologists. But as he spoke, one reason seemed to become much more significant than any other plausible reasons for his ire: the public had been completely unreasonable about rightsizing their expectations in the aftermath of the storm. As I sat listening to the details he shared with us, I took my usual approach of mentally imagining details from his descriptions — simulating the events in my head. In my mind's eye, I saw the short, drastic wind bursts he described knocking down localized infrastructure in thousands of scattered locations throughout the county. I saw the limited resources of specialized personnel who were trained to remove storm litter and repair telephone and power lines — trying their best to triage the damage. I saw how frustrated the trained police, fire, medical, and coast guard resources were in not being able to contribute much to the emergency's recovery. There were no riots. There were no fires or medical emergencies. The damage was mainly well inland from the coast. I saw how overworked the media volunteers were in receiving complaints about power outages that lingered into the second week of outage. After a few years of curbing my own outrage associated with news coverage of the Katrina hurricane emergency crisis in the Gulf of Mexico region, I experienced a welling up of compassion for the county emergency response personnel.

My latest research pursuit had required me to become aware of logistics (the flow of resources between the point of origin and the point of consumption in order to meet some requirements) and many of the domains in which logistics make a big difference to organizational and community success. My formal education in logistics started with an introduction to the time and motion studies that were done as the industrial age ramped up — as assembly lines emerged and people were working in close proximity on tedious repetitive tasks. My education continued with lessons on ergonomics (the science of fitting workplace conditions and job demands to the capabilities of the working population). My education then followed through to the current logistics theories and implementations of the information age (where services are often virtual and delivered at speeds much closer to the speed of light). Over the course of history, supply chain management, public transportation design, telecommunications protocols, etc. all benefitted from some form of advanced time and motion evaluation and improvement.

I felt like I was fortuitous to be at the right place at the right time — with the right motivations for being at an EOC (they had invited me as one who might be able to help through technology). Compared to all the possible simulation tasks we could start with, it seemed that a time and motion approach to the windstorm case study would be most straightforward. Take a map of the power outage situation as the recovery began its planning phase, mark locations where power lines were down, mark where large objects obstructed vehicular access, optimize a best transportation scenario (or at least a very close to optimal scenario) of trained personnel visiting all necessary service areas, and then move the given number of responders at reasonable vehicular speeds to service locations, wait at that location for the estimated time to repair/removal, and then move the responders on to the next service location until all power was restored. This very rough estimation of the nature of recovery demonstrated quickly how large numbers of households were going to have to be without power unless additional trained personnel could be educated in local culture, allocated responsibilities, and could add to the recovery manpower — even after Herculean efforts by any power companies and trained personnel.

An interesting question quickly came to mind: How many people would have a basic enough understanding of a computer-based visualization of the time and motion study to come to the conclusion the emergency operations center had done an excellent, if not stellar, job of recovering from the November windstorm? If the answer would surprise me in suggesting very few people would support that favorable conclusion, what could I do to try and increase that number over time?

Working with a couple of my favorite colleagues from the Seattle-based lab where I had been working for ten years, I helped create a time and motion simulator to visualize scenarios like a windstorm event. We built the simulator to allow for time and motion studies within any community on the globe. The coast guard was studying a scenario in Detroit whereby an international crisis would have to be mitigated on both sides of the Detroit River — in Canada and the United States. Earthquake response scenarios were of great concern in the southern island of New Zealand. We invited students at two universities to help us with stress testing visual time and motion studies for emergency response purposes in the Detroit, Seattle, and Christchurch communities.

We called our resultant simulation tool RimSim for what we hoped would be a future use as our tool developed -- to support the simulation of larger emergency response scenarios around the Pacific Rim. We expected larger emergencies to require larger collaborations across political jurisdictions. The RimSim would scale up to large crisis events. A tsunami in the Indian Ocean had caused devastating damage to life and property in multiple countries there. The Japanese tsunami event of 2011 caused devastating damage to life and property since then. As we built our tool such that scenario complexity could be independent of geographic scale, we began to see basic properties of emergency response efforts that were similar regardless of crisis area size — and we saw the complexity grew rapidly when multiple knowledge bases from experts in different professions were needed for effective response and recovery.

The RimSim tool allows for modeling responders into four categories, which we most often mapped to police, fire, medical, and coast guard personnel (thanks to those particular organizations that let us learn about what they do and how they are trained). We allowed the simulator to be played as a serious game — with staff and students implementing actions for the four categories of personnel. As we gained experience with implementation heuristics (often by trying out suggestions found in emergency response literature), we took advantage of the fact the simulation's visual representation took place on a computer that could algorithmically program the implementation to take place automatically by following instructions in software code.

After the initial novelty of game playing wore off, we coded up the game play strategies to support additional automation that let us run the simulation over and over without having to be present at the computer. One of our staff organized an experiment that compared different response efforts based on crisis scenarios — a tsunami scenario required incident management primarily close to water, an earthquake scenario required incident management along fault lines and liquefaction zones, a terrorist event took place in various highly-populated areas at highly-populated times, and epidemic events took place over longer time scales. We created simulation runs that looked to optimize personnel type response by heuristic, based on scenario. The results got us thinking deeply about emergency response — seeing the complexity involved even without human ergonomic and personality issues. But we were students and trained academic researchers. Would our tools help the first responders and emergency operation center personnel?

The RimSim development process provided a wonderful camaraderie with fun-loving, engaging, and creative people as we created RimSim together. Soon it became time for me to make a go of it alone for a while to prove my merit as an independent thinker and researcher — if I still wanted to follow through with finishing up a process worthy of a doctoral thesis defense. I would have to try and trade joyful collaborations with supportive pro-technology thinkers for newfound collaborations with emergency response planners, recovery planners, and first response personnel. Besides gaining access to new perspectives on community health, resilience, and prevention, I would gain a realistic perspective on how emergency response scenario simulators might help the emergency response planning process.

Formally, the accepted proposed abstract for a thesis on Adapting Simulation Environments for Emergency Response Planning and Training states:

Communities are preparing diligently for potential community-wide crises arising from natural and man-made causes. First responders are those people who train to fulfill emergency response roles on behalf of community residents, seeking to limit loss of life, protect property, and reduce the cost of long-term recovery periods associated with crisis scenarios. The cost of providing physical drills to train for participation in community-wide crises is exorbitant and the 24/7 demands for first responders can preclude participating in training even if a physical drill is made available. Simulation environments are computer programs with specialized interfaces that can expose humans to simulated crises in order to gain insight as to how they should respond in an actual crisis situation. Role-play allows for a live player to simulate the performance of activities independently as well as with other agents, all coordinated with simulation software to provide feedback as to their performance. The emergent field of serious games has attracted researchers who want to contribute to a distributed process of improving the experience and increasing the usefulness of such simulation environments.

This research develops and tests a software architecture named RimSim as a serious game for emergency response planning and training. The software design facilitates manipulation of various design issues such as the human interface and representational constructs for rapid assimilation and decision-making. Various implementations and testing of the RimSim within hospital evacuation teams for a specific community-wide hospital evacuation scenario demonstrates that the approach is viable and useful for further development and implementation. Appropriate metrics to evaluate the success of emergency response team players comes from a wide variety of fields including distributed cognition, distributed intelligence, situation awareness, and insight generation, each of which is described and integrated into the evaluation of subject experiments. In this research, metrics are calculated and discussed in terms of applicability and relevance to future work.

Upon integrating existing software tools and distilling the insight gained during the research described previously, we were ready to develop a simulation tool tailored to the needs of hospital emergency first responders. We worked with the emergency response coordinator of a 400-bed medical center and her colleagues at the King County Healthcare Coalition (KCHC) in Washington state to develop simulated human roles for a specific hospital evacuation scenario the coalition had identified as a critical skills development and assessment scenario. Through various collaborative meetings and publications, the KCHC concluded that they strongly believed training for a major hospital evacuation scenario would build critical emergency response competence within the county. In activities parallel to our general scenario software simulator development, the coalition reviewed and adjusted scenario roles, responsibilities, and cross-communication details associated with hospital evacuation. While they worked on identifying and describing the human roles involved the scenario, we researched artifact development for computer-based support as a potential training tool that could provide long-term benefit to hospital evacuation preparedness.

As a result of a focused brainstorming session with the RimSim software developers (who by now called themselves the RimSim:Response team), we ascertained a strong vision of what needed to be done to modify our software in order to test two hypotheses regarding the usefulness of simulation software in hospital crisis response:

1. A multi-user situational simulation environment can be effectively used as a training tool for generating insight among emergency response personnel.

2. A multi-user situational simulation environment can be effectively used as a training tool for improving situation awareness among emergency response personnel.

To be able to test these hypotheses, we iterated upon the design of the simulator software components. We added new resource types to include equipment resources that patients need to have access to throughout their stay in a hospital. We added new incident types that were specific to emergency response needs of patients in a hospital. We added the ability for incidents to be dependent on one another in order that one incident would have to be responded to completely before the next incident could be considered (to support cause and effect relationships). And, we implemented a situation awareness-scoring algorithm that would give players a rough but useful estimate of how well they were responding to the current crisis as a team.

Upon outlining the additional code work that needed to be done to adapt RimSim to the hospital crisis scenario, we approached the KCHC to help us effectively integrate simulator use into training drill support and research experiments in order to test our first hypothesis. We were able to modify and use an emergency hospital evacuation scenario developed in conjunction with the emergency response drill coordinator at the medical center we planned on evacuating in software simulations. The KCHC met independently to document the hospital evacuation scenario. As a result of their work, the team produced, and provided to me, many written documents that described the world domain of the simulation with details that could be encoded in software.

Hospital evacuation scenarios are discussed in terms of the human roles that would be performed in the case of an emergency. Scenario developers document their conclusions in a variety of manuals and specifications maintained by a King County Emergency Response committee. The software team spent many hours studying and incorporating the expected activities of key human roles into the software. A quick sense of that work follows here. A Hospital Evacuation Coordinator (HEC) in the evacuating hospital begins the emergency evacuation process by contacting all evacuating hospital floor coordinators who then provide a patient status report for all patients on each floor. The HEC contacts the prearranged Hospital Control (HC) contact at an external location to report on the current situation there. The HC contacts the Fire Department who selects a Fire Department Transport Coordinator (FDTC) to be in charge of all physical patient removal performed by Fire Department staff. The HEC also contacts the evacuating hospital's Hospital Transportation Coordinator (HTC) who is responsible for coordinating patient transfer with the FDTC. A Patient Tracking Officer and/or Patient Movement Coordinator may be involved in the communications between the HEC and HTC.

To negotiate patient allocation away from the evacuating hospital, the HC communicates with each Receiving Hospital Coordinators (RHC) to prepare the receiving hospitals for the receipt of evacuated patients and gain agreement for transfer. We documented the flow of communications between emergency hospital evacuation scenario roles in a flowchart. In our case study, we built interfaces for playing the roles in dark red while simulating roles in green strictly in software. Roles in dark red then became software simulations over time based on the performance of those roles.

With help from the KCHC, we chose to generate different patient incident types that each required creative response unique to each incident type. We were also able to generate different vehicle resource classes that would require creative matching of patient needs to vehicular capabilities. These incident and resource classes continued to be iterated upon for scenario performance training and improvement up to the time we performed the experiment that would test the second hypothesis.

Our work with the general RimSim scenarios had allowed us to develop and verify time and motion averages for the actions of all resources. We acquired average-driving times for transport, minimum average incident settlement times for time spent at each location, and average dispatch times for communicating incident requirements to the resources (police, fire, medical, and coast guard types). The average times are then used to create realistic random times for use in the simulation within a range centered by the average. Although we were able to reuse the average-driving times data for vehicle transport in a hospital evacuation scenario, we also had to develop averages for all the time and motion events that would take place within the hospital grounds. Walking times, wheelchair transport times, and assisted gurney transport times were measured through sample behaviors within the hospital. These were measured for stairwells as well as floor movement. Times had to be measured for common preparation tasks involved in getting a patient safely out of a bed and into a transport condition. Equipment preparation times are critical times for those patients that must have the equipment by their side at all times. Thankfully, we had other time and motion studies done at other hospitals to advise how to choose random times for simulation from reasonable ranges of possible times based on the averages we collected.

In order to be able to evaluate emergency response participation, we enhanced the RimSim software so that it would generate and store data about the more relevant variables we believed would be most important to provide a visualization of emergency response team behavior during patient evacuation of one medical hospital to other area hospitals. We needed to capture data for the hospital evacuation scenario that would consistently allow for comparison analyses to each of those simulated sessions we had run previously.

With satisfactory versions of all necessary software features in place, we fine-tuned the simulation tool to be ready for a variety of experiments that we could perform as agent-based simulations and then with combinations of human role players and software agents (where the software agents could be made more realistic upon considering the human role playing behaviors). To prove the merit of such work, we knew our simulator experiments should take place with trained emergency response personnel who could evaluate a simulator and/or analysis tool and demonstrate improved insight into better designing their role within the hospital evacuation scenario.

As the final step in preparing our software for hypothesis testing, we seeded the simulation with a realistic starting condition. We chose the date of Tuesday, April 20th 2010 as the base date and asked the hospital personnel to obtain actual data for all key simulation variables. We obtained the complete list of all patient-to-bed allocations for the evacuating medical hospital, and seeded our simulated hospital floor plan component with visual representation of all 235 patients. The KCHC helped us encode patient incident types into visual glyphs that incorporated color coding comprised of two parts: A semi-circular solid color pattern on the left-hand side of the glyph would represent the mobility of the patient while a rectangular solid color pattern on the right-hand side of the glyph would represent health class designation. The final color allocations we used were as follows:

Each of those classifications modified average time and motion study times for each encoding type used within the simulation. Upon placing visual glyphs on the five floors of the hospital to represent patient incident types, the patient tracking widget appeared with the five floor starting layouts seen here — with each patient spatially located in the bed within their room.

In preparation for our experiments, we also updated our hospital list of those hospitals participating in evacuating patient allocations and we updated visual glyphs for each hospital (including trained transportation routes from the UW Medical Center). The KCHC provided us with nineteen locations of hospital-care facilities that participate in the coalition and already had agreements to be contacted by hospital control in times of countywide emergency. For each hospital, a count of available beds for each health encoding class is an important data item. We included a list and map of hospital locations as part of the simulation software visualization, a well as available bed counts for each hospital as seen here:

Transportation vehicles would be simulated to take patients from the evacuated hospital to their new location. To prepare for our the simulation, we color-coded the vehicle resource types available for the scenario using the following color scheme:

We inquired about the available vehicle fleet for April 20, 2010 and put those vehicles into the simulation as available. We chose appropriate starting locations based on where the vehicles were on the morning of that date. We had four ambulances, two CCT Medic, two High-end EMS Medic, one Eight-Seat Aid Car, and a King County Metro Bus available for use in the simulation. The capabilities of each vehicle were well known by the fire department personnel involved with the scenario. We built those limitations into the scenario and used their existing load time data to develop a realistic range of load times for each vehicle based on patient condition.

With the simulation software ready to go, and with our software stress performance tests completed for the starting data condition, we asked the Hospital Evacuation Coordinator to start performing her duties through the simulated EOC we had set up for their use. The role players only used phones, walkie-talkies and other communications devices they would have available to them in the EOC. Every decision they made was recorded in the simulation in order for them to be able to see a simulation based on their results. They talked to simulated nurses and simulated fire personnel that were on sight to determine the status of patients. They talked to each other to command and control the series of response activities they deemed necessary to evacuate the hospital safely and effectively. The simulation ran and recorded all movement of personnel, transport vehicles, and patients.

When the simulation had run for 2.5 hours, the human role players stopped playing in order to discuss their strategies and the results of their actions. They then spent 46 hours away from the software before returning to run the scenario again from the starting condition. The amount of data generated to test the two hypotheses from the research perspective was sufficient for a doctoral thesis and journal article. Human role players provided valuable feedback in terms of possible steps to take to improve the simulation services. Having participated by watching the scenario session and managing the software throughout the simulation, the developers also had their own overlapping list of potential improvements to the software.

Simulating roles through software agents provides the opportunity to add many challenging twists to a scenario that the human role players might not expect. The simulation we used did not include any of those twists and instead varied only by the speed in which tasks were performed — the simulated humans did their jobs reliably and without distraction. The roles they performed were highly trained roles within the chain of command. Never once did a human role player who was performing supervisor duties suggest they wished a simulated role player could have behaved otherwise. The scenario we chose was mild on the chaotic scale in that regard. Patient behavior did not include any unexpected behaviors — they were all well behaved within the limits of their physical health condition and let the simulated assistants assist them without any new crisis incidents. As we learned from our time with other EOCs, external phone calls can be a real distraction for emergency response personnel — so much so that special roles have been developed and trained for dealing with the media as well as friends and families of individuals in harm's way (in this case, patients).

Watching a simulation of patients and vehicles moving within a spatially based visualization, especially when patient and vehicle movements were at their peak, provides a rich opportunity for the brain to absorb the nature of the phenomenon being watched. There were times when the flow of movement seemed to record naturally in my mind's eye and interesting patterns of movement naturally drew my attention. By the end of the second simulated session, I felt I had a more internal model of the scenario from a timing sense and had a much deeper awareness of what roles in an EOC entail. Creating the simulation of that county-wide wind recovery event would likely provide a similar awareness — even if all it did was present actually movement of the personnel involved after the fact.

As a result, it seems necessary to make a Web-enabled version of the RimSim software, as well as the modified version for the hospital evacuation scenario, available for other to use — either to play the software as a serious game or to modify the software first for another scenario before the playing begins. Like with chapters 7 and 8 of the book, the software that supported this case study will be updated, Web-enabled, and provide with support as funding provided by book contributions allows.