MAS course at URVF, lecture 12, URV applications of MAS in health care

1. LECTURE 12:
Applications of MAS
at URV (II)
Artificial Intelligence II – Multi-Agent Systems
Introduction to Multi-Agent Systems
URV, Winter-Spring 2010

2. Outline of the talk
Rationale for applying agents in health care
Some specific projects developed by the
members of ITAKA
Management of data of palliative patients
Web-based platform for providing home
care services
Research and development challenges
Final thoughts
http://deim.urv.cat/~itaka

3. Information and Communication
Technologies
End of 20th century: enormous development of
information technologies
Mobile phones
Personal and portable computers
Personal Digital Assistants (PDAs)
Internet
Information Society
Easy, flexible and cheap access to information

4. ICT and MAS
Recent trend: join the intelligent
performance of multi-agent systems with
the flexible access to information through
new technologies
Future scenario: ambient intelligence, in
which ubiquitous agents communicate
wirelessly to provide intelligent services to
users
In particular, AmI@Medicine

5. Health Care problems
Distributed knowledge
E.g. different units of a hospital
Coordinated effort
E.g. receptionist, general and specialised
doctors, nurses, tests personnel, ...
Complex problems
E.g. organ transplant management
Great amount of information
E.g. medical information in Internet

6. MAS applied in Health Care
Summary of main motivations
MAS are inherently distributed
Agents can coordinate their activities, while
keeping their autonomy and local data
Dynamic and flexible distributed problem solving
mechanisms
Use of personalisation techniques
Example: national organ transplant coordination

7. Fields of application
Patient scheduling
Patient monitoring
Agent-based decision support systems
Information agents in Internet
Community care, home care, care of
old/disabled people
Access to medical information
Management of distributed processes

8. Outline of the talk
Rationale for applying agents in health care
Some specific projects developed by the
members of ITAKA
Management of data of palliative patients
Web-based platform for providing home care
services
Research and development challenges
Final thoughts

9. PalliaSys Project
Integration of Information Technologies and
Multi-Agent Systems to improve the care
given to palliative patients
Spanish research project, 2004-05
Work conducted between the Research
Group on Artificial Intelligence at URV and
the Palliative Care Unit of the Hospital de la
Santa Creu i Sant Pau of Barcelona

10. Palliative care
Palliative patients are in a very advanced
stage of a fatal disease. The aim of their care
is to ease their pain
These patients may be located in hospitals
(Palliative Care Units-PCU, or other units of
the hospital), specialised hospice centres or
at their own homes

11. Aims of the PalliaSys project
To improve the process of collecting
information from the palliative patients
To improve the access to this information by
patients and doctors
To monitor the state of the patients
To apply intelligent data analysis techniques
on the data of the PCU

12. Information Multi-Agent
Technologies System
WAP
Server
Simul.
Data
Web Anal.
Web interface
Server
PCU Database
PCU Head
Patient DB Wrapper
Patient
PALLIASYS
Architecture
Alarm Doctor
management
Doctor
Web interface

13. Information collection
Patients have to send periodically non-
technical information relative to their health
state
Fill in a form with 10 items to be valued in
the [0-10] interval
In the developed prototype forms could be
sent
through a Web page, or
with a mobile phone via WAP (simulated)

14. Information access
All the data of the palliative patients are
stored in a central Data Base at the PCU of
the hospital
Personal information, family data, auto-
evaluations, health record
Patients and doctors may make queries on
the stored information
Patient queries are made directly on the DB (via
Web or WAP-simulated interface)
Doctor queries are made through agent
communication (the Doctor Agent requesting the
information from the DB Wrapper)

15. Data Base at the PCU / Security
There is an agent that controls the access to
the Data Base (the DataBase Wrapper)
The whole system includes security
mechanisms to protect the privacy of the
medical data
User authentication (private-public keys)
Encrypted messages (SSL)
Access through login/password
Permissions associated to user types

16. Information Multi-Agent
Technologies System
WAP
Server
Simul.
Data
Web Anal.
Web interface
Server
PCU Database
PCU Head
Patient DB Wrapper
Patient
PALLIASYS
Architecture
Alarm Doctor
management
Doctor
Web interface

17. Patient agents
There is a patient agent associated to
each palliative patient
It has to continuously monitor the status of
the patient, and send alarms to the doctor
associated to the patient if something goes
wrong

18. Doctor agents
A doctor agent is an agent associated to each
doctor of the PCU, which would be running in
the doctor’s desktop computer
It provides a graphical interface to help:
Request information about his patients
Define alarm situations
Receive alarm signals from patient agents

19. Classes of alarms
General alarms
They are defined by the PCU head (through his
Doctor Agent), and they have to be applied to all
the patients of the unit
Doctor-specific alarms
A doctor can define personal alarms, and he can
assign them
to a single patient, or
to all his patients

