Intelligent Event Processing for Emergency Medical ...

Download PDF
7 downloads 126153 Views 940KB Size Report
Comment
and assigns the alias names g1 and g2 to them. .... successfully to the Android platform, and it exhibits the ... [3] Bade, D. Event stream processing on android.
Intelligent Event Processing for Emergency Medical Assistance Holger Billhardt, Marin Lujak, Sascha Ossowski Universidad Rey Juan Carlos 28933 Madrid, Spain

{holger.billhardt, marin.lujak, sascha.ossowski}@urjc.es ABSTRACT The main objective of Emergency Medical Assistance services is to attend patients with sudden diseases at any possible location within an area of influence. Especially for severe emergency patients, the potential of such systems to reduce mortality is directly related to the response time, e.g., the time a patient has to wait for an ambulance. An efficient coordination of the ambulance fleet is crucial for reducing the response times of a service. And this requires complete, real-time information about the current state of the ambulance fleet. Such information is usually transmitted by the ambulance crew members. However, due to the often stressful work of those professionals, the information is frequently not sent in a timely manner. In this paper we present an approach that addresses this problem. We use a Complex Event Processing architecture to automatically identify and transmit incidents and changes in the operational states of ambulances. As a result, the availability of information in the control centre and, thus, the effectiveness of the service is improved. The system is inspired by the operational model of SUMMA112, the Emergency Medical Coordination Centre of the Autonomous Region of Madrid in Spain.

1.

INTRODUCTION

The healthcare domain in general, and the assistance in case of emergencies or urgencies in particular, has a high social impact given the immediate threat to a patient’s life or long-term health. Such extreme circumstances demand high-quality services that provide healthcare to people anywhere and anytime. In case of medical emergencies, the goal of emergency medical assistance (EMA) services is to provide acute medical care to patients and/or to deliver them to definitive care units (e.g., hospitals). Such services have to use the appropriate resources within a limited response time in order to provide an efficient assistance. The coordination

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’14 March 24-28, 2014, Gyeongju, Korea. Copyright 2014 ACM 978-1-4503-2469-4/14/03 ...$15.00.

Ralf Bruns, Jürgen Dunkel Dpt. of Computer Science Hannover Univ. of Applied Sciences and Arts 30459 Hannover, Germany

{ralf.bruns, juergen.dunkel}@hs-hannover.de

of the available resources to provide assistance to emergency patients (normally a fleet of possibly different types of ambulance vehicles), is of crucial importance for improving the main key performance indicator of an EMA services: the response time (time between a patient call and the moment an ambulance arrives and the patient can receive medical assistance). For the most sever emergency patients, the response time is directly correlated to the chances of saving life. This is the reason why many countries specify response time limits for EMA service provider organisations. In Europe and in the Unites States such limits usually lie between 8 and 15 minutes for sever emergency cases. Most modern EMA service providers use Decision Support Systems (DSS) for the coordination of their ambulance fleets. One of the main tasks that such systems have to support is the ambulance allocation task, i.e., to determine the most appropriate (available) ambulance that should be sent to assist a given patient. Two principal factors play a role in this decision: i) the type of ambulance, and ii) the distance of the ambulance to the patient’s location. The latter is directly related to the expected response time and, thus, is of crucial importance for providing fast assistance. In order to comply with the allocation task, EMA-DSS have to continuously monitor the state of the ambulance fleet. In particular, they require complete and real-time information about the operational states of the ambulances (whether they are available for assignment or not) and about their precise positions. Additionally, such systems can benefit from other context related information, like mission incidents or expected delays. Whereas real-time information about ambulance positions is usually available (e.g., through GPS sensors), this is often not the case for the operational states or other context related information. Usually the crew of an ambulance vehicle is supposed to transmit changes in the operational states as well as possible incidents to a central coordination centre. However, in practice ambulance crews often fail to transmit the information in a timely manner (e.g., because they are busy with attending a patient). As a result, EMA-DSS do often not have the precise information they require which may reduce their efficiency, especially in the case of ambulance allocation. In this paper we propose to improve the availability of information for EMA-DSS by using Complex Event Processing (CEP). CEP is a rather novel software technology capable of monitoring continuous streams of data and of providing support for fusion processing, so as to extract rel-

