1 Introduction

Despite current advances in information and communication technologies, information systems supporting disaster management are still far from sophisticated (Palen et al. 2007; Botterell and Addams-Moring 2007). There have been scattered efforts to tackle individual types of disasters, but a monolithic information system for supporting all phases and activities of disaster management is currently far too complicated. This is because there are a great variety of disasters each with its own characteristics, such as epidemic outbreaks, natural disasters, major accidents, and terrorist attacks. Prediction, detection, and specific handling activities are therefore different. In particular, the handling of emergency and unpredictable situations in the event of individual disasters indeed varies greatly, involving a large variety of organizations and personnel as well as heterogeneous physical and information resources. Therefore, it is impossible to hard-code all these software into one information system. Rather, a dynamic process and information integration approach that supports both human and system interactions should be advocated.

For example, let us consider the several serious epidemic outbreaks in Asia in the recent years (Lin and Chiu 2007). Each time, local governments and hospitals needed to take necessary actions to prevent the spreading of the disease, especially alerting notifications and resources allocation. As observed in recent practices when Severe Acute Respiratory Syndrome (SARS) and Avian Influenza appeared in Asia, the steps to retrieve the related patient records and to notify nearby countries had taken a significant time. In the case of epidemics such as SARS, the consequences of this could become very serious; and the required medicines as well as medical professionals could become inadequate within a short time. As for a natural disaster such as a tsunami after an earthquake, timely notification to neighboring areas is a matter of life and death. After a natural disaster, numerous casualties and other affected survivors require a large amount of various resources. Again, resource allocation on such a large scale is a difficult task, especially under urgency constraints.

By observing various types of disaster, we identify the resolution to one key problem, achieving timeliness in actions, as our main research objective. To this end, we introduce a Disaster Notification and Resource Allocation System (DNRAS) based on an Alert Management System (AMS) (Kafeza et al. 2004) implemented upon standard Web service technologies. Because our AMS can support highly customizable urgent requests and critical messages (known as alerts) on multiple platforms, the DNRAS can perform notification, resource level query and allocation, and information retrieval with a focus on the issue of timeliness through the monitoring of activities among various involved parties in disaster management. This platform is designed for the context of the Asia region, where many serious disasters have occurred. Based on our previous experience in healthcare informatics, we illustrate the practical relevance of our approach with an example of an epidemics outbreak (Lin and Chiu 2007). Under current practices, to discover and declare an epidemic outbreak requires the verification of many affected patients’ health history records, especially concerning symptoms and patterns of spreading. The delivering of such records by fax or e-Mail may often result in mis-interpretation because of scanning distortion or mis-reading of the hand-written text (Kafeza et al. 2004; Ride et al. 1994). This inevitably causes delays in the discovery and announcement of the outbreak. Therefore, the most critical issues of allocation and purchase of the required resources such as medicines, medical professionals, and equipment, need to be decided in a timely manner in order to prevent the spread of the disease. However, these activities involve many parties in the interactions and negotiations, together with many estimations and uncertainties. Moreover, effective communication is required with the infected areas, so that the actual condition of the infection cases can be reported and monitored without mistakes.

The rest of the paper is organized as follows. Section 2 discusses background and related work. Section 3 presents an overview of the main system requirements and our research methodology. Section 4 presents our DNRAS architecture highlighting the function of the AMS through an example of an epidemic outbreak. Section 5 further details how alert messages support various functions for disaster management in a timely manner. Section 6 presents the lessons learned through a case study of a SARS outbreak. Section 7 discusses the advantages of our approach with respect to various system stakeholders, and Section 8 summarizes the paper with our future work directions.

2 Background and related work

2.1 Integration and collaboration

Disaster management involves disparate functions and heterogeneous information sources across various parties (Wang et al. 2005). For example, Sharman et al. (2007) highlight some major principles for the design of systems to support critical incident support, which include coordination, resource management, information and intelligence sharing and dissemination. Therefore, integration is one main focus of disaster management.

In recognition of the need to streamline cross-organizational services or processes by creating an open and distributed system environment, a number of studies have shown increased interest in the field of Web services, which enable flexible service selection and composition for cross-organizational processes (Zhao and Cheng 2005; van der Aalst et al. 2007; Herrero et al. 2008). Recently, the approach of Web service-based information and process integration has been receiving much attention. Further, with Web services standards like the Universal Description, Discovery and Integration (UDDI), Internet users and Internet-based systems can easily locate the required services, and the cyberspace forms a loosely connected cyber-society with lots of business opportunities (Weerawarana et al. 2005). As such, business-to-business (B2B) interactions are now switching from old EDI formats to a common platform of Web services for service description and data exchange. Moreover, Web services are being adopted as promising technology to support open and distributed decision making and coordination in business applications (Wang et al. 2004). For example, McGregor (2007) suggests a framework for the design of Web service-based clinical management systems to support inter- and intra-organizational patient journals. Raghupathi and Gao (2007) explore a profile based on the Unified Modeling Language (UML) approach to modeling Web services in healthcare. We have also proposed a methodology based on workflow views and Web services for this purpose (Chiu et al. 2003a, b), where a survey of recent works on Web service composition can be found. As more and more organizations deploy Web service access, our DNRAS becomes feasible upon such infrastructures, especially for largely populated cities, where the speed of the epidemic outbreak is even more critical.

One type of work focuses on notification and information integration. For example, Bharosa et al. (2008) focus on the concept of information quality in adaptive information orchestration to address various issues in disaster management, such as accuracy, timeliness, relevance, quantity, completeness, format, security, and consistency. This is in line with our objectives, but we focus on actions and timeliness issues. Botterell and Addams-Moring (2007) present the problem of the diversity of research domains and technology solutions inherent to the problem of public warnings. The authors believe that a single technology for public warning (i.e., exchange of “Common Alerting Protocol” messages) is vulnerable because people need confirmation from several resources and therefore, multiple communication channels are necessary. This is in line with our alert mechanism, which supports multiple devices and platforms. However, our application of alert is not just concerned with information integration, but is also a general mechanism for collaboration and monitoring of process integration. Further, Kim et al. (2007) measure the effectiveness of emergency response systems, and identify early detection and response as well as communication capacity as being vital for critical incident management. They make use of interoperability standards such as EXML and GJXML for device communication. Our AMS is also based on Web services standards for interoperability and efficient communication.