20. Patient auto-evaluation
There are 10 differents aspects in patient’s
auto-evaluation forms (weakness, pain,
anxiety, hunger, etc)
Each of the aspects has to be evaluated by
the patient with an integer number from 0
to 10.
Each patient has to send an auto-
evaluation form every 2-3 weeks

21. Alarm types (I)
Alarms defined on a single auto-evaluation
(Weakness >7) and (Pain > 8) :
extreme_weakness
(Hunger < 3) and extreme_weakness:
dangerous_weakness
Extreme_weakness => patients 1, 3 and 4
Dangerous_weakness => patients 2, 3 and 7
Basic alarms can be combined with and/or/not
operators to define more complex alarms

22. Alarm types (II)
Alarms defined on a sequence of auto-evaluations
(Last 2 evaluations a,b) Weaknessb-Weaknessa > 2 :
fast_weakness_increase
(Last 4 autoevaluations a,b,c,d) Paind-Paina > 3:
extreme_pain_increase
(Evaluations received in the last 3 weeks)
Increase of pain degree > 4
These types of alarms may be defined on the last n
evaluations or on the evaluations received in a certain
amount of time
The use of Boolean operators and the definition of complex
alarm situations are also allowed

23. Alarm management
Alarms are defined by doctors through their Doctor
Agents
When an alarm is defined, it is automatically sent to
the corresponding Patient Agent (or set of agents)
When a new auto-evaluation is stored on the DB,
the associated Patient Agent gets a signal, and then
it checks all the alarms associated to that patient
If any alarm situation is detected, a message is sent
to the Doctor Agent that defined it with an
explanation of why the alarm has been activated

24. Information Multi-Agent
Technologies System
WAP
Server
Simul.
Data
Web Anal.
Web interface
Server
PCU Database
PCU Head
Patient DB Wrapper
Patient
PALLIASYS
Present State
Alarm Doctor
management
Doctor
Web interface

25. Data Analyser: main tasks
To apply Data Mining and Machine
Learning techniques to analyse the
information of the DB
To provide general statistics on the
data, which are useful to the PCU head
to fill in the annual report

26. Available medical data
Input data: sequence of treatment episodes
Patient location (home, PCU, socio-sanitary
centre)
Length of stay (days)
Medication received by the patient
Medical tests and procedures made on the
patient
General patient health status

27. Intelligent Data Analysis
Generation of patient circuits (circuit graph)
Automatic detection of patient states
Clustering techniques, unsupervised learning
Generation of models of patient evolution
(state graph)
Generation of decision structures (decision
trees, set of rules)
Possibility of making predictions on future states
and anticipate and prevent undesired situations

29. Circuit graph

30. State graph

31. Conclusion – PalliaSys main ideas
Information technologies and Intelligent
agents may be used to build useful systems
in the Health Care domain
Most of the ideas underlying this project
might also be applied in elderly care or home
care
Use of Information Technologies
Automated patient monitoring
Intelligent data analysis

32. Outline of the talk
Rationale for applying agents in health care
Some specific projects developed by the
members of ITAKA
Management of data of palliative patients
Web-based platform for providing home care
services: K4Care
Research and development challenges
Final thoughts

33. Knowledge-Based HomeCare eServices
for an Ageing Europe
Project Presentation
K4CARE Consortium
A Project funded by the European Community under the Sixth Framework Programme for Research and Technological Development
© K4Care, 2006 Contract no IST-026968

34. K4Care basic facts
March 2006 – March 2009 (3 years)
Extended until September 2009
EC funding: 3.130.000 €
Coordinator: University Rovira i Virgili
13 Partners from 7 countries

35. K4Care project
The aim of the K4Care European project is to provide
a Home Care model, as well as design and develop a
prototype system, based on Web technology and
intelligent agents, that provides the services defined in
the model
Basic features:
a) actors are members of well defined organizations, with
different roles and allowed activities
b) there is extensive domain knowledge to be considered
(e.g. standard clinical guidelines)
c) coordination of tasks in daily care

36. Clinical Guidelines (CGs)
Indications or principles to assist health
care practitioners with patient care
decisions
Applicable in diagnostic, therapeutic, or
other clinical procedures for specific
clinical circumstances

37. CGs: benefits
Consistent clinical practice, avoidance of
errors
Reutilisation and tailoring
Rapid dissemination of updates and changes
Consideration of appropriate knowledge at
appropriate time
Use of formal representation languages

38. CGs: barriers in daily use
Lack of awareness
Lack of familiarity Automatic
Inertia of previous management and
behaviours enactment of
No integration with guidelines
standard practices
Lack of time or resources

39. Use of CGs in Home Care
Problem: patients in health care usually suffer
from several pathologies, and it is not
possible to apply the guidelines directly
Challenge: take into account the
recommendations of existing guidelines, but
adapt their application to the personal
circumstances of each individual patient

