CSU498 PROJECT

REPORT

EMERGENCY MEDICAL SERVICE USING MULTI-AGENT

SYSTEM

Submitted in partial ful�lment of

the requirements for the award of the degree of

Bachelor of Technology

in

Computer Science and Engineering

Submitted by

CHRISTY MARIA MATHEW B080196CSHARSH UPADHYAY B080478CSNITISH GUPTA B080616CSSHRADDHA JOSE B080049CS

Under the guidance of

Mr. Vinod Pathari

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERINGNATIONAL INSTITUTE OF TECHNOLOGY CALICUT

NIT CAMPUS PO, CALICUTKERALA, INDIA 673601

May 2, 2012

CERTIFICATE

This is to certify that the major project entitled �Emergency Medical Ser-

vice using Multi-Agent System� is a bona �de record of the work presented

by CHRISTY MARIA MATHEW (B080196CS), HARSH UPADHYAY

(B080478CS), NITISH GUPTA (B080616CS) and SHRADDHA JOSE

(B080049CS) under our guidance and supervision. The major project report has

been submitted to the Department of Computer Science and Engineering of Na-

tional Institute of Technology, Calicut in partial ful�llment of the award of the

Degree of Bachelor of Technology in Computer Science and Engineering.

Project Guide

Place : NIT Calicut Mr. Vinod Pathari

Date : 02-05-2012 Assistant Professor

Head of Department

O�ce Seal

2

Abstract

This project aims to study the concept of Multi Agent Systems andtheir real world applications. More speci�cally, we wish to demonstrate howMulti-agent systems can be used e�ciently in the �eld of Emergency MedicalService. Our goal is to automate the process of choosing the best hospital forpatients in emergency situations, depending upon the type of emergency andtheir geographical location. We also present an agent based algorithm thatreturns a list of optimal hospitals for a patient su�ering from heart attackand stroke.

Contents

1 Problem De�nition 2

2 Introduction 3

2.1 Multi-agent System . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Areas of application . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Tra�c signal control . . . . . . . . . . . . . . . . . . . 42.2.2 Management of organ transplants . . . . . . . . . . . . 42.2.3 Management of information within a palliative care unit 42.2.4 Enterprise integration . . . . . . . . . . . . . . . . . . 52.2.5 Modeling Network-Enabled Military Command and Con-

trol using Multiple Agents and Social Networks . . . . 52.3 Background and Recent Research . . . . . . . . . . . . . . . . 52.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Design 7

3.1 Requirement Speci�cation . . . . . . . . . . . . . . . . . . . . 73.1.1 Domain analysis . . . . . . . . . . . . . . . . . . . . . 73.1.2 Required parameters and constraints . . . . . . . . . . 7

3.2 Preliminary Design of the System . . . . . . . . . . . . . . . . 83.3 Proposed Agent Design . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 QoS ranking of hospitals by the Ticker Agent . . . . . 113.3.2 Algorithm for Request Handler . . . . . . . . . . . . . 13

3.4 Justi�cation for the choice of design . . . . . . . . . . . . . . 13

4 Implementation 14

4.1 Tool used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.1 Introduction to JADE . . . . . . . . . . . . . . . . . . 144.1.2 Advantages of using JADE . . . . . . . . . . . . . . . 14

4.2 Prototype Details . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Conclusion 18

References 19

1

Chapter 1

Problem De�nition

Automate the process of �nding the optimal choice of hospitals that canprovide the best available Emergency Medical Service (EMS) as per thenature of emergency such that this service is made available with the leastdelay, thereby minimizing the risk to the patient.

2

Chapter 2

Introduction

2.1 Multi-agent System

A multi-agent system (MAS) is a system composed of multiple intelligentagents[7]. These agents cooperate with each other and coordinate their ac-tivities in order to solve complex problems. A distinguishing feature of agentsis their autonomous nature. They adapt to any change in the environmentin a proactive and intelligent manner. This may include changing the wayinformation is searched for, retrieved and processed. The important charac-teristics of agents are summarized below:

• Agents do not have a global view of the system. Instead, they havetheir own set of beliefs (ontologies) which guide their behaviour.

• Agents display some measure of autonomy.

• A multi-agent system is decentralized, that is there is no central agentfor coordination or control.

