31

Agent-based execution of Individual Intervention Plans David Isern, Miquel Millan, Antonio Moreno

University Rovira i Virgili Department of Computer Science and Mathematics Intelligent Technologies for Advanced Knowledge

Acquisition (ITAKA) Research Group Tarragona, Catalonia (Spain)

{david.isern, josemiguel.millan, antonio.moreno}@urv.cat

Gianfranco Pedone, Laszlo Z. Varga Computer and Automation Research Institute of the

Hungarian Academy of Sciences, Sztaki Kende u. 13-17,

1111 Budapest, Hungary

{gianfranco.pedone, laszlo.varga}@sztaki.hu

ABSTRACT

The K4Care European project has designed and is currently finalising the development of a Web-based multi-agent platform that will provide the medical and management e-services required in a Home Care unit. As the typical patients of this application present a set of co-morbid conditions, it is necessary to define care treatments that are personalised for each of them (Individual Intervention Plans). Each of these plans involves the execution of diverse actions from different actors of the system. The paper describes how the intelligent agents of the K4Care platform coordinate their activities in order to efficiently execute these personalised plans under the supervision of practitioners.

Categories and Subject Descriptors I.2.11 [Artificial Intelligence]: Distributed Artificial Intelligence - Multiagent Systems. I.2.1 [Artificial Intelligence]: Applications and Expert Systems - Medicine and science

Keywords Formal intervention plans, clinical pathways, clinical guidelines, multi-agent system, intelligent agents, home care

1. INTRODUCTION In electronic healthcare (e-Health) it is increasingly necessary to develop computerised applications to support people involved in providing basic medical care, reducing costs and providing relevant patient information at the point of care [17,35]. The care of chronic and disabled patients involves lifelong treatments under continuous expert supervision. Moreover, healthcare workers and patients often consider traditional treatments in hospitals or residential facilities unnecessary and even counterproductive, in terms of time, economic cost and efforts they have to spend. Elderly chronic patients are beginning to saturate national health services and increase health-related costs all around Europe. To face this challenge it is possible to differentiate medical assistance in health centres from ubiquitous assistance (Home Care -HC- model); the latter can undoubtedly

benefit from the introduction of Information and Communication Technologies (ICT) [18]. The K4Care European project proposes an ICT-based model of HC in order to support the provision of care services to a patient that requires assistance at home.

The typical HC Patient (HCP) is an elderly patient, with co-morbid conditions and diseases, cognitive and/or physical impairment, functional loss from multiple disabilities, and impaired self-dependency. The healthcare of the HCP is particularly complex because of the growing number of patients in such circumstances, and also because of the great amount of resources required to guarantee a quality long-term assistance. The project is developing a platform to manage the information needed to guarantee an ICT Home Care service, including:

• An integration with ICT whilst ensuring private and

customized data access. • The use of ontologies to define medical information and

the profile of accessing subjects. • A mechanism to combine and refine the ontologies to

personalise the information presented to the user according to his profile.

• The incorporation of know-how from geriatric clinical guidelines (known as Formal Intervention Plans, FIPs [19]).

• The semi-automatic generation of FIPs from databases of personalised healthcare treatments [21].

• The configuration of a knowledge-based decision support tool that can supply e-Services to all subjects involved in the Home Care model.

This paper is concerned only with the last item, the decision support tool, which has been designed as a Web-accessible multi-agent platform. The rest of the paper is organised as follows. Section 2 describes different systems oriented towards the execution of clinical guidelines. Section 3 describes the basic components of the K4Care service-oriented model, and outlines the three-layered architecture of the K4Care platform. The next section introduces the basic features of SDA*, which is the formalism used to represent care plans, and describes how personalised care treatments –called Individual Intervention Plans- are defined. Section 5 presents the agent-based execution of Individual Intervention Plans, detailing how the agents of the system coordinate their activities in order to execute them. Finally, several conclusions and lines of future work are commented.

Cite as: Agent-based execution of Individual Intervention Plans, D.Isern, M.Millan, A.Moreno, G.Pedone and L.Z.Varga. Procs. of Agents Applied in Health Care Workshop (AHC 08) collocated in AAMAS 2008, Moreno, A., Cortés, U. and Annicchiarico, R. (eds.), May, 12-13, 2008, Estoril, Portugal, pp. 31-40. Copyright © 2008, International Foundation for Autonomous Agents and Multiagent Systems (www.ifaamas.org). All rights reserved.

32

2. RELATED WORK The main goal of this paper is the implementation of a guideline-based execution engine, improving the general performance by using a multi-agent system, which coordinates both the collection of data and its transmission to the correct point of care.

In the literature, there are other systems related to the execution of guidelines, such as order entry systems and alarm-based systems, which are out of the scope of this paper. Computerised Physician Order Entry (CPOE) systems refer to a variety of computer-based systems for ordering medications, which share the common features of automating the medication ordering process. A basic CPOE system ensures standardized, legible, complete orders by only accepting typed orders in a standard and complete format. With the same goal, there are decision support systems that can provide advice on drug selection, dosages, and duration [7]. There are computerised systems that monitor certain events and trigger alerts about at-risk states and reminders of appropriate physical assessments and screening activities. Sometimes active systems provide an explanation that offers background information, definitions and risks [24]. These systems do not consider neither complex sequences of actions nor coordination aspects, but just react to specific situations.

