-

Preface: Applying AmI technologies to crisis management Preface: Applying AmI technologies to crisis management

Workshop at AmI2012

Monica Divitini1, Babak Farshchian2, Jacqueline Floch2, Ragnhild Halvorsrud2,

Simone Mora1, Michael Stiso2 1 Dept. of Information and Computer Science, NTNU, Trondheim, Norway {divitini, simonem}@idi.ntnu.no

2 SINTEF ICT, Oslo| Trondheim, Norway {Babak.Farshchian, Jacqueline.Floch, Ragnhild. Halvorsrud,

Michael.Stiso}@sintef.no 1

Introduction

Natural and man-made disasters are on the rise, with sources reporting on a five-fold increase of natural disasters in the last 35 years1. In 2010, DG ECHO (the EU Directorate for Humanitarian Aid and Civil Protection) reported a EU expenditure of €1115 million to respond to new or protracted crises, and 373 natural disasters killing around 300000 people2.

ICT solutions proposed for supporting crisis management vary considerably in scope and complexity, ranging from organizational workflow systems up to platforms like Ushahidi (http://ushahidi.com/) for crowd sourcing and the usage of Twitter (twitter.com) to share information among the population.

Because of their pervasiveness and ease of use, Ambient Intelligence (AmI) solutions hold a great potential to support crisis management in an efficient and effective way, thereby contributing to saving lives, reducing risks for rescue teams and lowering costs. Several example solutions are described in the research literature, such as monitoring of environmental data under hard conditions, impact of information presentation on decision-making, rescuer teams management supported with physiological data monitoring, situational awareness support for rapid crowd evacuation. This workshop has been organized to better understand the strengths of the AmI paradigm and challenges to its application. It offered to researchers and practitioners a 1 http://www.euractiv.com/foreign-affairs/europe-beef-response-natural-disasters-news-499193 2 EU DG ECHO, Annual Report 2010, available at

http://ec.europa.eu/echo/files/media/publications/annual_report/annual_report_2010.pdf space to reflect on where these increasingly pervasive and ambient technologies are going, what they will make possible, and how they will be used. Focus was on challenges connected to the use of AmI in crisis management as well as the opportunities to use AmI to conceive innovative solutions, e.g. empowering not only traditional actors, but also the population at large; supporting not only management, but also promoting continuous learning and training. Relevant topics included platforms issues, user interaction in challenging environments, methodologies and applications. This volume collects the 8 papers that were presented at the workshop, addressing these topics from different angles. Together they provide an up to date overview of the state of the art in the field. 2

Organization

The workshop was jointly organized by three EU IST research projects that investigate from different perspectives ICT support for crisis management: • • •

(http://www.bridgeproject.eu) aims at building a system to support technical and social interoperability in large-scale emergency management.

(http://www.mirror-project.eu/) aims at developing ICT tools for supporting workplace reflection and learning. Training of crisis workers is a core application domain of the project.

(http://www.ict-societies.eu/) aims at extending the application of pervasive computing beyond the individual to communities of users. Disaster management is chosen as one area for the evaluation of the proposed solutions.

More information about the workshop is available at the workshop http://ami4cm.wordpress.com/ website: Response to Emergence in Emergency Response

Lisa Anne Wood*, Monika Büscher*, Leonardo Ramirez† *Mobilities.Lab, Lancaster University, UK; †Fraunhofer FIT, Germany

Abstract. This paper develops a (constructive) critique of the potential of ambient intelligence technologies in emergency response. We explore some difficulties in, and successful practices of, inter-agency collaboration in emergency response, revealed in ethnographic field studies and collaborative design workshops with first responders undertaken in the frame of the Bridge project. We describe four challenges with reference to literature and our own fieldwork in Emergency Management Information Systems (EMIS) design: data transparency, interpretation/intuition, flexible working and information overload. We posit that ambient intelligence has a great deal to offer in the creation of emergency management information systems but that these offerings should be guided by ‘modesty’ and an ongoing entanglement with emergency practitioners. 1

Introduction

… the development of networking technologies must also take account of the social processes that form an important component of command and control and interagency cooperation. [1: 79]

Almost without exception, reports and reflections after disasters express concerns over the different emergency agencies’ abilities to work together (whilst also highlighting exemplary successes). These concerns often inspire innovation, investment and research. Recent research in Ambient Intelligence (AmI), for example, develops new support for coordination in emergency response through ad-hoc networking [ 2 ], agent-based workflow support [ 3 ], self-management and self-healing of emergent systems of systems [ 4 ], activity recognition [ 5 ], and risk analysis [ 6 ]. These technologies have great potential, yet there is often a lack of attention to the complex causes of the difficulties that emergency responders experience and to the often sophisticated practices that enable successful coordination. A deeper understanding of such factors and practices is needed to design useful support for real world practice.

In this paper we focus on aspects of collaboration and coordination between different emergency agencies during large-scale incidents to present a constructive critique of ambient intelligence systems. We explore how AmI tools may feature in a sociotechnical arrangement or ‘system of systems’ which supports inter-agency collaboration during emergency response.

Background

The EU funded Bridge project develops architectural support for the assembly of systems of systems for emergency response. Emergency management encompasses a variety of activities such as planning, training, risk assessment, and organizational change. Emergency response involves an exchange of data between different agencies and institutions, movement of people from service to service and cooperation from other actors (such as utilities companies, insurance providers, and telecoms operators). The emergence of appropriate assemblies of responders and resources depends on coordinated improvisation in a time critical, often dangerous and unpredictable environment. Collaboration is paramount and ‘effective’ collaboration may save lives. Ambient Intelligence or AmI has great potential in this context, as it can contribute in coordinating and orchestrating emergent interoperability, and help people identify actors and services relevant for the situation at hand. Innovation in this area, however, must be grounded in an understanding of the difficulties emergency responders experience, and their often multi-dimensional causes, as well as an appreciation of the often highly sophisticated and delicate practices of collaboration that make coordination possible. Undermining and failing to appreciate the local, lived and often successful collaboration efforts of those operating ‘on the ground’ can lead to costly failures with the potential to damage relations between organizations [ 7 ]. It is important for emergency management information systems design [ 8 ] to focus its efforts on supporting collaboration where it is needed without disrupting the social practices which enable these disparate yet cooperating entities to work together.

To understand the complex practices of intra- and inter–agency collaboration in large scale emergency response, we use in BRIDGE a range of methods that ‘entangle’ use and design. We have chosen to involve users deeply and equally as codesigners in long-term processes of socio-technical innovation. Our experience with participatory design shows that in-depth, long-term engagement with users and contexts of use can be a powerful source of constructive critique of technocentric visions and a breeding ground for new ideas that are grounded in and more appropriable for real world practices [ 9, 10 ]. This can make emergence of viable (and desirable) sociotechnical futures possible, and inform the design of technologies for such futures. In the frame of BRIDGE, we have carried out over 80 hours of interviews, domain analysis workshops and ethnographic observations with professional partners in police, fire and medical emergency services in the UK, Belgium, Norway, Germany and the Netherlands since April 2011. This work includes observations, go-along or walkalong [ 11, 12 ] and sit-down interviews, as well as ‘sandbox’ discussions, where emergency responders use props to describe real emergency response efforts from their own experience. Reflecting the nature of emergency response, the methods chosen in BRIDGE are often mobile and multi-sited. Since it is the detailed organisation of social and material practice what matters to system design, we follow an ethnographic approach based on the use of recordings of interviews and of naturally occurring activities.

In the next section we explore some difficulties in, and successful practices of, inter-agency collaboration in emergency response, revealed in ethnographic field studies and collaborative design workshops with first responders undertaken in the frame of the Bridge project. 3 3.1

Collaboration in emergency response

Emergent Collaboration

Some of the concerns expressed in official reports over a lack of collaboration following emergency response efforts sit uncomfortably with empirical studies of emergency responders’ work practices. Such studies show, for the most part, first responders work well together, their practices fold into each other’s and they address incidents effectively through collaborative working and engagement on a day on day, week on week basis. Empirical accounts of practices highlight an economical yet sophisticated process of configuring awareness [ 13, 14 ], the emergence of ‘adhocracies’ of emergency response actors (e.g. in the aftermath of the 9/11 attacks, [ 15, 16 ]), and the ability to ‘stretch’ communicative capabilities with new technologies [ 10 ], creatively avoiding a ‘fracturing’ of perceptual ecologies [ 17 ].

Following an inquiry into the London bombings in July 2005, for example, the coroner highlighted how when multi-agency responders were presented with uncertain, complex and traumatic circumstances they “did all that they could to ensure that lives were saved” [ 18 ]. This sentiment is echoed in the results of BRIDGE project. In our observations of and conversations about work practices with emergency responders, collaboration on a human-to-human level is rarely criticized and is not regarded as a problem but rather as routine. In a discussion with fire fighters they explained how ‘the men’ (sic) on the ground from fire, health and police agencies, work well together. Responders stated that multi-agency front line officers can collaborate effectively, because they work with each other regularly. This reflects a close community of individuals and agencies working together on small and large scale incidents, where plans, standardized procedures, and official terminologies represent resources (not blueprints) for situated action [ 19 ].

Reports from disasters often gloss over the difficulties of conceiving and implementing collaboration support in emergency response both at a human and at a technical level. This usually motivates attempts to eliminate differences among participating agencies, for example through centralization, which has not proven to be effective. ‘Environmental’ constraints, such as overeager centralization, cumbersome legislation, and conflicting business rationales impact on the responders’ capabilities to coordinate their contributions and collaborate. Moreover, when that work is augmented by technologies, important, but often taken for granted aspects of emergent collaborative practices can become undermined. In these situations, problems between agencies working together can emerge – they may, for example, be unable to share information embedded within technologies or act on information obtained through communication or observation. What works on a person to person level, for example in ‘motorhood’ collaboration around physical surfaces in co-present situations, should not be disrupted by radio systems which cannot interoperate or logging systems which can only be viewed by one agency. As a consequence, new systems need to be designed and integrate existing components with greater sensitivity to such collaborative work practices between agencies, moving between perspectives gracefully, without interfering with the work of responders. Technological futures must focus not only on overcoming breakdowns in collaboration, but also on ‘stretching’ existing, effective ways of working together. 3.2

Role and challenges for AmI in emergency response

Many authors have written about imagined futures for emergency response where AmI environments could improve collaboration and coordination of response efforts. The AmI environment is envisioned or designed to recognize the needs of people through analysis of abstractions of behaviour, predicting needs and reacting accordingly [ 20 ]. In a scenario proposed by [ 2 ], for instance, a world is imagined where, as off duty paramedics approach a scene of an incident “…body-worn AmI devices register them with the ambulance control centre <ad hoc networking, identification and authentication> and they are directed to the place they can be of most use” [2: 119]. The benefits of such interactions are highly valued and regarded by practitioners when discussing the potential of AmI systems in the context of emergency response. Such use of AmI raises, however, a number of concerns about the way in which the ‘social’ is removed or made invisible from these envisaged interactions. Critiques of AmI in health care and telemedicine, for example, highlight the ways in which creating intelligent environments disrupt social connectedness – remote monitoring removes the personal connections and the benefits of being cared for [ 21 ]. Indeed, cooperation and interagency collaboration is an effect emerging of the sociotechnical system working as a whole. In this sense, AmI tools are just one further element of the assembly. If they undermine the practices of inter-agency collaboration by removing negotiations or the space for interaction between participants, they can seriously disrupt sophisticated collaborative practices.

Against this background, it is a deep challenge for AmI to balance engagement and automation. Dealing with this challenge is possible through appropriation and flexible assembly, rather than designing systems for an imagined future and created by detachment from the realities of human practices. This is not a new endeavor. [ 10 ] have suggested that ambient intelligence systems need to be made ‘palpable’, enabling visibility, de-construction, understandability, coherence, stability, user control and deference. [22] has stated that promoting ‘engaged’ living, where it is possible to control interactions with the world as an alternate possibility for steering the field. Aiming at these qualities presents a plethora of opportunities for technological innovation yet also raises a number of serious challenges at different levels in the design of AmI systems. In our work, we identified several of these challenges. In the following we describe four of them with reference to literature and our own fieldwork in EMIS design.

Data Transparency. Ambient intelligent environments often make extensive use of instrumented environments via omnipresent sensors and actuators such as CCTV, RFIDs tags, etc [23], which imply a growing potential for increased surveillance possibilities. In a co-design workshop, we discussed anxieties about breaching the data protection act when sharing data in multi-agency collaboration. A dilemma was presented where a policeman needs to do something with a person and that person is known to have a blood infection. The ambulance representative stated, “We tell them discreetly ‘use your gloves’”. Jim, a Norwegian police officer, described interorganizational collaboration on the scene of an incident during the workshop, “If there’s a known violent criminal who might be armed injured on the scene, you’d tell the medics ‘be careful with him’”

This is not in breach of data protection regulations and highly effective for the safety of emergency response personnel. It is an ethical requirement for information systems to (at least) respect existing health and safety practices. The above exchanges are likely to happen in ‘fleeting moments’, in direct face-to-face interaction or, less likely, via the radio system. The information would be ephemeral and it is relatively easy to understand who is within reach of this information spatially, organizationally, and temporally. However, in future, such communications may be logged automatically, opening them up for retrospective scrutiny. Moreover, it may be possible to triangulate the personal information implied in the communication with ID information and location. This change of context might make professionals less inclined to divulge what they know to protect their colleagues, for fear of breaching data protection regulations. This raises the question of balancing between the benefits of seamlessly connected system with the privacy concerns that the profiling and monitoring capabilities of AmI systems create.

Information Overload. [24] argue that a ‘common operational picture’ does not lead to ‘situation awareness’. The assumption ‘that data is the only barrier to appropriate [understanding and] action’ is deeply flawed. This was elaborated on in our fieldwork where it was felt that information should be appropriately available at the different levels of an emergency command structure, that a common operational picture was not reliant on data intensive practices, and that providing excess information would “blur the lines of command” (Peter, Advanced Paramedic).

“As a commander remote, I don’t think you would be interested in that particular information [the status of individual victims]. I think you’d want the headline; the numbers.” (John, Senior Fire Fighter)

Yet increasingly, systems are developed that aim to generate more and more ‘data’ for emergency responders in order to ‘improve’ situation awareness, creating the potential to mask what is of importance. There is a delicate balance to be made between information overload and information simplification where digitally extended and augmented environments change interaction and involvement possibilities and threaten the ability to ‘dig deep’ enough into the system to see modes of information generation or aggregation.

Interpretation/Intuition. It is not possible for an intelligent environment to be intelligent enough for situated sense-making. In human communication and collaboration, there is interpretation and intuition used to understand intent. It is therefore difficult (if not impossible) to design a system that would produce an appropriate response due to its incapacity to fully ‘appreciate’ context and intentions. During a co-design workshop, in a discussion regarding the allocation of resources, responders talked about how the allocation or movement of personnel from one location to another is not simply the movement of people from one place to another. Ex-police officer and resilience manager, David, states: “One little thing that we questioned slightly is… automatic deployment… We felt that wasn’t really taking account of the dialogue that goes on between control rooms and the units that they are deploying: officers or paramedics are feeding back local knowledge and things like this and we felt that that’s something, an area that really needs looking at. It’s never a one way process, deploying resources.”

Resource allocation implies a process of negotiation that define the task itself, its parameters and how it should be accomplished. The work that is ‘done’ during the allocation of resources cannot necessarily be broken down into matching an individual’s skills with an area requiring assistance. As the example shows, asking someone to do something may involve trust in their professional capabilities, and delegation of responsibility or collaboration and negotiation: to determine whether the person being moved is fit for duty and indeed the best resource to move in the circumstances. Further to this, the accuracy to which such systems can ‘abstract’ human conduct underlying collaborative practices is restricted. A police officer might move from one side of the building to another, for example. What does such movement represent? Does it mean that one area is now safe? That the area where they were standing is now dangerous? That there is more need for them in the new location or that they are due to go home? AmI has no capacity to ‘read’ scenes in a way that could answer such questions. It can, however, make them, or digital representations of them, available to support the construction of awareness and the situated sense-making of its users.

Flexible Working. The above examples go some way in showing how coordination between different agencies in emergency response is an emergent phenomenon that depends on people’s ability to flexibly assemble technologies, people, and resources. It must allow for role improvisation. Our empirical studies and design collaborations with professionals provide insights into experiences of camaraderie and trust, and effective practices of improvisation and ‘motorhood’ coordination, that is, gatherings where knowledge and different perspectives are brought together, often around a shared physical surface, but increasingly also utilizing digital technologies. After it had been determined that there were no further bombs in the government buildings in Oslo after the attack on 22/7/2011, ambulance doctors went inside the buildings, doing triage with fire fighters. This was in response to a perceived danger 5 6 of fire fighters evacuating the wrong victims. Medical staff could do triage inside the buildings and allocate scarce transport resources more efficiently. 4

Conclusion

The Bridge project’s aim is to “augment human intellect …, extending their ability to learn, make decisions, reason, create, solve complex problems and generate innovative ideas”, based on Rogers ‘New Agenda’ for ubiquitous computing [22: 411]. Rogers states that UbiComp should move to “a mindset that wants to make the environment smart and proactive to one that enables people, themselves, to be smarter and proactive in their everyday and working practices.” [22: 418]. In this paper we have presented a constructive critique of AmI environments for emergency response based on longitudinal socio-technical design entanglements with emergency service responders. We posit that ambient intelligence has a great deal to offer in the creation of emergency management information systems but that these offerings should be guided by ‘modesty’ and an ongoing entanglement with emergency practitioners. We argue that collaboration practices are habitually successful and that AmI systems design should attempt to build on what makes possible this success.

We would like to thank the professional responders and our Bridge project colleagues for their insightful contributions and comments to this paper, in particular Aslak Wegner Eide and Ragnhild Halvorsrud.

Acknowledgements References

Shapiro, D. Participatory design: the will to succeed. in CC '05 Proceedings of the 4th decennial conference on Critical computing: between sense and sensibility 2005. Arhus, Denmark.

Van De Walle, B., M. Turoff, and S.R. Hiltz, Information Systems for Emergency Management. Advances in management information systems, v. 162010, Armonk, NY: M.E. Sharpe.

Ramirez, L., Practice-Centered Support for Indoor Navigation: Design of a Ubicomp Platform for Firefighters. Fraunhofer Series in Information and Communication2012, Aachen: Shaker Verlag.

Büscher, M., et al., Bottom-up, top-down? Connecting software architecture design with use. Configuring UserDesigner Relations Interdisciplinary Perspectives, 2008: p. 157.

Kusenbach, M., Street Phenomenology: The Go-Along as Ethnographic Research Tool. Ethnography, 2003. 4(3): p. 455-485.

Buscher, M. and J. Urry, Mobile Methods and the Empirical. European Journal of Social Theory, 2009. 12(1): p. 99-116.

Pettersson, M., D. Randall, and B. Helgeson, Ambiguities, awareness and economy: a study of emergency service work. Computer Supported Cooperative Work (CSCW), 2007. 13(2): p. 125-154.

Heath, C. and P. Luff, Collaboration and Control: Crisis management and multimedia technology in London Underground Line Control Rooms. Computer Supported Cooperative Work (CSCW), 1992. 1(1-2): p. 69-94. Mendonça, D., T. Jefferson, and J. Harrald, Collaborative adhocracies and mix-and-match technologies in emergency management. Communications of the ACM, 2007. 50(3): p. 44.

Kendra, J. and T. Wachtendorf, The waterborne evacuation of Lower Manhattan on September 11: A case of distributed sensemaking, 2006, University of Delaware Disaster Research Centre.

Luff, P., et al., Fractured Ecologies: Creating Environments for Collaboration. Human-Computer Interaction, 2003. 18: p. 51-84. Hallett, H., Coroner's Inquest into the London Bombings of 7 July 2005, 2011, HM Coroner: London, UK.

Suchman, L., Human-Machine Reconfigurations: Plans and Situated Actions. Second ed2007, New York: Cambridge University Press. Ingold, T., Bringing Things to Life: creative entanglements in a world of materials, in Realities2010, University of Manchester.

Milligan, C., C. Roberts, and M. Mort, Telecare and older people: who cares where? Soc Sci Med, 2011. 72(3): p. 347-54.

Rogers, Y. Moving on from Weiser's vision of calm computing: Engaging UbiComp Experiences. in Ubicomp 2006. 2006. Berlin: Springer-Verlag. Hert, P., et al., Legal safeguards for privacy and data protection in ambient intelligence. Personal and Ubiquitous Computing, 2008. 13(6): p. 435-444. Harrald, J. and T. Jefferson. Shared situational awareness in emergency management mitigation and response. in 40th Annual Hawaii International Conference on System Sciences HICS07. 2007. Hawaii: IEEE.

An Analysis of the use of Cognitive Surplus in Disaster

Relief Scenarios

Mark Roddy1 Abstract. In an increasingly connected world, can the cognitive surplus of the online community be effectively harnessed to help in the assistance of managing global disasters? Does this community even want to assist with disaster relief? The relief experts on the ground are continually being confronted with life and death scenarios, so how can they trust the veracity of any assistance provided by the online community? By providing examples of existing disaster management systems that have successfully leveraged the online community to assist in disaster relief, this paper suggests that online philanthropy exists, albeit this assistance does need to be manually verified. The paper goes on to use the results from an online survey to hypothesize a collective intelligence model for trusting this assistance. The potential impact of this could be to reduce the burden that the disaster relief teams have to exert in order to verify and validate this assistance. 1 Introduction On the 26th December 2004 an earthquake in the Indian Ocean resulted in one of the most destructive tsunamis ever to hit the islands of Indonesia. Within the first hours of this tragic event some 150,000 people had died or were declared missing, and millions were left homeless. Emergency services were fully stretched in trying to come to the aid of the victims. 1.1

Objectives The objective of this paper is to suggest to the reader a model for a next generation disaster management system, which would be used to help alleviate the suffering of future disaster victims.

The key objectives are to provide: - Examples of the state of the art for disaster management systems - Recommendations for the design of future disaster management systems

Cognitive Surplus and the Wisdom of Crowds Shirky (2010) describes cognitive surplus as people’s free time and offers insights into how this might be leveraged to impact changes around the globe. This free time is separate from people’s work time, where the expectation from the former is not necessarily market driven - people do not expect to be paid for any activity they are engaged in during their free time.

The social scientist Dan Ariely (2008) explores this further - he discusses a scenario of a Thanksgiving dinner where the son-in-law stands up at the end of the meal and offers his mother-in-law payment for the services rendered, it was an artificial scenario but served to highlight the dichotomy between free time and work time people in their free time do things for free, while people in their work time do things for payment.

But the question still exists - how to harness this cognitive surplus and in particular how can it be leveraged in disaster relief scenarios? Watching television is an activity usually carried out in our free time, and Shirky (2010, pp.9-10) writes, “imagine treating the free time of the world’s educated citizenry as an aggregate, a kind of ‘cognitive surplus’”. Shirky uses the creation of Wikipedia as a model to measure how big this surplus might be and estimates that the creation of Wikipedia represents “something like one hundred million hours of human thought”. He compares this to watching television, which in the US alone is about two hundred billion hours every year, which is roughly equivalent to two thousand Wikipedia projects every year from cognitive surplus.

Through the introduction of innovative online networking technologies it could be possible to transition the passive usage of our cognitive surplus (e.g. watching television) to more active engagement to help and support those in need. The hit television game-show “Who Wants To Be A Millionaire?” asks contestants to answer a question from four possible answers. If the contestant is unable to answer the question they are able to rely on three lifelines: ‘Fifty-Fifty’, ‘Phone a Friend’, or ‘Ask the Audience’. An interesting statistic1 is that the ‘Ask the Audience’ lifeline has a 95% success rate.

Why is this? It is an example of a phenomenon known as wisdom of the crowd. Surowiecki (2004, p.70) cites, “The idea of wisdom of crowds also takes decentralisation as a given and a good, since it implies that if you set a crowd of self interested, independent people to work in a decentralised way on the same problem, instead of trying to direct their efforts from the top down, their collective solution is likely to be better than any other solution you could come up with”. 1 http://en.wikipedia.org/wiki/Who_Wants_to_Be_a_Millionaire%3F “Who Wants To Be A

Millionaire?” Wisdom of crowds resonates with the cognitive surplus ideas. On the one hand there is the potential to leverage the online communities’ cognitive surplus to assist in disaster relief and on the other hand there is the ability to aggregate the crowd’s (taken here to mean the online community) responses to arrive at the correct result. Combining these concepts strongly suggests that a collective intelligence model might exist that further increases trustworthiness and information veracity, which will be discussed later in this paper. 3 Disaster Management Systems This section provides some best in class examples of organisations (all voluntary) that are using online tools to assist in the relief of disaster management scenarios. Some of these organisations use collaborative cognitive surplus to provide online support back into the disaster zone. 3.1 Ushahidi Ushahidi2 is a not for profit organisation “that specializes in developing free and open source software for information collection, visualisation and interactive mapping”. Ushahidi was a response to the violence in the aftermath of the controversial Kenyan elections of 2008.

Ushahidi started as a collaborative website set up by a group of Kenyan journalists and was used to aggregate and map the reports of these violent events. It was seen as an extremely powerful communication tool, and with over 45,000 users was the catalyst for the design and development of today’s platform. The platform was successfully used in many recent disasters, including as a relief response tool for the Haiti earthquake, when it was used by online volunteers to create a visual crisis map of the disaster zone, by clustering data mined tweets emanating from the disaster site.3 The volunteers then used Skype to relay the cluster details of their map back to relief teams. 3.2 The Sahana Software Foundation The Sahana Software Foundation, established in 2009, is another not for profit organisation whose mission “is to help alleviate human suffering by giving emergency managers, disaster response professionals and communities access to the information that they need to better prepare for and respond to disasters through the development and promotion of free and open source software and open standards”. 2 http://ushahidi.com/about-us “The Ushahidi Project” 3 http://usatoday30.usatoday.com/tech/news/2011-04-11-japan-social-media_N.htm Today” “USA Sahana originated in Sri Lanka as a response to the Indian Ocean tsunami disaster in 2005.4 The platform has had numerous deployments, including the 2011 earthquake in New Zealand where it was used to help as a people locator.5 3.3 Crisis Commons CrisisCommons6 is another example of a voluntary collaborative online community, whose aim is to support the management of disaster and crisis relief. The community emerged from so-called CrisisCamps, which are modelled on the BarCamp/CodeCamp7 concept, to “connect a global network of volunteers who use creative problem solving and open technologies to help people and communities in times and places of crisis”. They provide an example of a Voluntary Technical Community (VTC)8 and are supported directly by the US Federal Emergency Management Agency (FEMA).

This community has also been very active in supporting disaster relief efforts, a typical example being the collective support of the volunteers during the 2011 earthquake in Turkey where they successfully helped the relief agencies with support response and recovery efforts. 4 Design Recommendations The European Union Seventh Framework project, SOCIETIES9 has conducted some initial evaluations with the European Union’s Civil Protection Mechanism (CPM), using paper prototyping techniques. The objective of SOCIETIES is to design and evaluate a next generation mobile platform that integrates existing Social Networking sites with emerging Pervasive Computing frameworks, so as to create likeminded, purpose driven communities. The paper prototypes were designed to receive feedback from the CPM’s disaster experts on their views about using the cognitive surplus of the online community to aid in the disaster relief. The experts were presented with sample scenarios that attempted to describe how this online community might be leveraged in a disaster. For example, one scenario described the disaster team being 4 http://wiki.sahanafoundation.org/doku.php “The Sahana Foundation” 5 https://pl.nlm.nih.gov/christchurch/index.php?mod=inw&act=default “People Locator for the

ChristChurch Earthquake” 6 http://wiki.crisiscommons.org/wiki/Main_Page “Crisis Commons” 7 http://en.wikipedia.org/wiki/BarCamp “Crisis Commons Bar Camp” 8 http://www.emergencymgmt.com/emergency-blogs/campus/Crisis-Commons-Monitors

Turkey-Earthquake-102311.html “Voluntary Technical Community” 9 http://www.ict-societies.eu/ “FP7 SOCIETIES Project” confronted by some street signage that they were unable to translate. A digital photograph of the signage was taken and uploaded to the online community for translation. Another example asked the volunteers to spot the difference between satellite images of the disaster zone taken before and after the catastrophe, so roads or bridges that were destroyed could be identified in advance and alternative routes coursed. Two key findings10 resulted from this research: • •

Trust: how could the experts in the field trust the veracity of the results that they were receiving back from the online community? Automated decision-making: the experts said they would have to be very wary about handing over life or death decision making to machines, but were open to experimentation through simulation. They saw the benefit of automating some of their processes but were sceptical about where the veracity line would be drawn between automated services and the traditional manual verification process, particularly where lives are at stake.

In addition to this an online survey was undertaken in March 2012 (Roddy, 2012) and the results showed that a strong willingness does exist for a community of online volunteers to assist with disaster relief, and that this community would be willing to offer significant amounts of their cognitive surplus to this philanthropic activity. The survey also showed that this online community would be willing to provide personal profile information and that they would also be prepared to operate as part of a community of volunteers.

This is important because it indicates a potential model for establishing diversity. An assumption can be made here that a diverse community of online volunteers exists, which is at the heart of Surowiecki’s (2004) premise that diversity in the crowd will provide more accurate results than an expert.

The next steps would be to prove the above through future experimentation. That experiment would involve establishing an online user community of volunteers. These volunteers would provide their profile information at a granularity level that correlates to diversity; call this a ‘diversity factor’.

In total there are three components to be designed into this platform: i. Firstly the platform will need to have some process for deciding whether to send the data to an expert group or a diverse group. This could be done using a ‘task tagging profile’ and an ontology or semantic algorithm. ii. Secondly the platform needs a process that discovers the appropriate list of diverse volunteers; labelled as a ‘diversity factor’. Again, this could be done using ontology assessment of the volunteer’s profile tags. 10

http://www.ict-societies.eu/files/2011/11/D8.1_public.pdf “SOCIETIES Evaluation Report” Paper

Trial iii.

Thirdly the platform needs to be able to predict the ‘certainty or veracity level’ of the results, which is at the heart of Surowiecki’s ‘Wisdom of Crowds’ model. The problem here is to work out how many volunteer responses are needed to solve just one problem. The platform is trying to avoid: a) any mistakes being made, and b) volunteers deliberately providing false responses. By asking ‘x’ amount of volunteers to work on a problem and aggregating their responses, increases the veracity of the feedback.

An example is summarised in the message sequence chart below: The chart starts with a help request from the relief team working in the disaster zone. This could be something like help with parsing through satellite images of the disaster zone before and after the disaster, and reporting back on the amount of damage that has been done. So these images are uploaded to the Disaster Management Platform with a “Help Requested” tag, and a brief description of the profile of the task that they need help with. In this particular example help is needed parsing the satellite images for damage.

Using the “Task Profiler” component the platform now needs to figure out whether this particular help request requires the attention of an expert group or a diverse group and so sends the task profile to the Recommender System. The Recommender System parses through the task profile information and because this particular task does not require any particular skill advises back to the platform that a diverse group rather than an expert group is required to solve this task.

The platform now sends a request to the Diversity System to supply a diverse list of volunteers. So what does diverse mean here? The precise design of this component will be a next step but at a high-level the “Diversity Factor” algorithm will data mine the profiles of the complete list of volunteers (could be from their online social media profiles) and present back a subset list that is diverse. Diversity here could include: • • • • 50% of the list could be women The age profiles could be evenly spread Their ethnicity could be evenly spread

The educational profile could be evenly spread The platform will now send the task to this volunteer list and collate back their responses. Having aggregated the collated responses, which forms the “Veracity Level” of the task, the platform forwards the task solution back to the disaster team. 5 Conclusions This paper has made some recommendations that could aid the design of a collective intelligence emergency responder tool (this could also be a plug-in to existing systems, such as the Ushahidi platform). Use cases now need to be defined that list typical problems encountered in disaster relief, and these use cases would be used as input to the system design requirements.

The implemented design could be tested in a simulated environment, by setting up an experiment with actual relief workers and asking them to send their simulated help requests into the platform.

The experiment would continue by engaging on a real user (the online community) evaluation that compared the results that used the ‘diversity factor’ with those using the existing system (i.e. the manual verification process). Another important test will be to prove whether or not diversity is actually needed at all. This could be tested by setting up a controlled experiment that tests the use cases with the Recommender System turned ‘off’ and then repeating this again with it turned ‘on’. The overall objective here is to conclude that the system provides accurate enough results for the onsite disaster experts to be able to trust the feedback given, and as such remove the labour intensive manual verification process, thereby freeing up the valuable resources of the relief teams in the disaster zones. Available from: Available from: Available from: Cernea, D., S Mora, A Perez, A Ebert, A Kerren, M Divitini, DG de La Iglesia, N. Otero (2012). Tangible and Wearable User Interfaces for Supporting Collaboration among Emergency Workers, Proc of CRIWG 2012. pp. 192-199.

Di Loreto I., S. Mora, M. Divitini (2012). Collaborative serious games for crisis management: an overview. Proc. 21st International IEEE WETICE 2012.

Kristiansen A., Andreas Storlien, Simone Mora, Birgit R. Krogstie, Monica Divitini (2012).

Mobile and collaborative timelines for reflection. Proc. of IADIS conference on Mobile Learning 2012, Berlin, Germany. IADIS Press.

Krogstie, B., Prilla, M., Knipfer, K., Wessel, D., and Pammer, V. (2012). "Computer support for reflective learning in the workplace: A model. "International Conference on Advanced Learning Technologies (ICALT) 2012. City: ACM: Rome.

Mora, S., Boron, A., & Divitini, M. (2012). CroMAR: Mobile Augmented Reality for Supporting Reflection on Crowd Management. International Journal of Mobile Human Computer Interaction, 4(2), 88–101. doi:10.4018/jmhci.2012040107 Roberts, R. and C. Lajtha (2002). A New Approach to Crisis Management. Journal of Contingencies and Crisis Management vol 10 ( 4) 2002 ,pp. 181 – 91 Sagun, A., D., Bouchlaghem, and J.C Anumba (2008). "A Scenario-based Study on Information Flow and Collaboration Patterns in Disaster Management," Disasters (33:2), August 2008, pp. 214-238.

Schwantzer, S., Müller, N., Faltin, N., (2012) D2.2 Software Architecture – version 2, MIRROR deliverable

BRIDGE Risk Analyzer: A Collaborative Tool for Enhanced Risk Analysis in Crisis Situations1

Mass Soldal Lund and Atle Refsdal

SINTEF ICT, Oslo, Norway {atle.refsdal,mass.s.lund}@sintef.no Abstract. When a crisis occurs, such as a fire in a chemical facility, difficult decisions need to be made based on assessment of risk. Is it safe enough for responders to enter the area? Do we need to evacuate the public from the nearby area? Assessing risks may require information from a number of different sources, as well as collaboration across organizations and management levels. In this paper we present ongoing work to develop a collaborative tool to support risk analysis in crisis situations. The tool will be tightly integrated with a complementary tool to make coordinated situation assessments, planning, decision making, information gathering and sharing, thereby providing a unified and integrated crisis management support facility.

Keywords: Risk analysis, crisis management 1 Crisis management is a highly challenging task. Big decisions need to be made based on information from a number of different sources, such as detectors, sensors, bystanders, the public, on-site responders, and external domain experts. Successful crisis management depends on the ability to identify and obtain the relevant information, as well as to process this in a way that provides a good basis for making decisions. A recent example from Norway showed how unavailability of operational information, partly due to poor and outdated ICT solutions, contributed to the escalation of a major crisis [16, pp. 332–334]. These challenges are a major motivation for the BRIDGE project (http://www.bridgeproject.eu). Focusing on large-scale emergency management and the ubiquity of ICT support, the project aims to facilitate cross-border and cross-agency collaboration, allow the creation of a common, comprehensive, and reliable operational picture of the incident site, enable integration of resources and technologies into workflow management, and enable active ad-hoc participation of third parties. 1 The work on which this paper reports has been funded by the European Commission through the projects BRIDGE (Contract no. 261817) and NESSoS (Contract no. 256980). We are grateful for the feedback we got from experts during workshops and demonstrations.

Risk analysis is an essential prerequisite for decision making. Ensuring that the different actors involved in the crisis management and response have a shared understanding of the relevant risks is an important contribution to establishing shared situation awareness and a common operational picture. In this paper we present ongoing work to develop a collaborative tool to support risk analysis in crisis situations, called the BRIDGE Risk Analyzer (BRA). The BRA will be closely coupled with a tool, called the BRIDGE Master [ 1 ], for supporting coordinated situation assessments, planning, decision making, information gathering and sharing. The Master provides, among other things, functionality for visualization and management of all collected information and available resources during an incident and integration with hand held devices to be used in the field. Together, the BRA and the Master will contribute to a unified and integrated crisis management support facility.

In this paper we present the method used for researching and developing the BRA as well as our current results and findings. The paper is structured as follows: In Sect. 2 we present the general research and development method used. A description of how this method has been instantiated in the first and second iteration is given in Sect. 3 and Sect. 4. In Sect. 5 we present related work, before concluding in Sect. 6. 2

Method As research and development method we adopt an approach to technology research provided in [ 21 ]. The approach is focused on development of new and better artifacts and prescribes an iterative process of three phases.

The first phase – problem analysis – is concerned with identifying the needs for new and better artifacts. This should preferably be done in interaction with potential users and other stakeholders. In the second phase – innovation – the goal is to construct an artifact that satisfies the identified needs. The third and final phase – evaluation – is an investigation into whether or not the artifact actually satisfies the needs. In order to do this investigation, hypotheses and predictions concerning the artifact must be formulated based on the needs. Then these must be tested using a selection of established research strategies. (For an overview of research strategies, see [13, pp. 31– 34]; the research strategy chosen for the early iterations in the research and development of the BRA can be classified as judgment studies.) 3

First Iteration Based on Paper Prototype For the initial iterations we chose to use a lightweight instantiation of the method. The goal was to quickly reach a point where we had something concrete that could be presented to experts in the crisis management domain. This approach would ensure that we would receive feedback and corrections for bad ideas at an early stage.

Problem Analysis: Literature and Discussions Our initial problem analysis was carried out as an informal process where we acquired knowledge about the crisis management domain in general and risk analysis during crisis situations in particular mainly through literature, brainstorming and discussions. Typical resources that we drew upon included literature and investigation reports such as [ 5,17,19 ]. Moreover, we obtained domain knowledge through the Emergency project (http://heim.ifi.uio.no/~ketils/emergency/the-emergency-project.htm) which aims to improve decision support in emergency situations. Finally, we drew upon our general knowledge about risk analysis.

The above process allowed us to establish the following initial set of requirements for a tool, targeted toward the incident command level, to support risk analysis in situations where the decision frame is longer than a few minutes: R1: Be simple and intuitive to use. R2: Support identification and assessment of potential risks toward the safety of responders or the public, infrastructure, the environment, or other assets. R3: Facilitate exploitation of preparatory risk analyses performed before the crisis. R4: Support editing/updating of risk models during the crisis. R5: Support geographical location of risks. R6: Support identification of information that is typically needed to assess risks. R7: Facilitate participation of actors, such as domain experts, not present at the incident site in the analysis. 3.2

Innovation: Paper Prototype Following the strategy of a lightweight approach to the first iteration, the first artifact was developed as a paper prototype [ 20 ] of an application to be deployed on an interactive multi-user touch table. Paper prototypes can be developed with little resources, while still providing a good basis for discussions and feedback. Fig. 1 shows a picture of a part of the paper prototype. Although it aimed to fulfill all the requirements above, space restrictions mean that we must limit ourselves to explain some of the central aspects.

Fig. 1. Paper prototype of the BRA demonstrated at the evaluation workshop We chose to use graphical risk models expressed in a simplified version of the CORAS language [ 12 ]. The CORAS language was developed in order to be easily understood, and from other domains we have positive experiences with using CORAS models during risk analysis sessions involving actors from very different backgrounds. Moreover, we believe that graphical models are well suited for use with a touch interface. The functionality includes interacting with the model and sending information request to external experts.

P1.1 P1.2 P1.3 P1.4 P1.5 The Oslo participants found the tool useful for the command center, but wanted simpler support for the incident command. This was modified after we explained that a library of predefined risk models would be used, so that risk models need not be built from scratch during the crisis. One participant seemed to disagree that the tool was too complicated for the incident command. Still, our overall impression was that a simpler tool is wanted for the incident command level, so P1.1 was not confirmed. Interestingly, the Lancaster participants found the models too simple to be used by scientific or technical advisors, but suitable for local authorities and police, and possibly also for informing the press and the public.

As far as we could observe, all participants quickly grasped the meaning of the models. They did not ask questions that indicated misunderstandings or incomprehension. We therefore consider that P1.2 was confirmed.

The functionality for requesting support from external experts was only briefly explained due to time restrictions. It did not raise further discussion or comment from the participants. Our impression is that this was seen as a useful feature, but a clear evaluation of P1.3 could not be made at that point. A need for a list of risk treatment options that is related to different risk levels, so that different options are proposed depending on the risk level was suggested. This means that P1.4 was falsified.

Apart from the comments described in the evaluation of P1.1, the participants' feedback did not indicate that any of the features were unsuitable or redundant.

Evaluation: Workshop The paper prototype was evaluated primarily through workshops organized by BRIDGE [ 1 ] in Oslo 29/9-2011 and in Lancaster 16/4-20122. The workshops included interactive sessions where the paper prototype was presented to experts from the crisis/emergency domain and the experts were asked questions and encouraged to give their feedback. Three experts participated in this session in the Oslo workshop, while two experts participated in the Lancaster workshop. Although not explicitly formulated as such prior to the workshops, our underlying hypothesis (H), and the predictions 2 BRIDGE also organized a similar workshop in Delft 6/12-2011. However, in this workshop we presented a version of the BRA for mobile devices, so this is less relevant for this paper. (P) derived from the hypotheses, can be captured as follows: H: The tool adequately supports the incident commanders and their assistants w.r.t. risk analysis during largescale crisis management. P1.1: The workshop participants will consider the BRA easy to use for incident commanders and their assistants. P1.2: The workshop participants will easily understand the graphical risk model. P1.3: The workshop participants will find the possibility to requesting support from external experts to be useful. P1.4: The workshop participants will not identify additional features that they consider necessary. P1.5: The workshop participants will not consider any of the presented features redundant or unsuitable.

Table 1 summarizes our evaluation of the predictions based on an informal analysis of notes and video recordings of the workshops. We can of course only draw preliminary conclusions to be followed up by more systematic investigations later. 4

Second Iteration Based on Executable Prototype In the second iteration we focused on building an executable prototype, but still doing fairly lightweight evaluation. The goal was to present something that resembles the final artifact to get feedback on design decisions at an early development stage.

Problem Analysis: Refinement Based on Workshops and Interaction The second problem analysis was primarily based on the evaluation from the first iteration. Perhaps the most fundamental feedback was the considerations regarding the target group. Workshop participants had expressed doubt as to whether the tool was simple enough for use by the incident command, but they had also stated that it would be useful for the command center, and that it could help making better assessments. This, together with the fact that a command center will typically be more involved in a large emergency than the smaller incidents, and that BRIDGE is concerned with large-scale emergencies, led us to change the target group for the tool to include the command center, rather than to discard the design. This means that we added the requirement that it should be possible to use the tool cooperatively both at the command center and the incident command. We envision that the command center personnel will typically do most of the actual tailoring and editing of risk models during the crisis, while the incident command will be able to see the results and make adjustments as they see fit. This harmonizes well with the idea that the higher command levels should provide support for the on-site responders. However, the tool itself should not place strong restrictions on how the work is divided between the levels, as feedback from the workshops indicates that the level of sophistication of support tools used by the incident command level can vary greatly. We plan to develop a simpler version for mobile devices later, but this is beyond the scope of this paper.

The evaluation after the first iteration also led to the inclusion of a requirement based on the proposal described under the evaluation of P1.4. Hence, the list of requirements from Sect. 3.1 is extended with the following: R8: Facilitate collaborative use of the tool at the command center and the incident command. R9: Support identification of proposed risk treatments that depend on estimated risk level.

Innovation: Executable Prototype The executable prototype of the BRA is developed as a Microsoft PixelSense (http://www.pixelsense.com) application for the Samsung SUR40. Samsung SUR40 is a computer built as a table with the table top made up by a 40'' multi-touch screen. Fig. 2 shows the prototype BRA deployed on the touch screen table. In addition to functionality for creating and editing simplified CORAS diagrams, the prototype also connects to middleware developed in the BRIDGE project. Through this middleware it exchanges messages with the Dynamic Expertise Integration Network (DEIN) [ 18 ], a system for communicating with off-site experts as part of the crisis management. In summary we can say that the development of the executable prototype during the second iteration focused on the fulfillment of requirements R1, R2, R4 and R7 defined in Sect. 3.1, while requirements R3, R5 and R6, as well as requirements R8 and R9 defined in Sect. 4.1 were postponed to later iterations.

Fig. 2. Executable prototype of the BRA deployed on a Samsung SUR40 table 4.3

Evaluation: Demonstration For the second evaluation of the BRA, the prototype was featured as one of several tools in a project wide demonstration of BRIDGE, held in VersuchStollen Hagerbach (http://hagerbach.ch ) in September 2012. The BRA was used to review risks of escalation of a crisis and to send risk specific requests for information through the DEIN system. At the time of writing, we are still waiting for the participants' feedback.

The overall hypothesis H from the first evaluation remains the same, except that we included command center personnel in the target group. Due to the different nature and focus of the second evaluation, new predictions were formulated to fit the particularities of the demonstration: P2.1: The domain experts consider the use of risk models in the BRA as a useful tool for use at the command center and the incident command. P2.2: The domain experts consider sending requests for information to DEIN from BRA a useful feature to support the risk analysis. P2.3: The domain experts do not consider any of the demonstrated features of the BRA redundant or unsuitable. 5

Related Work The study of the effectiveness of visual or graphical communication of uncertainty and risk goes back a couple of decades, though according to a survey from 1999 [ 11 ], studies testing visual aids in risk communication until that point in time were few. In one of the first studies [ 8 ] a group of non-technical was people subjected to a number of graphical means for visualizing uncertainty. This study showed that how uncertainty is presented by graphical means is relevant for how it is perceived. A study of communication of health risks [ 3 ] found that the respondents preferred a presentation combining a short text and an illustration over a longer piece of text. The 1999 survey [ 11 ]concludes that the evidence available in 1999 points in the direction that visual aids are useful for communicating risk, but that the tasks of the reader (the purpose of the communication) always must be considered when choosing what aids to apply. Research on the CORAS language [ 6,7 ] indicates that a simple iconography combined with text labels is effective in communication of risk, and thus points in the same direction as earlier research.

In [ 2 ] a risk model, expressed in the CORAS language, for forest fires is developed based on a process similar to risk and emergency preparedness assessment in the offshore industry [ 15 ]. The model is parameterized by influence factors such as the direction and speed of the wind and the quality of the wood. In [ 4 ] an interactive mapbased tool capable of visualizing risk is presented. This tool has inspired certain aspects of the BRA.

There exist a number of computerized support tools for incident management, such as Essential Incident [ 9 ], opsIncident [ 10 ] and E Team [ 14 ]. They all provide support for information collection and, to varying degree, risk analysis. However, we are not aware of any tool that uses graphical risk models to be viewed and updated on a multi-user interactive touch table in a way similar to the BRA. 6

Conclusions and Future Work Focusing on the method of research and development as well as the results, we have presented ongoing work to develop a collaborative tool to support risk analysis in crisis situations. Our goal is to provide, in conjunction with the BRIDGE Master, a unified and integrated crisis management support facility. Although results so far are promising, a number of issues still need to be addressed in later iterations.

The next step in the research and development process is obviously to evaluate the outcome of the demonstration described in Sect. 4.3, before initiating a new iteration of the process. In the problem analysis step of this third iteration the evaluation of the demonstration will be used to revise the list of requirements. The innovation step will focus on further development of the executable prototype to support the requirements not addressed so far. Requirements R5 and R6 will be supported by integrating with the BRIDGE Master and thus making its features and information available to the BRA. Requirements R3 and R8 will be supported by a risk model repository to hold preparatory risk models as well as risk models shared among several instances of the BRA. Requirement R9 will be supported by automated reasoning based on the information provided to the BRA and conditions specified in the preparatory risk models. The evaluation of the third iteration will be a second demonstration where the focus will be on the user interfaces of the BRIDGE system.

Mathias Wilhelm, Eva Burneleit, Sahin Albayrak DAI-Labor/TU-Berlin, Ernst-Reuter-Platz 7, 10587 Berlin, Germany

{firstname.lastname}@dai-labor.de Abstract. In mass casualty incidents, operation managers have to make decisions under highly stressful conditions. At present, the tactical information is mostly written down on paper-based worksheets, which are inconvenient to use. As a result, the operation managers tend to avoid the paper sheets and try to remember information which is error-prone. To overcome this issue, this paper presents an IT-supported tactical worksheet for touch devices. It describes a user-centered approach that gathers the requirements on the proposed worksheet from a comprehensive long term expert panel with three senior fire brigade officers, two of their assistants, three researchers, and one designer. To validate the specified requirements, a first prototype was implemented and pre-evaluated in a real mass casualty incident simulation with 20 casualties. The evaluation revealed further design and implementation aspects to be considered in future work.

Keywords: tactical worksheet, tactical decision making, tactical information visualization, mass casualty incidents 1 In a mass casualty incident (MCI), operation managers are confronted with a great amount of information, which they have to process in order to make tactical decisions. Despite modern technologies, the information is still gathered by the on-site staff and communicated via radio, and by paper. In order to store and to structure all information, a so called tactical worksheet (TWS) is used. Interviews with senior fire brigade officers performed in context of this paper revealed that paper-based TWSs are stationary and inflexible due to their size (DIN/ISO A3 and larger). Additionally, more than one sheet is necessary because the operational information is dynamic and changes during the operation. Consequently, the information of the current worksheet has to be transferred to an additional one or, alternatively, it must be switched between the current TWS and the previous ones. Due to this overhead and discomfort, operation managers tend to avoid paper-based TWSs and manage all information in their mind. Interviewed senior fire brigade officers stated that because of the high stress, huge amount of information and long operational duration, they can lose control of the information management or even forget important information. In extreme case, this issue can cost life.

Addressing these issues, this paper proposes an electronic version of a TWS which is gathering and managing operational information in real time to support the operation manager in his decision making. The TWS was developed within the ALARM1 project [ 7 ] aiming to develop modular IT-solutions which support emergency medical service providers and rescue staff in mass casualty incident response and training. In fact, the ALARM solution contains a ubiquitous computing infrastructure providing, for example, RFID tags in order to record information of casualties, handheld devices for the rescue stuff, cameras, mobile tablet computers and a robust AD-HOC network supporting seamless WLAN, GPRS, and satellite communication. This infrastructure allows a broad collection of operation information seeming appropriate for the proposed TWS.

In the following section, the paper gives an overview of the state of the art in which this work is motivated. In section 3, it describes the user-centered design process and the requirements gathered from the expert panels and interviews with senior officers and their assistants of the Berlin fire brigade. Based on the collected requirements, the TWS solution is described in section 4, which is presenting software development aspects in general as well as the user interface and the interaction design aspects. In section 5, the implementation of a first prototype and in section 6, its preevaluation is briefly described. The paper ends with a conclusion in section 7, in which the approach is discussed and an outlook presenting planned future work. 2

Related Work To overcome the disadvantages of paper-based worksheets and to give operation managers support in an MCI, there exist different approaches. In the following, selected approaches will be presented and briefly discussed.

In [ 2 ], a multi-touch table solution supporting natural and intuitive interaction for the command and staff position is presented. This solution gives an overview about the current situation by visualizing the number and the location of casualties as well as of available rescue resources on a map. It is designed primarily for the leading medical doctor and it supports no input in order to send orders to the rescue resources.

A generalized support system for rescue staff is presented in [ 3 ]. The advantage of this system is that it can be connected with nearly any existing database, because it applies a semantic description for the data input. The focus of this project is more on generalized information and data visualization and less on supporting communication, e.g. for giving commissions to the rescue resources. A triage system providing information of the casualties for large displays and handheld devices is presented in [ 8, 1 ].

A design methodology for interactive emergency management systems is presented in [ 5 ]. This methodology is applied on a task management system including a backend, decision and planning support, and a user interface for mobile devices. In [ 6 ], a design guideline for mobile checklist applications as well as a prototype imple1 ALARM: Adaptive Lösungsplattform zur Aktiven technischen Unterstützung beim Retten von Menschenleben (in English: Adaptive solution platform to the active technical support in saving life) mentation is presented. The guideline is focused on the different organization (e.g. police or fire brigade) involved in MCIs. It provides different features such as execution monitoring and logging.

All presented approaches support the decision process of the operation manager, but none of them accompanies the operation manager from the beginning to the end of the operation. Further, no approach discovers the whole spectrum of an operation. This is the starting point of the research of this paper. 3

Methodology In order to develop a TWS tailor-made meeting the requirements of an operation manager, a user-centered design approach was applied. This approach is oriented mainly on the software requirement analysis and design process proposed in [ 4 ]. It consists of four stages (noted below) and was performed with three senior fire brigade officers and two of their assistants representing the stakeholders. The whole design process was guided and performed by two researchers and one designer from the institute of the authors. In the following, the different stages are listed in detail: 1. Requirement Process: At first, the relevant roles including their connection and the workflow of an MCI were determined by open interviews. The interviews were performed separately with each of the stakeholders and followed a formless structure. The stakeholders were asked to explain the whole workflow of an MCI. In this process, the interviewer made notes and asked questions in between. All determined roles were covered by the stakeholders. 2. Requirement Elicitation: This elicitation of the requirements of the stakeholders consisted of a combination of an open interview and scenarios. These scenarios were oriented on the gathered workflow in stage one. In this process, each stakeholder simulated a complete MCI workflow based on different paper-based TWSs investigated from different free available internet sources2. 3. Requirement Analysis: Based on the information gathered in stage two, the relevant requirements were identified, structured and documented. Afterwards, a wireframe study was performed and discussed with the stakeholders in order to create the interaction concept and to model the cooperative workflow. Finally, mockups serving as design templates for the prototype implementation were created and discussed. 4. Requirement Validation: In order to validate whether the conceptual design meets the requirements of the stakeholders, a first prototype was implemented and evaluated in a small real simulated MCI with 20 casualties. During the whole simu2 Tactical worksheet examples which were applied for the scenario with the stakeholders: http://www.idf.nrw.de/service/downloads/downloads_hilfsmittel.php (accessed on 2012/08/22) http://www.orgl-pm.de/Taktisches_Arbeitsblatt_MANV_PM.pdf (accessed on 2012/08/22) http://snuconline.com/SNUC_Online.com/Tactical_Worksheets (accessed on 2012/08/22) http://www.srpmic-nsn.gov/government/fire/sog.asp (accessed on 2012/08/22) lation, the stakeholders working with a TWS prototype were observed and, afterwards, interviewed regarding the usage of the TWS. The gathered information was used to step back to stage three in order to perform the requirement analysis again based on this new information.

The information gathering process and the requirement analysis proved to be very time consuming. The following statement of a fire brigade officer highlights the difficulty of the requirement analysis: “99% of the decisions are decisions from the gut and only 1% is based on tactical information.” This means, that only few decisions are based on tactical information such as weather forecast, geographical peculiarities, or casualties and resources statistics, but these decisions can cost life. The main challenge was to identify exactly these requirements for the TWS in order to provide the right information at the right time. 4

Requirements In the following, the identified requirements are listed and discussed: Domain knowledge:  Up-to-date overview of all casualties: Based on the casualty statistic, the operation managers plan the operation and manage the rescue resources.  Up-to-date overview of available resources: Operation managers must be aware of the available resources at the operation. In particular, they must ensure that enough resources are available to transport the casualties to hospitals. Another aspect at a long-term MCI is that the operation managers are responsible for the crew. Therefore, they need to know the total number of resource staff involved in the MCI. These aspects imply that it must be recognizable which resources are still approaching and which already arrived at the operation location (and where they are).  Map: Based on a map, operation manager can plan the operational structure, e.g.

where the treatment area should be created.  Operational areas: It should be possible to create the operational structure with the TWS. Further, it should be possible to assign a leader and resources to operational areas as well as to provide the visualization of their position and area on the map.  Dangers: The dangers should be illustrated on the map including detailed information about the dangers.  Weather forecast: Based on the weather forecast, operation managers plan the operational structure. For instance in case of a fire, they must mind the forecast wind direction in order to know the direction of the smoke.

Needs:  Tasks and Requests: In order to keep the operation manager aware of the given tasks and received requests from the subunits, the whole task and request handling should be covered by the TWS and it should keep track of the task status.  To make notes and sketches: One expressed request was the possibility of making notes via voice, stylus input or picture snapshots in order to document the operation, to send the rescue coordination center additional information/impressions of the operation, or to add some important notes.  Remember/alarm functionality: Caused by the high impact of stress, operation managers tend to forget the time. This issue can lead to forgetting periodic occurring tasks (such as giving a situation report to the rescue coordination center) or frequent checks of the state of given assignments/requests.  Documentation: At present, no reversion-save documentation system has been found recording the decisions of the operation manager and the overall operation progress. Such documentation is very useful for the review and the post-analysis of the operation as well as for the training of rescue staff. Furthermore, it could be useful for the operation manager to clarify the operational decisions in case of any legal actions.  Checklists: The importance of checklists was noted in nearly all interviews within the first and the second stage of the design process. A checklist should contain frequently occurring tasks at each MCI such as to wear a signal vest signing to be the operation manager, to create a treatment place, or to give the situation report to the rescue coordination center. In order to create one, some example checklists from the fire brigade were received. All fire brigade officers disliked the checklists in the wireframe concept. It was recognized that they have not to be reminded of everyday business duties. However, it was discovered that they need to be reminded of periodic tasks such as to give a situation report to the rescue coordination center. Design aspects:  Strict hierarchal chain of commands: The TWS must not violate the strict hierarchal chain of commands. For instance, a sub-operational unit leader should not be able to send a request for additional resources (e.g. for transporting casualties to the hospitals) to the rescue coordination center.  Simple to use: MCIs as well as their simulations occur very rarely. Thus, it can happen that operation managers have no contact with the TWS for month or even years. Consequently, all user interfaces must be intuitive, easy to use and robust. 5

Concept After the identification of the requirements on the TWS, the following six workflow use cases were created in order to design the interaction workflow: alerting and drive, arriving and role changing, situation assessment and situation report, giving commission and sending a request, (sub-) operational units, and information and note area. The design is based on the requirement, that all important operation information must be visible on one view. Additionally, the design concept should be transferable to different touch devices, e.g. large multi-touch tables, tablets or smart phones. To fulfill this requirement, to create the interaction concept and to model the cooperative workflow, a wireframe-based prototype was developed (Fig. 1). Particularly with regard to the requirement of displaying all relevant information on one view, the design concept has been split into the following four equal sized areas (Fig. 2):  Map area: This area provides the following full multi-touch-based interactive views: a street map, a combination of a satellite view and a street map, an object plan if available, and a free sketch/note area. The two map views include the illustration of (sub-) operational units, dangers, casualties and some additional information such as wind direction.  Information area: Here, the over-all operation information is displayed ranging from arbitrary information such as operation address, (operation) time, to casualties and resources statistics.  (Sub-) operational unit area: In this area, all (sub-) operational units are listed providing specific information such as (sub-) operational unit leader, assigned resources, or casualties in this (sub-) operational unit.  Task and Request area: This is a management area providing an overview of all given tasks/commissions and received requests, as well as an log view documenting the inputs of the user and incoming events, and a note and documentation area allowing to record or to write down some notes.

Fig. 1. Wireframes for the TWS at different design/conceptual phases (left is an early version and right an advanced one).

Fig. 2. The final mockup showing the four area design.

In order to provide a more detailed and larger view, each area can be resized by a short single touch inside an area expanding buttons. It is also possible to enlarge two areas at the same time. Last, but not least, the TWS supports drag and drop actions between the different areas for special interactive elements, e.g. dragging an operation unit from the operation unit area on the map. Thanks to a modular design, all areas and their interactive elements can be used as single modules. Therefore, it is possible to transfer the whole concept to smaller screens.

Besides the requirements concerning interaction and design aspects, further functionalities were considered in the conceptual phase such as an automatic sending of the situation report (because the TWS holds all information to be given in a situation report and thus, the operation manager does not have to be reminded to do it), reminding of special events (e.g. that not enough resources are available to transport the casualties or to check the state of given commissions), and a role rights management component controlling and managing the displayed information for all roles.

After the wireframes were accepted by the fire brigade officers and their assistants, mockups were created. These mockups served as design templates for the prototype implementation. 6 To validate whether the design concept meets the requirements of the operation manager, a preliminary prototype was implemented and evaluated in an MCI simulation with 20 supernumeraries acting as casualties. This simulation was originated to perform an integration and cooperation test of all components developed in context of the ALARM-project [ 7 ]. Consequently, the simulation did not claim to simulate an MCI.

Aligned to the ALARM-project solution, the TWS receives and sends all information from/to a local server, the so called local platform, via ActiveMQ3. The local platform is the central element of the operational structure. It gathers all accruing operation information from mobile clients such as triage or transport information. Every time new information is coming in, the local platform forwards this information to the TWS. The TWS prototype itself was implemented in Java using MT4j4, supported no input functionalities, and was deployed on a Motion J3500 tablet PC5.

The simulation consisted of only one treatment area which was already build-up at the beginning. During the whole simulation, one researcher accompanied the operational manager and noted everything related to the TWS including issues, the way of interaction, and remarks of the operation manager. This intermediate evaluation revealed open design issues such as the difficulty of reading color-coded casualty statistics in bright daylight and new requirements such as more variations of the casualty statistics, and the wish of recognizing possible problems in the triage process such as the need of more rescue staff for the triage. The notes from the simulation are currently analyzed and will be considered in the requirements analysis again. http://activemq.apache.org/ (accessed on 2012/08/22) http://www.mt4j.org (accessed on 2012/08/22) http://www.motioncomputing.com/products/tablet_pc_J35.asp (accessed on 2012/08/22) In this paper, an IT supported tactical worksheet supporting operation managers in their decision making was presented. It includes the comprehensive requirement analysis and conceptual aspects. Although the requirements were established in context of the ALARM project for the Berlin fire brigade, they should be general enough to apply to other fire brigades. Finally, a preliminary prototype was evaluated in a real MCI simulation with 20 casualties in order to validate the design concept developed from the identified requirements. The evaluation revealed useful feedback to the design which has to be still analyzed. Based on information gathered from this analysis, the requirement analysis as described in section 3 has to be performed again. Furthermore, it will be considered how the ubiquitous computing infrastructure of the ALARM solution can be used to recognize critical situations at the MCI. The reworked design concept and an enhanced prototype implementation will be tested on a real MCI simulation with about 33 casualties.

Acknowledgements. This work originated in conjunction with the ALARM project which is sponsored by the German Federal Ministry of Education and Research (contract/grant number 13N10109).

References

Applying AmI Technologies to Crisis Management:

AmI 2012 Workshop Summary Monica Divitini1, Babak A. Farshchian2, Jacqueline Floch2, Ragnhild Halvorsrud2, Simone Mora1 and Michael Stiso2

1 NTNU,

N-7491 Trondheim, Norway {monica.divitini, simone.mora}@idi.ntnu.no

2 SINTEF ICT,

P.O.Box 4760 Sluppen, N-7465 Trondheim, Norway {babak.farshchian, jacqueline.floch, ragnhild.halvorsrud, michael.stiso}@sintef.no Abstract. The AmI4CM workshop was organized as part of AmI 2012 in Pisa, Italy. This short paper summarizes the workshop content and the discussions that took place during the workshop. 1

The workshop aims to bring together researchers and practitioners working on the application of AmI (Ambient Intelligence) to crisis and disaster management. Because of their pervasiveness and ease of use, AmI technologies hold a great potential to support crisis management in an efficient and effective way. The focus of the workshop is to better understand (1) the strengths of the AmI paradigm, (2) challenges to its application, and (3) its potential in the development of innovative solutions. The workshop is open to participation from different standpoints, including platform and user interaction issues, methodological approaches, and specific applications.

The workshop is jointly organized by three projects that investigate ICT support for crisis management from different perspectives. BRIDGE1 aims at building a system to support interoperability – both technical and social – in large-scale emergency management. MIRROR2 aims at developing ICT tools for supporting workplace reflection and learning. Training of crisis workers is also a core application domain of the MIRROR project. SOCIETIES3 aims at extending the application of pervasive computing beyond the individual to communities of users, developing the concept of Cooperating Smart Spaces. Disaster management is chosen as one area for 1 http://www.bridgeproject.eu/en 2 http://www.mirror-project.eu/ 3 http://www.ict-societies.eu/ the evaluation of the proposed solutions in SOCIETIES. All three projects are funded by the EU Seventh Framework Programme.

Papers: The workshop has an open call and is advertised in a long range of relevant lists and communities. Organizers use easychair.org to do the review process. The workshop papers are peer-reviewed by the organizing committee4. Eight papers were received by end of deadline for submission in 2012. All eight were accepted for participation in the workshop. As you can see in the proceedings, the papers represent diverse aspects of AmI in crisis management, including tools, platforms, studies and observations.

Workshop participation: The workshop was divided into two parts: presentations in the morning and a SWOT analysis in the afternoon. All accepted papers were presented by the authors during the workshop, and all but one of the authors participated in the SWOT session in the afternoon. The SWOT session was interactive and involved all the participants at equal level.

Preparations: In addition to the paper review process we also asked the participants to create profile cards for themselves, which turned out to be very useful during the workshop (see Figure 1). We also asked Jacqueline to give the workshop an overview of AmI, how it was defined in the literature, and what applications it had. The presentation was given in the beginning of the workshop in order to create a common understanding of the subject. 4 Since this is the first time we organized this workshop we did not extend to a larger reviewer group. This will be done for future editions. Besides the papers that are presented in these proceedings, the other major deliverable from the workshop is a SWOT analysis5 that we did during the workshop. The process consisted of two parts, one brainstorming part and one clustering part.

In the brainstorming part the participants were given a 20 minutes individual task of writing down their contribution to the analysis on Post-It notes. Afterwards each participant was asked to present the contribution to the others. We used the windows in the room to hang the notes. Table 1 at the end of the paper shows a raw format of the contributions.

The clustering part was about grouping the contributions to major thematic groups. This task was also done involving the whole group of participants (see Figure 2). At the end we documented the results in a mind map. A portion of the map is shown in Figure 3. The groups under each heading included the following:  Strengths: Support for situation awareness, support for non-experts, diffused enabling technologies such as smart phones, relevance for the society.  Weaknesses: Technology-driven focus, inherent technological complexity, contribution to information overload, lack of robustness in the available technology and systems.  Opportunities: Emerging technological trends that can help AmI4CM, can contribute better to organizational aspects and logistics, can help in analysing large amounts of data, can be used also for preparedness.  Threats: Methodological weakness (real world evaluations and validations almost possible), integration and standardization challenges, technological challenges (e.g. infrastructure failure during disasters), lack of acceptance (e.g. big brother issues, usability issues).

If you need the complete mind map document please contact one of the co-organizers. 4

Future work The workshop home page6 will work as a blog for the community of the participants. We believe the workshop contributed positively to the field. The participants were very active before and during the workshop. We hope the workshop will continue as a series as part of the AmI conferences or elsewhere. We thank all the participants for the cooperation. 5 SWOT analysis (alternately SWOT Matrix) is a structured planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture. (Definition from Wikipedia) 6 http://research.idi.ntnu.no/ami4cm/

Harmful Weakness: Lack of trust in automation, Lack of privacy, Infrastructure to set up, Many prototyped solutions are not stable enough, e.g. network, Security/privacy, Inability to observe relevant information, Introduce additional technical overhead, A tendency to remove the social, A tendency to focus on the technical, Non-technological issues might hamper use of technology during crisis, Too much reliance on infrastructure, Provide useful information, Saving time, Regional differences, need to do lots of adoption work, Access to social data might be limited in rural areas, Lack of common framework/middleware for integration, Problems making sense of a lot of collected data, Weakness in the design process, with multiple stakeholders, Lack of robustness, Rising complexity of the systems, and integration with existing infrastructures. Complex systems with a lot of risks, Lack of integration with everyday life for normal people, Fragile and too complex systems Threats: Communication barriers among agencies, There is a gap between technical and application-related knowledge, Infrastructure threats, Dependency on technology can become a problem when technology not available, Low user acceptance, Misinterpretation of prototypes because they are often too mature for user involvement, Network and service availability, Difficult to get tools in daily practice, Successful use of this type of technology might require too much costs, Accountability, Lack of acceptance due to privacy issues, Users not allowed to do real crisis, barrier, Invasiveness of AmI technologies, Acceptance and the difficulty of it, Trust in technology when there is no continuous usage, Integration into existing organizational patterns and existing technologies, Difficulty with standardization, Lack of transparency, Very different scenarios; challenge for generalizing, Methodogically weak when it comes to evaluation, Big brother

References

1. BRIDGE Newsletter , no. 2 ( 2012 )

2. Braendeland , G.: Forberedende beslutningsrisikoanalyse for håndtering av skogbrann i Elverum kommune . Technical report A17367 , SINTEF ICT ( 2011 ) [In Norwegian]

3. Connelly , A.N. , Knuth , B.A. : Evaluating risk communication: Examining target audience perception about four presentation formats for fish consumption health advisory information . Risk Anal . 18 ( 5 ), 649 - 659 ( 1998 )

4. Eide , A.W. , Stølen , K. : Geographic visualization of risk as decision support in emergency situations . In: 5th International Conference on Human System Interaction (HSI'12) ( 2012 )

5. Flin , R.. , Arbuthnot , K . (eds.): Incident Command: Tales from the Hot Seat . Ashgate Publishing Company ( 2002 ) [Reprinted 2008]

6. Grøndahl , I.H. , Lund , M.S. , Stølen , K. : Reducing the Effort to Comprehend Risk Models: Text Labels Are Often Preferred Over Graphical Means . Risk Anal . 31 ( 11 ), 1813 - 1831 ( 2011 )

7. Hogganvik , I. , Stølen K. : A graphical approach to risk identification, motivated by empirical investigations . In: 9th International Conference on Model Driven Engineering Languages and Systems (MoDELS'06). Lecture Notes in Computer Science , vol. 4199 , pp. 574 - 588 . Springer ( 2006 )

8. Ibrekk , H., Morgan, G.: Graphical communication of uncertain quantities to nontechnical people . Risk Anal . 7 ( 4 ), 519 - 529 ( 1987 )

9. IHS. Essential Incident . Flyer ( 2010 )

10. IHS. opsIncident. Flyer

11. Lipkus , M.I. , Hollands , J.G. : The visual communication of risk . J Natl Cancer Inst Monogr . 25 , 149 - 163 ( 1999 )

12. Lund , M.S. , Solhaug , B. , Stølen , K. : Model-driven risk analysis . The CORAS approach . Springer ( 2011 )

13. McGarth , J.E. : Groups: interaction and performance . Prentice-Hall ( 1984 )

14. NC4 . E Team. Flyer ( 2011 )

15. NORSOK Standard Z- 013 : Risk and emergency preparedness assessment . Edition 3 ( 2010 )

16. NOU 2012 : 14: Rapport fra 22. juli-kommisjonen ( 2012 ) [In Norwegian]

17. NOU 2001 : 9: Lillestrøm-ulykken 5 . april 2000 ( 2001 ) [In Norwegian]

18. Pavlin , G.: Dynamic Expertise Integration Network (DEIN): User Manual (Draft), Version 0 .6. Thales Research and Technology

19. Rake , E.L. : Crisis Management. Coping and decision making on-scene . Ph.D. thesis , University of Stavanger ( 2008 )

20. Snyder , C. : Paper prototyping . IBM developerWorks ( 2001 )

21. Solheim , I. , Stølen , K. : Technology research explained . Technical report A313 , SINTEF ICT ( 2007 )

1. Adler , C. , Krüsmann , M. , Greiner-Mai , T. , Donner , A. , Chaves , J.M. , Estrem , À.V.: ITSupported Management of Mass Casualty Incidents: The e-Triage Project . In: Proceedings of 8th International ISCRAM Conference . ( 2011 )

2. Artinger , E. , Coskun , T. , Schanzenbach , M. , Echtler , F. , Nester , S. , Klinker , G.: Exploring Multi-touch Gestures for Map Interaction in Mass Casualty Incidents . In: 3. Workshop zur IT-Unterstützung von Rettungskräften, Informatik 2011 . ( 2011 )

3. Babitski , G. , Bergweiler , S. , Grebner , O. , Oberle , D. , Paulheim , H. , Probst , F. : SoKNOS: Using Semantic Technologies in Disaster Management Software . In: ESWC'11. LNCS , vol. 6644 , pp. 183 - 197 . Springer Berlin/Heidelberg ( 2011 )

4. Bourque P. , Dupuis , R.: Guide to the Software Engineering Body of Knowledge 2004 Version . In: Guide to the Software Engineering Body of Knowledge , 2004 . SWEBOK ( 2004 )

5. Humayoun , S. , Catarci , T. , Leoni , M. , Marrella , A. , Mecella , M. , Bortenschlager , M. , Steinmann , R.: Designing Mobile Systems in Highly Dynamic Scenarios: The Workpad Methodology . In: Knowledge, Technology & Policy 22 , pp. 25 - 43 . ( 2009 )

6. Krüger , U. , Wucholt , F. , Beckstein , C. : Electronic Checklist Support for Disaster Response . In: Proceedings of the 9th International ISCRAM Conference . ( 2012 )

7. Lawatschek , R. , Düsterwald , S. , Wirth , C. , Schröder , T. : Alarm: A Modular IT Solution to Support and Evaluate Mass Casualty Incident (MCI) Management . In: Proceedings of the 9th International ISCRAM Conference . ( 2012 )

8. Martí , R. , Robles , S. , Martín-Campillo , A. , Cucurull , J.: Providing Early Resource Allocation During Emergencies: The Mobile Triage Tag . In: J. Netw. Comput. Appl . 32 ( 6 ), pp. 1167 - 1182 ( 2009 )