Software Architecture of Remote Assisted Living

Transcription

1 Adaptation Issues in Software Architectures of Remote Health Care Systems Orlando Loques Instituto de Computação Universidade Federal Fluminense (UFF) Niterói, RJ, Brazil Alexandre Sztajnberg Dept. de Informática e Ciência da Computação Universidade do Estado do Rio de Janeiro (UERJ) Rio de Janeiro, RJ, Brazil alexszt@ime.uerj.br ABSTRACT In this text we identify relevant adaptation issues concerning the software architecture of a system for intelligent health monitoring of a person at home. Our solution integrates medical knowledge, patient's physiological and behavioral data, and environmental conditions. The designed software architecture includes modules for context management, alarm generation, reasoning and learning. A fuzzy logic model, and rules based on medical recommendations, helps analyzing and identifying critical situations of the patient. In this scenario, ubiquitous computing has an important role allowing the non-intrusive monitoring of several relevant context variables. Considering this infrastructure, we argue that configuration management and context management are key mechanisms to support the adaptation requirements of the target class of applications. Finally, we describe our approach towards tackling the related architecture adaptation issues. Categories and Subject Descriptors D.2. [SOFTWARE ENGINEERING]: Software Architecture, Domain-specific architectures, Adaptive Architectures General Terms Design, Software Architecture, Configuration Management, Context management, Experimentation, Remote Health Care Keywords Remote assisted living, health care, software architecture adaptation and configuration 1.INTRODUCTION All around the world, the elderly population, which is more susceptible to chronic diseases and critical health conditions, is increasing, putting an enormous pressure on the health care infrastructure. This situation is particularly serious in countries where there are insufficient economic resources to cater for the health of the population. In this scenario, remote health assistance represents a potential solution, helping to alleviate an overloaded hospital system and providing better health care services. However, the accrual of its potential benefits demands for specialized hardware and software infrastructures, in order to Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SEHC '10, May 3-4, 2010, Cape Town, South Africa Copyright 2010 ACM /10/05... $10.00 collect and process the relevant information for implementing remote health care services. In this text, we focus on some adaptation aspects of the software architecture of an ubiquitous computing system designed to support remote assisted living applications [5, 6, 12]. As represented in Figure 1, a Home Health Station (HHS) is provided in the architecture, collecting and processing information from sensors. The overall architecture also includes a Supervisory Medical Facility (SMF), used to remotely monitor a large number of patients, and interfaces for use by doctors, caregivers, and relatives of the patients. In this scenario, the relevant physiological, behavioral an environmental data can be collected and interpreted in real-time. Additionally, activities related to a person's behavior (e.g., going to the bathroom, sleeping, eating, etc.) can be inferred by processing data from sensors located in the environment [7]. Bedroom WiFi AP TV Ambient Sensors Decision Process - activity recognition - inference: context + rules - learning and personalisation Patient s Home WC Care Plan - new measurements - take medications -diet or exercises Office - Blood pressure - Heart rate - Activity... Home Health Station Remote Supervisory Medical Facility Figure 1. Remote assisted living: system overview We also have identified an intra-architectural adaptation requirement concerning the set of medical rules that identify critical patient s conditions [5, 6]. At this level, a Learning Process can identify recurrent false (clinically irrelevant) alarms and suggest to the physician a rule parameter adjustment aiming to improve the confidence on the system outputs. The learning process procedure has to be customized for each different kind of health treatment or patient illness. At the HHS, the collected data is represented by fuzzy variables, in order to cover inherent inaccuracies of the associated variables (e.g., blood pressure) and processed through artificial intelligence techniques, based on a set of rules produced in cooperation with

