Alerts for Healthcare Process and Data Integration - Semantic Scholar

Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Alerts for Healthcare Process and Data Integration+ Dickson K.W. Chiu1, Benny W. C. Kwok1, Ray L. S. Wong1, S.C. Cheung2, Eleanna Kafeza3, Marina Kafeza4 1

Department of Computer Science and Engineering, The Chinese University of Hong Kong 2 Department of Computer Science, Hong Kong University of Science and Technology 3 Department of Marketing and Communications, Athens University of Economics and Business 4 Pepagni University Hospital of Iraklion and Medical School, University of Iraklion, Crete, Greece email: [email protected], [email protected], [email protected], {bennykok2000, digital_ray, mkafeza}@yahoo.com

Abstract In healthcare chain workflow management, urgent requests and critical messages in these systems (referred to as alerts) have to be delivered and handled timely. Presently, most systems cannot address urgency and alerts are often handled in an ad-hoc manner. In this paper, we propose a sophisticated alert management system (AMS) for effective healthcare chain workflow management under urgent constraints. We develop a model for specifying alerts, in which alerts are associated with healthcare tasks and a set of parameters are captured for their routing and urgency requirements. Further, alerts also serve as a mechanism for both process and data integration. The AMS matches the specialties of healthcare personnel and functionalities of Web Services providers to receive an alert, based on the alert specification. We then propose a routing mechanism that is initiated when the alert message is not acknowledged or serviced within the deadline, so that the alert can be re-routed if necessary. Monitoring is especially essential to ensure timeliness and availability of services, otherwise suitable exceptions should be raised and handled. We outline our implementation framework with Web Services for communications among healthcare service providers and mobile devices for medical professionals. We demonstrate the applicability of our approach with a pilot prototype medical house-call system (MHCS) with evaluations of medical professionals.

1. Introduction In healthcare chain workflow management, both process integration and data integration among health service providers are vital. Besides organizations, individual practitioners (such as doctors and nurses), administrators, and patients are also involved heavily in the workflows. Tasks +

like medication monitoring, emergency hospitalization of patients, laboratory examination results, shipment of drugs, exchange of patient records among healthcare service providers, etc., produce large number of messages. That is, both process integration and data integration are necessary. Timely communication of accurate information is a key success factor for the provision of quality healthcare chain services. We refer to these urgent messages as alerts. Existing practice of using cellular phones and pagers for communications is not adequate for seamless integration with existing and future healthcare information systems. Recent advances in Internet technologies have created a global platform for organizations and individuals to communicate among one another, carry out various commercial activities, and provide value-added services. Web Services [12][23] provide loosely-coupled standard interfaces among autonomous systems within and among organizations in the form of a set of well-defined functions for both programming and human user interfaces. In particular, Web Services support event-driven information integration for timely service provision and interaction [4] For end users, the use of Personal Digital Assistants (PDA) and mobile phones for ubiquitous computing are getting popular [1]. Previously mainly just for storing addresses, scheduling and organizing tasks, these devices can now support for Internet accessibility with recent advancement of mobile technologies. In addition, new mobile “smart devices” featured with different software and hardware capabilities, such as Wireless Application Protocol (WAP) and Short Message Service (SMS)[17], are kept introduced into the market. When these mobile devices are used in a healthcare environment, they are called mobile healthcare computing devices (MHCDs). The use of MHCDs is becoming part of daily life, thus making ubiquitous computing a possibility for healthcare envi-

This work was supported by the Hong Kong Research Grant Council with an Earmarked Research Grant (HKUST 6170/03E).

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

1


ronments as well. Awareness, accessibility, and responsiveness are the key relationships between clients and organizations in the world of ubiquitous computing [11]. In particular, healthcare applications must respond actively and very timely to patients’ needs as this is crucial to life or death. Most healthcare alerts have to be handled within a time period. There are several issues to be considered in this problem. The alert model should include various alert types and parameters that qualify the service provider to receive an alert. Apart from service suitability, application specific considerations like costs, waiting time, service time, etc., may also be important. In addition, routing, monitoring, and logging the alerts are also mandatory functionalities, in order to shift the burden of these communications from the manual work to an automated system. To take advantage of the connected Internet environment, we propose an alert management system (AMS) as the key driver software module for healthcare process and data integration with urgency support in this paper. The AMS aims to minimize delays by providing a monitoring system. This paper generalizes and extends our previous work on workflow modeling [7], process integration [4], and contract enforcement [3]. The contributions of this paper are as follows: (i) an enhanced conceptual model for specifying alerts based on the requirements of healthcare chain workflow management and a set of routing parameters; (ii) alerts as a unified mechanism for capturing requirements of both healthcare process and data integration; (iii) a practical architecture for the AMS based on contemporary Web Services for programmatic interactions, together with multipleplatform support for human users; (iv) a mechanism for (re-)routing alerts and increasing their urgency when alerts are not acknowledged or processed within deadline, (v) a practical pilot prototype to demonstrate the applicability of our approach in healthcare chain workflow management. The rest of our paper is organized as follows. Section 2 discusses an overview of our methodology and the requirements for a medical house-call system (MHCS). Section 3 compares related work. In section 4, we describe our alert conceptual model that captures both data and process integration requirements, for both human and Web Services providers. Section 5 presents the system architecture for our MHCS, highlighting the AMS and its mechanisms for monitoring and routing the alerts. Section 6 discusses the applicable of our alert mechanism based on our case study. We conclude in section 7 with our future work.