evant information in real-time. The basic concept of CEP is in-memory pattern matching, which means to identify in the data stream those patterns of data that represent a meaningful situation in the application domain. Thus, CEP enables situation-aware application systems. The idea is that both, changes in the operational states of ambulances as well as possible mission incidents are automatically detected and transmitted through an CEP architecture. We use as a reference model the operation of the Emergency Medical Coordination Centre SUMMA112 ; the centre responsible for out-of-hospital emergency medical assistance in the Autonomous Region of Madrid in Spain. The outline of the paper is as follows. In Section 2, we give a brief description of ambulance coordination, both in general and in the case of Madrid. Section 3 presents some related work. In Section 4, we introduce the main concepts of our event-driven EMA architecture. In the next section, some implementation issues are given. Finally, we summarise the most significant features of our approach and give a brief outlook on future lines of research.

2.

COORDINATION PROBLEM

Even though EMA services in different regions and countries have different modes of operation, the main lines of medical emergency management are similar for all of them. The assistance procedure typically starts when a patient calls an Emergency Coordination Centre asking for assistance. The call is received by an operator who screens the call and gathers initial data from the patient. The operator (if necessary with the help of a physician) assigns a severity level to incoming calls. According to this severity evaluation of a call, a specific type (and number) of ambulances is assigned, taking into account their availability, distance, and the estimated time to reach the patient. When the ambulance arrives at the patient’s location, the crew provides first aid and in some cases “in situ” assistance. According to the conditions of the patient, s/he is transported to a hospital. EMA services typically work with at least two types of ambulances: basic life support (BLS) and advanced life support (ALS) units. In the most severe cases, assistance by ALS units is required and reducing the time a patient has to wait until the ambulance arrives is usually crucial for a successful medical treatment. From the logistic point of view, there are two main issues that are directly related to the average response time of an EMA service: allocation and redeployment of ambulances. The allocation problem consists of determining which ambulance should be sent to assist a given patient. Redeployment consists of relocating available ambulances in the region of influence in a way that new patients can be assisted in the shortest time possible. Usually, the decisions related to these issues are taken by a Coordination Centre in a centralized manner. The positions of ambulances as well as their operational states are usually available to the Coordination Centre through GPS technology and a continuous communication with the units. In the Autonomous Region of Madrid, the SUMMA112 service is in charge of managing medical emergencies. The Coordination Centre for Medical Emergencies of SUMMA112 receives more than 1.200.000 calls per year – one call each 30 seconds. Around 60.000 of these calls are classified as life-threatening situations (called “level 0” emergencies). In these cases, one of the 43 ALS units (26 Mobile Intensive

idle

assigned

assisting

transfer

work-break out of service

Figure 1: State Transitions

Care Units and 17 Rapid Intervention Vehicles) available to SUMMA112 are assigned. After assisting a patient, s/he is taken to one of the 38 hospitals in the region. Once an ambulance has finished a mission, it returns to its home base and waits for a new assignment. The assignment of ambulances and hospitals is done using the closest method rule based on the first-come/first-served (FCFS) principle and taking into account the severity level of a patient. In particular, the first level-0 patient is assigned to the closest ALS unit, then the next patient is assigned to the next closest unit, and so on, taking as candidates always the units that are available at each time. No redeployment decisions are taken, as the ambulances usually depart from their home bases and return to their bases after the completion of a mission. Home bases have been distributed strategically within the territory of the Autonomous region of Madrid. Not all ALS ambulances are available 24 hours a day. Some vehicles may be temporarily inactive, due to breakdown, repair, maintenance, or cleaning. Furthermore, agreements with trade unions assure that the ambulance crews can take breaks during their working shifts in order to have meals etc. During these times, the vehicles are considered active (i.e. they can be assigned to a patient), but the Coordination Centre needs to take into account that higher “start-up times” apply, as crews need to return to their vehicles. For instance in the case of Madrid, the average start-up time of an ambulance is about 1-2 minutes. If the ambulance crew is having a work break, this time is incremented in about 2 minutes. Figure 1 summarises the different operational states of ALS units, and their possible transitions. An idle ambulance may be requested to assist an emergency patient. In this case, its state changes to assigned and the ambulance is supposed to move to the patients location. Once the ambulance arrives, it changes its state to assisting meaning that it provides “in situ” assistance. The assistance phase can result in two situations: i) the patient dos not need any additional aid and the ambulance becomes idle again, or ii) s/he has to be transferred to a hospital (state transfer ). In the latter case, after the patient has been admitted at the hospital, the ambulance changes to state idle. idle ambulances can have work-breaks, e.g., for having lunch, and any ambulance may suffer a breakdown due to some incident in which case its state becomes out of service. In [14] Lujak and Billhardt report on a prototype of a DSS to assist EMA operators to manage life-threatening (level-0) emergencies. The system uses a novel ambulance allocation mechanism where an auction-based assignment of patients to ambulances tends to globally optimise the sum of the expected travel times in each particular moment. The global

