# Process Design Patterns in Emergency Management

Tomáš Ludík, Tomáš Pitner

► To cite this version:

Tomáš Ludík, Tomáš Pitner. Process Design Patterns in Emergency Management. 11th International Symposium on Environmental Software Systems (ISESS), Mar 2015, Melbourne, Australia. pp.434-444, 10.1007/978-3-319-15994-2_44. hal-01328588

HAL Id: hal-01328588

https://inria.hal.science/hal-01328588

Submitted on 8 Jun 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques 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.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Process Design Patterns in Emergency Management

Tomáš Ludík¹,² and Tomáš Pitner²

¹Department of Emergency Management: University of Defence, Brno, Czech Republic

²Faculty of Informatics: Masaryk University, Brno, Czech Republic

tomas.ludik@unob.cz, tomp@fi.muni.cz

**Abstract.** Emergency management is a discipline of dealing with and avoiding risks. In case of any emergency the immediate and fast intervention is necessary. It is possible only because of well-prepared contingency plans and adequate software support. Therefore, the aim of this paper is to focus on the common characteristics of process modelling within emergency management and to define the design patterns that are typical of this area. These Design Patterns enable faster and simpler generation of emergency processes and contingency plans as well as subsequent software support. They result from the current documentation and legislation. Each design pattern does not represent a final emergency process, but only a certain structure which is necessary to further customize according to current user requirements. Specifically, 16 design patterns have been identified and described on more management levels. The present form of design patterns is a result of the consolidation of many real processes of emergency management that arose and were verified within several research projects or set of directed interviews with emergency management experts.

**Keywords:** emergency management · process framework · process modelling · contingency plans · design patterns · directed interviews

## 1 Introduction

Process management is an implemented and often used approach in business practice which enables a variety of organisations to achieve better results from a long-term point of view (Weske, 2012). On the other hand, the functional management approach often predominates in public administration (Smith, 1776). With regard to the poorer utilisation of an organisation's sources and assets, the functional management approach does not enable the achievement of these results. It achieves the set objectives more slowly and handles constantly ongoing changes only with great difficulty. These properties can be seen especially in the area of emergency management, where a fast and efficient intervention will enable not only the rescue of assets and the environment, but above all human life. There is an unambiguous necessity to gradually reduce using the functional management approach to emergency situations and to start coping with these situations in a process manner.

In case of process management, it is not only a change in the management approach, but also the entire information support of processes. This differs from the
classical rigorous development of information systems. Process-oriented systems must react to the dynamic environment in an organisation quickly and be capable of adapting themselves to current needs and priorities (Pekárková et al., 2013). For this purpose, a lot of new approaches, methods and instruments have appeared in reaction to this trend (Barta, 2013). Moreover, emergency management is specific because of the distrust of information technologies, because of necessary interoperability with other information systems and because of the emergency information system's complexity and the necessity to develop resistance to breakdowns and crashes (Hiltz et al., 2010; Haddow et al., 2013).

Based on the abovementioned description, there are two principal requirements for emergency management. First, there must be a change from the functional to the process management approach and, at the same time, support for the new method of coping with emergency situations with information through advanced information technologies. For this purpose, the Process Framework for Emergency Management has been defined. It provides well-arranged, unambiguous and complex instructions of how to achieve this complex change in the management method as well as in the information support in the area of emergency management.

## 2 Process Framework for Emergency Management

The Process Framework for Emergency Management consists of five main components which describe the problems of different areas. In specific terms, it is process methodology, reference architecture, factors for implementation, design patterns and quality assurance processes.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Process framework for emergency management</figcaption></figure>

*Process methodology* – the methodology contains the instructions of how to identify and describe the user roles and processes in the field of emergency management. For this, it recommends the appropriate recording forms of emergency management processes, which is the Business Process Modelling Notation combined with the Use Case diagram from the UML. If in need of automation, the methodology provides the
instructions of how to further configure processes, how to add required data and ser-
vices and subsequently how to interpret them through the workflow engine. For more
information about process methodology, see (Ludík and Ráček, 2011a).

*Reference architecture* – this provides a view and recommendation concerning the particular software components which can be used in process automation and, at the same time, it reflects the requirements resulting from emergency management processes. The entire design is based on the Workflow reference model. Then this conceptual model is completed with specific tools and components which can be found in the sphere of information support of processes in organisations, whereas stress is laid on the independence of specific software from a particular provider. For more information about reference architecture, see (Ludík et al., 2011).