Multi agent systems, also sometimes known as self-organized systems, at-tempt to arrive at the best solution without external interference of anykind. The individual strategies of the agents are simple, yet they displaycomplex behaviours like self-steering, cooperation, coordination etc. Theagents share their knowledge using messages that conform to the communi-cation protocol of the system. In other words they have their own languagethat is within the constraints of the system. Such systems may be used indomains with the following features:

• Information is spread across multiple locations

• Cooperation and coordination is needed between several intelligent en-tities for solving complicated problems.

• The problem can be split into sub-problems which may or may not beinterdependent[11].

3

2.2 Areas of application

The use of Multi-agent systems in �nding solution to the real world prob-lems, which are now handled manually, can lead to better performance. Fewapplications of Multi-agent systems in the real world, which were considered,are listed below. These applications show coordination and cooperation pro-vided by Multi-agent systems to formulate solutions.

2.2.1 Tra�c signal control

The general concept behind coordinating tra�c signals is to provide green-wave progression whereby a motorist travelling along a road receives continu-ous green signal. "The principal purpose of the control system is to minimizeoverall stops and delay by utilizing the maximum capacity of the system andminimizing the possibility of tra�c jams by controlling the formation ofqueues"[14]. So, if a system detects a tra�c incident, it must decide where,when, what and how to perform the control actions to deal with it. Currentapproaches towards a tra�c signal control are completely human based. Wepropose that a Multi-agent System (MAS) is able to almost-automaticallycarry out the required function.

2.2.2 Management of organ transplants

The aim is to �nd a suitable recipient who is nearest to the donor's hospital.This reduces the delay and the cost of organ transportation. This systemsuggests suitable recipients in close proximity to the hospital. The �naldecision is left to the donor's hospital. This system is used to manage organtransplants taking place at multiple locations within the same region[11].

2.2.3 Management of information within a palliative care

unit

To provide e�cient palliative care there is a need for cooperation betweenthe doctor's and the patient's sides. This is where MAS comes in handy.An agent at the patient's side monitors the patient and updates a centraldatabase. This database is located at the Palliative Care Unit and storesinformation about all the patients. If this agent notices any alarming symp-tom it immediately noti�es the agent at the doctor's end and ensures thatdoctor is informed[11].

4

2.2.4 Enterprise integration

Using MAS the planning and scheduling for product completion can be mon-itored, coordinated and the obtained information be communicated to thedepartments in charge. In the present system there is not much communica-tion between all the divisions. Agents assist in information and knowledgegathering which can be used for the planning process. This system has thecapability to cooperate with other systems and can even help in the deci-sion making process of system analysts and human managers. With thehelp of agents, rescheduling and completion of jobs on time can be e�cientlyachieved[12].

2.2.5 Modeling Network-Enabled Military Command and Con-

trol using Multiple Agents and Social Networks

It is possible to develop an architecture for such Command & Control systemsthat are based on an empirical model of a military commander's thinkingprocesses. We can add social networking constructs to a multi-agent systemand model network-enabled capabilities in a complex, real-world domain.The events of September 11, 2001, have been used as a case study in thisregard. The �aws in the existing hierarchical model of communication inmilitary are already studied and an alternative model of communication,using Multi Agent Systems, is proposed[8].

2.3 Background and Recent Research

The goal of research on multi-agent systems is to �nd methods that allow usto build complex systems composed of autonomous agents which operate onlocal knowledge and posses only limited abilities and are nonetheless capableof enacting the desired global behaviours.

"At its most ambitious, multi-agent systems aims at reverse-engineering emergent phenomena as typi�ed by ant colonies, theeconomy, and the immune system. Multi-agent systems approachesthe problem using the well proven tools from game theory, eco-nomics and Biology [15]."

Software can be developed that processes larger amounts of data and whichcan recognize patterns. Many multi-agent systems explore or monitor a givenspace, where each agent has only a local view of its own area. Each agentlearns a map of its world and the agents further share their maps in orderto aggregate a global view of the �eld and cooperatively decide which areasneed further exploration. This is a form of cooperative learning.

As per the literature, the possible variables for decision making in theemergency medical services are decided from the capabilities of hospital and

5

attributes of EMS stations. As variables are also associated with economic,technological, social and safety factors , the variables are classi�ed into di�er-ent domains say, equipment factors, professional factors, regulatory factors,environmental factors etc.Analysing the scenario, basically the following ac-tors are involved along the whole process: patients, coordinator sta�, physi-cians, ambulances and hospitals. These participants collaborate with eachother to assist patients as fast as possible[13].