assignments are recalculated in a dynamic manner whenever changes in the environment could imply the existence of a better global solution. Simulations based on historical data of the Madrid region have shown that significant improvements in the average response time of SUMMA112 ’s emergency service can be achieved. In order to be efficient, ambulance allocation mechanisms require complete information about the current state of the ambulance fleet. In the case of Madrid, in principle, the ambulance crews are to inform the Coordination Centre of changes in their status in a timely manner. However, in practice this is not always the case. Often the crew simply forgets to transmit such changes (e.g., when they go to have a work break for meals) or the report with delayed (e.g., because they are fully dedicated to a potentially life-saving assistance). In practice, this can lead to a decay in performance. Additionally, possible incidents due to external influences, like delays in the arrival of ambulances or an unforeseen breakdown, are often not detected fast enough in order to take alternative assignment decisions. Therefore, automatic means for detecting changes in the states of ALS units based on contextual information is a relevant problem, with an important social (potentially life-saving) impact.

3.

RELATED WORK

Several commercial software applications exist for emergency medical services. Most of them target the US market (e.g., RescueNet Data Management Suite for EMS, National EMS Information System, Medical Response Emergency Software), and usually combine different tools for different parts of the emergency assistance process (e.g., computer aided dispatching, management of calls, billing software, etc.). By contrast, in Europe where public health care systems prevail, emergency services often use their own proprietary software systems. In practice, few deployed software solutions provide integral support to the assistance process [6, 5, 7]. Furthermore, they are not easily tailorable to needs and preferences of the stakeholders (patients, coordination centres, hospitals and, in particular, ambulance crews). In many deployed systems, the selection of ambulances and/or hospitals is done manually or only partially supported by software tools. Brotcorne et al. provide a good review of ambulance allocation and redeployment strategies from the early 1970s through 2003 [4]. Most of the state-ofthe-art approaches are either static or probabilistic. Some of the models consider allocation and redeployment together, while others concentrate only on the redeployment of ambulances [9, 10]. In [11], the authors apply a statistical model using historical data of emergency calls. More recent research has focused on developing dynamic optimisation models to repeatedly relocate ambulances throughout the day [9, 16]. Compared to static and probabilistic approaches, a dynamic multi-agent model has the advantage of producing a solution which depends on the current state of the system and adapts adequately and quickly to unpredicted new situations. However, the aforementioned approaches usually assume that adequate and complete information about the state of the ambulances is available, which cannot always be assured in real-world emergency scenarios (e.g., emergency crews correctly prioritise assisting a sever patient over timely sending status information to the emergency centre). While in-

