Alert Based Disaster Notification and Resource Allocation

1. Alert Based Disaster Notification and Resource Allocation Dickson K.W. Chiu Senior Member, IEEE kwchiu@acm.org, dicksonchiu@ieee.org Drake T. T. Lin, Eleanna Kafeza, Minhong Wang,Haiyang Hu, Hua Hu, Yi Zhuang

2. Introduction • Disaster increasing frequency and severity • epidemic outbreaks, natural disasters, major accidents, terrorist attacks … • SARS, Avian flu, tsunami, … • IS for disaster management badly required • Unified framework for supporting all phases and activities • different prediction, detection, and specific handling activities • variety of organizations and personnel • heterogeneous physical and information resources • dynamic process and information integration approach • human and system interactions • resource allocation under urgency constraints • timeliness in action • Disaster Notification and Resource Allocation System (DNRAS) • Based on Alert Management System (AMS)

3. Example: epidemic outbreaks • SARS, Avian flu, … • Retrieve and analyze related patient records • Monitor symptoms and patterns of spreading • Records by fax or e-Mail result in mis-interpretation • Serious consequences • Timely notification - nearby countries • Resource allocation • Medicines and equipment • Medical professionals • Many parties in the interactions and negotiations • Many estimations and uncertainties

4. Requirements Overview Sales Reporters Storage Storage NotificationInformation Physician Physician Hospitals Emergency Services Administrators Local Government Authorities • Both human and computerized systems are involved • Stakeholders have different degree of computerization • Web Services supports both type of interactions in a unified framework Notification information Storage Pharmacies /HealthcareSupplies Broadcast /Internet Media Internet & mobile devices Mobile Individuals Public/Victims Experts Officials Physicians Administrators

5. Role of Alerts in Strategic IS / DSS What are Alerts? • Different from general events, alerts have more specific attributes, e.g., urgency and process requirements. • Different from exceptions, they need not relate to abnormal behaviors. • asynchronously received through business events / exceptions / incoming requests • synchronously generated by internal business application • handled by the AMS by requesting services from: • internal information systems • management / human attention • external e-Service providers • 3R – Retry, Reroute, Reassign

6. System Architecture

7. Alert Life Cycle

8. System flow of a DNRAS node Fetch next queuing request DNRAS Scheduler Application Logic Update response Information request Find the required information Update the information Generate and queue in cached database to cached database required request Information complete Information not complete Aggregate the results Reschedule the request Receive request alert Send request alert Return an update response to Send acknowledgement from other DNRA node to next node the request node Response Alert ManagementSystem

9. Defining the policies according to which the urgency of the alert will be “elevated” Example Alert Urgency Elevation

10. Web Services Summary • Notification alerts - attend to the verification and identification of the specific disease problem using medical information • General information alerts - inquires for general information • Resource alerts - identify the place that can provide the requested information or resource • Personal information alerts - give information for a specific person. • Database query / update Web services. • See paper for detailed parameter examples.

11. Advantages of Web services • System integration - flexible process orchestration in disaster management is able to integrate with legacy applications. • Communication and Monitoring - theDARNS 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 - 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.

12. Lessons Learned • Studied Toronto SARS outbreak 2003 case. • Scarborough-Grace hospital were not alerted to the possibility of an epidemic when several relatives of the first victim were found to be suffering from related symptoms and just considered TB • Delays in identifying the outbreak are vital. • Direct and efficient communication among different agencies required. • When 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. • Lack of isolation rooms – ICQ quarantined for 12–14 days. • But continue to transfer patients to other hospitals!! • Effective communication and resource allocation is critical

13. Lessons Learned (2) • Physicians require efficient and immediate access to personal information files related to an epidemic outbreak. • Second SARS victim died in York Central Hospital had been next to the first victim in Scarborough-Grace hospital. • Information requests should be categorized structured, monitored, and associated with temporal deadlines. • Efficient information retrieval, aggregation, and association might lead to an early diagnosis of the disease • Communications, exchange of information, and notifications are crucial.

14. Applicability Discussion • Government authorities • Resolve existing problems involved in unreliable manual procedures • Handle exceptions • Liaise with variety of parties and personnel • AMS monitors / tracks such alerts • Trials and simulations • Emergency service providers (hospitals / pharmacies) • Fast rescue and recovery • Locate resource holders for quick delivery • Decision coordination • Mobile individuals (healthcare professionals) • Ensure necessary and correct personnel involved • Records / information retrieval • Improved communications

15. Summary • DNRAS, which supports alert notification and resource allocation in the event of a disaster • Cached information in the node and nested query requests to aggregate information • AMS for the coordination of various functions at various stages of a disaster outbreak, including detection, notification, remedy, and recovery. • DNRAS can be built and plugged into the existing infrastructure of various stakeholders to bridge internal systems and external partners to form a grid • Improved information and process management

16. Future Work • Privacy control of personal records • Exploring various settings of the urgency tables • Context-awareness in ubiquitous communication management • Complexity involved in the communication processes • user communication management with agents • Failure of commitments and their relation to contract enforcement • Impact of cancellations, other possible exceptions • E-negotiation subsystem for negotiating costs and allocation • System dependability, such as redundant connection links and nodes

17. Q&A Thank you!