2. Background and Methodology Overview In Hong Kong, there are some healthcare corporations providing on-call service called “House Call”. Patients can call their affiliated healthcare corporation and request for doctor consultation at their homes. When the call center of

the healthcare corporation receives a call from a patient (either electronically or by phone), they will arrange a doctor to perform the consultation immediately, or to make an appointment for the consultation at the patient’s requested time. The patient may also request to be sent to a hospital and consult a doctor there. The patient may specify a doctor. Otherwise, the call center finds a doctor with the required specialties (if any) from a list of off-duty doctors first, then from a list of on-duty doctors, and lastly, from a list of doctors from healthcare partners. In some cases, the system may also need to find a nurse to assist doctors to carry out the consultation. When the required personnel are found, the patient will be confirmed. At the same time, the patient’s healthcare records may be required to send from hospitals and other clinics to the doctor’s mobile device. After the consultation is finished, the doctor submits a healthcare report for the consultation together with any prescription. The prescription is routed to a pharmacy so that the medication can be delivered (by courier service) to the patient’s home. Lastly, the patient or his/her insurance company is charged for the consultation. Motivated by the general lack of alert management systems, we start off our study by gathering the objective and requirements of the medical professionals and the medical house call service providers. Nowadays, the progress in the medical field has resulted in the hyperspecialization of the doctors, the introduction of new and advanced types of examinations and processes, and the increasing request of the patients for better quality of medical care. At the same time, recent advances in information technology are being deployed to facilitate this new complicated healthcare environment. One of the most prominent objectives is the need for accurate, safe, and continuous communications among highly specialized medical professionals and healthcare service providers. There has been a great demand amongst the medical professional for an alert management system that is robust, efficient, cost effective, simple, and user friendly to improve the communications. Based on these objectives, detailed requirements were elicited and formulated into an alert conceptual model. Then we sketched an overall system architecture for the call house management system, with focus on the AMS design. We then worked out the detailed mechanisms for each components of the system. In the design, we also have to pay attention to flexibility so that alert management policies could be adapted to handle various situations for various partners. According to these designs, we built a prototype to demonstrate the functions to the medical professionals for evaluation. As for deployment, we plan to split it into phases. The first phase is to establish a computerized call center to manage all the alerts for medical personnel, replacing the current manual system. After getting used to the new ar-

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

2


rangements and fine tuning of the alert management policies, the second phase is to extend the system to connect to medical partners. In the third phase, we plan to include further intelligence into the system, in particular, with advanced capability reasoning [7], scheduling with mobile location dependent information, service negotiation, integration with traffic routing.

Figure 1. Stakeholders of a Medical House-Call System

Figure 1 summarizes the stakeholders of the Medical House-Call System (MHCS). The system must be designed specifically to match the need and interest of each stakeholder as follows: Patients – The primary need of the patients is to have quick response to their call and timely house-call service with healthcare professionals of the required specialties. If there are suddenly too many calls, phones may not be able to get through. In additional to phone, patients may want to request house call via the Internet through different devices. Besides through a browser on a PC, patients may call through other mobile devices. In addition, patients with long-term sickness can also call via pre-programmed devices with a simple interface (such as just an electronic button). Call Center – Costly manual procedures have many problems in providing quality services effectively and efficiently. Call center staff members require a lot of knowledge and experience in order to handle patients’ calls correctly and timely. There is a strong need for automating the workflow. Their knowledge and experience should be captured by the system. This is because the process is often urgent and error-prone, and there are many possible exception cases, such as, failure of finding suitable personnel, absence and lateness of the personnel, etc. The main operational problem is that there are so many other parties and personnel to liaise with. The correct personnel have to be communicated through their available channel at the correct location with the correct information. Once they have committed to service a call, the call center has to satisfy their information need (in particular electronic patient records), together with required process support. The call center also has to make

