Alerts HICSS37-1

Alert-driven E-Service Management

Dickson K.W. Chiu, Benny Kwok, Ray WongDept. of Computer Science & Engineering,

Chinese University of Hong Kongkwchiu@acm.org, {bennykok2000, digitalray}@yahoo.com

S.C. CheungDept. of Computer Science,

Hong Kong University of Science & Technology scc@cs.ust.hk

Eleanna KafezaDepartment of Marketing and Communications, Athens University of Economics and Business

kafeza@aueb.gr

Alerts HICSS37-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

Alerts HICSS37-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

Nurse / Helper

DoctorPatient

Make House Call

Find Doctor for Notification

Confirm Doctor and Patient

Report Absence of DoctorHandle Absence of Doctor

Find Administrative Staff

Payment

Find Nurse / Helper

Request Help

Finish Consultation

Send Information

Update Doctor Status

Call Center

Administrative Staff

Report Updated Status

Alerts HICSS37-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

Alerts HICSS37-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)

Alerts HICSS37-6

Alert Conceptual Model

Schedule

Devices

*

1..*

*

1..*

Response

Role

Service Provider

11..* 11..* 0..n1 0..n1

1..*1..*

Capability Profile

Task

1..n

1

1..n

1

require

Alert

0..1

1

0..1

1

1..*

0..*

1..*11 1..*

0..*

1..*

associate

request

Alerts HICSS37-7

Alert Life Cycle

Send alert

Log Alert

Check if response received by deadline

Check if service performed upon service due

Find matching service provider

Generate new alert to admin staff

[ no ]

Increase Alert Urgency

[ no ]

Determine device / web service access point

[ yes ]

[ yes ]

[ flexible task ]

[ specific task ]

Alerts HICSS37-8

Alert Urgency Strategy Definition Defining the policies according to which

the urgencies of the alert will evolve Example

dtdtdtTdtdtT CriticalVery

dtdtTdtT Critical

dtTTt Very Urgen

(default) T Urgent

)(002

32121

211

1

t

t

t

t

tU

Urgency002 Action

Urgent default

Very Urgent Submit a second alert to the same service provider, notifying about the approaching deadline

Critical Redirect the alert to another SP that has the best response time

Very Critical Send the alert to several SPs and accept the results of the one that response first, notify an administrator

Alerts HICSS37-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

Alerts HICSS37-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 )

Alerts HICSS37-11

Implementation Architecture

Database

ApplicationLogic

Alert Management

System

Web / WAP Access

Web Service Server

XSLT ProcessorWeb Front-end

Web Services Programmatic

Access

Public UDDIRegistry

Triggered Action

Alert Input

XSLT Style Sheets

Desktop Laptop PDA Mobile

Patient Doctor Nurse/Helper

Call Center

Administrative Staff

HospitalsMedicalPartners

Internet

Medical House-Call System

Alerts HICSS37-12

Sample Screen – Alert Ack

Alerts HICSS37-13

Sample Screen – Doctor Selection

Alerts HICSS37-14

Sample Screen – Status Monitor

Alerts HICSS37-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

Alerts HICSS37-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

Alerts HICSS37-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

Alerts HICSS37-18

Q&A

Thank you!

Alerts HICSS37-19

AMS Architecture