Odd Steen
email: odd.steen@ics.lu.se

Andrew Pope
email: a.pope@ucc.ie

Marion Rauner
email: marion.rauner@univie.ac.at

Nicklas Holmberg
email: nicklas.holmberg@ics.lu.se

Simon Wood- Worth
email: s.woodworth@ucc.ie

Sheila O'riordan
email: sheila.oriordan@ucc.ie

Helmut Niessner
email: helmut.niessner@univie.ac.at

Karen Neville
email: karenneville@ucc.ie

A Comprehensive Decision Support System for Enhanced Emergency Decision Management and Training

Keywords: Emergency Management, Emergency Management Systems, Emergency Decision Making, Emergency Decision Support Systems, Emergency Management Taxonomies

Emergency decision makers face a challenge taking rapid and highrisk decisions during an emergency situation, especially when the emergency is cross-border and requires multi-agency cooperation. The emergency decision makers use emergency management (EM) system and sometimes decision support systems (DSS) when responding to a crisis. To date the emergency decision makers have not had access to a system that supports them in all facets of the full EM cycle. This paper describes work in progress designing and building a comprehensive system of systems that intend to be that support for emergency decision makers. The system has successfully demonstrated its value from a technical and user perspective. Future tests will demonstrate if it will enhance decision management in reality-based emergency scenarios.

Introduction

Large scale emergency situationsbe they natural, deliberate or accidentalare inevitable. They do not respect borders, a large number of people and animals, both domesticated and wild, die and the long-term consequences from economic to mental health can for years devastate the affected population. When emergency decision-takers respond to emergency situations they are sometimes overwhelmed by decision-making [START_REF] Alexander | Principles of emergency planning and management[END_REF]. They are required to, based on accessible and available information, make rapid high-risk decision when responding to an emergency situation. Quick decisions regarding allocation of strained resources, prioritizing casualties, while simultaneously trying to contain the level of impact are challenging.

To better manage and respond to emergency situations, emergency decision makers are often supported by disaster management systems that can e.g. provide graphical representation of relevant data about the emergency and its consequences. Even if decision support systems (DSS) have been used for emergency management [START_REF] Egli | Beyond the storms: Strengthening preparedness, response, & resilience in the 21st century[END_REF][START_REF] Whybark | Co-creation of improved quality in disaster response and recovery[END_REF] a problem of disaster management systems is the lack of active decision making support needed for effective and efficient emergency responses.

Decision making under emergency situations requires special DSS to be prepared and account for often unforeseen, unique, complex, extreme, and evolving situations and issues that emerge during disasters [START_REF] Tufekci | An integrated emergency management decision support system for hurricane emergencies[END_REF][START_REF] Turoff | Dynamic emergency response management for large scale decision making in extreme events[END_REF]. Emergency responders require real-time data and learning/modelling tools to best cope with such situations based on related disaster scenarios. Such a decision support would for instance need to provide capabilities to allocate available and often scarce resources to improve the identification and management of assets during an emergency response [START_REF] Kondaveti | Decision support system for resource allocation in disaster management[END_REF]. These systems need to integrate multiple components, such as: geographic information systems (GIS), storm tracking tools, damage projection and flooding models, and models for evacuating an affected population [START_REF] Tufekci | An integrated emergency management decision support system for hurricane emergencies[END_REF]. Also, the decision makers need training in emergency management to be better prepared for an emergency situation. Hence, not only is support for decision making in a live situation needed, but also for training of emergency decision makers.

These challenges are addressed by the S-HELP (Securing Health Emergency Learning and Planning) project [START_REF] Planning | Securing Health Emergency Learning[END_REF]. With a Design Science Research [START_REF] Gregor | Building Theory in the Sciences of the Artificial[END_REF][START_REF] Gregor | The anatomy of a design theory[END_REF] approach the project researches and develops a comprehensive DSS for end-users to be better prepared, make better decisions, and perform better in emergency situations. The S-HELP DSS will provide support for rapid and effective decision-making for all stages of the emergency management lifecycle [START_REF] Alexander | Principles of emergency planning and management[END_REF] from mitigation and preparedness (pre-disaster) to response and recovery (post-disaster).

The challenges for the S-HELP project is to design a DSS that:

 Is flexible enough to integrate with existing legacy systems and tools.  Offer advanced capabilities and functionalities such as learning approaches based on taxonomies to increase semantic and organizational interoperability of cross-border multi-agency response.  Facilitate emergency responders to overcome operational inefficiencies and delays regarding coordination and communication to best handle time critical major disaster situations.

Based on this the research question of the paper is: How should a system that meet these challenges be designed? The purpose of the paper is to describe and discuss work in progress designing and building the system of artefacts that will provide a comprehensive support for emergency decision-makers and thus be the DSS that hitherto has been missing.

In section 2, the foundational emergency management taxonomies are discussed. Next, the S-HELP overarching system architecture and interoperability is presented in section 3, followed by a more detailed description of the major system components in section 4. How the system is tested is discussed in section 5. Finally, the conclusion in section 6 provides policy implications and further research.

Foundational Taxonomies for Emergency Management

In the S-HELP project, a DSS is developed for end-users to be better prepared, make better decisions, and perform better in emergency situations. For this reason, an SHELP strategic disaster management wiki to classify disasters (disaster risk, disaster types, extent of event, vulnerability) was created, to illustrate decision making, and to explain the emergency management (EM) environment, emergency management cycle, and the stakeholders involved [START_REF] Rauner | Decision Support for Strategic Disaster Management: First Release of a Wiki[END_REF][START_REF]Glossary of terms and definitions and common grounds and standards for interoperability[END_REF]. This content was expanded by emergency interventions/tasks and emergency resources (emergency responders/skills, equipment and materials, information and data) under consideration of the EU civil protection mechanism (including the EU Civil Protection Modules, [13]). Furthermore, key terms for the three S-HELP disaster scenarios (chemical spill, flooding, biological hazard) were included. The S-HELP strategic disaster management wiki was implemented using the wiki platform of the University of Vienna, Austria which can be accessed via https://wiki.univie.ac.at/display/SHELP/. To enhance semantic and organizational interoperability of end-users [START_REF] Vernadat | Enterprise modelling and integration[END_REF], the above content was incorporated in the S-HELP DSS as described in sections 3 and 4.

The strategic disaster management wiki contains main figures, describes terms, links to essential EM organizations, and refers to key literature [START_REF] Rauner | Decision Support for Strategic Disaster Management: First Release of a Wiki[END_REF][START_REF]Glossary of terms and definitions and common grounds and standards for interoperability[END_REF]. The second release of the wiki incorporates 951 glossary terms and 33 figures based on 183 references to the literature.