2 medical experts (Figure 2). The identification of a patient's abnormal condition can activate a local device (e.g., turning on an air conditioning appliance), start an interaction with the person (e.g., through a TV screen), increase the data monitoring rate, or send an emergency message to the SMF. Our prototype is focused on hypertensive patients monitoring [5], but its modular architecture should allow its customization for different kinds of illnesses. In principle, the basic customization implies in specifying a new set of medical rules, specialized for the targeted illness; an appropriate set of sensors to collect the relevant physiological and contextual data has also to be selected. Additionally, a personalized Care Plan should also be setup, according to the medical recommendations applied to the patient's illness (please, see Section 3). The design of the software architecture of context aware applications for remote health care represents a major challenge on the Software Engineering area. In particular, several requirements associated with specific application aspects have to be translated into (or associated to) elements of the architecture, e.g., security, safety, privacy, medical knowledge, user's interfaces, etc. [17]. Here we concentrate on architectural level adaptation requirements that we have identified in our project. In the next section we characterize these requirements; our approaches regarding their associated implementation issues are presented in Sections 3 and 4. A brief application example is presented in Section 5. input variables physiological behavioral environmental Context Management vital signs patient s profile patient s data adjust monitoring rate Learning Reasoning medical rules medical guidelines Home Health Station patient s situation Figure 2. Reasoning & Learning Modules 2.ADAPTATION ISSUES Remote Supervisory Medical Facility Each installation of the system must be configured to the targeted residential environment and also individualized for the type of illness of the patient to be assisted. Since each person is unique, his/hers monitoring requirements (including the set of sensors required) and the software features necessary for their support may vary greatly. Additionally, the health problems of the patient change over time, which introduces requirements for flexibility and adaptation in the architecture of these systems [17]. At runtime, context-aware applications are constrained and bound by the state of the used components and resources, regarding their availability and quality. For instance, considering remote assisted living applications, the environment where they are usually deployed can often change: sensors or new medical equipments can be added, removed or may fail. As a consequence, these applications need to gracefully adapt to cater for: resource and context variations; specific features required in the particular application; and the operational quality (regarded to nonfunctional requirements) expected by the application. In the HHS, we notice the presence of a flow of tasks based on the intrinsic characteristic of the application, where a doctor prescribes actions to be performed by the patient (e.g., physical exercises in the morning), and the medication to be taken, through a Care Plan, depicted in Figure 1. The care plan (a sequence of tasks, similar to a workflow) is used to guide the interaction of the system with the patient being assisted at home. For instance, the system can remind the patient, via a message on the screen of a TV, the need to take a drug forgotten in the right time. However, in order to give some freedom to the patient, this interaction cannot be intrusive forcing him\her to comply strictly with the tasks embedded in the care plan (e.g., to interrupt a bath to take a medicine). Thus, the care plan activities can be dynamically rescheduled in accordance with the activities being performed by the patient, but without affecting the patient's adherence to the medical treatment. For example, identifying the situation (having a bath) the system notifies the patient later, at a more appropriate occasion. The rescheduling of the care plan may require a software reconfiguration in order to add (or remove) a specific task (implemented by a software module) to comply with the new scenario, e.g., a pending blood pressure measurement task can be revoked in order to free shared resources. Similar questions have recently been identified by other researchers [4, 16]. This specific adaptation issue is also being addressed in our research. 3.CONFIGURATION MANAGEMENT Configuration management is a well established discipline used to control the evolution of software. However, in conventional settings, the architecture configuration is defined at design or deployment time and is kept mostly unchanged during the execution. In our class of applications, besides requiring a customization before deployment, the configuration of the software architecture can vary after implantation, demanding techniques and mechanisms to support configuration management at runtime, e.g., [3, 9, 13]. In the previously discussed scenario, several factors make up the system configuration at any given instant of time, for example, the execution stage of the care plan, the firing of medical rules leading to alarm messages, and the environment devices statuses. A proper implementation of the configuration management mechanism, in such dynamic environment, will provide a chance for audit and control over the evolution of the architecture elements, allowing, for example, the automatic identification of conflicting elements or to detail (a posteriori) the reason that caused an alarm to be fired. Dispense with automated support for the adaptation of the architecture configuration at runtime is not reasonable, because the use of ad hoc techniques would be extremely laborious, expensive and error-prone [8]. In a related line of research, we developed a generic framework to support self-adaptive (configurable) applications [3, 13]. The adaptations are defined through a contract language that is associated to the software architecture description of the application. The contracts specify configurations that should be imposed at typical contexts that are recurrent during the application's operational stage (note: available configuration primitives can be used to create configuration scripts that can be executed at runtime). We are experimenting using this framework to express the dynamic adaptation requirements of our target home care application. The ultimate goal is to automate the mechanical aspects of the configuration process, reducing costs and increasing the reliability of the applications.

