Disaster Reduction Potential of IMPRESS Platform Tools

Abstract

In our paper we will present the IMPRESS Platform tools that have been used for tests and validation purposes in the case of Palermo Demo. The demo has been part of a national Italian field test exercise for civil protection authorities and all related services along. The system validation and tests procedures have been fulfilled in alignment with the authorities remarks. The outcomes and results from each tool in the platform will be described and the added value for the users who worked with them.

1 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 [1] 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.

2 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.

2.1 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 (ActiveMQ) 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 Fig. 1.

Fig. 1.

WARSYS architecture

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.

2.2 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) [2] 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 [3] 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 Fig. 2.

Fig. 2.

General architecture of the LOgEVO component

2.3 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’.

SORLOC therefore has a single scope: determine a SOuRce LOCation. This determination has two facets, one temporal and one spatio-temporal [5]. Each facet has two subcomponents:

• Locate a source in time or time and space

• Provide an estimate of epidemic progression

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.

2.4 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 cross-border 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) (Fig. 3).

Fig. 3.

General architecture of the PATEVO component and its collaborative functions

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 [6] 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.

2.5 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 [7] 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 Fig. 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 [8] 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.

Fig. 4.

Architecture of the DHC component

The Data Harmonization Component uses the D2RQ server [9], an RDB2RDF technology, as well as, the SILK framework [10].

2.6 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.

2.7 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 (Fig. 5).

Fig. 5.

General architecture of the recommendation component and relation to other components

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 multi-tier 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.

2.8 INCIMOB Component

The 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.

Both applications have a general common architecture, depicted in Fig. 6.

Fig. 6.

General architecture of the IMPRESS smart applications

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.

3 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 (Fig. 7) between July 29 and August 17, 2012.

Fig. 7.

Palermo waste dump of Bellolampo

All the parameters about the toxic cloud that has been transferred above Palermo city center have been extracted from the past event in 2012. The designed scenario for IMPRESS system testing on 7th of June 2016 included sudden event consisting of a fire occured in a ship moored just outside the Palermo harbor (in Fig. 8 the red circle indicates the location of the ship).

Fig. 8.

Palermo district involved called “Kalsa” plus the boat location in the gulf (Color figure online)

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 km², indicated by the shaded area in Fig. 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.

4 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.