After a careful review of the current literature, seven projects, six coming from academic research and one commercial system, were selected: Arezzo, DeGeL, GLARE, GLEE, HeCaSe2, NewGuide, and SAGE.

2.1 Arezzo Arezzo is a commercial product to create, visualise and enact PROforma guidelines [8,9]. PROforma is an executable process modelling language that has been successfully used to build and deploy a range of decision support systems, guidelines and other clinical applications [10].

The tool is composed of three elements: a Composer, a Tester and a Performer. The Composer is a graphical tool used to create guidelines. The Tester is a tool created to test the guideline logic before deployment (it checks that all statements in decisions, tasks and enquiries are well written). The Performer inference engine allows running the guideline, taking into account data related to patients stored in existing healthcare systems (electronic medical record). During the enactment of a guideline in the performer engine, a task changes its internal state depending on whether the task is awaiting for data, suspended, finished, or it cannot be accomplished in the current state of the patient. Arezzo uses the Domino autonomous agent model ([9]). The model deals with a large class of medical problems and establishes a relationship between decision making and plan enactment procedures. The main goal of this model is to identify the basic elements required in any language to represent clinical guidelines that can be used for both decision making and plan management.

2.2 DeGeL Digital electronic Guidelines Library (DeGeL) is a web-based, modular and distributed architecture, which facilitates the gradual conversion of clinical guidelines from text to a formal representation in Asbru [23,36]. The initial textual guidelines go through an intermediate layer between the textual and the final form, where experts add

semantic information. The intermediate layer uses a meta-ontology that defines a hierarchy of basic concepts. Internally, Asbru organises a clinical guideline as a library of plans created during the decomposition process performed in the specification phase. These plans are interrelated in a hierarchical network of plans and sub-plans using a parent-child relationship which is encoded using control structures (e.g., do in parallel) [37]. The guideline execution module, Spock, incorporates an inference engine that can retrieve data stored in a patient's medical record. Spock is a modular client-server application that consists of: i) a set of classes, that allow to store any guideline, ii) a parser, that interprets the content of a guideline, and iii) a specialized module, the Controller, which synchronizes the communication between the system layers and external services [36,37].

2.3 GLARE GuideLine Acquisition, Representation and Execution (GLARE) is a system to acquire and execute clinical guidelines [1,27,28] . Guidelines use an ad hoc graph-based representation, where each action is represented by a node, while control relations are represented by arcs. This system is focused in the management of temporal constraints between different actions in the graph. An execution module allows executing/simulating a guideline using the appropriate retrieved data from a database. Each patient has his own medical record, which is updated continuously with the actions executed during the enactment. The architecture is complemented with a database of available resources in a given hospital, which allows making domain-dependent execution of guidelines. Moreover, GLARE allows the local adoption and update of guidelines to cope with both the need to apply them to new situations (countries, hospitals and/or departments), and with the need to manage updates (e.g., authoring, recording the history of a guideline and learning from experience) [27].

2.4 GLEE GLEE is a tool for executing guidelines encoded in the 3rd version of GLIF (called GLIF3) [33,34]. GLEE defines three levels of abstraction: data, business logic, and user interface. The data level contains the electronic medical record with a guideline repository and the clinical event monitor, that allows the execution (or simulation) of clinical guidelines through an event-driven model. The business logic level contains the GLEE execution engine, formed by a server and many clients. The server interacts with the data level, and clients interact with users (both through defined interfaces). At the bottom, we find the user interface level, where the clinical applications that exchange data with the upper levels are located [34].

The execution model of GLEE takes the “system suggests, user controls” approach. A tracing system is used to record an individual patient's state when a guideline is being applied to him. It can also support an event-driven execution model once it is linked to the clinical event monitor in a local environment. The tracing system allows maintaining two main views of the execution. On the one hand, GLEE suggests which actions can be performed and decides which actions (whose preconditions are satisfied) can change the state from started to finished. On the other hand, the user can control the process, and it can initiate, confirm or decide different transitions between actions.

33

2.5 HeCaSe2 Healthcare Services release 2 (HeCaSe2) is an agent-based platform that offers health care services to users (patients and doctors). The platform defines an architecture of agents with different roles, and with multiple interactions between them and humans or medical devices [11,14,15]. Clinical guidelines in HeCaSe2 are represented using the PROforma representation language [26]. In addition, actions and enquiries are enriched with a widely used terminology, the Unified Medical Language System (UMLS, [16]), in order to unify the vocabulary and to allow sharing medical knowledge. The authors propose an architecture based on different kinds of agents interconnected following the organisational rules of a medical centre. Each agent acts autonomously with its own knowledge and data. There isn't any central control and the number of agents depends on the specific configuration (e.g., doctors, departments, and devices in a medical centre). The coordination of the tasks to be performed is made internally by agents by retrieving all information concerned to the patient and following the execution of a guideline applied to him. Using the guideline, a doctor can consider all the available data and take an informed decision. During the visit, if the doctor needs another test to be performed on the patient, agents negotiate the best alternative according to the preferences/constraints of the user, the doctor and the hospital services.