3 At this stage of our research, we also intend to refine our architecture design to conform with the principle of software product lines; this will help to model our target domain specific applications and their acceptable configuration variations. With this strategy we intend to further simplify configuration management, enabling to fulfill the adaptation requirements of the application throughout its life cycle [11]. Provisioning for reuse, as the adoption of a library of components and services, is also planned aiming to reduce the cost of software deployment. 4.CONTEXT MANAGEMENT In our approach, the specification of an architecture configuration adaptation is associated to logical rules (predicates) that take into account the current application's context, i.e., its configuration, including components and used resources, as well as domainrelated information such as: the current activity and location of the patient, health status, whether or not the patient lives alone, or a new medical routine prescribed by a doctor. The context information inferred or collected from the environment is applied to evaluate predicates that trigger (re) configuration actions. Such class of applications can benefit from mechanisms to discover resources that meet their non-functional requirements and mechanisms to monitor the operational status of those resources. The activity of discovering and monitoring resources is recurrent in ubiquitous systems used in applications, such as home automation or e-health. Thus, it is desirable to describe these activities using high-level abstractions and manage them in a uniform way. To provide such a high-level discovery and monitoring capabilities the infrastructure has to offer basic services and enforce a discipline for their use. For instance, components and resources to be discovered, used and monitored have to be described and then published (or registered) in some directory service. Without these steps clients would not be able to find a required service, validate if a service really offers what is needed, and even check its operating conditions. Moreover, the description style of components and resources should be decoupled from specific implementations and should facilitate the integration of new elements. In addition, interaction among the resources and the infrastructure should also be independent from specific communication mechanisms, so they can be integrated and reused more easily in other technological domains. In [14], we describe a Context Service that provides access to context information and a Discovery Service, which allows the dynamic discovery of resources, considering context constraints (defined by contract profiles) to be satisfied. The software architecture of these services was designed as a framework of objects, which are implemented as Web Services and follow a simple design pattern (depicted in Figure 3) composed by the following components: Resource Agent (RAgent): A Resource Agent makes context information available and responds to monitoring queries on behalf of a given resource, hiding low-level details used in the sensing and acquisition of raw data. Each resource type is associated to an XML description, which specifies its properties. Registration and Directory Service (Reg&DirServ): This service implements the primary repository for all resource discovery and monitoring elements. At startup each RAgent has to register itself in the Reg&DirServ to inform the class of resource it belongs to, its properties, and if each property is static or dynamic. Context Service (ContextServ): This service is responsible for making available context information and hiding the communication details from the RAgents. It provides a high-level access interface for information requests. A client application can customize which data is required and how it shall be collected. Discovery Service (DiscServ): This component provides an interface that can be used to identify among registered resources a list of resources of a given kind that complies with a set of context constraints. The returned list can be further filtered or ranked so that the best possible resource is identified. When performing a discovery activity, the DiscServ goes to the Reg&DirServ and gets a list of resource locations that comply with context restrictions. If one or more attributes have dynamic values, the DiscServ has to ask the ContextServ for recently monitored information. The client application (in our approach, an architecture configurator) can query the DiscServ to find a resource of a given type and a given set of attribute values or range of values. After setting the initial configuration of resources, the context-aware application can monitor the context using the ContextServ. The interaction between the client and the ContextServ can also be set to push or pull styles. A query submitted to the ContextServ can be customized so that a specific set of RAgents is monitored. The resulting response is a composition containing information of all RAgents in the set. query Client pull context push context Discovery Service query context Context Service locate resources pull state push state validate resource Registration and Directory Service register Resource Agent Figure 3. Context management components 5.ASSISTED LIVING APPLICATION A more detailed description of a context-aware remote assisted living application, which employs the services described in Section 4, is available in [14]. The scenario we are working on was depicted in Figure 1; a typical setting involves sensors that collect data from the patient s home, interpret the collected data and send the results to a Supervisory Medical Facility, that can be situated in a hospital, or directly to a doctor. Each room has a set of ambient sensors (such as, temperature, light and humidity levels). The heating and cooling system of the house and Digital TVs that are able to receive and display messages are also part of the application. The patient will wear a location tag and a motion sensor (an accelerometer). The patient will also have to put on a medical appliance [15] (able to measure heart rate rhythm regularity, blood pressure, respiratory rate, body temperature, and oxygen saturation (SpO2)), when the care plan says it is time to do so. All devices communicate with a computing node using a mix of wireless and wired network. The identification of a patient's abnormal condition can trigger local actions or notify through an emergency message an external entity. The Home Health Station (HHS) runs a software system comprised by the following modules: reasoning and learning, care