formation about the context of ambulances is available in principle, either through sensors (GPS, acceleration, etc.) or by means of external sources (traffic information, weather service, etc), the high frequency of the data streams generated especially by the former make it difficult to exploit this context information in real-time for ambulance coordination. In [8], Complex Event Processing has been proposed as general computational approach for processing continuous streams of data in sensor networks. Recently, some projects demonstrate the applicability of CEP for processing mobile sensor data [1], [2]. However, mobile devices serve only as special event sources in these projects – the real processing of sensor data is delegated to powerful backend servers. In [12] it is proposed to preprocess sensor data on the mobile device in order to achieve context-aware event filtering, but sophisticated event processing rules are still executed on the server. Sensors of mobile phones are also exploited in [15] to diagnose the actual behavior of the user. But in contrast to our approach, specialized activity recognition algorithms are used instead of CEP. In this paper, we propose an architecture, where the complex event processing is directly executed on mobile devices to achieve situation awareness.

4.

CEP FOR EMERGENCY DSS

4.1

Complex Event Processing

Complex Event Processing is a software technology for processing high frequency event streams in near real-time [13]. Everything that happens inside or outside of a system is considered as an event. CEP analyses streams of incoming events to detect the presence of event patterns. An event pattern is a particular sequence of events with a special meaning for the application domain. A pattern match signifies a meaningful state of the environment and causes either the generation of a new complex event or triggers a domainspecific action. Complex events correlate between simple events and provide the real power of CEP. Event stream processing systems manage the most recent set of events in-memory and employ sliding windows and temporal operators to specify temporal relations between the events in the stream. The core concept of CEP is a declarative event processing language (EPL) to express event processing rules. An event processing rule contains two parts: a condition part describing the requirements for firing the rule and an action part that is performed if the condition matches. The condition is defined by an event pattern using several operators and further constraints. In the following, we use a simplified pseudo language for expressing event processing rules, which is easier to understand than an EPL of a productive CEP system. This pseudo language supports the following operators: Operators AND, OR Boolean operator for events or constraints. NOT Negation of a constraint. -> Sequence of events. .within defines a time window in which the event has to occur. An event processing engine analyses the stream of incoming events and executes the matching rules. Event processing rules transform low level simple events into more complex events in order to gain insight into the current state of

the environment. Luckham introduced the concept of event processing agents (EPA) [13]. An EPA is an individual CEP component with its own rule engine and rule base. Several EPAs can be connected to an event processing network (EPN) that constitutes a software architecture for event processing. Event processing agents communicate with each other by exchanging events.

4.2

EMA Coordination Center

CallManger

Patient

Operator

Ambulance Allocation Mechanism

In each Ambulance Vehicle (CEP Architecture)

position events

mission events

situation events

rules

We propose a distributed 2-layer architecture for emergency DSS (see Figure 2). The first layer ‘EMA Coordination centre’ is located in the central control centre and has the responsibility of managing the operations of the ambulance fleet. The second layer is deployed in each ambulance vehicle and should provide the DSS with the actual operational states of each vehicle. Furthermore, it should autonomously diagnose problems and critical delays.

Filtering Agent rules GPS events

position events

acceleration events

motion events

Motion Agent rules

acceleration events tablet sensors

Layer 1: EMA Coordination Centre

• GPS position events for localisation. • situation events representing the operational state of an ambulance (e.g., idle, assigned, assisting, transfer, work-break or out of service, as described in Figure 1). • mission events that report relevant mission-specific problems like expected delays or car breakdowns. Based on this information, the EMA Coordination Layer assigns new patients to ambulances and imposes re-assignments when the current context advises to do so. More details can be found in [14].

Layer 2: Ambulance Vehicle (CEP) Every ambulance is equipped with its own CEP component/layer, for instance, installed on a mobile tablet computer. The task of this component is to continuously analyze the current state of the ambulance vehicle in real-time and to provide the EMA Coordination layer with up-to-date situation-aware information, e.g., driving with velocity, stopping, (lunch)breaks, delays, etc. Nowadays, standard tablet computers are equipped with a rich set of built-in internal sensors, e.g., for measuring the acceleration, rotation, distance, luminance, air pressure, humidity, magnetic field, environmental temperature, gyroscope, GPS, etc. We try to take advantage of those built-in tablet sensors in order to derive the behaviour of the ambulance vehicle from the physical state of the tablet computer. For example, the GPS position of the tablet is also the GPS position of the ambulance.