Another type of work focuses on coordination and collaboration. Existing solutions include the use of blogs, wikis, websites, and on-line forums (Palen et al. 2007). Customized systems focus on the design of interactive responses through the use of collaborative tools. For example, WORKPAD (Mecella et al. 2006) is an adaptive peer-to-peer software infrastructure for supporting collaborative work of human operators in disaster scenarios. However, urgency notifications and system-to-system collaborations are not adequately supported in these types of systems. To partly overcome these problems, Fiedrich and Burghardt (2007) highlight the deployment of agents for this purpose. The use of agents has attracted much attention, such as the work presented at the First International Workshop on Agent Technology for Disaster Management (Jennings et al. 2006). Our use of alerts as a unified mechanism to address all these major issues is complimentary to the agent approach because agents can work on top of our alert mechanism (Chiu et al. 2008b).

Further, improved communications among personnel is also a key to quick response. For example, Buono et al. (2008) propose a Wireless Internet Information System for Medical Response in Disasters (WIISARD) to bring together broad-based participation from academia, industry, military, and emergency responders of the city and county of San Diego, in order to coordinate and enhance care of mass casualties in a terrorist attack or natural disaster. It also provides emergency personnel and disaster command centers with medical data to track and monitor the condition of hundreds to thousands of victims on a moment-to-moment basis, over a period of hours to days at the disaster site. Containing a mesh network of multiple CalMesh nodes, WIISARD has developed technologies to enhance communication among emergency team members and ensure their safety by tracking the “hot zone,” or location and wind drift, of chemical or radioactive matter used as a weapon of mass destruction against civilians. We employ the alert mechanism to address communication issues (Kafeza et al. 2004).