2.6 NewGuide NewGuide is a framework for modelling and executing clinical practice guidelines [5,6]. Guidelines are represented using the GUIDE representation language, which is based on Petri Nets [20]. It allows to model complex concurrent processes as well as temporal, data and hierarchical issues. GUIDE is integrated into a workflow management system which proposes an infrastructure that enables inter- and intra-organizational communication through a Careflow Management System (CfMS) that, on the basis of the available best practice medical knowledge, is able to coordinate the care providers’ activities

The inference engine is composed of three main elements: a general manager, a message manager, and an instance manager. The inference engine is invoked by a clinician and automatically creates an instance of a guideline (previously retrieved according to some criteria) for the management of an individual patient. All the steps followed in the execution of a guideline are supervised by an instance manager. At the same time, all instances are controlled by a general manager. After loading the guideline, the instance manager needs to collect all the patient’s data stored in his patient record. The execution engine goes step-by-step recommending actions, such as drug prescription or laboratory tests and, at the same time, stores that information in a logs database. All log data is used to monitor the status of a patient in the CG in another module named reporting system. In addition, the communication between NewGuide and the external world is governed by the message manager, which delegates requests and responses to the web user interface or to an external entity (through a SOAP interface) on the basis of the system configuration. The responsibility for maintaining the correct guideline flow and timing is left to the external CfMS [5].

2.7 SAGE The SAGE project pursues two main goals. First of all, to create an infrastructure that allows medical experts to author and encode guidelines using a standard representation, and then, to use this infrastructure to deploy these guidelines across heterogeneous clinical information systems [3,29-31]. The internal representation of guidelines in SAGE is made using the EON formalism which is comprised of a set of Protégé classes and plug-ins [32]. The execution engine, called SAGEDesktop ([3]), is implemented as a centralised element. Given a guideline, it collects the required data from an internal repository and allows medical experts to emulate the real guideline behaviour. The execution engine interacts with the clinical information system (CIS) via an event listener and a set of services (terminology, patient record and general applications). The terminology server was added to customise the terms used in some specific local applications. Calls to/from the execution engine and the CIS were made through a set of defined APIs, which allow interoperability with existing systems. Services related to the Electronic Medical Record (invoked using medical record calls) allow the engine to retrieve the appropriate patient data. After that, the action service calls allow the engine to initiate actions within the CIS.

3. HOME CARE PLATFORM In the case of elderly people with chronic illnesses, it is widely accepted that their treatment at home increases their life quality and reduces costs. While the healthcare information system of a single medical centre is usually rather centralised, medical assistance in Home Care naturally needs a distributed service-oriented architecture, as many kinds of actors from different institutions are involved (family doctors, nurses, social workers, specialist physicians, etc.). Thus, the K4Care platform, which is based on a generic HC model [4,12], needs to manage information from distributed sources. In the following subsections we discuss the K4Care service model and the K4Care platform architecture.

3.1 The K4Care Service Model The K4Care platform provides services to its users. Each user will achieve his goals using a set of services specific to his user type. Every user is represented in the system with an intelligent agent. Services may invoke other services, defining a distributed service-oriented architecture.

The K4Care service model is based on the real processes of Home Care used in the clinical institutions of the K4Care medical partners, and focuses on the following basic concepts:

• Service: it is an abstract notion of a complex activity, typically accomplished via the collaboration between several actors. It may have several instantiations, which are called procedures. Different procedures instantiating the same service may be used for different localisations, e.g. in different countries or medical centres. In that way, each medical centre can implement a service using its own available resources and expertise. In a given K4Care platform installation each service has one and only one procedure instantiation.

34

• Procedure: it is a formal description of a set of tasks organized in some workflow (sequential, parallel, conditional branches, etc.). The procedure may be the instantiation of a medical or management process in the medical centre. The workflow control structures of procedures are described in the SDA* language (see Section 4.1). Tasks can invoke the services of other agents in the system; therefore, a procedure may be seen as a composition of services. Procedures are created by humans, usually medical centre managers or physicians in charge of Home Care units.

• Task: it is an execution step in a procedure, usually a request to execute another service. The task is described by a 4-tuple (subject, object, service or action, doc). The subject is the type of agent (e.g. a nurse or a social worker) which has to execute the service or the action. The object is the actor on which the service is expected to be executed (e.g., a specific patient). The doc is a document related to the service. All actors must reflect their activities in documents. If the subject corresponds to the same type of agent that is executing the current procedure, then the service is executed internally.

• Action: it is an activity that can be executed by an agent on its own. The set of actions that an agent can perform can be considered as the agent’s skills or abilities. Each action of the agent is provided as a service to other agents. When an action is executed, no procedure description retrieval is needed (i.e. actions are atomic entities). The set of actions that a given agent type is capable of carrying out is described in the Actor Profile Ontology.

3.2 K4Care Platform Architecture The architecture shown in Figure 1 is divided in three main modules: the Knowledge Layer, the Data Abstraction Layer, and the K4Care agent-based platform [4].

The Knowledge Layer includes all the data sources required by the platform. It contains an Electronic Health Record subsystem that stores patient records with personal information, medical visits and ongoing treatments. The Actor Profile Ontology (APO) contains information about all the types of actors allowed in the system (e.g., actions that each type of actor can perform). The Case Profile Ontology (CPO) includes medical information on syndromes, symptoms and diseases (e.g. symptoms associated to each disease). Both ontologies are represented in OWL. The platform provides two databases with procedural information codified in SDA* ([22], see section 4.1). On the one hand, there is a repository of the procedures that implement administrative services. On the other hand, there is a store of Formal Intervention Plans, which are general descriptions, usually defined by international care organizations, of the way in which a particular pathology should be dealt with.