sure that the required service is provided on time. Thus, the call center wants to access service personnel via various electronic channels, such as, SMS, email, fax, Personal Digital Assistant (PDA), I seek you (ICQ) [31], etc., in order to minimize costly and inefficient manual calls and retry calls. Doctors and nurses – Doctors need good assistance in their time and schedule management anywhere anytime. This is also helpful for nurses. Apart from the details of a call (such as the location, patient’s symptom and equipment required), doctors need complete and accurate patient records, which is often even more difficult during house-calls. Doctors also want the house-call to be recorded in his patient record database. Besides, they have to communicate with many other parties (such as the call center, hospitals, their own clinic, etc.) for support. Ambulances – Ambulances also need details of the call and key patient records. In particular, they need mobile device support to receive the information. Doctor’s Clinics – Doctor’s Clinics provide base support to doctors and host their small healthcare information system for their patients’ clinic record. Pharmacies – Pharmacies want the prescription to be sent electronically to them for more accurate service and integration into their inventory systems. Hospitals - Hospitals hold patient records. They need the details of the call and preferable a more complete patient history in order to triage the patient as soon as they arrive. Healthcare partners and insurance companies – Healthcare partners also operate call centers and therefore have similar objectives. Insurance companies want the call centers to operate efficiently, thereby reducing their expenditure eventually. In particular, a patient’s insurance company has all his/her claim records and therefore a complete patient history can be constructed electronically by checking all the healthcare services consumed by the patient. In summary, the overall characteristics of the MHCS requirements are as follows. All the stakeholders want their systems to be mutually interoperable, but in a secure, expandable and timely manner. As such, they can form a service grid [12] to cut down operation costs and expand service opportunities. Service requests involve processes requests (e.g., to attend house-call) and data requests (which mainly involve in data integration of patient records). Some requests may have a single specific target (e.g., a patient’s family doctor, or a particular data source) while some others allow for flexibility in matchmaking (e.g., a doctor with certain specialties). Both human and computer systems are heavily involved in the grid. In addition, both manually and automated processes should be supported to allow for gradual migration and maximized chance of participation into the service grid. Automated processes are often heterogeneous and loosed coupled.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

3


Further, the main characteristic of this kind of service gird is that timeliness and urgency is much more important than ordinary business-to-business interactions. As detailed in the next section, we encapsulate the essences of all these requirements into an alert conceptual model.

3. Related Work Raghupathi et al. [26] point out that information technology (IT) is important to healthcare and the estimated IT expenditure on healthcare in 2002 is 21.6 billions in the United States. New healthcare applications supporting ITbased strategy are required for meeting competitive challenges. Ammenwerth et al. [1] also report that one of the major issues that mobile technologies can help in hospitals is communication and reachability management. Communications that include the patient, the message sender, and the urgency are useful. Hripcsak et al. [15] preliminarily identify the need for event monitors, and describe some of the requirements of such monitors, such as, tracking healthcare events, looking for clinically important situations, and sending messages to the providers. Eienstadt et al. [10] further categorize messages as alerts, results, and replies [10]. The limitation of their approach is that they only focus on alerts that can be handled by 2-way pagers. Ride et al. [25] argue that the problem of figuring out to whom the message should be sent is a difficult one. They only suggested some ad hoc solutions, e.g., sending a message to whoever has recently examined the patient electronic record. Applying workflow technologies in health administrative data integration have been discussed in health informatics communities (e.g., “International Medical Informatics Association” [17] ) for a period of time. For example, Marsh [20] presents a multi-model medical information system for demonstrating the virtual medical world. Takeda et al. [29] present a system architecture for supporting networked electronic patient records. Similarly, Liu et al. [19] propose a web-based referral information system for sharing electronic patient records based on XML. Further, Grimson et al. [13] 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. However, none of these approaches provides a seamless integration that permits the use of workflow technologies or alert mechanisms. Suomi and Tähkäpää [30] study the requirements of a contact center for public healthcare with a case study in Turku, Finland, and point out that contact routing is the main system functionality. They also provide a good survey in call centers that run with older technologies. We proceed further to detailed system design and prototyping, with focus on urgency requirements for alert routing, employing additional mobile technologies, and healthcare partner process integrations.