An organization based multi-agent system for medical emergency assis-tance constructed on top of an abstract architecture speci�ed in the THOMASproject (MeTHods, Techniques and Tools for Open Multi-Agent Systems)has been studied.THOMAS platform allows for the integration of two wellestablished research �elds: Service-Oriented computing and Multi-agent Sys-tems. It uses the notion of organisation as a key abstraction to build MASin open environments[9].

2.4 Motivation

Current approach on a medical emergency is completely manual. The desiredoption is the closest hospital where the doctor and facilities are available.A complete manual approach causes delay which is least desired and mayeven be fatal. The proposed multi agent system can cut short this delayby processing the information gathered from di�erent hospitals in regularintervals and matching them with the patient's requirements.

6

Chapter 3

Design

3.1 Requirement Speci�cation

3.1.1 Domain analysis

On the medical community front, we consulted Dr. C.D. Joseph, cardiologist,Amala Hospital, Trichur, Dr. Anil Thomas M.B.B.S and Dr. Beena Ommen,Assistant Professor, Medical college, Calicut to collect information aboutthe symptoms and emergencies. They helped us by providing informationabout various types of emergencies from a doctor's perspective. We were alsoable to gather the information for properly ranking the hospitals in order ofpreference in case of an emergency based on the data from the hospitals.

3.1.2 Required parameters and constraints

Factors to be considered by the agent to decide on the best-�t option

1. Location: Closest hospital with the required facilities should be theoptimal choice. However, under certain situations where �rst aid be-comes critical, the nearest hospital with adequate �rst aid facilitiesbecomes our optimal choice. For example, stabilizing the condition oftrauma patients often takes higher priority[13].

2. Severity of condition: The nature of the emergency and the threatlevel together decides the severity of the request[13].

3. Availability of doctors or specialists: A farther hospital with therequired specialist at service is always a better option than a nearerhospital without adequate sta�. The professional level of doctors andnurses as well as their availability are to be considered[13].

4. Legal issues: Some hospitals in India, especially private hospitals,hesitate to admit patients due to legal constraints.

7

5. Availability of advanced technology and equipments: Availabil-ity of advanced technology and equipments required for the treatmentneeds special consideration. The total number of equipments in use andtotal number of all equipments in hospitals are important factors[13].

6. Availability of cots and rooms: The hospital should be able to suit-ably accommodate the patient at the emergency ward and e�cientlymanage the situation so that no patient will be left waiting at an emer-gency.

7. Availability of oxygen, medicines, bandages, syringes etc: Avail-ability of life sustaining medicines and other immediate requirementslike injections, syringes, bandages etc. becomes a major issue in cer-tain situations. For example, in cases involving snake bites availabilityof antidotes are of prime importance.

8. Degree of congestion: The number of people awaiting treatment inthe emergency ward determines the delay in treatment[13].

9. Ability to handle rush: The minimum employee strength of thehospital required to manage the rush at the time of emergency.

3.2 Preliminary Design of the System

The process of addressing medical emergency situations involves the follow-ing major roles:

• User: is responsible for sending a distress call to the Service Coordi-nator.

• Hospital: This role is played by the hospitals which are a�liated tothis service. They must send data periodically to the Service Coordi-nator (the data consists of the parameters mentioned in section 3.1.2).They are also responsible for dispatching a suitable ambulance to thelocation of the patient(s).

• Middle man or Service Coordinator: Responsible for returningthe optimal choice of hospitals based on the updates sent by the hos-pital and the nature of the distress call to the patient. They also keeptrack of the situation in the hospitals by receiving periodic updatesfrom them.

8

Figure

3.1:

Overviewof

thesystem

design

.

9

Following are the various agents that individually, or in collaborationwith other agents, represent the aforementioned roles (Figure 3.1):

• Mobile Agents: They represent the user and send the distress call tothe Request Handler Agent. They also receive the optimal list ofhospitals form the request handler and contact the Hospital Agentthat represents the chosen hospital. Each user is represented by aseparate mobile agent. It should be noted that our usage of the term"Mobile Agents" merely implies that these agents reside on the user'shand-held device. They do not travel from one device to another.

• Hospital Agent: They represent the participating hospitals (eachagent representing an individual hospital) and provide periodic updatesto the Ticker Agent. They also receive request for service from theMobile Agents who have made their choice and dispatch a suitableambulance to the patient's location.

