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.
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 [
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
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 [
A generalized support system for rescue staff is presented in [
A design methodology for interactive emergency management systems is presented
in [
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
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 [
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
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
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).
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 [
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).