Iñaki Martinez-Sarriegui
Hong Zhu
, Lijun Shan
, Gema García-Sáez
, Enrique J. Gómez
and M. Elena Hernando
Bioengineering and Telemedicine Centre, Politechnical University of Madrid, Spain
CIBER-BBN Networking Research Centre, Spain
Department of Computing, Oxford Brookes University, U.K.
Department of Computer Science, National University of Defence Technology, China
Keywords: Software agents, MAS Formal Specification, Modelling, Diabetes Care, Telemonitoring, Telemedicine.
Abstract: This paper presents the modelling and formal specification of a telemedicine system for diabetes care. In
such scenario, the multiagent technology supports the distributed autonomy of several Personal Assistants;
the communications between them and the hospital´s agents; the control of the system´s access and
multitask functionality; scalability; adaptability; robustness; and the provision to the physicians with the
necessary automatic processing tools for the analysis of the large amounts of data generated by patients. We
evaluated the AOIS meta-model and the CAMLE’s modelling environment concluding that this
methodology is adequate to represent a complex medical system like the one presented. The model and the
formal specification provide a more complete view of the system and contain very useful information to
cope with the future system evolution.
Diabetes is the fourth leading cause of global death
by disease. Currently 246 million people worldwide
suffer from diabetes and the forecast for 2025 is that
it will increase to affect 380 million (IDF, 2003).
Diabetes Mellitus is a chronic disease characterised
by a sustained elevated blood glucose level, caused
by a reduction in the action of insulin secretion
where related metabolic disturbances generate
severe, acute and long-term complications that are
responsible for premature death and disability (De
Leiva et al., 1995). Effective control of patients’
blood glucose level minimises the progression of the
disease and reduces the risk of long-term
neurological, renal and cardiovascular
The treatment of diabetic patients attempts to
achieve normal levels of blood glucose by
maintaining a careful balance between diet, physical
exercise and insulin injections therapy. Patients
monitor their own blood glucose levels to take
decisions regarding the adjustment of changes of
insulin doses, meals and physical activity.
Due to its multifactorial and systemic character,
Diabetes Mellitus has been considered a paradigm of
chronic disorders which has led to an extensive
application of information technologies. Nowadays
telemedicine provides an integrated approach to
information technology tools, which enhances co-
operation between users, information and knowledge
Any telemedicine system for chronic care has to
help patients’ and physicians’ decision making but
supposes a huge quantity of data and increases
users’ workload.
To define and develop a telemedicine system for
chronic care it is important to know well the
characteristics of health care and then choose the
best design and technology for the implementation.
Health care is characterized by requiring distributed
knowledge to solve the different problems requiring
cooperation between professionals of different
independent entities. Generally the problems are too
complex and are decomposed in sub-problems easier
Martinez-Sarriegui I., Zhu H., Shan L., García-Sáez G., Gómez E. and Hernando M. (2009).
In Proceedings of the International Conference on Agents and Artificial Intelligence, pages 507-512
DOI: 10.5220/0001661405070512
to solve. It is needed a continuous access to medical
information and this information has to be personal
and proactive (professionals usually ask information
about diseases or surgery before they have to face
the problem).
The properties and features of multiagent
systems (MAS) perfectly fit with the characteristics
of health care above commented: distributed
systems, sociability, management of distributed
information, autonomy, proactivity, communication
and coordination between separate entities (Nealon
and Moreno, 2003).
There is a growing interest in the application of
agent-based techniques (Wooldridge, 2002) to
problems in the medical domain in different fields
and oriented to several diseases. Some examples are
Health Care at home (Koutkias et al., 2005), Health
Care coordination (Aldea et al., 2001).In diabetes
care there have been also some applications of the
agents approach. In monitoring field we can see the
SuperAssist project (De Haan, 2005), or the M2DM
project (Hernando et al., 2003) and in management
field the project proposed by Zhang et al. (2008)
Modelling plays a crucial role in the
development of medical systems and its evolution as
the main tool of requirements analysis and
system/component design, representing the users’
requirements with a set of agents at various
granularities and organizing the agents into an
information system.
This paper presents the adequacy of the AOIS
meta-model (Zhu, 2005) for the modelling and
formal specification of a complex telemedicine
system for diabetes care (Hernando et al., 2004;
Rigla et al., 2007).
2.1 Modelling and Formal
In the AOIS meta-model, the basic unit that forms
an information system is the agent (Zhu, 2005).
Agents are defined as real-time active computational
entities that encapsulate data, operations and
behaviours, and situate them in their designated
environments.Agents perceive the visible actions
and states of the agents in its environment and take
actions and change state according to the situation in
the environment and its internal state. A multiagent
system (MAS) consists of a group of agents.
In the conceptual model, the classifier of agents
is called caste, the basic brick of MAS. Caste serves
as a template that describes the structure and
properties of agents. Agents are instances of castes.
Caste allows dynamic classification. That is, an
agent can change its caste membership (casteship) at
run-time. An agent can take an action to join a caste
or retreat from a caste at run-time. When an agent
joins/retreats from a caste, it will obtain/lose the
structural and behavioural features of the caste.
Dynamic casteship allows users to model the real
world with MAS naturally and to maximize the
flexibility and power of agent technology.
In the AOIS model, state variables and actions of
an agent can be visible or invisible (internal). Agents
communicate with each other by taking visible
actions and changing visible state variables, and by
observing other agents’ visible actions or
statesVisible actions are only observed by those
agents interested in the agent’s behaviour.
Agents in a MAS are designed and implemented
with a designated environment. In other words, the
environment of an agent is specified but allowed to
vary within a certain range when an agent is
2.1.1 CAMLE
The Caste-centric Agent-oriented Modelling
Language and Environment (CAMLE) is a language
that employs the multiple views principle to model
complicated systems (Shan et al., 2006). In CAMLE
there are three types of models that may consist of
one or more diagrams:
A caste model normally comprises one caste
diagram with a set of caste nodes representing
various types of agents in the system, and a set
of links representing various relationships
between agents of the castes.
A collaboration model may consists of a set of
scenario-specific collaboration diagrams that
represent the interactions between agents in
specific scenarios, and a general collaboration
diagram that summarises the communications
between agents.
A behaviour model. It describes an agent’s
behaviour in terms of how it acts in certain
environment scenarios at the micro-level.
2.1.2 SLABS
The Specification Language for Agent-Based
Systems (SLABS) bridges the gap between graphic
modelling and implementation in the AOIS
development process (Zhu 2001, Zhu 2003).
The manual production of a multi-agent systems
formal specification is labour-intensive, costly, time
consuming and error-prone. The CAMLE modelling
ICAART 2009 - International Conference on Agents and Artificial Intelligence
environment automatically generates the formal
specifications from the graphic models.
2.2 Modelled System
The following scenario illustrates the functionalities
of the telemedicine system covered in the modelling
and specification.
Scenario 1:
Carmen is a type 1 diabetes patient that is
followed up with a telemedicine service. She is
provided with a PDA running a special application
for diabetes management that download monitoring
data from glucometers and insulin pumps using
wireless communication. Additionally she can insert
her blood glucose levels manually, view graphics
and review all her monitoring data that are stored in
a light database on the PDA. She has to periodically
synchronize the PDA database with the one in the
hospital. She could use the telemedicine Web
application to insert the data directly to the hospital
database but she prefers the PDA because she feels
more autonomy with it.
Scenario 2:
Luisa is an endocrinology physician. She
consults patients’ monitoring data through the Web.
She selects from which patient she wants to view
data, having the opportunity of viewing graphics
that helps her to take therapeutic decisions.
According to the data received from patients, she
decides to change their insulin therapy. Therapies
are stored in the hospital database and patients
receive the new therapy after synchronization.
Scenario 3:
Carmen synchronizes the databases again and
receives a message informing she has a new therapy.
She views the new therapy and configures the insulin
pump with the new therapy’s data. A reminder tool
is set to warn the patient if the synchronization
period is longer than a pre-fixed number of days.
Figure 1: Caste Diagram.
The modelling of the telemedicine system has been
performed by specifying caste diagram,
collaboration diagrams and behaviour diagrams.
3.1 Caste Diagram
We identified two different types of castes: actors
and software agents in the telemedicine system.
Figure 1 presents the caste diagram.
3.1.1 Actors
Actors are the users (patients and doctors), the
medical devices they use (insulin pump and
glucometer) and the databases of the system. Actors
are not agents but have to be represented in the
model in order to clarify the working process of the
3.1.2 Software Agents
We define 8 types of software agents as illustrated in
Figure 1:
Interface: This agent represents the graphic
interface of the applications. It allows users to
access the functionalities of the system.
Application-Logic: It is the logic of the users’
application and represents the applications
intelligence. It knows all the software agents
of the system and communicates with them to
provide the functionality demanded by the
Reminder: It warns the patient after a pre-fixed
number of days since the last synchronization.
DP: This agent is in charge of automatic data
pre-processing when new monitored data is
received from the PDA.
Graphics: It is the responsible of the on-line
generation of graphics on users’ demand.
MedDeviceComm: This agent manages the
communication between the applications and
the medical devices
DB-SQL: This agent is the only one that can
access the system data and manages and filters
the operations of other agents with the
DB_Sync: This agent manages the process of
database synchronization.
Figure 2: Collaboration diagram of Database Synchronization functionality.
3.2 Collaboration Diagrams
The main collaboration diagram describes all the
communications between agents. Additionally, we
created eleven specific communication diagrams -
one for each of the different functionalities offered
by the system in the scenario described in section
2.2 - detailing not only the communications but also
the sequence of them.
We classify the eleven specific communication
diagrams into three types according to participants:
patient, doctor or both:
‘Patient Diagrams’
: Configuration of Medical
Device; Downloading of data from Medical
Device; Database Synchronization; Database
Synchronization Reminder.
‘Doctor Diagrams’
: Patient Selection;
Creation/Modification of a New Insulin
‘Patient/Doctor Diagrams’
: Viewing of Data;
Insertion of Data; Viewing Graphics; Login
on the system; Viewing Therapy.
Figure 2 shows an example of the collaboration
diagram for database synchronization. The patient
can use an application running on a PDA (Interface
and Application-Logic) and store the data on a local
database, a light version of the one used in the
hospital. The patient has to synchronize both
databases. When he/she executes this action the
Application-Logic asks the patient’s password to
check the identity. In this process the Application-
Logic consults the database to verify the password.
Once the patient has been identified the
Application-Logic starts the synchronization
process. For security reasons, the access to databases
is restricted and has to be made through DB-Sync
agent, which is responsible of talking with the two
databases to really start the process. When the
databases have exchanged the data, DB-Sync agent
informs Application-Logic with the result of the
After the synchronization process, the first
Application-Logic action is to check the database for
new therapy prescription or messages. If there is any
new therapy, the Application-Logic agent informs
the patient. After that it communicates to DP agent
that a synchronization process has been made and
stores the event on the database. All the events in the
system are stored for auditory reasons.
The data downloaded from the insulin pump are
stored in the PDA database in a compressed mode
due to their size. In hospital database there are no
restrictions of size like in the PDA so those data can
be uncompressed. This task is made by DP agent
accessing the hospital database, processing the data
and storing them again.
ICAART 2009 - International Conference on Agents and Artificial Intelligence
Figure 4: Formal Specification diagrams of the castes: a) DB-Sync, b) DB-SQL, c) Database and d) Reminder.
3.3 Behaviour Diagrams
In the behaviour diagrams we detail the behaviour of
the agents of the system by specifying the rules that
need to be followed to provide the desired
In the collaboration diagrams we can see the
sequence of messages, while on behaviour diagrams
this sequence is illustrated giving the conditions that
have to be accomplished for the specific sequence.
For instance, “one database cannot send data to other
database if it does not receive the order from DB-
Sync agent” and “the DB-Sync agent cannot order
the start of a synchronization before the Application-
Logic specifies it”.
The behaviour diagrams of some of the
agents/castes are very large because they developed
a lot of functions in the system. In Figure 3 we
illustrate the behaviour diagrams of Graphics caste
and Reminder caste as an example of the behaviour
diagrams of the system.
3.4 Formal Specification
Once the model of the system is constructed, the
formal specification can be automatically generated
with CAMLE tool. Figure 4 shows an example of
the diagrams of the DB-Sync caste, DB-SQL caste,
Database caste and Reminder caste. When the
definition of the model and the formal specification
are finished, the implementation phase can start and
can be easily faced by the developers.
Figure 3: Behaviour diagram for: Reminder caste.
The described system supposes a step forward to the
goal of an ‘ambulatory artificial pancreas’. The
evolution of medical devices is creating a very
promising situation. However, its ambulatory use
requires the integration of close loop algorithms and
medical devices in Personal Assistants running on
portable terminals with communication capacities,
providing patients with mobility possibilities,
decision support tools and doctors’ remote
supervision and, at the same time, autonomy on their
An ‘ambulatory artificial pancreas’ is a complex
concept. In such scenario, the multiagent technology
supports the distributed autonomy of several
Personal Assistants; the communications between
them and the hospital´s agents; the control of the
system´s access and multitask functionality;
scalability; adaptability; robustness; and the
provision to the physicians with the necessary
automatic processing tools for the analysis of the
large amounts of data generated by patients.
We can conclude that the multiagent approach is
the approximation that better fits with those needs
and the AOIS meta-model facilitates the definition
and design of the required architecture. The
graphical interface of the CAMLE’s modelling
environment tool helps in the process of modelling,
allowing an easy creation of the different model
diagrams and providing an automatic checking of
the model consistency. The CAMLE tool also allows
the generation of the formal specification directly
from the different diagrams, which is a unique
feature among other similar environments where the
formal specification has to be manually done.
The presented model describes the current
functionality of a working multiagent system that
started to run in a hospital six years ago. The model
and the formal specification provide a complete
view of the system and contain very useful
information to cope with the future system
Aldea, A. et al. 2001. A Multi-agent System for Organ
Transplant Co-ordination. In the 8th Conference on AI
in Medicine in Europe: Artificial Intelligence
Medicine, LNCS 2101. Springer-Verlag.
De Leiva, A., Lefèbvre P. and Nerup J., 1995. European
dimension of Diabetes Research. Diabetologia, 39, p.
De Haan, G., O.B. Henkemans, and A. Aluwalia. 2005.
Personal Assistants for Healthcare Treatment at Home.
In the 2005 annual conference on European
association of cognitive ergonomics. Ghania, Greece.
Hernando, M.E., et al. 2003. Multi-agent Architecture for
the Provision of Intelligent Telemedicine Services in
Diabetes Management. In the workshop on Intelligent
and Adaptive Systems in Medicine. Prague, Czech.
Hernando, M.E, García-Sáez, G., Gómez, E.J. and del
Pozo, F. 2004. Intelligent Alarms Integrated in a
Multi-Agent Architecture for Diabetes Management.
Transactions of the Institute of Meassurement &
Control. 26(3), p 185-200.
International Diabetes Federation, 2003. Diabetes Atlas,
Brussels, 2nd Edition.
Koutkias, V. et al. 2002. A Multiagent System Enhancing
Home-Care Health Services for Chronic Disease
Management. IEEE Transactions on Information
Technology in Biomedicine, 9(4)
Nealon, J.L. and Moreno, A., 2003. Agent-Based
Applications in Health Care. In Applications of
Software Agent Technology in the Health Care
Domain. Basel, Germany. pp. 3-18.
Rigla et al. 2007. A Telemedicine System that Includes a
Personal Assistant Improves Glycemic Control in
Pump Treated Patients with Type 1 Diabetes. Journal
of Diabetes Science and Technology. 1(4), p. 505-510
Shan, L., Shen, R., Wang, J., Zhu, H., 2006. Caste-centric
Development of Agent Oriented Information Systems,
Handbook of Research on Nature Inspired Computing
for Economy and Management, Jean-Philippe Rennard
(Ed.), Idea Group Inc. p. 692-707.
Wooldridge, M. 2002. An introduction to Multiagent
systems. John Wiley, Chichester.
Zhang et al. 2008. Enhance Collaboration in Diabetic
Healthcare for Children using Multi-agent Systems.
AT2AI-6 Working Notes, From Agent Theory to
Agent Implementation, AAMAS 2008, Estoril,
Portugal, EU.
Zhu, H., 2001. SLABS: A Formal Specification Language
for Agent-Based Systems, International Journal of
Software Engineering and Knowledge Engineering,
Vol. 11. No. 5, pp. 529~558.
Zhu, H., 2003. A formal specification language for agent-
oriented software engineering, in Proc. of
AAMAS'2003, Melbourne, Australia, pp 1174 – 1175.
Zhu, H. 2005. Formal Reasoning about emergent
behaviour in MAS, Proceedings of SEKE’05, Taipei,
pp 280-285.
ICAART 2009 - International Conference on Agents and Artificial Intelligence