• Request Handler: It is a part of the Service Coordinator. TheRequest Handler receives the SOS request from the user. The RouterAgent receives and forwards the requests to the appropriate agentsdepending upon the type of emergency (Figure 3.2). That agent sendsa request to the ticker agent, which returns the list of optimal choiceof hospitals. It takes the locational factors into account and producesa new list. Based on the user preference (speci�ed in the SOS requestreceived earlier), it will do one of two things:

1. Directly ask the best hospital to send the ambulance

2. Return the list of options to the user.

• Ticker Agent: It is a part of the Service Coordinator. It is madeup of multiple small Ticker Agents (Figure 3.3), each responsible for adi�erent kind of emergency. Each such agent is composed of a Filterand a Sorter Agent. Each agent receives a periodic broadcast fromevery hospital (broadcast data consists of ALL parameters mentionedin section 3.1.2). The Filter Agent extracts the relevant informationdepending upon the type of emergency it is supposed to handle. Itthen sends the information to the Sorter Agent that ranks the hospitalsbased upon those factors. It then returns the list of hospitals back tothe Request Handler.

10

3.3 Proposed Agent Design

In this section we present the behaviours that are implemented in the RequestHandler and the Ticker agents:

3.3.1 QoS ranking of hospitals by the Ticker Agent

Ranking algorithm for case heart attack

Weighted sum of factors: The primary factors here are the medicineand equipments the absence of which reduces the desirability of the hospitalsigni�cantly. In the present medical emergency, any doctor can start themedication provided medicine and equipments are available. So this factoris given the highest weight of 1000 and if absent a negative weight of -500.

The next factor is the availability of specialist which is given a slightlylower priority (and hence a weight of 450) than any one of medicine orequipment considered because the expertise of a specialist is utilised onlywhen adequate medicines and equipments are present.Availability of cots is the next important factor which is given a lower weightof 300.

The hospital with a higher congestion to rush ratio is always more de-sirable as more people are available to render medical service. This alsoindicates how the quality of service provided by a hospital changes eachtime an additional patient is admitted.

The hospitals with legal issues are generally not preferred by patients. Butgiven the chance of survival is higher in such a hospital then legal issues doesnot have much impact. So they are given a weight of -300 if present and 0 ifnot.

It should be noted here that the value of the weights were arbitrarily choseninitially. These values were further �ne-tuned via trial and error method sothat the system does not return some absurd result.

11

Algorithm

1. For every hospital H, de�ne:

Congestion = sta� strengthtotal number of patients+1

Rush = Number of emergencies in the past 24 hours

To Rank the factors:

//med - Medicines, eqp - equipments (ECG desibrillator)if (med = True ∧ eqp = True)

wme = 1000 ; //weightage of med and eqpelseif (med = True ∨ eqp = True)

wme = 500 ;else

wme = -500 ;

//Specialist availability

if (sp = True)wsp = 450 ;

else

wsp = 0 ;

// Availability of cots

if (cots = True)wcots = 300 ;

else

wcots = 0 ;

if (congestion < 0.5)wcon_rush = 0 ;

else

wcon_rush =(congestionrush+1

)∗ 100 ;

if (legal_issues= True)wlg = -300 ;

else

wlg = 0 ;

12

// �nally, we sum the weightages to obtain total weight associated with H

WH = wme+ wsp+ wcots+ wcon_rush+ wlg

2. Rank the hospitals in the decreasing order of their weightages

3. Send the list of top 5 hospitals to the request handler

3.3.2 Algorithm for Request Handler

The following steps are involved in deciding the optimal choice of hospital:

1. Get the time to reach top 5 hospitals from patient's current location.

2. From the information sent from hospital, get the time to access themedical support

3. time to serve ti = max {time to reach hospital i, time to access medical support of hospital i}

4. Send the list of hospitals along with their respective time to serve valuesto the user agent

The request handler has the list of hospitals in the decreasing order ofpriority (ranked based upon the quality of service). It includes the timefactor to the list of hospitals and send it to the user agent which requestedfor the service.

3.4 Justi�cation for the choice of design

In the process of choosing the optimal hospital, we need to continuouslygather data from the participating hospitals. Each of these data gatheringattempts are quite complicated in themselves. Furthermore, there can bemultiple simultaneous requests. This adds to the complexity of the problem.Keeping in view the nature of the application domain and its high complex-ity, we have modeled the system as a multi agent organization. Reliability,robustness, maintainability, responsiveness are our major concerns here.[5]