The Data Abstraction Layer (DAL) provides Java-based methods that allow the K4Care platform entities to retrieve the data and knowledge they need to perform their tasks. This layer offers a wide set of high-level queries that provide transparency between the data (knowledge), its representation (OWL, SDA, or SQL calls), and its use (platform) [2].

The K4Care platform is a web-based application with a client side (a Web browser) and a server side (a servlet). Any actor interacts with the system through a Web browser and is represented in the system by a permanent agent (Actor Agents in Figure 1) that knows all details about his roles, permissions, pending results, pending actions, and that manages all queries and requests coming

Figure 1. K4Care Platform Architecture

35

from the user or other agents. In order to exchange information between the agents and the actors there is an intermediate bridge constituted by a servlet and a Gateway Agent (GA). The servlet is connected with the browser user session. It creates a GA each time that an actor logs in the system, whose mission is to keep a one-to-one connection with the corresponding permanent agent.

4. DEFINITIONS OF CARE TREATMENTS

4.1 SDA* formalism SDA* is a flowchart-based representation of clinical guidelines [22]. The most basic components of SDA* structures are the domain variables, which can be of three types (see Fig. 2):

• State variables, that represent terms that are useful to determine the condition of the patient at a certain stage (e.g., a patient with chronic kidney disease, who has high blood pressure).

• Decision variables, which are required by medical experts to choose among alternative medical, surgical, clinical or management actions within a treatment (e.g., a treatment may follow different paths depending on the blood pressure of the patient). A decision contains a set of logical conditions that should be evaluated before proceeding. Some of the values required in these conditions can be retrieved from the patient’s record (e.g., the last value of the patient’s blood pressure), but there could be findings to be entered by the practitioner during the medical visit (e.g., consider a secondary cause of hypertension).

• Action variables, which represent the medical, surgical, clinical or management actions that may appear within a treatment (e.g., define or change a drug therapy).

The basic pillars of SDA* structures are states, decisions and actions. States describe patient condition situations, and are defined by a subset of state variables. Decisions code alternative options required to guide the enactment of a plan. A decision is based on a subset of decision variables, and contains a set of alternatives. An action is one of the activities that an actor can perform in the treatment of a patient, and is represented by an action variable. Between those elements, directed edges define the direction of the steps and can be labelled with temporal constraints in order to represent deadlines and/or periodic actions. Fig. 2 shows an example of SDA* structure for the treatment of hypertension. States are represented as circles, decision as rhombus and actions as rectangles. The patient may initially be in any of four possible states (e.g., a diabetic patient with a high level of blood pressure -BP). After an initial assessment, and if there isn’t any secondary cause of the hypertension, the patient is recommended some life style modifications and treated with a drug therapy. The blood pressure is controlled periodically. If the initial drug therapy fails, then the physician should change the treatment until the blood pressure is stabilised in a safe range.

4.2 Individual Intervention Plan (IIP) In the K4Care platform, FIPs may be related to a syndrome (e.g., cognitive impairment), a symptom (e.g., abdominal pain) or a disease (e.g., dementia). A patient may suffer from several of these conditions; thus, the recommendations made by several FIPs must be taken into account to construct an Individual Intervention Plan (IIP). The IIP indicates the personalized care actions to be applied on a specific patient. Both FIPs and IIPs are represented using the SDA* formalism. The creation and management of IIPs follow a complex procedure which is controlled by a multi-disciplinary team called evaluation unit (EU), which includes four actors: the physician in charge of the Home Care unit (PC), a family doctor (FD), a social worker (SW) and the head nurse (HN). After the patient is admitted in the Home Care service, he is assigned a personalised Evaluation Unit. The first step in the patient’s care is the performance of a comprehensive assessment (CA), which includes a multi-dimensional evaluation (made by all members of the EU, filling a set of internationally standardised scales), a clinical assessment and a physical examination (which may be performed either by the PC or the FD) and a social needs and social network assessment (performed by the SW). Once all the results of the CA are available, the EU members analyze them and determine the syndromes, symptoms and diseases of the patient. The platform retrieves automatically the FIPs related to these conditions and the EU members then use a SDA* graphical editor, which is embedded in the web interface, to combine and personalise the relevant sections of these FIPs in order to build the specific Individual Intervention Plan for that particular patient. Thus, the medical team does not have to build it from scratch, and

Figure 2. SDA* flowchart for the treatment of hypertension

36

can take into account the international recommendations in the treatment of the patient’s conditions. The merging of different Formal Intervention Plans is a complex task, which requires the expertise of the human practitioners and would be very hard to automate. A very recent study [25] considers the combination of recommendations for patients with co-morbidities one of the present grand challenges in clinical decision support. The IIP contains follow-up actions in which the state of the patient is checked and, if necessary, the plan may be cancelled or changed. Once the IIP is ready, it is saved in the Electronic Health Record of the patient.

5. AGENT-BASED EXECUTION OF IIPs The agents of the multi-agent system of the K4Care platform embed all the system logic by representing the actors involved in HC services. Agents act semi-automatically, in the sense that several actions such as exchange of information, collection of heterogeneous data concerning a patient (results, current treatment, next recommended step, past history), or the management of pending actions, are performed by agents without the intervention of human users. There are other actions, such as the confirmation of the formation of an EU or the evaluation of some results received from laboratories, which require the user validation. Basically the K4Care upper layer is composed by the following elements:

