MAS course - Lect12 - URV health care applications

1,179 views

Published on

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

Published in: Technology, Health & Medicine
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,179
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
93
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

MAS course - Lect12 - URV health care applications

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  28. 28. Circuit graph
  29. 29. State graph
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. K4Care Model: Structure 1 Nuclear Structure + n Accessory Services THE K4CARE MODEL ... HCNS Actor Service Data/Information Action Procedure
  40. 40. K4Care Model: Actors and Teams
  41. 41. Knowledge layer
  42. 42. 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
  43. 43. 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
  44. 44. K4Care Ontologies (I) Actor Profile Ontology (APO) Types of actors Actions that each actor can perform Platform services Procedures Documents ...
  45. 45. K4Care Ontologies (II) Case Profile Ontology (CPO) Diseases Syndromes Signs and symptoms Social issues Assessment tests Interventions ...
  46. 46. 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
  47. 47. FIP for the management of hypertension
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. Interaction between agents and users
  52. 52. 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
  53. 53. Transparency between knowledge and its use
  54. 54. Agent-based execution of IIPs (I)
  55. 55. Agent-based execution of IIPs (II)
  56. 56. Agent-based execution of IIPs (III)
  57. 57. Agent-based execution of IIPs (IV)
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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 ...
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. Extra material for this week Many papers on the ITAKA web site on these projects

×