$EVWUDFW In this paper we introduce an extension of the PARADIGMA (PARticipative Approach to DIsease Global Management) approach to take into account the home healthcare assistance service. PARADIGMA defines and disseminates a common methodology and optimized protocols (Clinical Pathways) to support service functions directed to patients and individuals on matters like prevention, post-hospitalization support and awareness. Specifically, PARADIGMA will provide a platform of information services - user oriented and optimized against social, cultural and technological constraints - supporting the Health Care Global System in a continuous improvement process.
,QWURGXFWLRQ
This paper discusses the extension of PARADIGMA to take into account the home
healthcare assistance service. PARADIGMA aims to develop and demonstrate an
Internet based reference framework to share scientific resources and findings in the
treatment of major diseases [
PARADIGMA chooses to concentrate on a set of themes (basic diseases) that have a great relevance in the community: 1) Prophylaxis of thrombo-embolism, 2) Infant death reduction, 3) Colorectal cancer treatment, and 4) Improvement of performance in intensive care. The PARADIGMA Consortium comprehends 26 partners of 10 different Countries structured in 4 Competence Groups (one for each basic disease) and 9 Pilot Sites. Each Competence Group will formalize, for its specific disease, an integrated multi-disciplinary assistance plan, created to solve specific clinical problems, minimize incorrectness in medical practice and reduce related cost. They define the best sequence of actions to treat patients with specific clinical conditions, enlarging the attention from the clinical case to the patient and his complex needs of assistance. The Pilot Sites will be asked to describe their context and working conditions and to define their requirements in terms of information services and decision support tools.
The PARADIGMA architecture (see [
The outline of the paper is as follows. Sect.2 deals with the PARADIGMA’ s project structure and Sect.3 introduces the Navigator Architecture. Sect.4 illustrates the Home Healthcare Service requirements. Lastly, Sect.5 contains some conclusions.
7KH 3URMHFW )UDPHZRUN
PARADIGMA’ s objective is to support Disease Management improvement, focusing
on needs and characteristics of patients, workforce and structures. Three basic
knowledge repositories (Figure 1) have been implemented, starting from context
descriptions (which provide a formalisation of the “as is” reality of pilot sites) and user
requirements (which provide a set of possible use scenarios) [
Context Description User Requirement Def.
Clinical Pathways Def.
Ontology Definition
The PARADIGMA framework will make provision for suitable user interfaces both to
input data (electronic forms, questionnaires, guided interviews, etc.) and to navigate
(user and context oriented interfaces, customized functionalities, aimed training, etc.)
the framework itself.
The PARADIGMA Navigator can be seen as a knowledge-based computing
environment for [
In PARADIGMA these activities are supported by iGrafx (see [
Activity
Decision
Start/Sto link
Department )LJ
Basic Modeling Elements An DFWLYLW\ is a step in the workflow, which represents the clinical pathway. Each activity is specified by a set of parameters that describe its Inputs, Resources, and Outputs, its duration, its related costs, its capacity and scheduling of resources. Modeling elements are connected with OLQNV, which describe the control flow. An activity is placed into a 'HSDUWPHQW (represented as a “ swimming lane” ), which performs the activity. For instance, the workflow depicted in Figure 3 shows the clinical pathway describing blood treatment and includes a treatment of emergencies (the patient is taken to the hospital).
Start
End )LJ
A simple pathway specifying blood management and emergency treatment. [OK-next test]
cond [critical] The goal of our work is to develop in the Navigator framework a service that offers the following facilities to the user at the patient’ s home: Given the clinical pathway to be applied, the service specifies the pending deadlines and the actions to be taken next. Moreover, the service facilitates the execution of such actions by automatizing the activities that can be carried out via Web. For instance, suppose that the patient’ s blood has to be frequently tested and that the date of the next check up is set given the results of the previous one (this is a typical practice for people treated with blood thinners). Then, the system should alert the patient when the results of a blood test are available; moreover, if the patient cannot be easily moved from home to the hospital, the service should request from the nursery service a nurse to take his blood at home. The User Interface acts as a single point of access to the service, regardless the number of clinical pathways applied to the patient. This means that the active clinical pathways compete with one another in the management of shared resources such as the patient’ s clinical record. Moreover, the patient’ s activities have to be coordinated in order to prevent a scheduling of activities that cannot be carried out in parallel, and also to optimize the movements from home to hospital, if possible. A direct connection between the devices monitoring the patient and his clinical record is provided to support its real time update. The service adapts the instructions presented to the user on the basis of the following factors: - User Knowledge: the system will be exploited by users having rather heterogeneous expertise. However, the user’ s role clearly determines the background that she is expected to have. Therefore, the service will select the content to be presented on the basis of this information. - User capabilities: similar to the previous point, depending on the user’ s role, different actions will be selected to carry on the clinical pathways. For instance, suppose that the patient’ s blood pressure becomes very low and a clinical pathway prescribes to treat him with a drug. If the user interacting with the system is a nurse or a doctor, the service will suggest to treat the patient as expected; otherwise, the service will suggest to take the patient to the hospital or to call a doctor, depending on the blood pressure value. - Contextual conditions: the patient health state and the presence of devices in the patient room will be taken into account to choose the most suitable actions to perform. For instance, if the patient state becomes unstable, an emergency situation is activated and the service will suggest taking the patient to the hospital. Moreover, if needed (e.g., the patient cannot be moved to the hospital by car) the service will activate the emergency team of the hospital and request an ambulance with doctors on board.
The previous description suggests managing the active clinical pathways as parallel workflows whose progress depends on the patient’ s health conditions. It should be noticed that a direct specification of a clinical pathway, including all the possible variations, would lead to the definition of very complex workflows. For instance, for each activity, it would be necessary to specify all the alternative ways to perform it and the criteria for selecting the one to be applied depending on contextual conditions and on who is interacting with the healthcare assistance service. In order to reduce the complexity of the workflows and support the clinical pathway adaptation, we propose to separate the management of clinical pathways from the execution of the specific actions associated to their activities. The idea is that each clinical pathway should be defined as a partial ordered set of generic activities to be scheduled by a clinical pathway manager module. Each activity could be then performed in alternative ways, which are declaratively specified and separated from the clinical pathway specification in order to be analyzed by an activity execution engine. The activities to be carried out may be performed in different ways. For instance, activity A1 (Blood test) in Figure 3 can be performed either by taking the patient to the lab for the test or by having a nurse who goes to the patient’ s home, takes the blood and carries it to the lab (Figure 4).
DSSO FRQGLWLRQ: movable patient ERG\: - fix appointment with lab; - notify patient about place and time of appointment;
DSSO FRQGLWLRQ: non movable patient ERG\: - fix appointment with lab; - request nurse at home; - notify patient about time of arrival of nurse; - notify nurse about lab; )LJ
Alternative ways to perform an activity.
Moreover, activity A3 (go to hospital) can be carried out by taking the patient to the hospital by car or by exploiting an ambulance with an emergency team. During the execution of the workflow, the clinical pathway manager would manage the workflow at the level of the abstract activities; for each activity, the manager would exploit an execution engine that selects the actions to be performed (given the contextual conditions), executes them and returns the results to the clinical pathway manager. In turn, the execution engine would employ more or less complex techniques to select the actions to be performed and to execute them. Specifically: The execution of some actions includes both the invocation of supplier services and the presentation of detailed instructions to the user. For instance, if the patient can be taken to the lab, the engine should request an appointment from one of the available labs and notify the patient about place and time of the appointment. In that case, the activity should be considered as (successfully) terminated when the patient’ s blood is taken. The generation of instructions depends on the role played by the user who interacts with the service. For instance, suppose that the patient cannot be moved from home to the lab. Then, the system should request that a nurse comes at home at the specified date. Then, the patient has to be notified about the time of arrival of the nurse and the nurse must be informed about the lab she has to deliver the patient’ s blood. The separation of workflow management from action execution supports the specification of simpler clinical pathways and a high degree of flexibility in their execution. In fact: the specification of alternative ways to perform a certain activity can be isolated from the main workflow, therefore making the workflow specification concise, the activity execution module can be implemented as an intelligent component that takes information about the user interacting with the service, the patient and the context of interaction into account in order to select the actions to be performed and the instructions to present on the user interface, depending on the user’ s role. We are developing this framework in Java and standard communication/representation languages. Specifically, the User Interface component is based on XML techniques to support multi-device access (desk-tops, cell phones, PDA). Moreover, for specification and management of clinical pathways we selected the BPEL1.1 process language because it is emerging as a standard in Web Service composition and has some reference implementations available (e.g., the Oracle BPEL Server).
&RQFOXVLRQV The description of the PARADIGMA Project Structure offers an insight in the steps that can be needed to develop a network based information environment which aim is to connect the actors at all levels in the Health Care System in order to promote a “ participative” approach to diseases management.
We presented a framework supporting the execution of clinical pathways tailored to contextual conditions concerning the patient and the execution environment. Our framework manages the main steps of a clinical pathway by abstracting and separately treating the details affecting the execution of operations in specific contextual conditions. The separation of workflow management from action execution simplifies the description of clinical pathways and enhances the flexibility in their execution. In fact, the description of the different ways to perform an activity can be separated from the workflow (making the workflow concise) and an intelligent component may be employed as an activity execution module which selects the best way to perform the clinical pathways, given the user interacting with the service and the patient state.