Although information integration issues are not new in database research communities [28], applying workflow technologies in different application domains has many unique properties that entail special integration design considerations, such as [27]. In the context of workflow management systems (WFMS), we have recently proposed to separate user alerts from user sessions with the WFMS to improve the flexibility in our ME-ADOME system [2]. Online users are alerted through ICQ, 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 needs not connect to WFMS on the same device, or even on the same platform. For example, after receiving a SMS alert, the user may use his handset to connect to the WFMS via WAP, or he/she may reply with an SMS message. Alternatively, the user may find a PC with Internet connection or use his/her PDA to connect to the WFMS. As an extension to existing process models such as [27], our process model abstracts information regarding roles and their schedules of service providers possessing these roles. A preliminary version of our process model in the context of WFMS is available in [7]. We have employed a bottom-up data-driven methodology to extend information systems into Web Services [5]. We further incorporate alerts and their routing in this paper. To our knowledge, there are no other WFMS employing this approach. Further, there has no other work on alertdriven process integration or data integration currently.

4. Alert Conceptual Model Data Request

generates AMS Task

Process Request

1

Alert

0..*

generates 1 Specific Task

Flexible Task require

specify 1 Service Provider

Capability Profile 1..*

1..* Role

send

send

1 0..1 0..n

Response 0..*

Web Service Provider

Human Sevice Provider

1..*

Schedule

Devices *

1..* Service Access Points 1..*

Figure 2. UML Class Diagram for alerts in MHCS

Based on the requirements discussed in the previous section, we design a unified alert mechanism for both data and process requests. Figure 2 depicts our alert conceptual model in Unified Modeling Language (UML) Class Diagram [22]. When a workflow requires an external data request or process request, the AMS generates an AMS

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

4


Data/Process Requirements

Alerts Managed by AMS Web Services and Mobile Devices

Figure 3. The role of alerts in healthcare information systems

In this section, we first present our overall system architecture for the MHCS, and then detail the mechanism of the AMS, which supports sophisticated alert monitoring and routing. We also outline the Web Services definition required by the system for inter-organizational interactions. 5.1. System Architecture Alert Management System (AMS) Outgoing Alerts

Web Services Counterparty Counterparty Provider

The Outgoing Alert Monitor

Responses for Outgoing Alerts

WebServer Server Web Web Server

Incoming Alerts

Incoming Alerts Responses for Incoming Alerts

AMS AMS AMS

Internet ICQ, SMS, Email alerts

Human Service Providers

Web Services Server

Web, WAP, SMS, email reply

Call Center Personnel

Execute Alert Handlers

Incoming Alert Monitor

Event/Exception Handling

5. System Design and Implementation

Response of Incoming Alerts

Healthcare Information Systems and Workflows

Figure 3 further summarizes the conceptual architecture of alerts. The essence of alerts is to capture urgency requirements, as required by some healthcare information systems or workflow. It should also be noted that exceptions are subclasses of events [7]. Exceptions often, but need not always, have urgency implications. Different from general events, alerts have more specific attributes, in particular, urgency and service requirements. Different from exceptions, alerts need not be related to abnormal behaviors. That means, alerts can be (i) triggered asynchronously to handle an event or exception, or (ii) generated synchronously to satisfy the data or process requirement. Alerts received by a service provider have to be handled by either (i) rejecting the service (ii) its internal information systems, (iii) a human service provider, or (iv) in turn requesting other external service providers.

User Interface

task to monitor the enactment of the request. The AMS task is called a specific task if it requires a specific service provider. Otherwise if only some criteria for a task are specified, it is called a flexible task as the AMS may use matchmaking techniques (as discussed in the next section) to search for suitable alternative service providers. These criteria are specified in terms of roles, which can be used to represent the capability, position, and/or specialties of the service provider. A match is valid if the set of roles required is a subset of the service provider [7]. The AMS task generates alerts that are routed to matching service provider(s), which can be human service providers or Web Services providers. Sometimes, an alert might need to be sent to several service providers (e.g., doctors, or healthcare partners) with the similar capabilities, if the request is very urgent. Besides identification information, an alert has an urgency level, which could be a function of time. Normally when not responded, the AMS increases alert urgency with time, as further explained in the next section. Although traditionally alerts are small messages, we generalize the concept of alert to include any additional information are urgent, important, or that can better justify the request (new mobile devices can now support multimedia messages). For example, an audio file or an image could describe the injured patient better than text. A response is a service providers’ reply of an alert, indicating that the service provider may finish, confirm, or reject the request. For short enquiries to human service providers or simple processing of data by web service providers, the service provider may finish the request and respond with the required results right away. If more time is required, they reply with a confirm response to reflect their commitment to the request. Should the service provider feels that it is not able to service request or do so in time, it could reject the request. On the other hand, the AMS needs to deal with those alerts that are not responded by the deadline. From reported practice, we observe that as long as an alert is not responded, the service provider may be changed. As a result, the AMS can revise the matching between the alert and the service provider. In addition, as the time passes without any acknowledgement, the urgency of the alert should increase as well. Thus, this may in turn change the service provider to be requested. In our model, we propose a flexible approach, in which a strategy can be defined by the administrator.