• Actor agents (AAs) represent practitioners and patients, and use the Data Abstraction Layer methods in order to access the data they need. They are permanent in the system and monitor all pending and done tasks. Each particular kind of agent has its own role into the system defined in the Actor Profile Ontology. Each type of actor has different permissions and allowed actions. In the same way, the patient’s agent controls different tasks that involve the user’s interaction.

• A web interface, through which human users can access the system. It implements authentication measures, which control the access to the platform.

• One servlet and several gateway agents (GA) that allow exchanging information between the MAS and the web-based application. These agents are created dynamically when an actor logs into the system.

• SDA* executor agents (SDA-Es) that allow to enact a care plan for a patient and recommend the next step to follow according to his current state. The SDA-E is also created dynamically by an AA in order to enact a SDA* structure corresponding to an IIP or to a management procedure. SDA-E agents have been designed to be able to manage concurrently several SDA-based structures.

5.1 Preliminary steps

The enactment of an Individual Intervention Plan is a complex task that requires the interaction of agents and humans (see Fig. 3). Technically, it is one of the services provided by the K4Care platform. This service may be requested by the physician in charge. The person who is responsible of the management of the execution of an IIP is usually the head nurse. Note that each Home Care unit (modelled by a K4Care platform) has only one PC and one HN, but it may have many family doctors, social workers and other kinds of actors (nurses, specialist physicians, informal care givers, etc.).

Henceforth all preliminary steps will be explained through the example shown in Fig. 3. First of all, the Physician in Charge logs into the K4Care platform using the web interface. In this case, he wants to request the execution of the IIP of a particular patient called David Jones. This information is received by the servlet, which forwards it to the Gateway Agent associated to the PC (the GA is dynamically created when the user logs into the platform, and remains alive as long as the working session is active). This agent transmits the request to his corresponding permanent actor agent (step 1). At this point, the AA should know who is able to perform the required task. The agent retrieves this information from the Actor Profile Ontology (by calling some Data Abstraction Layer methods). In this case, starting the execution of an Individual Intervention Plan is responsibility of a head nurse (steps 2-3). Now, the actor agent of the PC contacts with the actor agent of the HN, who stores the request to begin the execution of an IIP (step 4).

When the head nurse logs into the system, her corresponding agent collects all her pending actions (actions that have been requested by other users while the head nurse was not logged into the system, step 5).

At some moment the HN will select that pending action (the “execution of the IIP of Mr. Jones”, step 6). The Actor Agent of the Head Nurse will then dynamically create a SDA-E agent, which will receive the identifier of the patient (step 7).

The SDA-E retrieves the corresponding SDA representation of the Individual Intervention Plan from the Electronic Health Record of the patient by calling the appropriate method of the Data Abstraction Layer (step 7a). When the agent receives the IIP (step 7b), it is ready to start the execution by sending to the AA of the HN the information contained in each of the elements of the plan (i.e., states, decisions and actions) (step 8).

The head nurse actor agent will manage the execution of the Individual Intervention Plan. It will obtain each of the elements of the SDA* structure, one by one, through requests to the SDA-E agent, and depending on the situation (action, decision or state) will invoke different services.

37

5.2 Execution of IIPs States are descriptions of the expected clinical situation of a patient at a certain point of his care. In the present version of the system, the AA of the HN does not process states in any way. The idea is that the HN should check whether the expected state (retrieved from the IIP) matches with the present clinical condition of the patient. If that is the case, the treatment is giving the expected outcomes and the HN may proceed with the execution of the IIP; otherwise, the EU should evaluate the difference between the intended and actual states and decide whether to continue with the execution of the IIP, to modify it or even to cancel it and make a brand new one.

When the SDA-E finds a decision, the logical expression contained in it should be evaluated, in order to decide which of the decision branches should be followed. The SDA-E collects all available data present in the EHR of the patient about the variables included in the expressions. If some data are not available, the AA of the HN sends the decision to the graphical interface of the HN, so that he can decide if the condition holds.

Finally, the last element that the SDA-E agent may send to the AA of the HN is an action. Concretely, the SDA_E sends a task, containing an action identifier and a type of actor as subject (e.g., action S6.WRITE_SOCIAL_REPORT, subject SW). The K4Care model includes 84 specific care actions that may be performed by 10 types of actors [4]. The execution of a care action (in the real world) is confirmed by filling (in the platform) a document, which is stored in the EHR of the patient (e.g., D18, SOCIAL_REPORT, is the document to be filled after performing action S6). There are 43 documents defined in the K4Care model (some documents are general enough to be usable to reflect the performance of different actions).

5.2.1 Action assignment As mentioned above, the SDA* representation of an IIP contains tasks. The task description contains the subject which is the type of agent which is expected to execute the service or the action. When the AA of the HN receives the task, its first mission is to assign the action to a specific person (which will be represented by a specific agent in the system). Different types of agent assignments can be identified:

1) The agent is assigned dynamically when the task is to be executed. The most suitable agent could be selected by negotiation, for instance applying the well-known Contract Net protocol, allowing each agent to make a proposal when a new task is available, and taking the assignment decision dynamically at execution time. The advantage of this solution is that we exploit the benefits of the agent design approach, however Home Care centres usually like to have a tight control of resources, and would like to know in advance who does what and when.