*Factors for Implementation* – the issue of emergency management processes is so comprehensive that the standard approaches used in the area of software engineering cannot be used. On this account, this part focuses on the description of factors and specific characteristics of emergency management. The identified factors can be divided into two groups, i.e. internal factors and external factors. For more information about factors for implementation, see (Ludík and Ráček, 2011a).

*Design Patterns* – these enable faster and simpler generation of emergency pro-
cesses. They result from the current documentation and legislation and are defined
based on many years’ experience of emergency process modelling. No design pattern
represents a final emergency process, but only a certain structure which it is necessary
to further customise according to current user requirements. For more information
about design patterns, see Section 4 of this paper.

*Quality Assurance* – this provides methods and tools to assure the quality of simu-
lated processes that must be in compliance with not only legislation and current emer-
gency plans, but especially in compliance with the requirements of bodies active in
emergency management. For more information about quality assurance, see (Ludík
and Ráček, 2011b).

3 Design Patterns State of the Art

In software engineering, a design pattern represents a general reusable solution to a commonly occurring problem within a given context in software design (Gamma et al., 1994). A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

In the same manner, it is possible to approach the design of process diagrams
(workflow) and to define design patterns in this field. The Workflow Patterns Initia-
tive is the greatest one in this field which is a joint effort of Eindhoven University of
Technology and Queensland University of Technology and which started in 1999.
The aim of this initiative is to provide a conceptual basis for process technology. In
particular, the research provides a thorough examination of the various perspectives
that need to be supported by a workflow language or a business process modelling
language (Russell et al., 2006). There are a few similar efforts. As an example, a
chapter in the book Designing Business Processes with Patterns (Glushko and McGrath, 2005) or a paper entitled Applying Patterns during Business Process Modelling (Gschwind et al., 2008) can be mentioned.

The design patterns can serve the purpose only in the event that they are comprehensible and described sufficiently. There is no single, standard format for documenting the design patterns. Rather, a variety of different formats has been used by different pattern authors. However, according to Martin Fowler, certain pattern forms have become more well-known than others, and consequently become common starting points for new pattern-writing efforts (Fowler, 2006). One example of a commonly used documentation format is the one used by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in their book entitled Design Patterns (Gamma et al., 1994). It contains the following sections:

* Pattern Name and Classification – a descriptive and unique name that helps in identifying and referring to the pattern;

* Intent – a description of the goal behind the pattern and the reason for using it;

* Also Known As – other names for the pattern;

* Motivation (Forces) – a scenario consisting of a problem and a context in which this pattern can be used;

* Applicability – situations in which this pattern is usable; the context for the pattern;

* Structure – a graphical representation of the pattern. Class diagrams and Interaction diagrams may be used for this purpose;

* Participants – a listing of the classes and objects used in the pattern and their roles in the design;

* Collaboration – a description of how classes and objects used in the pattern interact with each other;

* Consequences – a description of the results, side effects, and trade-offs caused by using the pattern;

* Implementation – a description of an implementation of the pattern; the solution part of the pattern;

* Sample Code – an illustration of how the pattern can be used in a programming language;

* Known Uses – examples of real usages of the pattern; and

* Related Patterns – other patterns that have a relationship with the pattern; discussion of the differences between the pattern and similar patterns.

# 4 Design Patterns for Emergency Processes

The process approach is applicable in different domains whereas each of them has certain specific characteristics. The aim of this section is to focus on the common characteristics of process modelling within emergency management and to define the design patterns that are typical of this area. The design patterns described in this section are an essential part of the process framework for emergency management in the Czech Republic which was presented in Section 2.
Analogous to other parts of the process framework, it is possible to independently
use the design patterns already created, without any links to the designed framework.
Even in this example, the defined design patterns will enable a faster and better identi-
fication, analysis and emergency processes design at all levels of emergency man-
agement. The identified design patterns are divided into three groups according to the
level of management at which emergency processes occur. These are strategic, opera-
tional and tactical levels.

## 4.1 Strategic Patterns

The strategic level represents the top-level management view of the solution of ex-
traordinary events and emergency situations. Emergency-related legislation and other
strategic documents defining general strategic procedures of coping with emergency
situations on the territory of the Czech Republic are among the most fundamental
documents influencing the design patterns. On the basis of these documents, it is pos-
sible to derive generally valid procedures used in coping with emergency situations,
and to define them in a process way. Higher level processes develop in this manner
and describe a general level of intervention management. This level is suitable for
further decomposition.