4 plan manager, data monitoring, context management, database, communication module, and a specialized touch screen interface. In our system, context data is comprised by the ambient sensor measurements, the patient s current activity and her/his location in the house, and the physiological/medical measurements. The context data and the inferred patient s health status are stored in a local database that maintains an individualized history of the patient. The history information is also sent to a monitoring center and is made available to the doctor and other involved health professionals and some of the patient s relatives. This historial data can be used for medium term predictions of the health situation of the monitored person. 6.CONCLUSION We argue that configuration management and context management concerns are strongly related. To begin with, both activities need context knowledge: patient related information, currently activated and deployable software modules, available resources and their statuses, available network infrastructure, and so on. In addition, at their specific level of concern, both need to know which features the application should have and the set of requirements to be met at each particular operating scenario. In other words, they together need to know the overall current configuration. Using this combined information a configuration manager entity can impose the best suited architecture configuration at any given time. Using a configuration support framework, like those described in [3, 9, 13], the relevant requirements can be expressed using architectural level contracts (which define a set of rules and context predicates) associated to an Architecture Description Language (ADL) based description of the application. This ADL enriched description can lead to a customized application configuration to be deployed for a specific patient, disease, house and sensor set. The requiured resources can be discovered and selected using the context management service described in Section 4. In addition, adopting a product line approach, at the deployment stage, the initial configuration would be immediately established; in our proposal, verification and validation procedures could be applied before deployment [2]. From then on, adaptive configurations would keep the application on the best possible operating path, in a sequence of operating contexts. Hopefully, manual configuration would be reduced to interventions to cater for application maintenance and evolution activities. We have implemented a working prototype that includes the main elements of the system described in this paper. We have evaluated the system output's confidence using synthetic data generated from ABPM (Ambulatory Blood Pressure Monitoring) exams of real patients. According to this evaluation, the proposed approach performs reliably for hypertensive patients, probably because it relies on averages and considers the vital signs overall history. Currently our efforts are being concentrated in improving the learning process using classical clustering and pattern recognition techniques such as proposed in [1, 10]. In addition to continuing to develop several aspects of the system, we intend to perform experiments with real patients in order to better evaluate our initial results. As a next step we intend to apply the proposed architecture to other types of illnesses, such as cardiac insufficience, that is closely related to our prototype initial application; this would allow a closer evaluation of the effort required to customization. 7.ACKNOWLEDGMENTS We would like to thank the medical members of our research group for their close collaboration and strong efforts for transmitting the medical knowledge required to undertake this project. This research is partially supported by CNPq and FAPERJ research funding agencies. 8.REFERENCES [1] Bezdek. J. C. Pattern Recognition with Fuzzy Objective Function Algorithms. Kluwer Academic Publishers, Norwell, MA, USA, 1981 [2] Braga, C., Chalub, F. and Sztajnberg, A. A formal semantics for a quality of service contract language. Electronic Notes in Theoretical Computer Science, 203, 7 (Apr. 2009), DOI= j.entcs [3] Cardoso, L., Sztajnberg, A. and Loques, O. Self-adaptive applications using ADL contracts. In Proceedings of the Second IEEE International Workshop on Self-Managed Networks, Systems & Services (Dublin, Ireland, June, 2006). LNCS, Springer Berlin / Heidelberg, 3996 (Jun. 2006), DOI= [4] Cho, Y., Choi, Jo. and Choi, Ja. Context-aware workflow system for a smart home. In Proceedings of the 2007 International Conference on Convergence Information Technology, (Gyeongju, Republic of Korea, Nov. 2007). ICCIT 07. IEEE Computer Society. [5] Copetti, A., Leite, J., Loques, O., Nóbrega, A. C. and Barbosa, T.C. Intelligent context-aware monitoring of hypertensive patients. In Proceedings of the 1st Workshop for Situation recognition and medical data analysis. 3rd International Conference on Pervasive Computing Technologies for Healthcare (London, UK, 2009). [6] Copetti, A, An architecture for intelligent context-aware remote assisted living applications, PhD Thesis in preparation (2010), Instituto de Computação, Universidade Federal Fluminense, Niterói, Rio de Janeiro, Brazil [7] Dalal, S., Alwan, M., Seifrafi, R., Kell, S. and Brown, D. A. Rule-based approach to the analysis of elder's activity data: detection of health and possible emergency conditions. In Proceedings of the AAAI Fall 2005 Symposia (Arlington, Virginia, USA, Sep. 2005). Caring Machines: AI in Eldercare, Technical Report FS-05-02, The AAAI Press. [8] Fernandes, P., Werner, C. and Murta, P. L. G. Feature modeling for context-aware software product lines. In Proceedings of the 20th International Conference on Software Engineering & Knowledge Engineering (San Francisco, CA, USA, 2008). [9] Garlan, D., Cheng, S-W., An-Cheng, H., Schmerl, B. and Steenkiste, P. Rainbow: architecture-based self adaptation with reusable infrastructure. IEEE Computer, 37, 10 (Oct. 2004), DOI= MC [10] Gustafson, E. E., Kessel, W. C. (1979). Fuzzy clustering with a fuzzy covariance matrix, IEEE Conference on Decision and Control, V. 17, pp [11] Lopes, L. G., Murta, L. G. P. and Werner, C. Odyssey-CCS: A change control system tailored to software reuse. In Proceedings of 9th International Conference on Software Reuse (Torino, Italy, Jun. 2006). ICSR9.