Use of a traditional client-server approach towards such a problem is im-practical because it would put too much strain on any one single entity. Thisleads to a severe performance bottleneck and a single point of failure. TheMAS approach distributes computational resources and capabilities across anetwork of interconnected agents. Since, an MAS is inherently decentralized,it does not su�er from a single point of failure.

An MAS consists of multiple, autonomous agents, which compute inde-pendently, thereby increasing the computational e�ciency. The informationfrom multiple agents, which may be spatially distributed, needs to be re-trieved, �ltered and coordinated[7]..

13

Figure 3.2: Structure of the Request Handler Agent.

14

Figure 3.3: Structure of the Ticker Agent.

15

Chapter 4

Implementation

4.1 Tool used

We aim to simulate the aforementioned architectural design using a suit-able multi agent development platform. For this purpose our framework ofchoice is JADE[6] (Java Agent DEvelopment Framework), a product underdevelopment by Telecom Italia Lab

4.1.1 Introduction to JADE

"JADE can be considered as an agent middleware that im-plements an agent platform and also provides a development en-vironment to create Java agents"[6].

An agent based application developed using JADE complies with the FIPA[3](Foundation for Intelligent Physical Agents) speci�cations for interoperableintelligent multi agent systems. It deals with message transport, encodingand parsing, or agent life-cycle; aspects that are independent of the applica-tions and are not part of any particular agent's behaviour. Agents commu-nicate with each other using ACL (Agent Communication Language).

4.1.2 Advantages of using JADE

• The whole JADE source code is distributed under an open source pol-icy, the Lesser GNU Public License (LGPL)[4].

• JADE is portable in di�erent run time environments (Figure 4.1), be itmobile or laptop, thanks to LEAP(Light ExtensibleAgent Platform).

• JADE o�ers an excellent suite of programming and testing tools.

• The JADE project is supported by a well maintained community website where users can download code and documentation, report possible

16

bugs and browse a collection of useful links maintained by the JADEteam.

Figure 4.1: JADE Architecture in the Wireless Environment [10].

4.2 Prototype Details

Implemented features

Features currently implemented in our prototype include the following -

• The algorithms for heart attack and stroke have been coded using theJava Agent DEvelopment Framework (JADE).

• All the agents, as given in the architectural design, namely the user,router, request handler, ticker agent and hospital agent have been im-plemented successfully,

• All the agents are run on di�erent computers connected via LAN.

• The prototype caters to two types of emergencies - heart attack andstroke.

• We have also implemented a one way sms scheme. The output is sentas an sms to the user's mobile number. The user is still emulated onthe computer as a user agent.

17

Third party technologies

The user agent normally resides on the patient's mobile phone while therest of the system runs on servers connected via the internet. Thus, theimplementation needed some kind of gateway that allow it to communicatewith mobile phones on networks such as GSM/GPRS or CDMA.

To implement our one way sms scheme, we made use of Java APIs suppliedby www.clickatell.com [2], an sms gateway provider. These APIs allow theagent to submit the message string and the destination mobile phone numberto the gateway provider which does the job of sending the message.

Challenges faced

Following were the challenges encountered during the development of this

system -

• Agent Intelligence: Human experts have their own set of heuristicsor rules of thumb that help them in making decisions when solving aproblem or making inferences from the given data. The challenge wasto develop heuristics which our automated agents can use to decideupon hospitals that are likely to provide the best service, and thenrank them in decreasing order of service quality. Additional heuristicswere needed to arrive at a solution which o�ers the optimal balancebetween the quality of service o�ered and the proximity of that hospi-tal. The �nal aim is to choose a hospital such that the probability ofpatients' survival is maximized.This requires considerable knowledge input from the medical commu-nity and the application of sophisticated techniques likeAHP(AnalyticHierarchy Process)[1].

• Agent Coordination and Cooperation: In our architecture, theTicker agent must cooperate with the Request Handler in order tokeep it aware of the latest hospital ranks. The Request Handler mustcoordinate with the Ticker so that it always works with the latest hos-pital rankings. If the hospital rankings change while a user request isbeing processed then this processing must be aborted and the calcula-tion restarted with the latest data.Implementation of such a scheme in the Request Handler was a chal-lenge since this agent receives messages from multiple User Agents.The periodic update message from the Ticker Agent might not be re-ceived at all if the message bu�er is full of pending user requests.Also, JADE usually employs cooperative multiprocessing for parallelbehaviours which prevents us from interrupting the request processingcalculation. Thus, multi-threaded behaviours had to be implemented