(un-)assignment events

Situation Agent

Event-Driven Architecture for EMA-DSS

The EMA Coordination Centre accomplishes the task of ambulance coordination based on the allocation method outlined by Lujak and Billhardt [14]. Inspired by the operation of SUMMA112, a multi-agent software architecture has been implemented that defines five different agent roles, each representing a participant in the EMA scenario: patient, call manager, operator, hospital and ambulance. Ambulance allocation relies on up-to-date information about the states of all ambulances in the fleet. In order to obtain this information, the EMA Coordination Centre collects continuously the following data and diagnoses the actual state of each ambulance vehicle:

Hospitals

Maps/Traffic

Figure 2: Event-Driven Architecture for EMA-DSS

4.3

Architecture of the Ambulance Layer

The CEP component of each vehicle processes different kinds of events emitted either by the sensors embedded in the tablet computer or from external information sources, such as traffic data. The event processing layer of our emergency DSS is based on a multi-staged EPN in order to logically structure and modularise the event processing rules. The bottom layer in Figure 2 depicts the different EPAs and illustrates the flow of events. In the following we describe the responsibilities of each EPA.

Filtering Agent Sensor data is often inconsistent or has redundant information because sensors are very noisy and have a fixed sampling rate. Therefore, in a first step, all technical sensor events emitted by the tablet computer have to be pre-processed to overcome inconsistencies or to filter out irrelevant events. For example, the GPS sensor of the tablet has a fixed sampling rate. Thus, many subsequent events are logically identical. But the EMA system is only interested in situation changes, and not in the repetition of events carrying similar measured values. Therefore, the Filtering Agent filters out those GPS sensor events in an ambulance that are related to the same geographical position. The following event processing rule has the task to find out if the ambulance has moved to a new position. rule: "new car position" CONDITION GPS-Evt AS g1 -> GPS-Evt AS g2 AND (Geo.isDifferent(g1,g2)) ACTION new PositionEvt(g2.x, g2.y) The rule considers two subsequently occurring GPS events and assigns the alias names g1 and g2 to them. A GPS event represents the geographical position as a pair. The followed-by operator -> denotes the temporal sequence of events. The newer GPS event g2 is only relevant

for further processing, if the ambulance location has changed significantly. Therefore, it is checked if the two GPS locations differ significantly by using a service isDifferent(..) provided by the class Geo that provides spatial operations. If the position of the ambulance has changed significantly, a new Position event is generated with the new coordinates. The Position event is propagated to the EMA Coordination layer as well as to the Motion Agent.

Motion Agent The incoming Position events are correlated with further sensor events of the tablet computer (e.g., acceleration sensor) in order to determine the particular behaviour of the ambulance vehicle. New (more complex) Motion events are derived that characterise the state of the individual ambulance vehicle. Possible states are for instance: i) driving (with a particular velocity) and ii) stopping (for a certain time period, e.g., due to a traffic jam or parking). rule: "stopping" CONDITION PositionEvt AS p -> NOT (PositionEvt OR AccelerationEvt).within(5 min) ACTION new StoppingEvt(p.ambulanceID) The above rule assumes that the ambulance has stopped unpredictably if a Position event is not followed by either a new Position event within a time interval of 5 minutes, and no car movement can be observed, i.e. no Acceleration events have occurred. The operator .within defines a time window, in which a certain event has to occur. If the ambulance has changed its position significantly within the last 5 minutes, at least one Position event must have been emitted. The following rule derives a corresponding Driving event. The average velocity of a moving ambulance can be calculated by aggregating all Position events within the last five minutes and determining the average of the measured distinct speed values. The speed is determined by a method getSpeed(..) that is provided by the GPS sensors.