In Fig. 1 the strategic disaster management wiki (#1; [START_REF] Rauner | Decision Support for Strategic Disaster Management: First Release of a Wiki[END_REF][START_REF]Glossary of terms and definitions and common grounds and standards for interoperability[END_REF]) represents an essential foundation for the skills taxonomy (#2; [START_REF] Rauner | Improving Decision Making in European Disaster Management: A Skills Taxonomy of Main Emergency Responders Needed for Key Emergency Interventions[END_REF][START_REF]Austria: Draft Skills Taxonomy Template[END_REF]), resources taxonomy (#3; [START_REF]Draft Rescources Taxonomy Template[END_REF]), and skills/disaster taxonomy (#4; [START_REF]S-HELP Interoperability Standard[END_REF]). These three taxonomies were implemented into the S-HELP DSS as described in sections 3 and 4.

These components of the S-HELP DSS play a key role in training end-users regarding general strategic disaster management for more effective and efficient emergency management, communication, and operation.

The co-operation of different multi-disciplinary emergency responders in disaster management is highly complex in emergency preparedness, response, and recovery. Endusers want to know who of the emergency responders are needed for which emergency interventions/tasks by using what emergency equipment/material in order that emergency management can be better performed and interoperability is increased.

For the skills taxonomy (#2 of Fig. 1) main emergency interventions/tasks performed by emergency responders using emergency material/equipment and EU Civil Protection Modules were investigated. Based on this, a skills taxonomy was developed by interlinking emergency interventions/tasks and emergency responders/skills [START_REF] Rauner | Improving Decision Making in European Disaster Management: A Skills Taxonomy of Main Emergency Responders Needed for Key Emergency Interventions[END_REF][START_REF]Austria: Draft Skills Taxonomy Template[END_REF].

Eleven main interventions were considered including their related tasks: 1) general emergency management, 2) emergency communication, 3) forewarning, 4) evacuation management, 5) impact response, 6) search and rescue, 7) emergency transportation, 8) emergency engineering, 9) emergency shelter, 10) emergency food program, as well as 11) care of vulnerable and secure groups. Emergency responders were classified into: 1) core emergency responders (e.g., government, health care organizations, emergency services), non-core emergency responders (e.g., government, strategic health authori-ties, health care organizations, energy providers, food and beverage providers, information and communication services, transportation services, waste disposal services, water and sewerage undertakers), as well as co-operating bodies (military, communities, environmental agencies, media, voluntary sector). EU Civil Protection Modules contain human and material resources of one or more member states and are able to perform pre-defined tasks in the areas of response [START_REF]European Commission: Decision 2010/481/EU Annex II, Euraton[END_REF][START_REF]European Parliament and the Council: Decision No 1313/2013/EU[END_REF]: 1) advanced medical post, 2) advanced medical post with surgery, 3) aerial forest firefighting module using airplanes, 4) aerial forest firefighting module using helicopters, 5) chemical, biological, radiological, and nuclear detection and sampling, 6) emergency temporary shelter, 7) field hospital, 8) flood containment, 9) flood rescue using boats, 10) ground forest firefighting, 11) ground forest firefighting using vehicles, 12) heavy urban search and rescue, 13) high capacity pumping, 14) medical aerial evacuation of disaster victims, 15) medium urban search and rescue, 16) search and rescue in chemical, biological, radiological, and nuclear conditions, and 17) technical assistance and support team, as well as water purification).

