AlertsHICSS37-1 Alert-driven E-Service Management Dickson K.W. Chiu, Benny Kwok, Ray Wong Dept. of Computer Science & Engineering, Chinese University of Hong Kong {bennykok2000, S.C. Cheung Dept. of Computer Science, Hong Kong University of Science & Technology Eleanna Kafeza Department of Marketing and Communications, Athens University of Economics and Business

AlertsHICSS37-2 Introduction E-services - Commercial activities, value-added services provided over the Internet Highly competitive and dynamic Response actively and timely to customers’ needs – key success factor for the provision of quality services Processes integration with stringent urgency requirements - healthcare and security applications Alerts - urgent requests and critical messages Alert Management System (AMS) Routing, monitoring, and logging the alerts Find suitable service - application specific considerations like costs, waiting time, service time For both B2B and B2C applications

AlertsHICSS37-3 Case Study – Medical House-call System Both human and computerized systems involved Different degree of computerization Web Services supports both type of interaction in a single framework

AlertsHICSS37-4 Advantages and Problems Solved Capturing knowledge and experience of admin staff Avoid errors and help handle exceptions Automates call center which is a bottleneck in the whole E-service process User can request house call via Web, mobile devices, and even an emergency button Service personnel receive from or reply to the system via different channels (SMS, PDA, ICQ) Automatic retry of calls Medical partners and hospitals form a service grid

AlertsHICSS37-5 Role of Alerts in Information Systems What are Alerts? Different from general events, alerts have more specific attributes, e.g., urgency and service requirements. Different from exceptions, they need not relate to abnormal behaviors. asynchronously received by external events / exceptions, incoming E-service requests synchronously generated by internal E- service application. handled by the AMS by requesting services: internal information systems human service provider external E-service providers E-Service Application Logic (J2EE/WFMS/…) Alerts (AMS) Events / Exceptions (Web Services)

AlertsHICSS37-6 Alert Conceptual Model

AlertsHICSS37-7 Alert Life Cycle

AlertsHICSS37-8 Alert Urgency Strategy Definition Defining the policies according to which the urgencies of the alert will evolve Example Urgency002Action Urgentdefault Very UrgentSubmit a second alert to the same service provider, notifying about the approaching deadline CriticalRedirect the alert to another SP that has the best response time Very CriticalSend the alert to several SPs and accept the results of the one that response first, notify an administrator

AlertsHICSS37-9 Service Provider Matchmaking Algorithm searches for those service providers that can play the role required for the alert Selects those that have a response time that is less than the deadline If the matching is successful, one service provider is selected according to a user- supplied cost function In case no matching is available, the algorithm upgrades the alert by expanding the roles whenever possible

AlertsHICSS37-10 Main Web Services Implementation Service Name (Provider): requestAlert Input: AlertID, RequestorID, AlertMessage, Roles, Urgency, ResponseRequired ( TRUE | FALSE ), Deadline Response: AlertID, ServiceProviderID, Ack (Confirmed | Denied | Deferred), ResponseMessage, AlertReceiptTime Service Name (Provider): cancelAlert Input: AlertID, RequestorID Response: Ack (Confirmed | Denied | Deferred ) Service Name (Requestor): receiveDeferredResponse Input: Item AlertID, ServiceProviderID, ResponseMessage, AlertReceiptTime Response: Ack (Confirmed, NotConfirmed )

AlertsHICSS37-11 Implementation Architecture

AlertsHICSS37-12 Sample Screen – Alert Ack

AlertsHICSS37-13 Sample Screen – Doctor Selection

AlertsHICSS37-14 Sample Screen – Status Monitor

AlertsHICSS37-15 Advantage of an AMS The urgency requirements, associated interactions with service providers, and the monitoring required by the administrators can be systematically and modularly captured into an AMS, instead of scattering around in the main workflow specification. The logic for sending, routing, and monitoring these alerts is supported in the AMS and can be heavily reused. AMS evolves from the exception handling and user-interface mechanisms of our ME-ADOME WFMS, by factoring out and extending, in particular, urgency requirements. Physical execution of individual tasks of regular processes is outside the scope of the AMS and is in capture in the application logic of individual information systems which can be a WFMS as well An AMS is light-weight and highly coherent, but loosely coupled with other sub-systems, enabling it to be plugged into any information system that needs such services

AlertsHICSS37-16 Conclusions  A conceptual model for specifying alerts based on the requirements of cross-organizational processes and a set of routing parameters  A practical architecture for the AMS based on contemporary Web Services – supports human and programmatic interfaces  An algorithm for matching service providers to alert requirements  A mechanism for (re-)routing alerts and increasing their urgency when alerts are not acknowledged or processed within deadline.  Flexible and reusable AMS can be plug into other systems

AlertsHICSS37-17 Future Work  Healthcare process and data integration  Interfacing and platform-specific issues  Location dependent applications  Workforce management  Mobile CRM  Inter-relations among alerts.  Failure of commitments and their relation to contract enforcement  Impact of cancellations, other possible exceptions  Tradeoff between quality/response time and cost, and service negotiation

AlertsHICSS37-18 Q&A Thank you!

AlertsHICSS37-19 AMS Architecture