40. K4Care Model: Structure
1 Nuclear Structure + n Accessory Services
THE K4CARE MODEL
...
HCNS
Actor Service
Data/Information
Action Procedure

41. K4Care Model: Actors and Teams

42. Knowledge layer

43. K4Care Knowledge structures
EHCR: Electronic Health Care Record
APO: Actor Profile Ontology
CPO: Case Profile Ontology
Procedures
FIP: Formal Intervention Plan
IIP: Individual Intervention Plan

44. DBs, Electronic Health Care Record
Data Base: with information about the
K4Care actors as users of the K4Care
Platform (e.g. contact information)
EHCR: with the data about the Home-
Care processes performed within the
K4Care Platform
Medical documents stored in XML

45. K4Care Ontologies (I)
Actor Profile Ontology (APO)
Types of actors
Actions that each actor can perform
Platform services
Procedures
Documents
...

48. K4Care Ontologies (II)
Case Profile Ontology (CPO)
Diseases
Syndromes
Signs and symptoms
Social issues
Assessment tests
Interventions
...

51. K4Care FIPs
Formal Intervention Plans (FIPs) are formal
structures representing the health care
procedures to assist patients suffering form
particular ailments or diseases
FIPs are represented with the SDA* formalism
States
Decisions
Actions
The SDA* formalism is used to represent
K4CARE Service Procedures
K4CARE Formal Intervention Plans
K4CARE Individual Intervention Plans

52. FIP for the
management
of
hypertension

53. Procedures
Formal specifications, in the SDA* language,
of the way in which an administrative service
(e.g. admit a new patient to the Home Care
service) has to be implemented

54. Definition of an
Individual Intervention Plan
Input: patient data (EHCR), result of
comprehensive assessment, general K4Care
knowledge structures (APO, CPO, FIPs)
Output: Individual Intervention Plan to be
applied on a patient
Process:
Select set of applicable FIPs (diseases, syndroms,
symptoms)
Merge FIPs
Adapt the resulting SDA* structure to the individual
characteristics of the patient

57. K4Care platform features
Agent-based Web-accessible platform that provides
a set of basic Home Care services
Definition of IIPs
Apply IIP to the patient
The most relevant aspect of this knowledge-driven
architecture is the separation of the knowledge
description from the software realization
Key elements of the architecture
declarative and procedural knowledge
interaction between agents and end-users
agent-oriented execution of patient-centred plans

58. Interaction between agents and users

59. Multi-agent system
1 Actor Agent for each user, permanently
running
When the user logs in, a Gateway Agent is
dynamically created
Two-way communication Web-servlet-GA-AA
When an Actor Agent has to manage the
execution of a procedure/IIP, it creates
dynamically a SDA-executor Agent

60. Transparency between knowledge and
its use

61. Agent-based execution of IIPs (I)

62. Agent-based execution of IIPs (II)

63. Agent-based execution of IIPs (III)

64. Agent-based execution of IIPs (IV)

65. K4Care main conclusions
Knowledge
Individual Intervention Plans allow practitioners to
implement accurate and personalised sequences
of actions for a particular patient’s treatment
Use
The architecture allows implementing agent-
based coordination methods between the actors
relevant in Home Care, which adapt their
behaviour dynamically depending on the
knowledge available in the platform

66. Outline of the talk
Rationale for applying agents in health care
Some specific projects developed by the
members of ITAKA
Management of data of palliative patients
Web-based platform for providing home care
services
Research and development challenges
Final thoughts

67. Some research topics on the use of
MAS in Health Care
Communication standards
Medical ontologies
Security mechanisms
Implementation of agents in mobile
devices
Personalised access to information
Less social and professional reluctance to
adopt agent technology
Legal issues

68. General research topics on MAS
Service description, discovery, composition
Standard agent communication languages and
protocols
Negotiation, coordination, cooperation techniques
Agent-Oriented Software Engineering
Trust
Human-agent interaction
Integration with legacy software
...

69. Outline of the talk
Rationale for applying agents in health care
Some specific projects developed by the
members of ITAKA
Management of data of palliative patients
Web-based platform for providing home care
services
Research and development challenges
Final thoughts

70. Some general thoughts (I)
It is difficult to work with doctors
Very busy, unaware of technical details, change
requirements…
However, they may end up being happy with a
rather simple system (e.g. a well-organised DB,
statistics for annual report)
It is difficult to sell “agents” to hospital
computer units
Understanding, maintenance, …
Information systems are hospital-wide,
centralised

71. Some general thoughts (II)
Security is a matter of degree …
Sometimes “real life” technical issues make
it unsuitable to use agents
Use of previous prototypes or programming
languages
The frontier between “agents” and “non-
agents” seems to be difficult to define

72. Extra material for this week
Many papers on the ITAKA web site on
these projects