18

which carry certain risks as a thread may not stop immediately whenit receives the interrupt signal.

19

Chapter 5

Conclusion

Multi Agent Systems approach proves to be e�cient in such complex sce-narios where implementing the solution using traditional approach becomesimpractical. With regards to our problem, this approach will certainly pro-vide a highly robust and reliable system in addition to speeding up the entiredecision making process. Our project helps people in health emergency sit-uations. It would aid them in making the correct choice of hospitals and cutshort the delay in receiving medical attention.

We are yet to conduct an extensive �eld test for our design. Since this is amatter of medical emergency , it is natural that users will display skepticismregarding the reliability of the responses given by the system. Therefore, wehave implemented it as a decision aid system where the user makes the �naldecision. Also the user agent is yet to be deployed on a mobile platform.

Future work

In addition to what has already been done so far, we plan to let the medicalcommunity have a look at our proposed solution. This will help us get anidea about the feasibility and practicality of our solution, and also how farour solution is from reality.

20

Bibliography

[1] Analytic hierarchy process - wikipedia, the free encyclopedia. http:

//en.wikipedia.org/wiki/Analytic_Hierarchy_Process. March 16,2012.

[2] Clickatell bulk sms gateway. http://www.clickatell.com/.

[3] Foundation for intelligent physical agents. http://www.fipa.org. Oc-tober 23, 2011.

[4] Gnu lesser general public license v3.0 - gnu project - free software foun-dation (fsf). http://www.gnu.org/licenses/lgpl.html. October 20,2011.

[5] Intelligent software agents. http://www.cs.cmu.edu/~softagents/

multi.html. October 19, 2011.

[6] Jade - java agent development framework. http://jade.tilab.com.October 21, 2011.

[7] Multi-agent system - wikipedia, the free encyclopedia. http://en.

wikipedia.org/wiki/Multi-agent_system. October 19, 2011.

[8] Giulia Andrighetto, Guido Boella, Jaime Sichman, and HarkoVerhagen, editors. Social Networks and Multi-Agent Systems

Symposium(SNAMAS-09), number ISBN-1902956753, Heriot-WattUniversity, Edinburgh, Scotland, April 2009. The Society for the Studyof Arti�cial Intelligence and the Simulation of Behaviour(SSAISB).Symposium held at the AISB 2009 Convention.

[9] Roberto Centeno, Moser Fagundes, Holger Billhardt, Sascha Ossowski,Juan Manuel Corchado, Vicente Julian, and Alberto Fernandez. Anorganisation-based multiagent system for medical emergency assistance.Technical report, CETINIA, University Rey Juan Carlos Madrid, Uni-versidad de Salamanca, Universidad Politecnica de Valencia Spain,2010.

[10] F.Bellifemine, G.Caire, A.Poggi, and G.Rimassa. Jade a white paper.September 2003.

21

[11] Antonio Moreno, A. Valls, and D. Riano. Medical applications of multi-agent systems. presented at ECAI Workshop on Agents Applied inHealth Care, Valencia, Spain, 2004.

[12] Finin T. Labrou Y. Chu B. Long J. Tolone W.J. Peng, Y. andA Boughannam. A multi-agent system for enterprise integration. InProceedings of the Third International Conference and Exhibition on

the Practical Application of Intelligent Agents and Multi-Agent Tech-

nology, H.S. Nwana and D.T. Ndumu (Eds.), pages 155�169, London,UK, March 1998.

[13] Hsiao-Hsien Rau, Chien-Yeh Hsu, Ajit Kumar, and Ni chun Hung. Iden-ti�cation of variables to decide optimal hospital for emergency patients.Technical report, Taipei Medical University, National Taipei Universityof Nursing and Health Science, Taipei,Taiwan, February 2011.

[14] S. S. Shamshirband, H. Shirgahi, M. Gholami, and B. Kia. Coordinationbetween tra�c signals based on cooperative. World Applied Sciences

Journal, 5(5):520�525, 2008.

[15] José M. Vidal. Fundamentals of Multiagent Systems. Morgan KaufmannPublishers, 2007.

22