In the resources taxonomy (#3 of Fig. 1 [START_REF]Draft Rescources Taxonomy Template[END_REF]) interlinked emergency interventions/tasks and emergency responder/skills (skills taxonomy) to emergency equipment/materials needed including information and data.

The advantage of the S-HELP DSS to handle three emergency scenarios (chemical spill, flooding, biological hazard) in several example countries (Austria, England, Ireland, Israel, and Northern Ireland) was investigated. It was found that the emergency responders, i.e., core and non-core emergency responders as well as co-operating bodies, responding to a disaster differ according to the underlying disaster type. These were categorized into: 1) natural disasters (biological, cosmological, geophysical, hydro-meteorological), 2) man-made disasters (socio-technical disasters, human conflicts, 3) hybrid disasters (both natural and man-made disasters), and 4) sub-sequent disasters [START_REF]Glossary of terms and definitions and common grounds and standards for interoperability[END_REF]. To enhance interoperability among end-users of different countries, a generic skills/disaster taxonomy which is applicable for any country was developed (#4 of Fig. 1; [START_REF]S-HELP Interoperability Standard[END_REF]). Such differences in emergency responders were illustrated for the three S-HELP scenarios (flooding -> natural disaster -> hydro-meteorological disaster -> hydrological disaster; chemical spill -> socio-technical disaster -> technological disaster; biological hazard -> natural disaster -> biological disaster -> epidemic) under consideration of the EU Civil Protection Modules. For the S-HELP flooding scenario, the primary and main core emergency responders are the emergency medical service, the fire brigade, and the police [START_REF]FLOODsite: Review Report of Operational Flood Management Methods and Models[END_REF]. Several EU Civil Protection Modules are suitable for a flooding which might be called via the Emergency Response Coordination Centre: 1) emergency temporary shelter, 2) flood containment, 3) flood rescue using boats, 4) high capacity pumping, 5) technical assistance and support team, and 6) water purification [START_REF]S-HELP Interoperability Standard[END_REF].

3

The S-HELP DSS Overarching Architecture

The S-HELP architecture employs a modular design (Fig. 2). This ensures that components in S-HELP are broadly self-contained units that provide tools and decision support functionality around a specific area of the emergency management problem domain. For example, the situation component provides a high level management of the emergency situations modelled within the system. The knowledge management component provides an interface and functionality relating to the large amounts of documentation and other knowledge assets that exists within the system. While each component on its own provides a level of functionality relating to its 'area of expertise', it is through the connection between components that the full power of the system may be realized.

Overview of the S-HELP System Components

As seen in the systems architecture model (Fig. 2) the comprehensive S-HELP DSS for emergency management and training comprises a collection of artefacts that together form an eco-system of vital components. Each component by itself is less important without the situational operability formed by interlinking the components into a whole system of systems. The overview below summarizes the components and their place and capability in the eco-system. Logging Component. Provides information managers with a system log of all content generated by S-HELP and external component and traditional data sources (e.g. telephone calls, weather alerts, media reports and e-mails). The information manager can choose data from the logging component and send directly to the CRS component as appropriate.

Learning Management

Geographical Information System (GIS)

Component. An INSPIRE compliant spatial database management system and front-end incorporating ArcGIS. Provides users with capabilities to visualize critical infrastructure and also assess hazard impact using rich datasets, modelling and spatial analysis tools. The GIS tool can also be used for training, exercises and response. The tool provides real-time visualization of hazards and incident response. The interactive features allow for end users to engage with the data for decision making and coordination purposes. The ability to import and export external models and shapes enhances multiagency coordination through the sharing of incident-specific critical information and data. Likewise, previous incidents and models can be geocoded such that relevant models are surfaced to the user based on the incident type and incident locale.

Twitter Component. The twitter component gathers information from the social media service Twitter. S-HELP users can search for tweets statically using location data (input manually or derived from location of current situation). Relevant tweets are displayed on a map and clustered accordingly. Relevant user information and tweet content will be displayed. Additionally, trending topics can be requested for given locations. A streaming service that reports and displays new tweets that relate to topics of given S-HELP users' preferences is also available. Using topic filters, the twitter module will display new tweets that meet the S-HELP users' filter queries, and it will do so in real time.

Major Backbone System Components

Essential for emergency decision making and training using the S-HELP DSS is the provision of generic and situational data consistent with the taxonomies (cf. section 2), interlinked emergency management documents and Standard Operating Procedures (SOP) documents, and geographic emergency data. Four major components of the S-HELP DSS form a back-bone infrastructure: the Knowledge Management System (KMS) component, the Repository for Data Sets component, the Document Management System (DMS) component, and the Current Recognized Situation (CRS) component.

Knowledge Management System (KMS)

A key enabler of the S-HELP DSS approach is the creation of a Knowledge Management System to create, store and transfer the knowledge assets that comprise the experiential knowledge of emergency management practitioners. This will facilitate individual and inter-and intra-group learning in crisis management decision-making. The creation of a Learning and Knowledge Management Systems (LKMS) necessitates the integration of a Learning Tool-set and Knowledge Management System. The LKMS comprises a repository for data sets realized as a relational database that stores emergency and disaster typology data consistent with the Emergency Management Taxonomies (cf. section 2). Furthermore, it is integrated with a knowledge repository (Open KM) that supports the storage and transfer of knowledge assets in the form of standard operating procedures, emergency plans, business process models, expert yellow pages and other relevant documents. This powerful knowledge repository has been integrated with a learning platform (Moodle), and learning tools, that facilitate the training of key emergency management personnel.

Repository for Data Sets Component

Viewed from an enterprise architecture perspective [START_REF] Finkelstein | Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies[END_REF][START_REF] Zachman International® | [END_REF] the taxonomies discussed in section 2 identify the inventory (row 1, column 1 in the Zachman Framework for EA v. 3.0) for the S-HELP LKMS, answering to the requirements set by the intentions (row 1, column 6 in the Zachman Framework for EA v. 3.0). Thus, the taxonomies specify the business concepts about which data needs to be managed in order for the S-HELP system to be able to fulfill the goals and intentions set by the planners of the system. Based on the inventory identification the inventory specification (row 2, column 1 in the Zachman Framework for EA v. 3.0) was digitally transformed [START_REF] Majchrzak | Designing for Digital Transformation: Lessons for Information Systems Research from the Study of ICT and Societal Challenges[END_REF] into a Unified Modeling Language (UML) conceptual model (see Fig. 3).

The conceptual model was transformed into a relational logical model (see Fig. 4) for the data set repository, and then further to a physical data model implemented in MySql Server 5.6.

Through this digital transformation, the data repository partly automates and digitalizes the foundational emergency management taxonomies.

The data set repository makes it possible to store and retrieve information about e.g. what kind of resources a generic emergency responder uses for one or more emergency tasks in responding to a specific type of emergency (e.g. a flood), as discussed in section 2 (see Fig. 5 and Fig. 6).

When the data set repository is populated with generic and specific, real incident data it will be a knowledge base of both general and situated emergency information that could be queried by emergency decision makers during a live incident or fed as data into emergency responder training scenarios used for the Learning and Knowledge Management System (LKMS). The output in Fig. 6 shows that in the 'London' region of the country 'UK' the 'County Police' acts as the generic key emergency responder (KER) 'Police', using e.g. the generic resource type 'Checklists/Plans' while performing the 'Evacuating' Intervention Task of the 'Evacuation Management' Emergency Intervention type in the 'Response' Intervention Phase to manage an emergency incident. As each country have built up their own and nationally tailored organization and structure of emergency management, it is important that total flexibility is guaranteed in associating a national responder body to a generic responder in the taxonomy.

The Party Pattern [START_REF] Fowler | Analysis patterns: reusable object models[END_REF] made it possible to record that a responder party (individual, organisation, or both) assumes the role of a national responder for a certain unique disaster event. The responder party type also assumes the responsibilities of a generic key emergency responder for a determined period. Modelling principles from [START_REF] Finkelstein | Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies[END_REF] made it possible to manage relations between super and sub entities through type entities, as well as maintaining dynamic hierarchical structures between data elements reflecting the taxonomies.

Combining all these connections gives the possibility to record what person and/or organization that acts as a national responder for a certain disaster event and also what person and/or organization that acts as a key emergency responder for the same disaster event (cf. Fig. 4). Document Management System (DMS) Component. Open KM (OKM) was configured to fulfill the document management functionality of the LKMS. OKM provides managerial capabilities such as tagging, reading, writing, and storing useful emergency intervention documentation. Hence, OKM can facilitate individual and group learning, and the management (sharing/transfer/creation/use and control) of end user knowledge as part of the LKMS.

The document structure implemented in OKM (see Fig. 7) is in accordance with the taxonomies discussed in section 2. Thus the structure of the data repository and the document management system are synchronized to accommodate easy integration of data sources in the LKMS.

The KM is incorporated into the S-HELP KMS component using REST (REpresentational State Transfer) services and also provides facilities to build work flows in the jBPM Business Process Management suite. Based on the taxonomy in project deliverable D2.4 [START_REF]Austria: Draft Skills Taxonomy Template[END_REF] a number of Business Process Model and Notation (BPMN: [START_REF]Object Management Group: Business Process Model and Notation[END_REF]) 2.0 models were developed in the project [START_REF]Sweden: Learning and Knowledge Management System (LKMS)[END_REF].

Current Recognized Situation Component

One important information management capability of the S-HELP system is the Current Recognized Situation (CRS) component. It was designed based on a work-flow identified by the S-HELP end-user group and incorporates lessons learned from Irish Framework for Emergency Management [START_REF]Principal Response Agencies, MEM: Framework for Major Emergency Management[END_REF]. The CRS module provides an electronic implementation of current manual information management systems which often incorporate the use of whiteboards. However, the system goes beyond merely providing a digital implementation of manual information management techniques. Current manual EM information management systems are highly dependent on hand written input of information by qualified "Information Managers" on a single set of on-site whiteboards and markers. When the whiteboards run out of space for new entries, a picture is taken and the content is erased. If there are multiple incidents associated with a single emergency situation, then boxes are informally drawn onto the corners of relevant whiteboards.

Integration with Taxonomy

Beyond merely providing a means of facilitating manual data entry the development team has also been working on automatically generating content for the CRS panels based on the taxonomy and data modelling efforts. Unique Java classes have been created based on the collective output of the University of Vienna's Emergency Management Taxonomy and Lund University's Object Model representation. Resource entries can be automatically generated based on queries executed on different disaster types upon instantiation. For example, when an incident is created with a specific disaster type (e.g. flood), queries can be executed to derive a list of possible intervention tasks associated with the disaster type (e.g. evacuating) and consequent responder and resources required to fulfil the interventions (e.g. police and evacuation vehicles) will be identified. Once identified, new CRS entities will be created and added to the Resources panel automatically. Moreover, the taxonomy can be used to generate sample response structures and populate generic action lists based on best practices, thus providing an important decision support and training function. Furthermore, past responses, gleaned from the KMS, can be displayed to leverage the experiential knowledge of historical incidents.

Testing of the S-HELP DSS

The S-HELP system adheres to the S-HELP Quality Manual which specifies a valid test suite for any software artefact. For the S-HELP project, the test suite must cover all documented requirements of all types, it must fit into the accepted types of software tests (e.g., unit, integration, system), it must be reviewed and all specified tests must be executed, passed and reviewed. In practice, three different test types have been executed.

Unit Tests target a specific class. Objects are mocked and injected as necessary to test that class in isolation from other classes. The Maven build and dependency manager is used to drive test suites; such testing is tightly integrated with the build process. This is expected in an agile test environment. Unit Testing is fully automated.

Integration Tests are designed to test the interaction of a specific class with other classes or with a remote service or database. In all other respects Integration Tests are similar to Unit Tests. Like Unit Tests they can be run automatically as part of the Maven build process. Similarly test results are reported automatically.

User interaction and System Tests are manual in nature. User Interaction tests follow the use cases laid out for the S-HELP system and are documented in Excel spreadsheets. Failing tests are logged as bugs in the JIRA Software reporting system (https://www.atlassian.com/software/jira). The focus of these tests is to ensure that the User Interface behaves as designed and is productively useful to an emergency command center operator.

System tests to date have been limited in scope. So far the S-HELP build/deployment process has been tested on multiple operating systems on Irish sites and also in a site in Austria. The test results demonstrate the deployability of S-HELP. Furthermore, the target platforms are diverse in terms of architecture and processing power (OS X and Ubuntu on Intel, Debian on ARM). These tests have demonstrated consistency of system operation and user experience across diverse platforms.

Conclusion

The S-HELP DSS will facilitate a better coordination and communication of multiagencies' emergency responders during major disasters to overcome operational inefficiencies and delays. This is especially essential and even crucial in times of increased susceptibility of our society to hazards and other threats caused by climate change, demographical change, political and economic instability, urbanization, migration, and flow of refugees (cf., e.g., [START_REF] Coppola | Introduction to international disaster management[END_REF][START_REF] Neville | Supporting Cross Border Emergency Management Decision-Making[END_REF]). The work on designing and building the S-HELP DSS is ongoing and tests carried out so far are promising. Work to be done is to test and demonstrate that the S-HELP DSS system of systems will provide the necessary emergency decision and training support for emergency decision makers. A series of three scenarios will be used to test this. These scenarios are being prepared to test incident intelligence, multi-agency response, what-if modelling, GIS capabilities, learning tool sets and post action evaluation. The scenarios will be used to test the system in a realistic operating environment across different disaster types. The scenarios comprise cross-border chemical explosion, biological hazard and widespread flood events. Future papers and articles will report on the outcome of these tests.

Fig. 1 .

 1 Fig. 1. Foundational emergency taxonomies for the S-HELP DSS

Fig. 2 .

 2 Fig. 2. S-HELP DSS Architecture[START_REF] Neville | Towards the development of a decision support system for multi-agency decision-making during cross-border emergencies[END_REF]

Fig. 3 .

 3 Fig. 3. S-HELP data repository conceptual model[START_REF]Sweden: Learning and Knowledge Management System (LKMS)[END_REF][START_REF]Repository for Data Sets[END_REF]

Fig. 4 .Fig. 5 .

 45 Fig. 4. S-HELP data repository logical model[START_REF]Sweden: Learning and Knowledge Management System (LKMS)[END_REF][START_REF]Repository for Data Sets[END_REF]

Fig. 6 .

 6 Fig. 6. Output from the query in Fig. 5 (only a few lines showing)

Fig. 7 .

 7 Fig. 7. Document structure in OKM

  System (LMS) Component. The S-HELP LMS platform provides admin tools, content authoring tools, communication tools, skills and performance management tools, and content management tools. The LMS platform facilitates the "End User Training Programme Concept" incorporating emergency management decision making and additional training content. Moreover, the LMS toolset integrates with the S-HELP modular architecture such that training and learning material can be surfaced and shared with other S-HELP components as appropriate. SOPs), existing plans and past response structures, and GIS models. Content can be tagged using the S-HELP taxonomy and location information. As such, relevant content is surfaced automatically based on incident type and location. Surfacing relevant plans, case studies, models, and past incident responses plays a vital role in ensuring that trainees can acquire the experiential knowledge gleaned from past incidents. Moreover, an expert's database will ensure that users can identify, locate and contact those with expertise relevant to the current incident or training scenario

	Knowledge Management System (KMS) Component. A repository of organizational
	best practices incorporating standard operating procedures (

Acknowledgments

This project is funded by the European Union's Seventh Framework Programme for research, technological development and demonstration under grant agreement N° 607865.


Nina Dobrinkova

Antonis Kostaridis
email: a.kostaridis@satways.net

Andrej Olunczek

Marcel Heckel

Danae Vergeti

Sofia Tsekeridou

Geert Seynaeve
email: geert.seynaeve@attentia.be

Andrea De Gaetano
email: andrea.degaetano@biomatematica.it

Thomas Finnie
email: thomas.finnie@phe.gov.uk

Efstathiou Nectarios

Chrysostomos Psaroudakis
email: nectarios&cpsaroudakis@aditess.com

Disaster Reduction Potential of IMPRESS Platform Tools

Keywords: IMPRESS Project, INCIMAG, INCIMOB, WARSYS, Medical Resources, Reaction in Mass Emergency

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In our paper we will describe a system which final test phase is still in process. However it has been partially tested on a big scale exercise in Palermo, Italy on 7th June 2016, but further final tests will be completed in February 2017in Sofia, Bulgaria. We will now focus on description and the system capabilities and designed functionalities which give opportunities to the emergency medical teams on the field and in the operational rooms in cases of mass emergencies. Some of the achieved results in the first tests will be also described. IMPRESS platform communication tool can be used for faster decision support and many saved lives in cases of mass emergencies. The IMPRESS project platform as designed can be used in assistance to support emergency medical teams on the field, that require involvement of diverse actors and deployment of various ICT systems to achieve the ultimate goal of efficient decision making and provision of a consolidated operational environment. This need comes to support various public safety agencies who are involved in a mass emergency response in their respective knowledge domains. To support these agencies a comprehensive ICT system with specific editions has been designed in the framework of FP7 call for Security with project acronym IMPRESS. The different systems or editions identified are targeting the needs of Emergency Medical Services (EMS), Law Enforcement, Fire Brigade, Coast Guard, Crisis/Civil Protection and Hospitals. Each edition is based on a core software platform whose purpose is to provide the standard command and control functions, the management of the required business processes, role based communications based on the organization's incident command structure, while at the same time being interoperable in a loosely coupled manner by exchanging open standard messages (e.g. alerts, resource requests, availability requests) in an intelligent way. These public safety agencies or organizations might have existing legacy systems with which interfacing occurs via another IMPRESS component, the core database responsible for all incoming data from different sources called -WARSYS.

The system operates in two directions on the field with mobile application called INCIMOB and on the dispatch center with desktop application called INCIMAG. Since the most significant operations take place on the field, first responders are equipped with a fully functional mobile data terminal which provides the chain of command with common situational awareness and the current reality on the field and act as their gateway to decision support tools. Patient tracking, situational reporting, resource messaging and geographical mapping are the primary functions of the first responder's mobile application. The structure of the system gives ability to the field teams and the teams in the hospitals or dispatch centers to communicate between each other through mobile devices bi-directionally. Field responders could have the capability to communicate via voice to the command center notifying them in real-time as to their status using their traditional telecommunication radios.

Decision Support Tools accessed by the Control Center application (INCIMAG) provide forecasting and recommendations to the incident commander and Emergency Operational Center (EOC) operators/logistic officers on what are the best course of action during an incident.

Drawing upon and combining all these layers of information, a Common Situational Picture and Situational Awareness well connected can provide regional, public health or ministerial authorities with what is occurring (severity, location, progress) and resource utilization. This provides a Common Situational Awareness (CSA) between the various public safety agencies (across command structures) and deep understanding and realization what can help in the detection of resource depletion depending on the mass emergency. The incident management tools are combined under the name INCIMAG and the incident management tool for the field operator is named INCIMOB.

The design of the system follows the IEEE1016 [START_REF]IEEE 1016-2009 Standard for Information Technology -Systems Design -Software Design Descriptions[END_REF] standard of decomposition, dependency, interface and detail description of the components that constitute each subsystem as well as their interconnection with other IMPRESS modules and devices. The system is partitioned into various subsystems and components that match up with the user requirements in order the appropriate tools to be available for the end-users in a health emergency situation. The components address the user-requirements directly but also provide ancillary tools that are required behind the scenes to make these user-requirements viable.

System Overview

The system designed under the project contains the following components:

 Reference Semantic Model, which defines an ontology related to the health emergency management in mass emergency  Data Harmonization Component (DHC), which makes the harmonization between the WARSYS (data base) component and the Reference Semantic Model  WARSYS is the data base, which extract data from various sources and homogenize it for the use of the different components  LOGEVO provides the logistics of health care resources, in hospital surge, when it comes to available medical care during events that exceed the limits of the normal hospital infrastructure  SORLOC is a SOuRce LOCalization module which can support decision making in cases of biological released desease giving information of the resulting disease outbreak  PATEVO component allows the simulation and prediction of the physiological/health state of casualties, including the effects of medical treatments  INCIMAG component includes the tools and environment to manage emergency incidents (it is a desktop solution)  INCIMOB part of the platform and refers to the mobile extension of the INCIMAG system, for on-field operations, patient tracking, receiving notifications, etc. INCIMOB has also INCICROWD option for regular people inputs  The training Component is an online training platform based on Moodle architecture providing to the users and operators useful information what tools and components can be found under the IMPRESS system platform.

WARSYS Component

WARSYS data base is the core of the IMPRESS system responsible for importing and storing structured data in the rest of the modules. It provides data importing capability from medical and logistics repositories (such as hospital information systems), while it has also the ability to store data by listening to the IMPRESS Messaging Bus (Ac-tiveMQ) module. WARSYS then provides the homogenized data stored, to the data harmonization component (DHC) module.

WARSYS incorporates technologies and knowledge extracted by various national Database projects in the past, but it's a totally new component designed and implemented for the IMPRESS Platform.

The innovation in WARSYS lies in the cooperation of various licensed and open source products integrated to a database system that support many different kind of data sources. In addition, this capability of WARSYS gives the opportunity to handle many different types of resources and data in the future.

The EDXL files family manipulation and importing is another innovation of IMPRESS and WARSYS as its subcomponent.

WARSYS architecture is represented in Figure 1. WARSYS architecture main component is the WARSYS Database where storage utilities are provided that make stored data available to the rest of WARSYS subcomponents as well as to other IMPRESS components. To support the operation of WARSYS Database the WARSYS DB Tools component is used. This component provides several administration tools and are used by authorised database administrative personnel (DBA) in order to manage import and export processes, provide maintenance, check WARSYS system health and connections to other IMPRESS components.

The rest of WARSYS architecture components are used to import (manually or automatically) and store data from different sources, as well as communicate with the other IMPRESS components through the message bus interface.

The Structured Data Import Component (SDIC) component is a set of visualised import stored procedures, called on demand by a user who has the relevant access privileges, in order to insert Hospital data into to the WARSYS Database. The SDIC component can be automatically called when data on the messaging bus become available.

The data import process is mainly handled by (SQL Server Integration Services) SSIS packages procedures. The first step is to validate the integrity of the files to be imported and append timestamp information, for security, validation and tracking purposes. Then the system identifies what this file is about and triggers the relevant import stored procedure. The stored procedure calls, the WARSYS SSIS mechanism and the file content is imported to the database on tables specified in the stored procedure. Apart from structured data, WARSYS can import data from other sources without using SSIS packages. This capability is mainly supported by python scripts. These scripts accept an XML as input, use the XSD schema file and insert data in MySQL tables. Using MSSM for MySQL, or other python scripts data from the MySQL databases are inserted to the MS SQL database.

Beyond the data import of EDXL files and other sources, WARSYS provides two more interfaces: one of the communication with the end user through the WARSYS Secure Web Interface and one for the interconnection with other IMPRESS components through the WARSYS IMPRESS Messaging Bus Interface.

Through the WARSYS Secure Web Interface component, and upon successful authentication, hospital personnel are able to connect to WARSYS and upload files or provide data manually regarding Hospital Availability, through web forms.

LOVEGO Component

The LOGEVO component main goal is to forecasts the evolution of the provision of resources to the hospital and to the field (Hospital Surge and similar) determining the time-curve of the amount of resources that can be provided to the system by exploiting the incremental capacity of the health structures involved in the crisis. In a Mass Casualty Incident (MCI) [START_REF]Committee on Guidance for Establishing Crisis Standards of Care for Use in Disaster Situations[END_REF] the health care resources which are necessary to treat the large number of patients exceed the resources available. The system's resources deployed in the field in normal situations are insufficient and are often quickly depleted. The management of an Emergency situation requires therefore putting into action plans capable to quickly and efficiently enhance the health care response. The ability of the health services to scale up their resource provision becomes a key point for decision support.

The LOGEVO component is one of the Decision Support System (DSS) elements in the IMPRESS system, set up to provide logistic support to the decision makers. The logic of LOGEVO was designed and samples were prototyped in Matlab [START_REF]MATLAB and Statistics Toolbox Release 2009b[END_REF] and the consensuses of medical doctors on the preliminary test results were obtained. LOGEVO component concerns hospital capacity, the hospital surge [4] capability and timing as well as the capacity and capability of the health service in general involved in a crisis event. By using this component, the imbalance between care needs, resources availability and the on-going modifications in the levels of both can become more optimized. The overall description of LOGEVO is depicted in Figure 2.

SORLOC Component

The rapid determination of a source of biological contamination in time and space is essential for a coordinated response to "Extra-Ordinary Public Health Challenge" (EOPHC). Determination of the source of contamination is harder for biological threats compared with incidents typified by physical trauma as they are expected to come to official attention several days after exposure and infection. SORLOC is responsible for determining the likely exposure source in time and space or simply time given field observations of a covert release of a biological contaminant. SORLOC component functionalities can provide observations that as a result return a probabilistic inference of the location of a release of a pathological biological agent. SORLOC is not an epidemiological surveillance system. A fundamental assumption of the models used is that the cases arise from a single confirmed outbreak of a known pathogen. SORLOC has been created to assist the decision makers in choosing where to focus resources (manpower and remediation measures) in the event of such an incident and arises from foreground work within Public Health England (PHE) on 'back-calculation' of epidemics or 'reverse epidemiology'. In keeping with the one-task one-component philosophy it was decided to split SORLOC into a set of discrete sub-components each of which would provide a single function to the greater SORLOC component. The natural subdivision was that of models and interface. This is because the models are (relatively) short running; very computational resource intensive processes while the interface is a long-running process that requires very few computational resources. Dividing the models into temporal and spatio-temporal comes from a similar decision based on the fact that these models are likely to be grounded in different mathematical frameworks.

Treating the models as separate sub-components allows us to develop the interfacing technology with a known model before we investigate novel techniques for the spatial analysis. Part of the challenge in construction of the interfacing comes from ensuring a consistent run-time environment and placing and retrieving data from a shared high performance computing cluster in an automated way. The other part of the challenge is the specification of the data for input and output as before this project no standard for the transmission of epidemiological data. However the work on SORLOC component is still ongoing and the listed challenges can be met within the whole architecture of IMPRESS system.

PATEVO Component

PATEVO is a DSS component in the IMPRESS system which predicts the patient's physiological status evolution over time, predicting therefore the scenario evolution in terms of victim physiological status. PATEVO has complementary functions, which support the functionality of the component and those functions are: SCENGEN, SYMPTSCORING, STATSCORING, GAUGER, DAMAGER, SYMPTER, RESESTER, aiming to implement logically distinct tasks necessary to complete the architectural design for the description of Scenario evolution in cases of emergencies. PATEVO is one of the DSS components designed to assess the evolution of patient health status with respect to evolving time, modelling both the effect of injuries and the effect of delivered treatments. To complete the picture of the Scenario evolution, a series of other functions are designed and implemented in order to test the functionality of the component in a real or simulated environment. The simulation environment will be also able to reproduce the two test-scenarios (the Palermo Scenario and the crossborder Scenario) against which the IMPRESS solution will be measured, as well as other different crisis scenarios. Each real or simulated crisis scenario produces a certain number of "affected" individuals (patients) among the existing "bystanders" (people exposed to risk), producing for each individual a set of anatomical lesions (with different levels of seriousness). Patients have to be triaged and appropriate care has to be delivered in the field, as first aid, or in definitive care structures, in order to restore their vital physiological conditions in an efficient way.

Each simulation instance starts with the generation of a CRISIS EVENT. The DSS PATEVO component predicts the evolution over time with physiological dimensions, which are called the Physiological State Variables (PSVs). The evolution is determined by the initial variable status (the initial defect), the initial rate of worsening and by the therapeutic maneuvers (if any) delivered. In the present formulation, medical care (treatments) is delivered by structures, which are called medical Assets: while an isolated surgeon, however good, will not be able to deliver effective care without instruments, drugs and assistance, an Operating Room (OR), endowed with all necessary human and instrumental accoutrements (surgeons, anesthesiologists, nurses, defibrillators, blood, IV sets etc.), is actually able to deliver a given standard of care. So is, for instance, an Ambulance. In the current terminology, therefore, isolated medical personnel are not considered, while OR's and Ambulances are health assets which can be employed and can be subject to competitive allocation (to some victim or to some other victim), to gradual increase via Hospital Surge mechanisms, etc. Clearly, not all Assets deliver the same Treatments: while an OR can administer oxygen, fluids, blood and vascular repair, an Ambulance can only administer oxygen and fluids. Each Asset is therefore characterized by the set of Treatments it can deliver. The row connecting the PSVs to the Score codes box (STATSCORING function) allows the system to have, in the simulation phase, a global vision, the "true" one, of the affected victim's status, determining the "true" scoring from the "Expected Time of Death", which represents the time at which one of the PSVs reaches a value indicating death. Moreover, from the Symptoms (observed in the field), medical personnel or volunteers make their own triage and are able to then test their performance in the triage procedure by comparing their scores with that automatically performed by the system (implementing appropriate scoring algorithms) from the detected symptoms (the SYMPSCORING function). The Reference Semantic Model is an ontology defined as the IMPRESS Ontology, whose objectives are interoperability, data harmonization and linked data provision. The IMPRESS Ontology design and implementation process follows the METHONTOLOGY [START_REF] Methontology ; Gomez-Perez | From Ontological Art Towards Ontological Engineering[END_REF] steps and is implemented in OWL. The IMPRESS Ontology upper layer contains the following four main concepts:

 EOPHC (ExtraOrdinary Public Health Challenge): The concept refers to the emergency events and incidents that take place and require response.  Person: The concept refers to the human individual.  Resource: The concept refers to anything that is used to support or help in the response during a health emergency.  Activity: The concept refers to any activity that takes place in order to reduce the impact of an emergency event.

The temporal aspects of the ontology have also been taken under consideration describing the evolution of the data through time. The data fact includes various sets of code lists described in SKOS as well as properties that are associated with user roles and geospatial data. The IMPRESS Ontology is further aligned with the TSO standard.

Data Harmonization Component

The Data Harmonization Component implements the data harmonization procedure that is required in order to harmonize the multidisciplinary and heterogeneous datasets of the IMPRESS Platform and provide a semantically homogenized view of the data. Also, these data are provided as linked data to the rest of the IMPRESS Components. Thus, Data Harmonization is also responsible for the linking of the RDF data [START_REF]Resource Description Framework (RDF[END_REF] with other third party linked data resources.

The Data Harmonization Component implements data harmonization using the IMPRESS Reference Semantic Model which covers the respective domains of knowledge of the domain of health emergency management.

The main tasks that are realized by the Data Harmonization Component are the following:

1. Provide a real-time RDF view of the IMPRESS data stored in the WARSYS database, based on a specific mapping file 2. Provide access to RDF data views via a SPARQL endpoint 3. Execute SPARQL queries to RDF data and process the results, if necessary 4. Links the IMPRESS RDF data with specific linked data resources using a specific mapping file 5. Handle and serve the requests for data from the Message Bus Based on the above, Data Harmonization Component includes four main subcomponents: the Mapping Generator which is responsible to generate the mappings between the database data and the RDF view, the RDF Viewer which provides access and exposes the RDF views, the Query Handler subcomponent which handles the requests for data and the Data Linker. As shown in figure 4, the DHC Manager receives requests for data from the Message Bus and based on the type of request calls the DHC RDF Handler which is responsible of querying the Mapping Generator for native RDF data or the RDF repository for linked data, through a SPARQL [START_REF]SPARQL Query Language for RDF[END_REF] endpoint. The Mapping Generator produces the dynamic harmonized view of the data that exist into the WARSYS database, while the DHC Data Linker generates RDF data linked with other Linked Data provided online. The results of the linking process are stored into an RDF repository in order to resolve issues of resources unavailability or low performance due to network latency issues.

The Data Harmonization Component uses the D2RQ server [START_REF]Accessing Relational Databases as Virtual RDF Graphs[END_REF], an RDB2RDF technology, as well as, the SILK framework [START_REF] Volz | Silk-A Link Discovery Framework for the Web of Data[END_REF].

Recommendation Component

The Recommendation Component produces recommendations/suggestions on how to distribute the patients over hospitals. The component, based on the patient status (and status forecast, using the PATEVO component) and on available resources (ambulance vehicles and hospitals bed availabilities in different categories; also forecast of availabilities using the LOGEVO component), gives a recommendation about the order of patients, the destination hospitals, and optimal routes to the hospitals. This component can be used in every day incident patients dispatching and case of mass casualty incidents (MCI).

The Recommendation Component consists of the Distribution Service and the Optimisation Services: The distribution computation is based on routing on a street network that will be loaded from a database (the street network parameters used for the routing can be adjusted manually, to reflect traffic information like max speed or road closures). Each patient has a transportation priority that determines the order of transport. In addition, patients have a set of needed Assest that determine the hospitals that come into consideration. The amount of available Assest of a hospital may increase over time, so additional patients can be brought to it subsequently.

The optimisation computation tries to find an optimal order for the patient transport. For this, it uses LOGEVO to determine the increasing Asset availabilities of the given hospitals. In addition, PATEVO/STATSCORING is used to get the health status of the patient, how its health status will evolve over time and how the treatment (Asserts) will influence the health status. Based on this an initial priority and needed Assets for each patient is determined which is used to compute the prehospital time of each patient via the distribution computation explained before. Based on the resulting prehospital time PATEVO is used to check the health status at arrival time. If a patient would be dead or if other constraints are not met, adjustments on the patient priorities are done and the computations are repeated.

INCIMAG Component

During mass casualty incidents and disaster, Public Safety Agencies rely primarily on voice over radio communication along with pen and paper notes for situational awareness. The Integrated Incident Management System called INCIMAG that functionalities are to interconnect stakeholders, decision makers, operators, first responders through standardized data interoperability for incident coordination and shared situational awareness. Although the system capabilities are to support different Public Safety Agencies our primary focus is for Emergency Medical Services by implementing payloads that include data specific to Emergency Medical Services such as incident representation, unit tasking, triage, treatment and transport tracking of emergency patients. The core existing geospatial platform (CEF -Chameleon Enterprise Foundation) of Satways Ltd. provided the Enterprise Application Open Service Gateway Initiative (OSGi) framework on top of which additional modules in the form of OSGi bundles were developed. With the final goal of a Multi-Agency system for emergency call taking, incident and resource management and coordination, this initial round of implementation includes various client side plugins as well as server side components and services for call taking, address geocoding, resource management, and communication with field resources, hospital availability and patient tracking. An application server, database, back-end services and messaging middleware provide the necessary multitier infrastructure for the rich client application to visualize and manipulate data according to the various standard flows for incident and resource management determined by a Public Safety Standard Operating Procedures (SOPs). The interaction between agencies during normal operations and in mass casualty incidents takes place through an intelligent message router, designed and implemented for this purpose. Its aim is to route messages to the proper recipients who have declared their interest in particular messages, roles, or geographic areas. A subset of the Emergency Management Exchange Language (EDXL) family has been implemented: the Common Alerting Protocol (EDXL-CAP), the Hospital Availability Exchange (EDXL-Have), the Situational Reports (EDXL-SitRep) and the Tracking of Emergency Patients (EDXL-TEP) which can all be wrapped in the Distribution Element EDXL-DE) planned for the final phase of of development of the system. This subset provides the interconnection of agencies which is very important in cases of emergencies. Finally a Mobile Application Programming Interface has been developed that will facilitate the interaction between INCIMAG instances and the related INCIMOB mobile application.

INCIMOB Component

The Both applications have a general common architecture, depicted in Figure 6. Each application contains of a set of modules. Furthermore, each module provides a set of features and uses a set of interfaces to communicate with the IMPRESS system.

Each application can provide a set of features: some are similar in both apps, while others are unique for the specific app. Multiple related features can be bundled in one module. To switch between the modules, the applications use a design pattern that is called 'navigation drawer'. This pattern is used in a wide range of mobile applications and is intuitive for persons that are using smartphones in their everyday life.

The modules, and with that the applications, use a set of communication channels to communicate with the rest of the world, in this case with the IMPRESS systems. To get data from the application to a server, a RESTful-or SOAP-Service is used to transfer data messages serialised in JSON or XML format. To get data from the server to the application without the need for the application to permanently asking for new data, another communication channel is necessary. This channel has to provide the possibility of pushing messages to the application. A message bus is used as solution for sending messages to the mobile application devices (smartphones). Furthermore, the application needs access to a map tile server, to display features on a map. All these communication channels need an internet connection. Therefore, access to WLAN/Wi-Fi or 3G/4G mobile networks is mandatory.

Palermo test case and achieved results

The IMPRESS system tests started in the beginning of the project's third year and on 7th June 2016 in Palermo, Italy the first tests of the described components were done. The use scenario take place in Plarmo, a city with 700,000 inhabitants located in the Mediterranean Area of Southern Italy, and simulates the sudden liberation of high concentrations of toxic compounds from a fire developing on-board of a ship moored in the Palermo harbor. The concept of the tested scenario moves from the availability of actual data from a historical fire, which developed in the Palermo waste dump of Bellolampo (Figure 7) between July 29 and August 17, 2012. The ship has mainly a cargo of plastic materials that, during the combustion, releases different toxic substances such as dioxins, hydrogen cyanide, hydrogen chloride, and phosgene. Dioxins are unintentionally, but unavoidably produced during the manufacture of materials containing chlorine, including PVC and other chlorinated plastic feedstocks. Dioxin is a known human carcinogen and the most potent synthetic carcinogen ever tested in laboratory animals. A characterization by the National Institute of Standards and Technology of cancer causing potential evaluated dioxin as over 10,000 times more potent than the next highest chemical (diethanol amine), half a million times more than arsenic and a million or more times greater than all others. World Health Organization state that "Once dioxins have entered the environment or body, they are there to stay due to their uncanny ability to dissolve in fats and to their rock-solid chemical stability".

The presence of a wind from North East carries the toxic cloud in the direction of the urban area. This produces sudden release of toxicants in a place close to a very populated city area. The scenario involves the District "Kalsa" of about 0.8 km2, indicated by the shaded area in Figure 8.

The systems tested during the Palermo demo were oriented towards deployment of INCIMAG suit and INCIMOB mobile version for immediate triage on the field with injured people. The desktop application of INCIMAG was installed in all involved authorities and hospitals in order to have cluster of involved actors. The INCIMOB operators were thought how to operate on the field with the mobile application. The simulation final results were quite optimistic, so on the second stage in Sofia, second half of February 2017 the full capacity of the system with recommendation engine will be included and the Decision support part of the system will be fully tested.

Conclusions

In this article we have described how the IMPRESS Incident Management Tools can work fully together to enhance and support the functions of the agencies involved in an everyday emergency situation, mass emergency incident and crisis situations. Each actor in such a situation requires technological support. If this on field support is timely provided and the basic activities are fulfilled the injured people and saved lives can increase its percentage. The Incident Management tools designed target the Emergency Medical Services, Law Enforcement, Fire Brigade, Coast Guard, Crisis/Civil Protection as well as Hospitals by empowering them with an information system (field and command center) which will provide a Common Situational Awareness and deep understanding and realization of the severity in the mass emergency. With IMPRESS ICT tool which can help in the detection of resource depletion or depending on the emergency situation evacuation or escalation of efforts on the field can deal better with Extra Ordinary Public Health Challenges.

Fig. 1 .

 1 Fig. 1. WARSYS Architecture

Fig. 2 .

 2 Fig. 2. General architecture of the LOgEVO component

Fig. 3 .

 3 Fig. 3. General architecture of the PATEVO component and its collaborative functions

Fig. 4 .

 4 Fig. 4. Architecture of the DHC component

Fig. 5 .

 5 Fig. 5. General architecture of the Recommendation Component and relation to other components.

  IMPRESS system comprises the mobile application INCIMOB that is connected to an INCIMAG desktop solution. INCIMAG is a full-featured command & control system to be deployed in command posts or emergency centres. INCIMOB is defined as mobile interface for INCIMAG and is therefore only connected to this system. INCIMAG provides an SDK-API to INCIMOB, which defines data exchange formats and communication channels. One of the major functions of INCIMOB is the registration and tracking of emergency patients. Recorded data will be processed by INCIMAG and the IMPRESS integration layer used as input for the PATEVO/LOGEVO components. In addition, the app provides up to date information about the ongoing event, status updates and recommendations from the DSS tools.Further development comprises also a public available version of INCIMOB, called INCIcrowd, which enables the public to support the IMPRESS system in terms of crowdsourcing. INCIcrowd will be a light version of INCIMOB, to enable the public to receive alerts, submitting observations and exchanging resource offers/needs. INCIcrowd will be connected to the IMPRESS system via a dedicated server and the IMPRESS message bus.

Fig. 6 .

 6 Fig. 6. General Architecture of the IMPRESS Smart Applications

Fig. 7 .

 7 Fig. 7. Palermo waste dump of Bellolampo

Fig. 8 .

 8 Fig. 8. Palermo district involved called "Kalsa" plus the boat location in the gulf

Acknowledgement

This work has been partially funded by the EC in the 7 th Framework Programme, (SEC-2013.4.1-4: Development of decision support tools for improving preparedness and response of Health Services involved in emergency situations) under grant number FP7-SEC-2013 -608078 -IMproving Preparedness and Response of HEalth Services in major criseS (IMPRESS).