Regarding existing systems, Sahana is a Web-based open source solution (Currion et al. 2007) (http://www.sahana.lk/overview) with the primary goals to help alleviate human suffering and to help save lives through the efficient use of information technology during a disaster. WIISARD (Killeen et al. 2006) is a prototype based on handheld devices designed for medical care at a disaster site. One of its components replicates the standard paper triage tag for recording and exchanging real-time medical data from the disaster site. Other components of WIISARD aim at enhancing the situational awareness of first responders. Their work is similar to our approach in the sense that they integrate alarms and alerts under the same common database messaging system. They also argue that clinical and disaster responses have key characteristics in common and they are dynamic in nature. In our approach, we focus on alerts and our work could be used in combination with their approach, introducing a more specialized mechanism for handling alerts.

2.2 Knowledge and decision support

Focusing on the inherent complexity and dynamics of emergency management tasks, much research focuses on quick knowledge sharing and decision coordination among multiple distributed organizations. For example, Becerra-Fernandez et al. (2008) are working on a project called virtual Emergency Operations Center (vEOC) for conceptualizing and developing measures of emergency management task complexity and uncertainty. They have also developed a research model that focuses on the mediating role of knowledge integration between emergency management task complexity/uncertainty and task performance. To reduce the redundancy of information in disaster response on the Web, Roman et al. (2008) propose a suite of electronic knowledge management (eKM) tools that can be used to reduce by one order of magnitude the information that people need to read in order to gain and maintain awareness of web content during emergencies. They have attempted to apply them to Web content from organizations’ websites and individuals’ blogs. By using eKM, the responders and victims are able to quickly gather an overview of general issues derived from many websites and then learn more about specific issues by navigating to a few websites.

Motivated by the urgent need to collect accurate, comprehensive, and timely information about emergency management, Song and Chang (2008) propose the use of abbreviation extraction to derive high-quality information from the text, in order to help users concentrate on higher-level interpretation and actual action by removing some troublesome and time consuming tasks. Systems using this approach also contribute towards emergency preparedness and provide timely and structured materials for emergency training and education purpose. Zhang et al. (2008) provide a review and critique of the literature on Web-based group decision support systems (wGDSS) and employ this in their system called ThinkTank to manage issues of food safety. The ThinkTank system employs a Web 2.0 architecture to support techniques such as brainstorming, organizing ideas, voting on alternatives, prioritizing, building consensus, etc. It also creates a clear, custom output of the content created during the innovation process for alignment on action or for future reference.

Smirnov et al. (2008) present a decision support system (DSS), which is implemented as a network of a set of Web-services, to address the issue of context-aware operational decision support in emergency situations. In the DSS, Web services are used to organize a service network according to context, and the purpose of the service network is to provide the DSS with contextualized information from diverse information sources and to solve problems specified in the context. The concept of context is proposed as a “problem model” to be solved in a particular kind of emergency situation. It is produced based on the knowledge extracted from the application domain (application ontology) and formalized by a set of constraints. Smirnov et al. demonstrate the ideas for real-time resource coordination and situation awareness for logistics management in fire response.

Although our DNRAS currently supports the function of resource management only at knowledge level, our system is extensible to support other knowledge level functions based on notification and information requests with our fundamental alert-based mechanism.

2.3 Alert based approaches

Our proposal of the use of an Alert Management System (AMS) originates from medical informatics (Kafeza et al. 2004). Raghupathi and Tan (2002) point out that new healthcare applications supporting information technology (IT) based strategies are required for meeting competitive challenges, and they estimated IT expenditure on healthcare in 2002 to be 21.6 billions in the United States. In particular, health-care applications will take advantage of the technological advances in communications technologies and mobile devices (Olla and Tan 2006). Ammenwerth et al. (2000) also report that one of the major benefits of mobile technologies is to help hospitals in communication and reachability management among patients and message senders, as well as to address the urgency requirements. Hripcsak et al. (1996) preliminarily identify the need for event monitors and describe some of the requirements such as tracking healthcare events, looking for clinically important situations, and sending messages to the providers. Eisenstadt et al. (1998) further categorize messages as alerts, results, and replies. The limitation of their approach is that they only focus on alerts that can be handled by two-way pagers. Ride et al. (1994) argue that the problem of figuring out to whom the message should be sent is a difficult one and only suggest some ad hoc solutions such as sending a message to whoever has recently examined the patient electronic record.

Although information integration issues are not new in database research communities (Sheth and Larson 1990), Sheng and Chen (1990) identify the application of workflow technologies in different hospitals as having many unique properties that entail special integration design considerations. Health informatics communities (e.g., the International Medical Informatics Association, http://imia.org) have been discussing the application of workflow technologies in health administrative data integration for a period of time. For example, Takeda et al. (2000) present a system architecture for supporting networked electronic patient records. Grimson et al. (2001) propose a Synapses prototype system for supporting federated healthcare records that provides an integrated view of patient data from heterogeneous distributed information systems on the Internet. Al-Ali et al. (2006) propose a prototype system to provide real-time wireless integration of patient information system with mobile devices. However, none of these approaches can provide a seamless integration that permits the use of workflow technologies or alert mechanisms. In particular, integration with manual access of legacy paper records through workflow management together with electronic records has not been presented as in those papers.

In the context of workflow management systems (WFMS), Chun et al. (2002) propose the automatic generation of workflows from domain knowledge. We have recently proposed separating user alerts from user sessions to improve the system flexibility (Chiu et al. 2002) in our Mobile E-commerce Advanced Object Modeling Environment (ME-ADOME) WFMS. Online users are alerted through ICQ (I seek you) (Weverka 2001) messages with the task summary and reply Universal Resources Locator (URL) as the message content. If the user is not online, or does not reply within a pre-defined period, the WFMS will send the alert by email. At the same time, another alert may be sent via SMS to the user’s mobile phone. Whatever the alert channel has been, the user may connect to WFMS on any other devices or platforms. For example, after receiving a SMS alert, the user may use his/her handset to connect to the WFMS via Wireless Application Protocol (WAP), or reply with an SMS message. Alternatively, the user may find a computer with an Internet connection, or use his/her personal digital assistant (PDA) to connect to the WFMS. As an extension to existing process models such as Sheng and Chen (1990), our process model abstracts information regarding roles and their schedules of service providers possessing these roles. We have employed a bottom-up data-driven methodology to extend information systems into Web Services (Chiu et al. 2004) and further incorporated alerts and their routing (Kafeza et al. 2004).

Besides healthcare applications, we have also pioneered in the application of alert management in a wide range of other application domains for process and data integration. For example, in electronic commercial applications, Lee et al. (2007) employ Web services and alerts to enhance workflow automation in insurance underwriting processes. Ng and Chiu (2006) study the feasibility of electronic government process integration with Web services and alerts through an emergency route advisory system. For industrial production, Chung et al. (2007) propose the use of an alert management system for concrete batching plants. Chiu et al. (2008) advocate alert management for ubiquitous support in distance education applications.

To our knowledge, there are no other WFMS employing an alert approach. Further, there has been no other work on alert-driven process integration or data integration currently. Neither have there any reports on the use of alert management concepts with Web service based implementation to manage against disaster outbreaks. In further comparison with related works, our integrated framework shows its differences in the framework of not just integrating local government authorities, but also addressing inter-government integration, especially on resource allocation issues. Next, we explicitly address the timeliness issues as our research focus by means of alert management.

3 Requirements and methodology overview

The objectives of our DNRAS are to provide timely notifications, aggregation of possible resources, and allocation of resources among parties inside and outside of the affected area. Therefore, the design of our platform focuses on alert notification and resource allocation through the Internet. We briefly introduce the main stakeholders as follows (Fig. 1).

Fig. 1
figure 1

Major stakeholders of the DNRAS

Full size image

Local Government Authorities

Their role is to verify that a disaster has occurred, to assess its in the area, and to notify the public through broadcast or Internet media, as well as to communicate with healthcare institutions, related professionals, and businesses in the local area about the alert level.

Media

These include traditional broadcasting services such as radios and televisions, as well as electronic media such as telecommunication services (especially SMS gateways) and Internet messaging services. They help the government authorities to broadcast disaster information to the public in a timely and accurately manner.

Hospitals

These are the primary consumers and resources requesters of this system after a disaster outbreak. Each of them also possesses a current level of different kinds of medicines and resources.

Healthcare Suppliers, Pharmacies, and Emergency Services

These are the primary providers of medicines, equipment, emergency services, and necessary supplies to support disaster remedies and recovery. For each supplier, the stock of required resources is always limited for each area. Similarly, emergency service equipment and personnel are also limited. The allocation of a certain amount of required resources from them is always related to the delivery time and capability/stock availability. Administrators working in these organizations sometimes request the supply levels of various items, so that they can adjust allocation in a timely manner and provide information about the supply level to consumers.

Mobile Individuals

These include members of the general public, ordinary citizens and victims, as well as expert level users in this system such as physicians and scientists. Experts and physicians may sometimes request information in order to make their professional assessment as well as initiate resource allocation requests. For example, physicians may request patient health history records and medicine; geologists may request geo-data for earthquake analysis. Note that especially in the case of the expert level users, requests may be communicated directly and individually as well as through their organizations.

Based on the above requirements, a system for the stakeholders requires timely notification of information about the disaster outbreak and access to the resource level of related parties. Moreover, the requested information needs to be transferred in a timely and correct manner in order not to delay the announcement of the disaster notification. Especially within and among highly populated areas, the Internet together with mobile devices (e.g., SMS) is the best choice to deliver such information. Therefore, the system needs to accommodate different platform and data format, and Web service is a good choice as the key unified technology.

In summary, the major functions of the DNRAS include the following: (1) It should provide aggregated information to queries about when the disaster has been happening together with the related information to other DNRAS systems; (2) It should maintain or cache a certain level of information, especially those records that are related to potential disaster outbreak; (3) Further to function 2, it should query the local parties about the resource levels that are available for allocation; and (4) As a notification system, it should notify nearby areas’ systems about possible disaster outbreaks according to the policy of the local authority.

Our research methodology follows the design research approach for information systems (Hevner et al. 2004). First, our awareness of the problem is motivated by these extended requirements. We start off our study by gathering the objectives and requirements of various previous disaster management projects, as well as studying the problems of real-life disaster cases and the ways that they were handled. We notice that recent advances in information technology are being deployed to provide support in this new, complex environment. One of the most prominent objectives is the need for accurate and timely communications among various parties involved in disaster management and handling. Based on this, detailed requirements were elicited and formulated.

Second, our suggested model is a conceptual DNRAS architecture based on the alert mechanism addressing these objective and extended from our previous work (Kafeza et al. 2004), as summarized in Fig. 2. The essence of alerts is to capture the urgency requirements as required by disaster management, so that timely actions in the DNRAS such as notification, information enquiry, and resource notification can be carried out to facilitate the overall disaster management processes and workflow. Our framework has the flexibility to include other customized intelligent actions when appropriate.

Fig. 2
figure 2

The role of alerts in the DNRAS for disaster management

Full size image

Third, the development of DNRAS started with a sketch of an overall system integration architecture (see Section 4), with a focus on the AMS. We then worked out the detailed mechanisms for each component of the system as well as the required AMS messages (see Section 5). In the design, we also had to pay attention to flexibility so that alert management policies could be adapted to handle various situations for various parties. According to these designs, we built a prototype to demonstrate the functions for evaluation.

Fourth, we present the evaluation of our approach based on a case study of the Toronto SARS outbreak (see Section 6), as well as a discussion on the benefits with major system stakeholders (see Section 7).

4 System architecture

Figure 3 shows the overall system architecture of MHCS based on our previous AMS core (Kafeza et al. 2004) implemented on the J2EE and Oracle platforms (Price 2002). We illustrate the mechanism of our system with a running example of an epidemic outbreak.

Fig. 3
figure 3

DNRAS system architecture

Full size image

When urgent communications are required for disaster management, the scheduler generates alerts with the necessary specification to the AMS. This approach separates the complex logic of communications management from the scheduler and normal workflows, which follows the models we proposed (Kafeza et al. 2004). Any subsequent processing that depends on the response or the result of external services has to wait until it finishes (as signaled by the AMS); otherwise the workflow can continue. On the other hand, functions from existing internal information systems can be triggered by the Process Execution Module of the AMS through the scheduler logic to carry out timely appropriate actions in response to incoming request alerts. In addition, the application logic supports an administrative Web front-end for the administrators.

To extend the accessibility for users on different platforms, eXtended Markup Language Stylesheet Language (XSL) technology is employed (Lin and Chlamtac 2000). For example, different Hypertext Markup Language (HTML) outputs are generated for Web browsers on desktop PCs and PDAs respectively, while WAP Markup Language (WML) outputs are generated for mobile phones. We can then build an alert response form for a tutor through WAP on a mobile phone and a PDA browser respectively.

As the AMS supports both the sending and responding of alerts for communications, a person or organization can be a service provider and requester through the DNRAS at the same time. The AMS consists of two major parts (see Fig. 4). Let us further explain how the AMS functions starting with when a disaster outbreak notification is received.

Fig. 4
figure 4

Typical life cycle of an alert in a UML activity diagram

Full size image

The Incoming Alert Monitor is responsible for receiving alerts and enacting the corresponding services (processes). In addition, the Process and Alert Definition module supports a tool, with which administrators may pre-define the tasks and their associated alerts according to the AMS model. For example, a disaster outbreak alert from the authorities in a neighboring city can trigger immediate programmed responses, because it is a reliable source with substantial information, such as disaster type, discovery time, urgency, severity, etc. However, when a citizen reports a disaster (say, a tsunami or severe explosion) through a call center, validation processes and triage processes are triggered instead. That means the alert triggers the appropriate handler workflows in the scheduler application logic through the Process Execution module. Such handler workflows can then generate outgoing alerts to the media, officials, hospitals, etc.

The Outgoing Alert Monitor subsystem is responsible for sending the alerts to the corresponding service providers (persons, programs, or organizations) and monitoring their responses. Human service providers (e.g., officials and experts) are communicated with using ICQ (Weverka 2001), SMS, and email too. In this way, a service provider supporting only manual interactions may still participate in data and process integration through an alert response form, through which the required response can be entered and sent to the requestor. For example, an administrator of a small hospital may enter a simple response through such a form (Chiu et al. 2008) to report its current spare capabilities with just a small delay.

The Outgoing Alert Monitor subsystem consists of three modules: the Urgencies Strategy Definition, the Role Matching, and the Service Provider Monitoring modules. The Urgencies Strategy Definition module enables the administrators to specify the policies that will be followed if the alert is not acknowledged within the deadline (e.g., send the alert to another official). The Role Matching module is responsible for identifying the service providers to which the alert will be forwarded (e.g., select a suitable official or expert “intelligently” as explained in the next subsection). The Service Provider Monitoring module is responsible for applying the strategies defined at the urgencies strategy definition by executing the actions specified by the administrators. Its functions include sending alert messages, receiving responses, maintaining alert status, and logging information. For every response message received, the Service Provider Monitoring module updates the status information of the associated alert, and tags the alert as “taken care of”. If the alert message has been sent to several service providers (e.g., officials or experts) for a very urgent request, those who confirm the earliest are assigned to the task while the rest will receive cancellation messages instead. Then for every alert in the active alert table with its deadline expired, the module checks the urgency strategy table, executes the associated action, and updates the status information accordingly.

Figure 4 shows a UML Activity Diagram depicting a typical life cycle of an alert (Chiu et al. 2008). All alert processing and messaging for an alert is logged (“Log alert” node) for auditing purposes. If the alert is a specific one (e.g., when the process requests enquiry with a specific official), there is no room for matchmaking. Otherwise, if the alert is a flexible one, a matching algorithm (“Find matching service provider” node) is invoked to search for suitable service providers (e.g., when ten physicians are requested). The “Determine device/web service access point” node determines the device for a human or the Web Service access point for a Web Services provider respectively. This feature accommodates future system advancement opportunities such as supporting agent-assisted communication and artificial intelligent based responses. Then, the “Send alert” node sends the alert accordingly. If the “Check if response received by deadline” node fails, the AMS will increase the alert urgency level, thereby triggering the alert message to be resent to either the same service provider or a different suitable one (as discussed in the next subsection). The last tolerance level is guided by “Check if service performed upon service due” node. If the service is not performed within a deadline (e.g., an official does not respond), then the AMS generates a new alert to the relevant administrator to notify this exception. In such a case, additional manual or system-assisted exception handling processes (Chiu et al. 2001) such as urgency elevation and disciplinary process can be carried out.

5 Alerts for disaster management

To illustrate further how the alerts help the timely integration of disaster management, Fig. 5 details the application logic of a DNRAS node. There are two major components running in a DNRAS node. One is the AMS, which responds to as well as requests from other DNRAS nodes. Another is the scheduler process, which fetches the request from the queue, sends out the required requests to other DNRAS (looked up in UDDI directories) via Web services, and processes the required information. In our DNRAS, we differentiate between four different types of alert requests as explained in the following subsections:

  • notification alerts, which attend to the verification and identification of the specific disease problem using medical information;

  • general information alerts, which inquires for general information;

  • resource alerts, which identify the place that can provide the requested information or resource; and

  • personal information alerts, which give information for a specific person.

Fig. 5
figure 5

System flow of a DNRAS node

Full size image

5.1 Notification alert requests

When a notification alert request such as an epidemic outbreak is received, the system returns the required notification data including the type of disaster notifications and the aggregated information in that area. The request formats in the R type and R con, are as follows.

R type

‘N’

R con

N dis

Disaster need to search for notification

 

N sym

Disaster description, including symptoms /?description of diseases (might contains multiple entries)

In the case of an unnamed epidemic outbreak, N dis can be set to Unknown Disease, using instead the parameter N sym to retrieve the notification records. Once the destination system receives the captioned request, the system searches the cached information database based on the disease name or symptoms. If the cached information contains the information requested, it aggregates the cases and returns the update response with the information below. If not, the request will populate via Web services to other DNRAS nodes to request more information, as described in the next subsection.

R type

‘N’

R con

N dis

Disease need to search for notification

 

N ara

Area that contains this request (might contains multiple entries)

 

N coun

The count of matched disease name or symptoms described (might contains multiple entries)

5.2 General information alert requests

For general information alert requests received via Web services, the requester should specify the type of information (typically a particular resource such as the storage level of a particular medicine) they require from the target database, the urgency of the request, and a request ID to identify the request. So, the parameters of the Web service include the following information.

R id

‘R’ + this request identifier

R time

Request life time in system

R type

Type of information required

R con

Request content (such as type of notification requested, resources matching parameters, information to match, etc.)

R pri

Request urgency

Upon receiving such a request, the Web services process puts it into a queue of the scheduler with the above information together with a time stamp so that the scheduler can maintain the life time of this request. This event also triggers the scheduler to acknowledge the requester via Web services about the queue insertion. The returned acknowledgement information is as follows.

A id

‘A’ + this acknowledgement identifier

R id

‘R’ + response identifier to ack

A time

Acknowledgement time

The scheduler checks for tasks that are ready for execution one by one in the queue. For each ready task, according to the request type (R type) from the task, different retrievals are performed based on the (R con) from the database. If the required information completely presents and matches the request, the scheduler aggregates the results, creates an update response to the requestor, caches the update information in the database, and removes the completed task from the queue. If the required information is incomplete, the schedule creates new entries in the queue to request the other DNRAS nodes to provide further information, and reschedule the current task in a time between 0 to R time based on priority of the request (R pri). An update response contains the following information.

U id

‘U’ + this update identifier

R id

‘R’ + request identifier

U con

The required information aggregated from the DNRAS node. A DNRAS node information will be included as well

5.3 Resource alert requests

When a resource request (such as medicine, ambulances, physicians, etc.) is received, the requester normally needs to know the availability level of items against a specific disaster or level of support for some certain operations. The format of the request is as follows.

R type

‘L’

R con

L nam

Resource information to be located

 

L sym

Minimum allocation requirements (might contain multiple entries)

As this request is a real-time query, the scheduler skips the cached information database. The query asks other DNRAS nodes in the area to look for the resource first. The scheduler waits until the deadline (based on R time) for the replies, aggregates them with the database information of the local DNRAS node for this resource, and returns the result to the requester. The returned information is in the following format.

R type

‘L’

R con

L dis

Resource information to be located

 

L ara

Area that contains this resources (might contain multiple entries)

 

L coun

The count of matched resource information described (might contain multiple entries)

 

L del

The delivery time for this resources (might contain multiple entries)

The returned information looks like very similar to the returned notification, but the most important thing here is that the system needs to take into consideration the delivery time L del of resources. This is because when a disaster occurs, the allocation and delivery of resources become critical factors in rescue operations. In the case of an epidemic outbreak, this is even more important in preventing the disease from spreading.

5.4 Personal information alert requests

Typical personal information requests include patient history records and information on suspected terrorists. We distinguish these from general information requests because they typically involve sensitive personal information. In this way, further privacy protection can be implemented in the next phase. Such information requests might concern the subject’s name, passport, local personal identification number, etc. For patient history record requests, the requested content might be a textual description of the patient’s symptoms, medical images of the patient, the applied medicine, operations, etc. The format of the query is as follows.

R type

‘P’

R con

P id

Subject ID information requested

 

P idtyp

This filed denoted type of P id (such as passport or local personal identification)

 

P his

Maximum history records to be retrieved

 

P img

Denoted if image to be retrieved or not

 

P inf

Subject information if available

Once the system scheduler receives this request, it will be forwarded to subsequent DNRAS nodes to search for the records based primary on the P id and P idtyp. The subsequent nodes will reply with acknowledgement that this request has been inserted into the queue. Then subsequent DNRAS nodes will search the cached information database to see if the patient records are available or not. If not, the DNRAS node continues to populate the request to other nodes once all the aggregation information has been returned. The DNRAS then aggregates such information and returns it to the requesting node. If an image is requested, P imgURL contains the Universal Resource Locator (URL) to the image download location. The returned information is in the following format.

R type

‘P’

R con

P id

Subject ID information requested

 

P name

This field will be inserted if P id cannot be located.

 

P inf

Subject general information (might contain multiple lines)

 

P imgURL

Denoted the image retrieval URL

 

Phis

Subject history records (might contain multiple lines)

5.5 ARNAS integration with web services

Suppose we have heterogeneous systems, each maintaining its own databases. To implement the DNRAS node into the system, we simply add a DNRAS node that runs the required Web services on top of the existing system for the integration. Let us illustrate some key Web services of the DNRAS node as follows.

DNRASRequestUpdate is responsible for information update into the DNRAS node database via the Web service request. The input parameters include the following.

U id

‘U’ + this update identifier

R id

‘R’ + request identifier

U con

The required information to be updated will be following by the different type described earlier

DNRASRequest is responsible for processing the request from other DNRAS node or the local user inquiries. The parameters include the following.

R id

‘R’ + this request identifier

R time

Request live time in system

R type

Type of information required

R con

Request content (Such as type of notification requested, resources matching parameters or patient information to match)

R pri

Request priority

5.6 Service provider matching and urgency strategies

The service provider matching module is responsible for searching a service provider (e.g., medicine provider) for each alert. The service provider matching algorithm (Kafeza et al. 2004) searches for those service providers that can play the role required by the alert (e.g., pharmacies and large hospitals with ample storage of the required medicine). The algorithm then selects those having a response time less than the deadline (e.g., by considering the distance from the outbreak location and their schedules in the system). This further restricts the set of service providers that can receive the alert. If the matching is successful, one service provider is selected according to an administrator-supplied cost function. The cost function can be based on the time required for service, monetary cost of the service or product, etc. In case inadequate matching is available (i.e., there exists inadequate service provision that can meet the deadline), the algorithm upgrades the alert by expanding the roles whenever possible (e.g., request the medicine from a nearby city). After the matching, an active alerts table keeps all instantiated alerts and the information whether the alert has been acknowledged or not.

If an alert is re-sent, the service provider for the matching algorithm will take into account the urgency strategy definition. The urgency strategy definition module is a tool for defining the policies according to which the urgencies of the alert will evolve. Moreover, this module is responsible for keeping and updating status information for the alerts. In our alert model, every alert is associated with an urgency value and a deadline, while every service provider is associated with an average response time for every service that it provides. During the specification phase, the administrator has to specify the urgency strategy tables. An urgency strategy table defines the policies for every urgency increase and the additional actions that should be taken. The administrator may define different urgency strategy tables for different types of alerts. For example, we could define the urgency values from the ordered set {Urgent, Very Urgent, Critical, Very Critical} and a default urgency function as follows:

$$U002\left( t \right) = \left\{ {\begin{array}{*{20}l}{{\text{Urgent}}} \hfill & {t \leqslant {\text{T }}\left( {{\text{default}}} \right)} \hfill \\{{\text{Very Urgent}}} \hfill & {{\text{T}} <t \leqslant {\text{T}} + {\text{dt1}}} \hfill \\{{\text{Critical}}} \hfill & {{\text{T}} + {\text{dt1}} <t \leqslant {\text{T}} + {\text{dt1}} + {\text{dt2}}} \hfill \\{{\text{Very Critical}}} \hfill & {{\text{T}} + {\text{dt1}} + {\text{dt2}} <t \leqslant {\text{T}} + {\text{dt1}} + {\text{dt2}} + {\text{dt3}}} \hfill \\\end{array} } \right.$$

Table 1 shows an example of an urgency strategy table. Here, let us consider the association of an alert with this table. The default level for the alert is Urgent. When the priority increases to Very Urgent because the selected pharmacy provides no response, the AMS creates another alert message to notify the pharmacy about the imminent deadline. If there is still no response, the AMS tries another pharmacy or hospital that has the best expected response time. If this step also fails, the priority further increases to Very Critical, where several pharmacies and hospitals will receive the alert, while an administrator is notified.

Table 1 Example urgency strategy table
Full size table

6 Lessons learned

In every disaster situation, disaster management is often overwhelmed by requests. In order to demonstrate the effectiveness of our approach and discuss the lessons learned, we further study a case concerning the Toronto SARS outbreak in 2003.Footnote 1

In the Toronto SARS outbreak, one of the problems that occurred was that when several relatives of the first victim were found to be suffering from related symptoms, the physicians of Scarborough-Grace hospital were not alerted to the possibility of an epidemic. They considered it a probable cluster of tuberculosis (TB) cases because such cases were common (400 per year in Toronto), and so, they just filed a report and sent it to the TB unit for investigation and follow up. A lesson learned is that delays in identifying the outbreak are vital and direct and efficient communication among different agencies is necessary. Although this was not a case of TB, several opportunities were missed to identify the epidemic nature of the disease.

Our DNRAS can contribute to minimizing such delays by automating some of the necessary processes for identifying an outbreak. Instead of filling out reports, a notification alert can be generated for the incidence. As such, all relevant information from the current database regarding similar cases as well as previous cases and patterns of the past can be retrieved and submitted to the appropriate experts through the AMS. A connection with other DNRAS nodes can retrieve relevant information from the corresponding databases, in which case other victims, who might have gone to different hospitals, can be identified. Aggregation of information then can take place and the notifications sent to the specified experts for diagnosis. In our example of the Toronto SARS outbreak, this would have resulted in a mismatch of information since the victims were suffering from SARS and not TB. In case the public health officers were not confident about the type of the disease, an unknown disease notification request could be submitted through the DNRAS.

Using our DNRAS, an alert could be sent to the public health office whenever a patient arrived at any hospital with suspicious symptoms similar to the previous cases. When the number of cases aggregated from the hospitals of a city reached a specific threshold, an alert for an epidemic disease could be propagated to the public health office of the region, as well as other neighboring cities. One of the lessons learned from the Toronto SARS case was that although the epidemic could have been constrained earlier, one major reason that it did not happen was that authorities were unwilling to close the hospital. A hospital is of major importance in a district and closing it has a lot of implications, not just psychological ones (for example the physicians were unable to cope efficiently with the problem), but also because of the lack of facilities for treating patients in the area. Hence, such an important decision could be easier made when the necessary information that indicated an outbreak epidemic is available in a timely and accurate manner. Our DNRAS can contribute in formulating such necessary evidence by aggregating, monitoring, and alerting information about possible outbreaks within specified time limits.

During the SARS outbreak in Toronto, one of the major issues that had to be addressed was the lack of isolation rooms, because isolation of the infected patient is of major importance for constraining the disease. However, when the outbreak occurred, the Carborough-Grace Hospital continued to transfer its patients to other hospitals regardless of the availability of isolation rooms. Moreover, during the outbreak, the entire Intensive Care Units (ICUs) of hospitals were quarantined for 12–14 days. Among the tertiary care university medical/surgical ICU beds and community ICU beds in Toronto, 38% and 33%, respectively, were closed at some point. Therefore effective communication and resource allocation is critical. Our DNRAS could coordinate such resource allocation automatically and in a timely manner by inquiring into the availability of such resources at other hospitals through alerts, and therefore could help schedule the transfers of patients for isolation. In addition, in epidemic outbreaks, delays in the decision and implementation of radical containment strategies are of major importance for controlling the disease. For example, when a hospital is sending out patients that might be infected, the availability of isolation rooms must be confirmed before the patient is sent since there is a danger of the infection spreading. The resource allocation alert should then be propagated with our alert mechanism until acknowledged.

Another lesson learned is that physicians require efficient and immediate access to personal information files related to an epidemic outbreak. Patient history records can connect the patient to existing known cases. For example, from the history of the second SARS victim who died in York Central Hospital, it was clear that he had also been admitted to the Scarborough-Grace Hospital emergency department observation unit, next to the first victim.

Overall, we can observe from this case that problems have stemmed from the lack of basic infrastructure for process and information integration. Currently, the gradual adoption of Web services could streamline such integration across heterogeneous organizations in a flexible way by creating an open and distributed system environment (Chiu et al. 2004; van der Aalst et al. 2007).

A further lesson learned is that information requests should be categorized structured, monitored, and associated with temporal deadlines. In this manner, efficient information retrieval, aggregation, and association might lead to an early diagnosis of the disease (see the future third phase of our project plan to include intelligence). Moreover, communications, exchange of information, and notifications are crucial. These are the aspects that our DNRAS system is addressing.

7 Applicability discussion

Based on the prototype and system descriptions, we have had discussions with the major system stakeholders, including government authorities, mobile individuals, and emergency service providers (hospitals and pharmacies).

The government authorities (particularly the public health office) are the primary stakeholders because the DNRAS helps to resolve the existing problems involved in the unreliable manual procedures required for disaster management effectively and efficiently. There is a strong need for automating the workflow because the processes involved are often urgent and error-prone. There are also many possible exceptional cases possible during disaster management such as the failure to find suitable personnel and resources, absence of personnel, lateness of actions, and so on. Such problems originate in the variety of parties and personnel that have to be liaised with. The relevant officials are first alerted to judge the impact of the disaster in their region. They can then request more outbreak information from the DNRAS of the source sub-node together with the required process support. The DNRAS also helps select and communicate with the local area service partners as detailed in the previous section to ensure the preparedness of all relevant parties. The AMS further keeps track of such alerts and therefore monitors the whole request in workflow processes in order to make sure that the required services and resources are provided on time, meeting the urgency requirements. Thus, the DNRAS node captures the request history and resources information and helps the coordinator of the system handle the resources correctly and timely.

With our platform support, we can further perform trials and simulations with relative ease and low costs with governmental support. Hospitals, clinics, emergency services, and supply partners can estimate the resources required to tackle the consequences of a disaster. Communications among various partners, especially those for humans, can be drilled. This could strengthen the overall preparedness to tackle disasters.

For broadcast and Internet media, their major role is to inform the public in case of a disaster. When a disaster notification is received via the DNRAS, the DNRAS help deliver the outbreak information correctly to the media and broadcast it to the public immediately. This avoids delay and incorrect information that might cause confusion to the public. This could greatly facilitate extremely urgent evacuations such as those in the event of volcano eruptions and tsunamis.

For resource holders such as hospitals, pharmacies, and emergency services, their major role is to cooperate with the government authorities to carry out disaster remedies. To address this, one of the most important issues is how fast the rescue and recovery can start and how soon the resources can be delivered correctly. With the DNRAS, resource holders can easily be located so that resource calculation and delivery time estimation can be predicted more accurately. The DNRAS also helps coordinate in the delivery of casualties and patients to the right location with resource estimation based on the information provided from hospitals and clinics (Ng and Chiu 2006). The DNRAS also helps allocate resources for the priority of the disaster area and prevent the rescue timeframe from being too long. Without a coordination mechanism like our DNRAS, each resource holder will have to carry out actions or make decisions individually without coordination or knowing the overall requirements of the region, and ineffectiveness and inefficiency will become inevitable. Hospitals play an extra role in providing timely information for verifying an epidemic outbreak through the DNRAS.

For healthcare professionals, accurate, complete, and timely information routing also helps the recovery process from a disaster. The DNRAS provides a paperless distributed environment that minimizes human intervention and therefore improves accuracy and timeliness. With our approach, all the data accesses are performed through alerts. The DNRAS can therefore ensure that only the necessary personnel and resources are involved in the process because the matchmaking mechanism suggested in the AMS (Kafeza et al. 2004) verifies the roles of the service providers for the alerts. In the case of an epidemic outbreak, the scattered patient records can be sent directly to the control center for outbreak analysis with this platform (similarly for the analysis of suspected terrorists). Thus, the privacy of investigated subjects can be protected. Further, because all such data access is recorded via the alert mechanism, auditing can be easily performed against possible misuse.

For mobile individuals, the AMS automates such communications via various electronic channels and attempts to communicate with alternate service providers (government officials and expert personnel via various mobile platforms as well as different service partners via Web service) in order to minimize the delay and costs involved in inefficient manual calls and retry calls. This facilitates multiple-channel notifications to the public, which Botterell & Addams-Moring (2007) have suggested.

As for adoption, a major problem in migration to the new system is that partner service providers may not be supporting Web Services or even computerization for some tasks. As our system architecture supports individual users to be alerted, the personnel of the service provider as well as individual professionals can request and reply information through the interactive Web-based front-end of a simplified standard DNRAS node software. As organizations are moving towards service-oriented models, service providers currently do not consider that such computerization will eventually need to do so. In addition, they will eventually realize the value of such systems. Moreover, the proposed external Web services interfaces are not complicated at all and can be easily programmed for alert reception and delivery. Moreover, such a DNRAS is light-weight, highly coherent, and loosely coupled with other sub-systems, enabling it to be plugged into any information system that needs such services. Besides routing alerts to external service providers, the DNRAS can also route alerts to other DNRAS within a large organization, such as a major hospital. They are orchestrated by Web Services technology to work together seamlessly in the organization and even cross organization boundaries to partner service providers. This architecture is highly scalable and interoperable. As such, upgraded systems can provide alert support through a DNRAS gradually for adequate testing and streamlining the switch-over, which may otherwise be impossible involving a large number of participants in a service grid (Gentzsch 2002).

8 Conclusion

In this paper, we have presented an architecture of DNRAS, which supports alert notification and resource allocation in the event of a disaster. The DNRAS can provide the necessary information quickly via cached information in the node and nested query requests to aggregate information required to handle the disaster. We have also employed alert mechanisms as a unified platform for the coordination of various functions at various stages of a disaster outbreak, including detection, notification, remedy, and recovery. As such, the alert management system (AMS) supports communications of both human (e.g., physicians) and Web Services (e.g., supplies partners) providers. Such DNRAS can be built and plugged into the existing infrastructure of various stakeholders to bridge internal systems and external partners to form a grid (Gentzsch 2002). Therefore, this architecture is also scalable to provide a more efficient way to deal with the disaster outbreak and global resources control via inter-DNRAS communications.

The introduction of the alert mechanism offers several important advantages and distinguishes our research work. (1) It ensures that an alert can reach the node that has to be notified with monitoring support. (2) The inclusion of multiple platforms helps both human (such as officials and experts) and supply partners to integrate into the DNRAS platform. (3) The implementation of an urgency policy that uses concurrently multiple devices to communicate the alert can increase the probability of informing the critical node on time. (4) An automated alert can make sure that the information is passed accurately and completely. (5) The DNRAS allows the choice of received information, reception devices, and desired time slots by controlling the scheduler active time.

Further, we employ Web services as the key enabling technology. This is highly applicable because of following reasons. (1) The integration progress is easier because Web services are supported on different platforms. (2) As the Internet is 24 × 7 available, Web services platforms provide a faster and more accurate notification process than using human communication, especially when there is a major disaster, electronic data communication is more reliable to transmitting the large amount of information instead of human communication, and increase the data integrity. (3) Different data formats are employed in government, hospitals, clinics, and supply partners. One of the best ways to import and integrate the data into the DNRAS is via XML with XPATH/XQuery (Lin and Chlamtac 2000) to select and transform the necessary data. The data conversion process is simplified without modifying the existing systems, thus minimizing the implementation costs. (4) During data import into the DNRAS databases, validation can be facilitated with XML Schema, simplifying the data validation progress without the need for extensive client-side programming.

In summary, the contribution of this study lies in its novel approach to flexible workflow management using Web service technology and alert management system for disaster handling. By integrating Web services with alert-driven communication and resource allocation for flexible process orchestration, this approach leads to more intelligence, flexibility, and collaboration in disaster management. The benefit offered through Web service technology and alert-driven process orchestration includes:

  • System integration: Through Web service-based data communication and system integration, the system for flexible process orchestration in disaster management is able to integrate with legacy applications.

  • Communication and Monitoring: the DARNS infrastructure provides an interoperable system architecture for creating an efficient communication and monitoring infrastructure in order to respond to disasters efficiently.

  • Intelligence: Complex disaster problems can be identified and diagnosed in a timely way by alert-based data communication and information aggregation, and can be handled through flexible resource allocation and process orchestration.

  • Scalability: It is easy to extend the system by adding more web service based functionalities into each node of DNRAS to improve data communication and process coordination.

  • Reusability: The proposed architecture and Web services are reusable by other applications for flexible process orchestration in disaster management.

As for deployment, we plan to split it into phases. The first phase,now ongoing, is to establish the application to handle epidemic outbreaks. The conclusion of the first phase will lead to better experience and fine tuning of the alert management policies. In the future, the second phase will be to extend the system to handle other types of disasters such as major accidents (Ng and Chiu 2006), terrorist attacks (Wong et al. 2008), and natural disasters. In the third phase, we plan to include further intelligence into the system, in particular, with advanced capability reasoning (Chiu et al. 1999), scheduling with mobile location dependent information (Hong et al. 2007), service negotiation (Chiu et al. 2004b), and integration with traffic routing (Ng and Chiu 2006).

As for future work, privacy control of personal records preventing information abuse is our primary concern. We are exploring various settings of the urgency tables in cooperation with the administrators. We are also investigating the application of context-awareness in ubiquitous communication management, based on our experience in enterprise services (Hong et al. 2007). Moreover, the complexity involved in the communication processes will be further analyzed and managed based on an adaptive approach to complex process management in dynamic situations (Wang and Wang 2006). On the other hand, we are also interested in further possibilities in user communication management with agents (Chiu et al. 2003a, b). We are also interested in the impact of cancellations, other possible exceptions, and the tradeoff between quality and costs. On the other hand, an e-negotiation subsystem is required to provide an efficient way for negotiating the costs and allocation of resources during supply shortage (Chiu et al. 2004b). System dependability, such as redundant connection links and nodes, are also interesting research issues in this information systems frontier.