Process Execution alerts Module

Role Matching Module

Urgencies Strategy Definition Module

Service Provider Monitoring Module

Process / Alert Definition Module Create Alerts

Medical House-Call System Workflow and Application Logic

Database

Figure 4. System architecture highlighting the HAMS

We have built a prototype for the MHCS on the J2EE and Oracle platforms [24]. Figure 4 depicts the overall implementation architecture of MHCS. As the AMS only manages the alert, domain-specific application logic is required for a complete system. When data or process services are required, the application logic generates alerts with the necessary specification to the AMS. Any subsequent processing that depends on the result of the external service has to wait till it finishes (as signaled by the AMS); otherwise the workflow can continue. On the other hand, the application logic is triggered by the Process Execution Module of the AMS to carry out timely appropriate actions in response to incoming alerts.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

5


In addition, the application logic supports an administrative Web front-end for the Call Center personnel.

Figure 5. Sample alert acknowledgement user interface

To extend the availability for users on different platforms, eXtended Markup Language Stylesheet Language (XSL) technology is employed [18]. 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. Figure 5 illustrates a sample alert response form for a doctor through WAP on a mobile phone and a PDA browser respectively. 5.2. AMS Mechanisms Our AMS supports an organization to be both a service provider and requester at the same time. Each organization can use the AMS to both receive and submit alerts. The AMS consists of two major parts (see Figure 4). The Incoming Alert Monitor is responsible for receiving and queuing alerts and enacting the corresponding services (processes). In addition, the Process and Alert Definition module supports a tool with which users may define the tasks and their associated alerts according to the AMS model. Thus, incoming alerts received as requests to a Web Service, SMS messages or via a web interface, can trigger the appropriate alert handlers in the application logic can be executed through the Process Execution module. The Outgoing Alert Monitor subsystem is responsible for creating and submitting the alerts by means of Web services requests to the corresponding service providers, and monitoring their responses. As for human service providers, they are communicated with ICQ, SMS, and, email too. As such, a service provider supporting only manual record retrieval may still participate in data and process integration through an alert response form. The alert can be routed to a clerk, who input manually the required response to the requestor’s Web service. 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 specifies the policies that will be

followed if the alert is not acknowledged within the deadline. The Role Matching module is responsible for identifying the service providers to which the alert will be forwarded. The Service Provider Monitoring module is responsible for applying the strategies defined at the urgencies strategy definition. Its functions include sending alert messages, receiving response, maintaining alert status, and logging information. For every response message received, it updates the status information of the associated alert. It tags that the alert has been “taken care of”. If the alert message has been sent to several service providers, the first one to confirm is assigned to the task while the others will receive a cancellation message 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 6 depicts a typical life cycle of an alert in UML Activity Diagram. All alert processing and messaging for an alert is logged (“Log alert” node) for auditing purposes. If the alert is a specific one, 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 a suitable service provider. 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. 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, 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).

[ flexible task ] Find matching service provider

Log Alert

[ specific task ]

Determine device / web service access point Increase Alert Urgency

Send alert

[ no ] Check if response received by deadline

Check if service performed upon service due [ no ]

[ yes ]

Generate new alert to admin staff

[ yes ]

Figure 6. Typical life cycle of an alert in UML activity diagram

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

6


The last tolerance level is guided by “Check if service performed upon service due” node. If the service is not performed within deadline (e.g., the doctor does not notify his arrival to the patient’s location on time, or a patient record is not received within deadline), then the AMS generates a new alert to the relevant administrator to notify this exception. As such, additional manual or system assisted exception handling processes [8] can be carried out. 5.3. Service Provider Matching and Urgency Strategies The service provider matching module is responsible for searching a service provider for each alert. The service provider matching algorithm searches for those service providers that can play the role required for the alert. The algorithm then selects those that have a response time that is less than the deadline. 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 a user-supplied cost function [7]. In this application, the cost function can be based on the time required for service, distance to be traveled, charges of the service provider, etc. In case no matching is available (i.e., there exists no service provider with the requested role that can meet the deadline), the algorithm upgrades the alert by expanding the roles whenever possible (e.g., request a specialist instead of a general practitioner). After the matching, an active alerts table keeps all instantiated alerts and whether the alert has been acknowledged or not. If an alert is resent, the service provider matching algorithm will take into account of 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 {Low, Normal, Urgent, Very Urgent, Critical, Very Critical} and a default urgency function as follows: t ≤ T (default) Urgent °Very Urgent T < t ≤ T + dt1 ° U 002 (t ) = ® T + dt1 < t ≤ T + dt1 + dt2 °Critical °¯Very Critical T + dt1 + dt2 < t ≤ T + dt1 + dt2 + dt3