*Emergency Management Process, Solving an Extraordinary Event, Solving an Emergency* and *Solving a Flood Situation* are included among the strategic design patterns of emergency management. Each design pattern is identifiable unambiguous- ly through an *Identifier*. The *Title*, *Motivation*, *Description*, *Structure*, *User Roles*, *Known Uses*, *Related Patterns* and *Regulations* have been selected as further attrib- utes for describing a design pattern.

SP-2: Solving an Extraordinary Event.

*Motivation* – The aim of the design pattern is to show how to efficiently solve an extraordinary event in compliance with legislative requirements within the shortest possible time. An extraordinary event that occurs in a certain environment is usually solved by the Integrated Rescue System (IRS) components in a regular way.

*Description* – The solution of an extraordinary event proceeds in a few basic steps. First of all, the emergency operational centre receives a notification of the occurrence of an extraordinary event such as a fire, road traffic accident or leak of a hazardous substance. Based on the received information, the situation is analysed. According to its extent, the particular rescue components are activated. Their task is to come to the intervention site as fast as possible. After the arrival of particular components, the intervention commander who is responsible for coping with the emergency situation is appointed. First of all, he analyses the intervention site and assigns tasks to subor- dinate units. Afterwards, he monitors and evaluates the situation and responds to the development of the situation as a whole. The individual rescue components, such as firefighters, ambulance services and the police perform rescue and clean-up works. At the end of the intervention, the activities connected with finishing the intervention as well as evaluating the extraordinary situation that took place.
<figure><img src="image_3.png" /><figcaption>Fig. 2. Solving an extraordinary event (SP-2)</figcaption></figure>

*User Roles* – Emergency Operational Centre, Intervention Commander, Integrated Rescue System.

*Known Uses* – Extraordinary events in the Czech Republic are solved every day. It may be e.g. a road traffic accident on the motorway, a hazardous substance leak, fire, explosion or other situations which need the assistance of the IRS. The entire process is initiated by an emergency call and subsequently it continues based on the type and characteristics of a given event.

*Related Patterns* – The described design pattern specifies the Response activity in the Emergency Management Process (SP-1) pattern in case of an extraordinary event.

*Regulations* – The defined process as such is primarily based on the Act on the Integrated Rescue System (Act No. 239/2000 Coll.).

## 4.2 Operational Patterns

The processes at the operational level are among the group of design patterns that have to be customised most, as they are markedly dependent on the site and characteristics of an extraordinary event or an emergency situation. The emergency plans of particular regions and municipalities have been developed with regard to local knowledge, e.g. the specific experience of emergency components or available resources in a given region. The IRS operational plans, which also are a basic starting point for creating the design patterns, describe the so-called ideal case of how to solve a given situation. However, it is necessary to take into account the fact that a real solution of a situation may be affected by other facts in practice. The operational design patterns serve primarily as a general starting point for process modelling at the operational management level. It is necessary to further adapt these processes according to specific user and territorial requirements. In the next part, one of seven specific operational design patterns within emergency management is presented.

### OP-1: Reception of Information on an Extraordinary Event.

*Motivation* – Each extraordinary event or emergency situation is dealt with as soon as it is reported to the IRS operational centre. Here, it is very important to recognise
the character of the extraordinary event quickly and correctly, and to respond to it
through intervening components. It is also necessary to find out which of the reported
situations are of an emergency character and in which cases the emergency call num-
ber was abused.

*Description* – The emergency operational centre operator receives a report on an extraordinary event. He must find out the necessary information from a reporting person, especially the address and type of the event. In case of suspicion that the information is false, the operator calls back to the reporting person. Afterwards, the operator evaluates the extraordinary event; he selects a unit or units and sounds the alert. The unit for which the alert was sounded must confirm the alert and subsequent departure up to a certain time limit or may cancel the alert or departure for e.g. a defect on intervention equipment.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Reception of information on an extraordinary event (OP-1)</figcaption></figure>

*User Roles* – Operator of Emergency Operational Centre, Rescue Units.

Known Uses – The process is executed not only in the emergency operational cen-
tre of emergency calls 112, but also in other operational centres of the IRS compo-
nents. The process is initiated by an incoming call, through which an extraordinary
event is reported and completed by the departure of particular IRS components.