2) The agent is assigned statically when the IIP execution is started. In this case agents are assigned to each task of the whole IIP. The advantage of this solution is that once the agents are assigned and the IIP execution is started, then there isn’t any other overhead, and the SDA Engine agent can talk directly to the relevant agents. However, in this case we have to assign agents to actions which may not be executed, because they are in a branch of a decision and the branch is not selected during the execution. This is very inconvenient for the medical staff, because they have to assign actors hypothetically.

Figure 3. Agent-based execution of IIPs

38

3) The agent is assigned statically when a decision is made. This case is similar to the previous one, but we only assign agents to actions of an already selected branch. The advantage of this solution is that the medical staff does not have to assign actors to branches which are not executed. Moreover, according to K4Care medical partners’ experience, this is usually the working practice of medical staff. They evaluate the patient at decision points and then decide which branch to take. The evaluation is usually done by the Evaluation Unit assigned to the patient.

Sometimes the actor assignment is simple, because the patient and the type of agent directly imply a given agent instance. If the action has to be made by a Physician in Charge, a Family Doctor, a Head Nurse or a Social Worker, then the assignment is made automatically to the corresponding person in the Evaluation Unit of the patient. Otherwise (e.g., if a nurse or a specialist physician is needed) the HN has to select a concrete person to perform the action. In the present state of the platform, it is assumed that this assignment is made directly by the HN with tools outside of the K4Care platform that allow her to take these decisions. The platform can provide a pop-up menu in the GUI with the available actors so that the Head Nurse can select the name of the chosen one quickly.

5.2.2 Management of groups of actors

It is worth noting that an actor type within a task can be either a single actor type or a group of actor types. For example, a nurse is a single actor type, while an Evaluation Unit is a group of actor types, consisting of a Physician in Charge, a Family Doctor, a Head Nurse and a Social Worker.

Different assignment strategies for single actors were commented in the previous section. If the subject of an action is a group of actor types, then it can be specified in the IIP in two different ways: either as a group or as a single actor type responsible for the action of the whole group. In both cases the actor assignment will take a single actor type when it tries to assign the final actor who will be required to perform the action:

• If the subject is specified as a group, then a default actor type will be taken as the responsible of the activity of the group. For example, in the case of the Evaluation Unit, the Physician in Charge of the Home Care unit will be the default actor type: EU.PC. Thus, the actions that have to be made by the EU will be sent to the PC, who will have to coordinate the performance of the action with the rest of the members of the EU and fill the appropriate document when the action is completed.

• The other possibility is that the IIP specifies explicitly which member of the group is the subject of the action. For example the IIP might say that the Social Worker of the Evaluation Unit is the responsible for a particular action: EU.SW. In that case the action, although is a full responsibility of the whole EU, will be sent to the SW, who will be responsible of filling the final document after the completion of the action.

Once a single actor type has been found, the single actor type has to be substituted with a concrete actor. This process requires collaboration between the SDA Engine agent and the AA of the HN. The SDA Engine agent makes the substitution of group actor types with single actor types and then sends the actor type to the AA of the HN, who is controlling the execution of the IIP. This agent then makes the actor assignment as described in the previous subsection, and then sends to the AA of the assigned actor the action to be executed.

5.2.3 Action performance Once the AA of the HN knows the person assigned to the action, it sends a message to the AA of that person requesting the performance of the action (indicating the action identifier, the patient to whom it must be applied and the identifier of the document to be filled, step 9a). When that person logs into the system, he will see this request in the list of pending actions (step 9b). When he selects this action, a message will be sent by his GA to his AA (step 10). Then, the AA will retrieve, using the appropriate method of the DAL, the document to be filled to reflect the performance of the action (steps 11 and 12). The AA sends the document to the web interface (through its associated GA and the servlet), and the user fills it (steps 13 and 14). Then the AA stores the filled document in the EHR of the patient (step 15) and sends a message to the AA of the HN to indicate that the action has been performed (step 16). After that, the AA of the HN would request to the SDA-E the next element (state, decision or action) of the IIP.

6. CONCLUSIONS AND FUTURE WORK

The use of Individual Intervention Plans in Home Care provides several benefits both to patients and medical practitioners. The care plan designed by the Evaluation Unit is not created from scratch, but it is based on the recommended best practices (derived from evidence compiled in randomised clinical trials) included in standardised, globally accepted FIPs. Furthermore, the IIP is fully personalised, adapted to the patient’s particular medical and social circumstances.

The inclusion of intelligent autonomous agents permits to enact and assign tasks in an efficient way avoiding a central monitor or controller. Actor agents, who are permanent within the system, receive requests and results asynchronously, and those are filtered and sorted to the human user when he logs in. On the other hand, some activities (e.g., the analysis of some simple decisions in a care plan) can be performed by agents without the supervision of humans. The proposed open architecture allows implementing agent-based coordination methods between the actors relevant in Home Care.

It is interesting to note that management services, codified as procedures, are also represented in the SDA* formalism. Thus, the same mechanism used to enact IIPs is being used to execute the procedures that provide the basic management services (e.g., constitution of an Evaluation Unit, addition of a new patient).

39

Some lines of current and future work are the following:

• The AA of the HN could make some kind of automated processing of states, and only alert the humans in the EU if there is a discrepancy between the expected and actual states of the patient.

• The assignment of specific people to actions could also be more automated (e.g., if a nurse is needed to perform an action, a contract net protocol could be established between the AA of the HN and the AAs of the available nurses). For these negotiations to be effective, actor agents should keep internally information about their timetable and preferences (in a way similar to the one proposed in the HeCaSe system, [13]).

• When all the results of the Comprehensive Assessment are available, the platform could use the medical knowledge stored in the CPO to help the EU to determine the syndromes, symptoms and diseases of the patient (e.g., if the blood pressure is above a certain level, it could suggest the hypertension disease automatically).

• The development of the platform is in its last stages. The last year of the project will be devoted to its test in the institutions of some of the medical partners of K4Care.

ACKNOWLEDGMENTS This work has been funded by the European IST project K4Care: Knowledge Based Home Care eServices for an Ageing Europe (IST-2004-026968). The authors would like to acknowledge the work of the other members of the K4Care consortium, especially the medical partners, led by Dr. Fabio Campana, and Dr. David Riaño (project co-ordinator and designer of the SDA* formalism). The authors of this paper are solely responsible for its content. It does not represent the opinion of the European Community and the Community is not responsible for any use that might be made of the information contained herein.

REFERENCES [1] Anselma, L., Terenziani, P., Montani, S., Bottrighi, A.:

Automatic Treatment of Temporal Issues in Clinical Guidelines in the GLARE System, In Proc. of Proceedings of the 12th World Congress on Health (Medical) Informatics, MEDINFO 2007 (Brisbane, AUS, 2007), 807 - 811

[2] Batet, M., Gibert, K., Valls, A.: The Data Abstraction Layer as Knowledge Provider for a Medical Multi-Agent System, In Proc. of Workshop From Knowledge to Global Care, collocated in AIME 2007 (Amsterdam, The Netherlands, 2007), 1-9

[3] Berg, D., Ram, P., Glasgow, J.: SAGEDesktop: An Environment for Testing Clinical Practice Guidelines, In Proc. of 26th Annual Conference of the IEEE Engineering in Medicine and Biology Society, IEBMS 2004 (San Francisco, US, 2004), 3217-20

[4] Campana, F., Moreno, A., Riaño, D., Varga, L. 2008. K4Care: Knowledge-Based Homecare e-Services for an Ageing People, In Annicchiarico, R., Cortés, U., Urdiales, C. (eds.), Agent Technology and e-Health 95-115.

[5] Ciccarese, P., Caffi, E., Boiocchi, L., Quaglini, S., Stefanelli, M.: A guideline management system, In Proc. of 11th World Congress on Medical Informatics, MedInfo 2004 (San Francisco, USA, 2004), 28-32

[6] Ciccarese, P., Caffi, E., Quaglini, S., Stefanelli, M.: Architectures and Tools for innovative Health Information Systems: the Guide Project, International Journal of Medical Informatics 74 (2005), 553 - 562.

[7] Coiera, E. 2003. Guide to Health Informatics Hodder Arnold.

[8] Fox, J., Alabassi, A., Patkar, V., Rose, T., Black, E.: An ontological approach to modelling tasks and goals, Computers in Biology and Medicine 36 (2006), 837-856.

[9] Fox, J., Beveridge, M., Glasspool, D.: Understanding intelligent agents: analysis and synthesis, AI Communications 16 (2003), 139-152.

[10] Fox, J., Patkar, V., Thomson, R.: Decision Support for Healthcare: the PROforma evidence base Informatics, Informatics in Primary Care 14 (2006), 49-54.

[11] Isern, D., Moreno, A.: Distributed guideline-based health care system, In Proc. of 4th International Conference on Intelligent Systems Design and Applications, ISDA 2004 (Budapest, Hungary, 2004), 145-150

[12] Isern, D., Moreno, A., Pedone, G., Varga, L.: An Intelligent Platform to Provide Home Care Services, In Proc. of Workshop From Knowledge to Global Care, collocated in AIME 2007 (Amsterdam, The Netherlands, 2007), 90-99

[13] Isern, D., Sánchez, D., Valls, A., Moreno, A.: HeCaSe: An Agent-Based System to Provide Personalised Medical Services, In Proc. of Workshop Agentes Inteligentes en el Tercer Milenio en X Conferencia de la Asociación Española para la Inteligencia Artificial, CAEPIA 2003 (Donostia, San Sebastian, 2003)

[14] Isern, D., Sánchez, D., Moreno, A.: An ontology-driven agent-based clinical guideline execution engine, In Proc. of Artificial Intelligence in Medicine, AIME 2007 (Amsterdam, The Netherlands, 2007), 49-53

[15] Isern, D., Valls, A., Moreno, A.: Learning the user’s preferences for multiple criteria ranking, In Proc. of XIII Congreso Español sobre Tecnologías y Lógica Fuzzy, ESTYLF 2006 (Ciudad Real, Spain, 2006), 325-330

[16] Lau, L. M., Shakib, S.: Towards Data Interoperability: Practical Issues in Terminology Implementation and Mapping, In Proc. of HIC 2005: Thirteenth National Health Informatics Conference (Melbourne, Australia, 2005), 208-213