5 [12] Loques, O., Carvalho, S., Copetti, A., Sztajnberg, A., Erthal, M. and Santos, R. SADES: Sistema de assistência domiciliar à saúde telemonitorada. Technical Report, Instituto de Computação, UFF, Niterói, RJ, Brazil, [13] Loques, O., Sztajnberg, A., Cerqueira, R. C. and Ansaloni, S. A contract-based approach to describe and deploy nonfunctional adaptations in software architectures. Journal of the Brazilian Computer Society, 10, 1 (Jul. 2004), [14] Sztajnberg, A. et alli. Applying context-aware techniques to design remote assisted living applications. Intern. Journal of Functional Informatics and Personalised Medicine, Inderscience Publishers, 2, 4 (Dec. 2009), DOI = [15] Telcomed Advanced Telemedicine Industries. Wristclinic - the all-in-one wireless remote medical monitoring revolution, 2010; [16] Wieland, M., Kaczmarczyk, P. and Nicklas, D. Context integration for smart workflows. In Proceedings of the Sixth Annual IEEE Conference on Pervasive Computing and Communications (Hong Kong, China, Mar. 2008). PerCom DOI= PERCOM [17] Zarifi Eslami, M. and van Sinderen, M. J. Flexible home care automation adapting to the personal and evolving needs and situations of the patient. In Proceedings of 3rd International Conference on Pervasive Computing Technologies for Healthcare (London, UK, Apr. 2009). PervasiveHealth IEEE Press. DOI= /ICST.PERVASIVEHEALTH