*Related Patterns* – The presented design pattern specifies the method of acquiring the information on an emergency situation which is a part of both the Solving an Extraordinary Event design pattern (SP-2) and Solving an Emergency design pattern (SP-3).

*Regulations* – Design pattern is based on the Combat Order of Fire Security Units.
As another starting point to define the design pattern, the Act on the Integrated Res-
cue System and the Emergency Management Act were used.

**4.3 Tactical Patterns**

The design patterns at tactical level describe the activities of the intervention com-
mander and other IRS components intervening in the scene of an extraordinary event.
The defined tactical design patterns are based on the general low-level standardised procedures which describe the activities of intervening components in the intervention site. It is necessary to state that these procedures are not formalised sufficiently in some of the basic components of the IRS. For this reason, the designed tactical patterns are primarily based on the Combat Order of Fire Security Units. This is a set of documents containing standardised procedures for the Fire Rescue Service units in the intervention site. The following tactical patterns have been defined: *Issue, Confirmation and Fulfilment of Order, Information Exchange, Management of Intervention, Establishment of Crisis Staff and Organisation of Intervention Site*.

**TP-1: Issue, Confirmation and Fulfilment of Order.**

*Motivation* – The design pattern defines the general procedure of issuing, confirming and fulfilling the orders. Order, command, direction and instruction are control acts for conducting an intervention through which every commander discloses his decision to his subordinates to perform a definite task. To issue orders, commands, directions and instructions in the intervention site is not only an authorisation, but also a task of each management level.

*Description* – The superior issues an order to the addressee (subordinate). The order must be confirmed or, if need be, repeated by the addressee, which proves that the addressee understands the order. It is necessary to make sure that the order has really reached the addressee. If the addressee does not understand or does not confirm the order, the order is repeated again. When the order is issued, the subordinates follow it and the superior checks its fulfilment. After that, the subordinate reports the fulfilment of the order to the superior who issued the order and the design pattern is completed. In issuing an order, the principles apply as follows: an order must be performable and structured logically so that it is evident what its aim is. It is also important to stress the purpose of the order. It must be apparent that the commander is convinced of his decision. The content of the order must be clear, unambiguous and understandable. In case of an urgent situation, the order must be brief and must be issued rapidly.

<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Issue, confirmation and fulfilment of order (TP-1)</figcaption></figure>

*User Roles* – Superior, Subordinate.
*Known Uses* – The design pattern is applied regularly within coping with every extraordinary event or emergency situation. Emergency management is based on the clear hierarchical structure of management. The particular intervening persons are obliged to fulfil orders and instructions of their unit commanders in the intervention site. The unambiguous responsibility for fulfilling all the activities is allocated in the intervention site.

*Related Patterns* – The design pattern supplements the operational design patterns which primarily describe rescue and clean-up works in the intervention site.

*Regulations* – The design pattern is defined based on the Code of Practice of Chapter Ř which is a part of the Combat Order of Fire Security Units.

## 5 Interviews with Experts

Set of directed interviews with emergency management experts, was used as method for verifying the process framework as well as design patterns applicability in practice (Pitner et al., 2014). The experts answered 8 questions. The addressed experts were chosen to cover the field of handling extraordinary events and emergency situations. For this reason, the key areas of emergency management, within which the application of the process framework is relevant, were identified. Out of these areas the experts were addressed and asked for assessing the defined framework. The experts are introduced in the alphabetical order as follows:

* *Emergency management and its impact on the environment* – Assoc. Prof. Vladimír Adamec;

* *Emergency management economic aspects* – Eduard Bakoš, PhD;

* *Dealing with emergency issues from the viewpoint of the municipality* – Aleš Kudlák, MSc;

* *Emergency management in power plant engineering* – Oldřich Mach, PhD;

* *Education in the field of civil protection* – Bohumír Martínek, PhD;

* *Computer-generated simulation in emergency management* – Assoc. Prof. Vladimír Vráb;

* *Dealing with emergency situations from the viewpoint of fire brigade* – Lukáš Vymazal, MSc.

The performed directed interviews can be sum up as follows. The presented process framework provides sufficient instructions for using the process management approach in solving emergency and extraordinary situations. It is a logical and correct approach which is usable in practice. The framework is easy to understand for the workers in the field of emergency management. It can be stated that, currently, the process framework becomes a necessity and an actual trend.