in the states may trigger a new calculation of the ambulance allocation mechanism. For instance, considering the transition from assigning to assisting. If the ambulance was assigned to a new patient and the position of the ambulance is the same as the assigned location of the patient, then it can be inferred that the ambulance is attending the patient “in situ”. rule: "transition assign to assisting" CONDITION AssignEvt AS a -> PositionEvt AS p AND (a.patientLoc = p.position) ACTION new AssistingEvt(a.ambulanceID, a.patientID) Another example is the transition from assisting a patient to transfer him/her to the hospital. If the emergency team is attending a patient and afterwards the ambulance is driving again with a minimum speed of 10 km/h, then it can be assumed that they are on the way to the assigned hospital. If it is not necessary to treat the patient in the hospital, the ambulance crew must manually set its state to idle. The next rule infers this transition. rule: "transition assisting to transfer" CONDITION AssistingEvt AS a -> (NOT IdleEvt AND DrivingEvt AS d) AND d.velocity > 10 ACTION new TransferEvt(a.ambulanceID, a.patientID)

Situation Agent

Further event processing rules for the other state transitions defined in Figure 1 have been specified in a similar manner. Another important task of the Situation Agent is to detect possible problems that threaten the successful fulfilment of an emergency mission. Events related to detected problems in ambulance behaviours may require a change in the current global set of assignments of patients to ambulances. Common problems are delays or breakdowns that are recognised by the two following rules. When the EMA Coordination layer has assigned a new patient to an ambulance, it also has calculated an estimated arrival time to reach the requested address of the patient. It is now very important to continuously verify, if the ambulance can fulfil its assigned task in time. If any problem occurs, the EMA-DSS has to be informed immediately in order to reschedule the patient to a more appropriate ambulance if necessary. The most common kind of problems are delays due to high volumes of traffic. The following rule tries to figure out if the assigned ambulance requires more time than expected to reach its destination, i.e., it is delayed (according to a predefined threshold value).

In the final processing stage, the task of the Situation Agent is to determine the current situation of the ambulance with respect to its emergency mission. The motion information of the ambulance vehicle as analysed by the Motion Agent must be correlated with the last known activity in order to obtain the current operational state of the ambulance. In particular, the agent has to verify the correct transition between the possible operational states (see Figure 1). The derived operational state is expressed by a Situation event that is propagated to the EMA Coordination layer. Changes

rule: "expected delay" CONDITION AssignEvt AS a -> PositionEvt AS p AND delay = (Traffic.arrival(a.patientLoc,p.position) - a.arrivalTime) AND delay > THRESHOLD ACTION new DelayEvt(a.ambulanceID, a.patientID, delay)

rule: "driving" CONDITION PositionEvt.avg(getSpeed()) .within:batch(5 min) AS avgVelocity ACTION new DrivingEvt(p.ambulanceID, avgVelocity) In summary, the Motion Agent processes a correlation step to synthesize Motion events of the ambulance vehicle that are propagated to the Situation Agent.

Sensor Event

5.

AssignmentEvent patientID patientLocation hospitalLocation arrivalTime

The proposed EMA-DDS has a distributed software architecture:

GPSEvent coordinates Position Event

Assign

Acceleration Event coordinates

• The EMA coordination centre is realised by a multiagent system that implements, among other tasks, the coordination of the ambulance fleet for achieving an optimised assignment of ambulances to patients.

UnAssign

Reassign Explicit Events Materialized Events Situation Event

Motion Event

Stopping

Driving velocity

Assigned patientID patientLocation

Idle

Assisting patientID patientLocation

Transfer patientID hospitalLocation

Breakdown ambulanceID location

Delay ambulanceID expectedDelay

Figure 3: Event Model The new expected duration from the current position to the destination is recalculated by a service arrival(..) provided by the class Traffic that requests an appropriate Internet traffic service. Such traffic services can calculate the estimated time for a route with respect to the current traffic situation. Another kind of severe problem is a vehicle breakdown. For instance, if the ambulance was assigned to a patient, but no movement was detected for at least 5 minutes, then a breakdown of the vehicle is assumed. Immediately, a Breakdown event is raised and propagated to the EMA Coordination layer. rule: "mission breakdown" CONDITION AssignEvt AS a -> StoppingEvt AS s ACTION new BreakdownEvt(a.ambulanceID, s.location)