Table 1: Example Urgency Strategy Table Urgency002 Urgent Very Urgent Critical Very Critical

Action default Submit a second alert to the same service provider, notifying about the approaching deadline Redirect the alert to another SP that has the best response time Send the alert to several SPs and accept the results of the one that response first, notify an administrator

Table 1 shows an example 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 there has been no response, the AMS creates another alert message to notify the service provider about the eminent deadline. If still there is no response, the AMS tries another service provider with the same roles and the best response time. If this step also fails, the priority further increases to Very Critical, where all available service providers with requested roles will receive the alert, while an administrator is notified.

6. Applicability and Discussions In this section, we discuss the applicability of the AMS to healthcare chain workflow management with reference to our pilot prototype MHCS, focusing on process integration and data integration aspects. We also discuss migration issues and the general applicability of alerts. 6.1. Process Integration and Workflow Management With future support of an AMS, the main workflow of the MHCS at the Call Center is much simplified, as depicted by Figure 7. 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. Process requests to human service providers (including doctors and nurses) and those to Web Service providers can be uniformly modeled as alerts in this application framework and architecture. The logic for sending, routing, and monitoring these alerts is supported in the AMS and can be heavily reused. Thus application development can be much streamlined.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

7


management and process integration with service partners involving both human and programmatic interaction can be supported.

Receive / enter call [ Hospitalization requested / required ]

Contact hospital

Find doctor

Gather patient record

6.2. Healthcare Data Integration

[ nurse required ]

Call ambulance

Send patient to hospital

Find nurse

Send patient record

Get sources for medical claims from insurance company

Perform House Call

Order medicine for patient

Request patient records from doctors

Request drug history from phramacies

Request patient records from hospitals

Billing

Combine the records

Figure 7. Workflow of the medical house-call center in UML activity diagram

It should be noted that an AMS targets for urgent, asynchronous, unstructured, or even ad-hoc tasks (such as exception handling). Therefore, it is complimentary to conventional workflow management systems (WFMS) which targets at regular synchronous task flows. In fact, the motivation of AMS evolves from the exception handling and user-interface mechanisms of our ME-ADOME WFMS [2], by factoring out and extending, in particular, urgency requirements. The 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 (as illustrated in Figure 4), which can be a WFMS as well.

Figure 8. Alerts and status monitoring

A vital administrative function is to monitor the status of service progress, and especially exceptions. Thus, the AMS generates alerts to relevant administrator(s) upon exception. For example, the administrator can monitor house-call status through a customized House-call Status Monitor page (cf. Figure 8) based on a customized view of the AMS’s active alert table. Manual manipulations can be carried out if necessary. As such flexible workflow

Figure 9. Sample healthcare data integration plan in UML activity diagram

Since we also model data requests as alerts, a healthcare data integration process (“Gather Patient Record”) can similarly be modeled as workflows, while individual data requests are modeled as alerts. Figure 9 depicts a sample workflow for healthcare data integration. For example, the insurance company can extract the list of healthcare service providers from the claim records of a patient. Then, each of these healthcare providers can be requested for the relevant patient records by sending alerts to them through the AMS. Urgency requirements apply as the doctor needs the information latest by his arrival to the patient’s home, while the hospital needs the information by the arrival of the patient. As such, the AMS not only caters for the interactions but also the urgency requirements for data integration. Data sources that can only support manual procedures can still participate in this process as our architecture provides web-based alert response forms. Moreover, humans may be involved as approval may be required for accessing patient records. In this case, though some requests may be rejected or some of them may not be able to meet the deadline, at least the data integration process can be speeded up as much as possible. For privacy reasons, other integration plans may be necessary and can thus be flexibly tailored for. For example, the scattered patient records may be sent directly to the doctor in charge of the current house-call or to the patient’s home personal computer.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

8


6.3. Migration and More General Applications With a web-based system, patients can either enter their call through the web via different devices or use the traditional way with a phone to the call center. In nonurgent cases, the web-based system offers new functions. For example, patients or their family members may browse the web page to select the doctors and hospitals to be requested for. A patient may access his/her own medical records online. However, tradition call center, as usual for most services, cannot be totally replaced, especially under more urgent conditions. Another 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 humans to be alerted, either the call center staff or personnel of the service provider can help enter information into the system through the interactive web-based alert response forms (cf. Figure 5). The worse scenario is that a call center staff is alerted to carry out manual work (e.g., calling a hospital through a phone to notify a patients’ arrival) and record the deed through an alert response form. As organizations are moving towards service-oriented computing, service providers currently do not consider such computerization will eventually need to do so in order to increase their competitiveness. 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 an AMS is lightweight and highly coherent, but 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 AMS can as well route alerts to other AMS within a large organization, such as a 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 an AMS gradually for adequate testing and streamlining the switch-over, which may otherwise be impossible involving a large number of service providers in a service grid [12]. 6.4. Evaluation by Medical Professionals Based on the prototype and system descriptions, we have discussed with medical professionals to have their evaluation. A summary is as follows. In the existing practice, alerts are communicated mainly through phones and pagers. In today’s hospitals, doctors do not work at their desks or stay all the time at their clinics. Trying to reach a doctor on telephone is not always feasible. There are also