Individual parts of the framework are divided logically and their description provides information about their relevance. The description of individual parts is well-arranged, adequate and accurate. Some of the experts have recommended emphasizing the strengths of the designed system, refining the terminology and describing the framework to be easy to understand for the lay public.
The identification of emergency processes, their subsequent optimisation and visualisation can be considered as the main contributions of the process framework. The automation of processes and the information support to cope with emergency situations have been evaluated as the biggest contribution. The emergency processes defined clearly will enable a relative independence of the human factor. Further contributions can be seen in the savings of time, personnel and finance.

## 6 Conclusion

The process design patterns are defined based on the authors' many years' experience with modelling the emergency management processes. The present form of design patterns is a result of the consolidation of many real processes of emergency management that arose and were verified within several research projects, directed interviews with emergency management experts or within the development of bachelor's and master theses. The aim of this paper is not only to create a basic set of design patterns for the area of emergency management, but also to show the method of how the design patterns can be defined in this area and, subsequently, to use them in modelling the emergency management processes.

## References

1. Barta, J. 2013. The Use of Simulations for the Need of Environment Protection. *Environmental Software Systems*. Heidelberg: Springer. vol. 2013, no. 413, p. 294-301. ISSN 1868-4238.

2. Fowler, M. 2006. *Writing Software Patterns* [online]. Martin Fowler. [2014-06-20]. Available: http://www.martinfowler.com/articles/writingPatterns.html

3. Gamma, E.; Helm, R.; Johnson, R. et al. 1994. *Design Patterns: Elements of Reusable Object-Oriented Software*. Addison-Wesley. 395p. ISBN 0-201-63361-2.

4. Glushko, R.; McGrath, T. 2005. *Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services*. MIT Press.

5. Gschwind, T.; Koehler, J.; Wong, J. 2008. Applying Patterns during Business Process Modeling. In *Proceedings of the 6th International Conference on Business Process Management*. Springer-Verlag, Berlin, Heidelberg. ISBN 978-3-540-85757-0.

6. Haddow, G.; Bullock, J.; Coppola, D. 2013. *Introduction to Emergency Management*. Fifth Edition. Butterworth-Heinemann. ISBN 978-0124077843.

7. Hiltz, S., Walle, B., Turoff, M. 2010. The Domain of Emergency Management Information. In *Information Systems for Emergency Management*. Volume 16. Advances in Management Information Systems. Armonk, NY: M.E. Sharpe. ISSN 1554-6152.

8. Ludík, T., Ráček, J. 2011a. Process Methodology for Emergency Management. In *IFIP Advances in Information and Communication Technology*. Heidelberg: Springer. ISSN 1868-4238.

9. Ludík, T., Ráček, J. 2011b. Process Framework for Emergency Management. In *Proceedings of the 6th International Conference on Software and Database Technologies*. Portugal: SciTePress. ISBN 978-989-8425-77-5.

10. Ludík, T., Navrátil, J., Langerová, A. 2011. Process Oriented Architecture for Emergency Scenarios in the Czech Republic. In *International Conference on Business Process Man-
agement. Venice: World Academy of Science, Engineering and Technology. ISSN 2010-3778.

11. Pekárková, L., Eibenová, P., Pitner, T. 2013. A Framework for Monitoring and Evaluation of Learning Processes. In *Environmental Software Systems. Fostering Information Sharing*. Berlin, Heidelberg: Springer. pp. 525-532. ISBN 978-3-642-41150-2.

12. Pitner, T., Motschnig, R., Kozlíková, B. et al. 2014. *Constructive Communication in International Teams: An Experience-Based Guide*. First Edition. Münster: Waxmann Verlag. 248 p. ISBN 978-3-8309-3025-9.

13. Russell, N.; Hofstede, A.; Aalst, W. et al. 2006. *Workflow Control-Flow Patterns: A Revised View*. BPM Center Report BPM-06-22. BPMcenter.org.

14. Smith, A. 1976. *An Inquiry into the Nature and Causes of the Wealth of Nations*. London: W. Strahan and T. Cadell.

15. Weske, M. 2012. *Business Process Management, Concepts, Languages, Architectures*. Second Edition. Berlin Heidelberg: Springer-Verlag. ISBN 978-3-642-28616-2.