4.4

• Each ambulance vehicle is equipped with a CEP component to provide the EMA coordination centre with its current operational state or any upcoming problem. Mobile tablet computers, which contain already the necessary built-in GPS and acceleration sensors, provide the runtime environment for the CEP components.

Mission Event

Workbreak

IMPLEMENTATION ISSUES

Event Model

Figure 3 illustrates the event model of our system. The different types of events used in the event processing rules presented above are distinguished in explicit events and materialized events. Explicit events are events that are emitted by an explicit event source. In our case, we have two event sources: (a) the sensors embedded in the tablet computer and (b) the assignment sent by the EMA Coordination layer. An assignment event represents the assignment of a patient to an ambulance. Three different events can be distinguished: • assign: assignment of a patient to an ambulance, • reassign: assignment of a different patient to an ambulance,

The EMA coordination centre communicates with the ambulance agents by exchanging events: Assignment events inform the ambulances about their missions; Mission and Situation events inform the DSS about the operational state of the entire system. Performing complex event processing directly on a mobile device is a rather new approach. So far, commercial CEP engines have not been developed for mobile operating systems. However, an unofficial version of the widespread open source CEP engine Esper 1 (in version 3.2) has already been ported successfully to the Android platform, and it exhibits the main features of powerful CEP systems [3]. We successfully deployed Esper on an Android device. Our practical experience confirms that CEP is ready for mobile use and the advanced sense-and-response capabilities of CEP are now available on mobile devices as well. It is crucial that the DSS diagnoses always the correct operational states of the ambulances. In each vehicle, all conclusions about its current situation are immediately shown to the crew. In the very unlikely case that the DSS has derived a wrong state, the crew can overrule and correct it manually.

6.

• unassign: the current assignment of an ambulance is cancelled. Materialized events are events that are derived by an event processing rule, in our case: Motion, Situation and Mission events.

CONCLUSION

In Emergency Medical Assistance systems, an efficient ambulance location mechanism requires complete and realtime information about the current state of the ambulance fleet. In this paper, we presented an approach that automatically provides the DSS of an EMA Coordination Centre with the actual states of all ambulance vehicles for allowing an situation-aware and optimised (re-)assignment of ambulances to patients. For achieving situation awareness in the EMA system, an existing infrastructure of standard ambulance vehicles can be enhanced by mobile tablet computers that sense continuously GPS and acceleration sensor data. The software component running on the tablets is based on Complex Event Processing and correlates the streams of sensor data. In summary, the proposed architecture possesses the following properties: • Situation and context awareness: The built-in sensors of the tablet computers in the ambulance vehicles provide the DSS with a continuous stream of context data. 1

http://esper.codehaus.org/

Appropriate event processing rules derive automatically the current motion of the car (driving or stopping), as well as the actual state of the mission (e.g., idle, assigned, assisting). Furthermore, additional context data is incorporated, in particular actual traffic conditions are taken into account for predicting expected delays. The automatic conclusion of ambulance state changes, which are immediately propagated to the control center, prevents human errors and is a key issue for an efficient operation of the EMA. • Real-time processing: The car sensors emit continuously enormous amounts of data. CEP is designed for efficiently handling stream data directly in-memory. In-memory processing enables (almost) real-time operations. • Autonomy: Each ambulance deduces its current situation autonomously (which can be overruled by the ambulance crew). By evaluating the current situation, each crew can decide on their own, how to fulfil an assigned mission. Only relevant state changes are propagated to the control centre. The control centre is responsible for coordinating the different ambulances, but the operational states of the ambulances are determined locally. • Distributed processing: Fine-grained sensor data such as GPS is processed locally in the ambulances vehicles, which makes the entire DSS scalable. Furthermore, network traffic between ambulance agents and the control centre is reduced. In future work, we will provide a quantitative evaluation of the prosed architecture under different load scenarios. This will allow us to identify situations where the CEP layer is particularly useful. We also intend to extend our model to more specific and complex EMA scenarios, such as the treatment of patients with acute myocardial infarction with ST-segment elevation (STEMI) where, to be able to perform Percutaneous coronary intervention (PCI), not only ambulances but also on-duty cardiologist teams and hospitals with PCI-enabled units need to be coordinated.