possibilities in which parts of the information are lost or imprecise. In an emergency situation, timely scheduling and arrangements are crucial for the patient’s outcome. The introduction of the AMS mechanism offers four important advantages. (1) It will make sure that an alert can reach the person who has to be notified. (2) The inclusion of multiple mobile devices and platforms helps both the medical professions and the patients. (3) The implementation of an urgency policy that uses concurrently multiple devices to communicate the alert can increase the probability to inform the person on time. (4) An automated alert can make sure that the information is passed accurately and completely. An additional contribution of this call center prototype is that it provides an infrastructure for total solution healthcare chain workflow integration, which can save much paper work and administration (e.g., payment collection), at the same time providing more accurate information (e.g., prescription routed to pharmacy). The system also guides call center operators to choose the right medical professionals to minimize possible specialty mismatch. Another system feature that the doctors appreciated is that it offers the capability to choose the kind of received information, reception devices, and desired time slots.

7. Conclusions In this paper, we looked into the problem efficiently conveying alerts to the right service provider at the right time using Web Services and mobile devices, for service provision under urgency constraint. We have proposed a framework of an alert management system (AMS) supporting both human and Web Services providers. This framework introduces a flexible alert conceptual model that allows users to specify tasks, alerts, roles, and their inter-relations. We further illustrate that alerts can capture requirements for both data integration and process integration requests. We have also presented our AMS architecture with an implementation outline based on Web Services and described the alert monitoring and routing mechanisms involved. We have further proposed a matchmaking approach flexible enough to be customized for different urgency strategies for different application requirements. As such, an effective AMS can be built and it can be reused by plugging into systems that require sophisticated alert support. We have demonstrated the applicability of the AMS in healthcare chain workflow management with a Medical House-call System, supporting both healthcare data and process integration. We are moving into the second phase development of the system while we are studying the requirements and application of an AMS in a hospital environment. We are also implementing the AMS under our ME-ADOME WMFS [7], aiming to strengthen the support for alerts for general workflow and E-service management. We are in-

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

9


vestigating in inter-relations among alerts. In particular, we are looking into alerts due to failure of commitments [5] and their relation to contract enforcement. We are also interested in further issues of collaborative workforce management, especially managing the diary of healthcare personnel with agents [3]. We are also interested in the impact of cancellations, other possible exceptions, tradeoff between quality and cost, and service negotiation [5].

References [1] E. Ammenwerth, A. Buchauer, B. Bludau, and R. Haux, “Mobile information and communication tools in the hospital,” Intl .J. of Medical Informatics, 57 (1):21-40., 2000. [2] D.K.W. Chiu, S.C. Cheung, and E. Kafeza, “Three-tier View-based Support for Mobile Workflow,” In Proc. 1st Intl. Conf. on Mobile Business, CDROM, Athens, Greece, July 2002. [3] D.K.W. Chiu, S.C. Cheung, E. Kafeza, and H.F. Leung, “A Three-Tier View Methodology for adapting M-services,” IEEE TSMC, Part A, 2004, (to appear). [4] D.K.W. Chiu, S.C. Cheung, K. Karlapalem, Q. Li, Sven Till, and E. Kafeza, “Workflow View Driven CrossOrganizational Interoperability in a Web Service Environment,” Information Technology and Management, 2004 (to appear). [5] D.K.W. Chiu, S.C. Cheung, P. Hung and H.-f. Leung, “Constrained Based Negotiation in a Multi-agent Information System with Multiple Platform Support,” In Proc. HICSS37, Jan 2004, CDROM, 10 pages. [6] D.K.W. Chiu, S.C. Cheung, and S. Till, “An Architecture for E-Contract Enforcement in an E-service Environment,” In Proc. HICSS36, Jan 2003, CDROM [7] D.K.W. Chiu, Q. Li, and K. Karlapalem, “A Meta Modeling Approach for Workflow Management System Supporting Exception Handling,” Information Systems, 24(2):159-184, 1999. [8] D.K.W. Chiu, Q. Li, and K. Karlapalem, “Web InterfaceDriven Cooperative Exception Handling in ADOME Workflow Management System,” Information Systems, 26(2):93120, 2001. [9] D.K.W. Chiu, K. Karlapalem, Q. Li, and E. Kafeza. “Workflow Views Based E-Contracts in a Cross-Organization EService Environment,” Distributed and Parallel Databases, 12(2-3):193-216, 2002. [10] S. Eisenstadt, M. Wagner, W. Hogan, M. Pankaskie, and FC Tsui. W. Wilbright, “Mobile workers in healthcare and their information needs: are 2-way pagers the answer?” In Proc. AMIA Annual Fall Symposium, 1998, pp.135-139. [11] A. Fano and A. Gershman, “The Future of Business Services in the age of Ubiquitous Computing,” CACM, 45(12):83-87, 2002 [12] W. Gentzsch. Grid computing: a new technology for the advanced web. In Proceedings of the NATO Advanced Research Workshop on Advanced Environments, Tools, and Applications for Cluster Computing, Springer, LNCS2326:1-15, 2002. [13] J. Grimson, G. Stephens, B. Jung, W. Grimson, D. Berry and S. Pardon, “Sharing health-care records over the internet,” IEEE Internet Computing, vol. 5, no. 3, pp. 49-58, May/June 2001.