[17] Lenz, R., Blaser, R., Beyer, M., Heger, O., Biber, C., Bäumlein, M., Schnabel, M.: IT support for clinical pathways - Lessons learned, International Journal of Medical Informatics 76 (2007), S397-S402.

[18] Michie, S., Johnston, M.: Changing clinical behaviour by making guidelines specific, BMJ 328 (2004), 343-345.

40

[19] NGC 2007. National Guideline Clearinghouse. URL: http//www.guideline.gov [last access: 01/10/08]

[20] Quaglini, S., Stefanelli, M., Cavallini, A., Micieli, G., Fassino, C., Mossa, C.: Guideline-based Careflow Systems, Artificial Intelligence in Medicine 20 (2000), 5-22.

[21] Real, F., Riaño, D., Bohada:, J. A.: Automatic Generation of Formal Intervention Plans Based on the SDA Representation Model, In Proc. of Twentieth IEEE International Symposium on Computer-Based Medical Systems, CBMS 2007 (Maribor, Slovenia, 2007), 575-580

[22] Riaño, D.: The SDA* Model: A Set Theory Approach, In Proc. of Twentieth IEEE International Symposium on Computer-Based Medical Systems, CBMS 2007 (Maribor, Slovenia, 2007), 563-568

[23] Shahar, Y., Young, O., Shalom, E., Galperin, M., Mayaffit, A., Moskovitch, R., Hessing, A.: A Framework for a Distributed, Hybrid, Multiple-Ontology Clinical-Guideline Library and Automated Guideline-Support Tools, Journal of Biomedical Informatics 37 (2004), 325-344.

[24] Shiffman, R. N., Liaw, Y., Brandt, C. A., Corb, G. J.: Computer-based Guideline Implementation Systems: A Systematic Review of Functionality and Effectiveness, Journal of the American Medical Informatics Association 6 (1999), 104-114.

[25] Sittig, D. F., Wright, A., Osheroff, J. A., Middleton, B., Teich, J. M., Ash, J. S., Bates, D. W.: Grand Challenges in Clinical Decision Support, Journal of Biomedical Informatics 41 (2008), 387-392.

[26] Sutton, D. R., Fox, J.: The syntax and semantics of the PROforma guideline modeling language, J Am Med Inform Assoc 10 (2003), 433–443.

[27] Terenziani, P., Montani, S., Bottrighi, A., Molino, G., Torchio, M.: Clinical Guidelines Adaptation: Managing Authoring and Versioning Issues, In Proc. of 10th Conference on Artificial Intelligence in Medicine, AIME 2005 (Aberdeen, Scotland, 2005), 151-155

[28] Terenziani, P., Montani, S., Bottrighi, A., Torchio, M., Molino, G., Correndo, G.: The GLARE Approach to Clinical Guidelines: Main Features, In Proc. of Symposium on Computerized Guidelines and Protocols, CGP 2004 (Viena, AU, 2004), 162-166

[29] Tu, S. W., Campbell, J., Musen, M. A.: SAGE Guideline Modeling: Motivation and Methodology, In Proc. of Symposium on Computerized Guidelines and Protocols, CGP 2004 (Prague, Czech Republic, 2004), 167-171

[30] Tu, S. W., Campbell, J. R., Glasgow, J., Nyman, M. A., McClure, R., McClay, J., Parker, C., Hrabak, K. M., Berg, D., Weida, T., Mansfield, J. G., Musen, M. A., Abarbanel, R. M.: The SAGE Guideline Model: Achievements and Overview, Journal of the American Medical Informatics Association 14 (2007), 589-598.

[31] Tu, S. W., Glasgow, J. 2006. The SAGE Guideline Model Technical Specification. Stanford Medical Informatics. Technical report SMI-2006-1243.

[32] Tu, S. W., Musen, M. A.: Modeling Data and Knowledge in the EON Guideline Architecture, In Proc. of Proceedings of 10th Triennial Congress of the International Medical Informatics Association, Medinfo 2001 (London, UK, 2001), 280-284

[33] Wang, D., Peleg, M., Tu, S. W., Boxwala, A. A., Ogunyemi, O., Zeng, Q., Greenes, R. A., Patel, V. L., Shortliffe, E. H.: Design and Implementation of the GLIF3 Guideline Execution Engine, Journal of Biomedical Informatics 37 (2004), 305-318.

[34] Wang, D., Shortliffe, E. H.: GLEE – A Model-Driven Execution System for Computer-Based Implementation of Clinical Practice Guidelines, In Proc. of Proceedings of American Medical Informatics Association Annual Symposium, AMIA 2002 (San Antonio, TX, USA, 2002), 855-859

[35] Wyatt, J. C., Sullivan, F.: eHealth and the future: promise or peril?, BMJ 331 (2007), 1391-1393.

[36] Young, O., Shahar, Y.: The Spock System: Developing a Runtime Application Engine for Hybrid-Asbru Guidelines, In Proc. of 10th Conference on Artificial Intelligence in Medicine, AIME 2005 (Aberdeen, Scotland, 2005), 166-170

[37] Young, O., Shahar, Y., Liel, Y., Lunenfeld, E., Bar, G., Shalom, E., Martins, S. B., Vaszar, L. T., Marom, T., Goldstein, M. K.: Runtime application of Hybrid-Asbru clinical guidelines, Journal of Biomedical Informatics 40 (2007), 507-526.