Acknowledgment This work has been partially supported by the Spanish Ministry of Science and Innovation through the projects OVAMAH (grant TIN2009-13839-C03-02; co-funded by Plan E) and ”AT” (grant CSD2007-0022; CONSOLIDER-INGENIO 2010), by the Spanish Ministry of Economy and Competitiveness through the project iHAS (grant TIN2012-36586-C03-02), and by the German Ministry of Economics and Technology (grant ZIM KF2425003MS2).

7.

REFERENCES

[1] A. Mouttham, L. Peyton, B. E., and Saddik, A. E. Event-driven data integration for personal health monitoring. Journal of Emerging Technologies in Web Intelligence (2009), 144–148. [2] Amade, D. Joining oracle complex event processing and j2me to react to location and positioning events. http://www.oracle.com/technetwork/articles/amadeicep-090595.html (2010).

[3] Bade, D. Event stream processing on android. http://vsis-www.informatik.unihamburg.de/projects/esper-android/ (2010). [4] Brotcorne, L., Laporte, G., and Semet, F. Ambulance location and relocation models. European journal of operational research 147, 3 (2003), 451–463. [5] Centeno, R., Fagundes, M., Billhardt, H., and Ossowski, S. Supporting medical emergencies by mas. In Proceedings of the Third KES International Symposium on Agent and Multi-Agent Systems: Technologies and Applications (2009), Springer-Verlag, pp. 823–833. [6] Centeno, R., Fagundes, M., Billhardt, H., Ossowski, S., Corchado, J., Julian, V., and Fernandez, A. An organisation-based multiagent system for medical emergency assistance. In Proceedings of IWANN 2009, Bio-Inspired Systems: Computational and Ambient Intelligence (2009), Springer-Verlag, pp. 561–568. [7] Ciampolini, A., Mello, P., and Storari, S. A multi-agent system for medical services synergy and coordination. In International ECAI 2004 workshop on Agents applied in health care (2004), J. Nealon, ˝ U. Cortes, J. Fox, and A. Moreno, Eds., p. 38U46. [8] Dunkel, J. On complex event processing for sensor networks. In Proceedings of ISADS 2009: International Symposium on Autonomous Decentralized Systems (2009), IEEE, pp. 249–254. [9] Gendreau, M., Laporte, G., and Semet, F. A dynamic model and parallel tabu search heuristic for real-time ambulance relocation. Parallel computing 27, 12 (2001), 1641–1653. [10] Glover, F. Future paths for integer programming and links to artificial intelligence. Computers & Operations Research 13, 5 (1986), 533–549. [11] Henderson, S., and Mason, A. Ambulance service planning: simulation and data visualisation. Operations Research and Health Care (2005), 77–102. [12] I. Mohomed, A. Misra, M. E., and Jerome, W. Harmoni: Context-aware filtering of sensor data for continuous remote health monitoring. In Proceedings of Pervasive Computing and Communications (PerCom) (2009), IEEE, pp. 248–251. [13] Luckham, D. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley, 2002. [14] Lujak, M., and Billhardt, H. Coordinating emergency medical assistance. In Agreement Technologies, S. Ossowski, Ed., vol. 8 of Law, Governance and Technology Series. Springer Netherlands, 2013, pp. 597–609. [15] P. Wu, J. Zhu, J. Y. Z. Mobisens: A versatile mobile sensing platform for real-world applications. Journal of Mobile Networks and Applications (2013), 60–80. [16] Rajagopalan, H., Saydam, C., and Xiao, J. A multiperiod set covering location model for dynamic redeployment of ambulances. Computers & Operations Research 35, 3 (2008), 814–826.