[14] I. Haimowitz, J. Farley, G..S. Fields, J. Stillman, and B. Vivier, “Temporal Reasoning for automated workflow in Helath Care Enterprises,” Electronic Commerce: Current Reasearch Issues and Applications, , Springer, LNCS 1028:87-113, 1996 [15] G.. Hripcsak, P. Clayton, R.A. Jenders, J.J. Cimino, and S.B. Johnson, “Design of a Clinical Event Monitor,” Computers and Biomedical Research, 29:194-221, 1996. [16] P. Hung and D.K.W. Chiu, “Developing Workflow-based Information Integration with Excepion Support in a Web Services Environment,” In Proc. HICSS37, Jan 2004, CDROM. [17] International Medical Informatics Association (IMIA): www.imia.org [18] Y.-B. Lin and I. Chlamtac, Wireless and Mobile Network Architectures. John Wiley & Sons, 2000. [19] C. T. Liu, A. G. Long, Y. C. Li, K. C. Tsai and H. S. Kuo, “Sharing patient care records over the World Wide Web,” Intl. J. of Medical Informatics, 61(2-3):189-205, May 2001. [20] A. Marsh, “The Creation of a global telemedical information society,” Intl. J. of Medical Informatics, 49(2):173-193, 1998. [21] F. Malamateniou and G. Vassilacopulos, “A Workflowbased Approach to Virtual Patient Record Security,” IEEE TITB, 2(3):39-145, 1998. [22] Object Management Group. Foreword UML specification 1.4, September 2001. http://www.omg.org/ [23] D. Peltzer. .NET & J2EE Interoperability, McGraw-Hill Osborne, 2003. [24] J. Price. Oracle 9i JDBC Programming, McGraw-Hill Osborne, 2002. [25] D.M. Ride, C. Safran, R.S. Philips, Q. Wang, D.R. Calkins, T.L. Delbanco, H.L. Bleich, and W.V. Slack, “Effect of Computer Based Alerts on the Treatment and Outcomes of Hospitalized Patients,” Archives of Internal Medicine, 154:1511-1517, 1994. [26] W. Raghupathi and J. Tan, “Strategic IT Applications in health care,” CACM, 45(12)56-61, 2002. [27] O. R. L. Sheng and G. H. M. Chen, “Information Management in Hospitals: An Integrating Approach,” Proceedings of Annual Phoenix Conference, 1990, pp. 296-303. [28] A. Sheth and J. Larson, “Federated database systems,” ACM Computing Surveys, vol. 22, no. 3, pp. 183-236, 1990. [29] H. Takeda, Y. Matsumura, S. Kuwata, H. Nakano, N. Sakamoto and R. Yamamoto, “Architecture for networked electronic patient record systems,” Intl. J. of Medical Informatics, 60(2):. 161-167, 2000. [30] R. Suomi and J. Tähkäpää, “Establishing a Contact Centre for Public Health Care,” In Proc. HICSS36, Jan 2003, CDROM. [31] P. Weverka. Mastering ICQ: The Official Guide. IDG Books. ICQ Press, 2000, http://www.icq.com [32] Workflow Management Coalition. The Workflow Reference Model. (WFMC-TC-1003, 19-Jan-95, 1.1)

0-7695-2056-1/04 $17.00 (C) 2004 IEEE

10