IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
1597
A Model for Ubiquitous Care of Noncommunicable Diseases Henrique Damasceno Vianna and Jorge Luis Vict´oria Barbosa
Abstract—The ubiquitous computing, or ubicomp, is a promising technology to help chronic diseases patients managing activities, offering support to them anytime, anywhere. Hence, ubicomp can aid community and health organizations to continuously communicate with patients and to offer useful resources for their self-management activities. Communication is prioritized in works of ubiquitous health for noncommunicable diseases care, but the management of resources is not commonly employed. We propose the UDuctor, a model for ubiquitous care of noncommunicable diseases. UDuctor focuses the resources offering, without losing self-management and communication supports. We implemented a system and applied it in two practical experiments. First, ten chronic patients tried the system and filled out a questionnaire based on the technology acceptance model. After this initial evaluation, an alpha test was done. The system was used daily for one month and a half by a chronic patient. The results were encouraging and show potential for implementing UDuctor in real-life situations. Index Terms—Collaborative work, noncommunicable diseases, public healthcare, ubiquitous computing, ubiquitous health.
providing continuous management, and have Internet access, enabling the connection with people and information systems that have the capacity to help in NCDs care activities. Considering the related works, it is possible to imply that still little attention is given to support the search of nearby resources and people that are able to help chronic patients in their activities. This paper proposes the UDuctor, a model for ubiquitous care of NCDs. The main focus of this proposal is to fill this gap. Additionally, UDuctor supports the features for self-management and communication with health organizations that are present in the related works. The paper is organized in six sections. Section II presents an introduction to ubiquitous health and chronic care models (CCMs). Section III addresses works which have applied uHealth in some activity of NCDs care. Section IV describes the UDuctor model. Implementation aspects are covered in Section V. This section also describes two practical experiments involving chronic patients and the results obtained with them. Section VI presents final remarks and directions for future works.
I. INTRODUCTION CCORDING to the latest global status report on noncommunicable diseases (NCDs) by the World Health Organization (WHO), the burden of these diseases continues to grow, especially in low and middle income countries [1]. These diseases can be caused by habits such as a sedentary lifestyle and smoking that result in “metabolic or physiologic changes” like, for example, high blood pressure, overweight, and obesity. The NCDs treatment must be done continuously, since there is no cure for most of those diseases. Therefore, patients need to be aware of their condition, follow the treatment planned by the medical responsible, and know how to act when needed. In some occasions, the patient may not have the required confidence to perform certain activities, requiring the collaboration of someone with experience [2]–[4]. In this way, it is possible to observe that smartphones merge two useful features for aiding the control of NCDs. They are always close to their owners,
A
Manuscript received May 16, 2013; revised September 11, 2013 and November 9, 2013; accepted November 17, 2013. Date of publication November 27, 2013; date of current version September 2, 2014. This work was supported by the Capes/Brazil (Coordination for the Improvement of Higher Education Personnel) and CNPq/Brazil (National Council for Scientific and Technological Development). The authors are with the Applied Computing Graduate Program (PIPCA), University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo-RS, 93022000, Brazil (e-mail: [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/JBHI.2013.2292860
II. BACKGROUND This section introduces the u-Health and CCMs subjects. These subjects contain the principles that guided the construction of the UDuctor model.
A. Ubiquitous Health The term ubiquitous computing, or ubicomp, was first used by Mark Weiser and his colleagues of Xerox, and may be understood as the use of several distributed computers seamlessly integrated to enhance physical environments [5], [6]. The ubicomp is applied in many areas, such as education [7], commerce [8], accessibility [9], and health. The use of ubicomp in health is also called u-Health or pervasive health [10], [11]. Most of u-Health applications are centered in hospital routine management [12]–[14], patients monitoring [14]–[16], or well-being [10], [17]. u-Health hospital applications focus on the enhancement of hospital staff routines such as medicine administration and prescription, medical team collaboration, and management of conferences, surgeries and emergencies rooms. Patients monitoring applications are commonly used for aiding the care of elder and chronic patients remotely. The well-being class encompasses those applications oriented to personal health management, such as diet management, personal training assistants, and games oriented to the practice of physical activities.
2168-2194 © 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications standards/publications/rights/index.html for more information.
1598
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
The NCDs care can be benefited by u-Health technologies. However, it is desirable that this support be based on existing CCMs. These models will be explained in the next section.
TABLE I RELATED WORKS COMPARISON
B. Chronic Care Models The rapid growth of chronic conditions cases resulted in the creation of models to support their management [2], [18]. The Chronic Care Model (CCM) [2], [19] and the Innovative Care for Chronic Conditions (ICCC) [18] are two models that may be used for chronic care management. The CCM describes practices to improve the interactions between patients and health providers. Thus, for patients to acquire the skills and confidence required to manage their conditions, they need to cooperate with their caregivers, providing information and assessments as a way to help the optimization of their care. In turn, ICCC is a WHO initiative to create a model that can be applied in the care of many chronic conditions. The ICCC breaks its components into three levels (micro, meso, and macro) on the assumption that to succeed, the model must comprise every level from patient to government. There is a strong integration between communities and health organizations in both models, so that patients can succeed in taking care of their own chronic condition. The next section will highlight some u-Health works that cover NCDs care in some way. III. U-HEALTH IN NCDS CARE We decided to focus our study of related works in proposals that contemplate the care of NCDs in the following aspects: self-management support; support for communication among patients, members of the community, and health organization; and support for the search of nearby help. These topics were chosen due to the importance given to them in the CCM and ICCC models. The wellness diary (WD) is a personal mobile application for wellness management based on cognitive-behavioral therapy concepts [20], [21]. Patients use self-monitoring to identify and learn which actions and behaviors influence their health condition. The WD has three components: users self-observations input, self-observations view graphs, and user activities calendar. In self-observations input, the users can add data about the consumption of food and drinks, weight, blood pressure, sleep quality, and stress. The self-observations view is composed by charts that let the users understand the results of their decisions. The activities calendar is used to schedule activities to the user and is integrated to the mobile device calendar. Koutkias et al. [22] propose a framework to use data collected by monitoring sensors to identify adverse effects of drugs in patients. The framework uses an ontology that describes concepts related to effects of drug use, e.g., goals related to drug use, or adverse effects which may be caused by this use. The system architecture has two components: the clinical subsystem and the mobile base unit (MBU). Information about substances, contraindications, adverse drug effects, and alert management resides in the clinical subsystem. The subsystem supports vitalsign monitoring rules which are used to control the medication
usage effects in patients. These rules are sent to the MBU which is responsible for vital sign data acquisition and monitoring. When a vital sign reading is outside the patterns defined by the rules, the MBU sends an alert message to the subsystem which forwards the information to the patient’s responsible. Paganelli and Giuli [23] present a context-aware system to support NCDs care and management. This system runs on top of a service platform to support continuous care of chronic conditions called ERMHAN [24]. The ERMHAN platform aids in the care for network actors, i.e., patients, relatives, and health organization members, which share responsibilities in care taking activities. The platform provides an environment for home monitoring and alert generation for the care network according to the rules entered into the system. A. Analysis of the Studied Works We compare the related works in the way they provide support for self-management; communication among patients, members of the community, and health organization; and search of nearby help. Table I shows the results of this comparison. The self-management support is determined by the goals and activities provided by a care team and should be performed by the patient. Support for these activities can be done by aiding the intake of healthy foods, physical activities, or reminders for tasks that should be done continuously. The communication among patients, members of the community, and health organization indicates if the work enables the connection with members of the community, or members from health organizations, as way to obtain support for some kind of NCDs care activity, or to alert that the patient needs help. For example, Koutkias et al. framework [22] sends an alert for the patient’s caregiver if the prescribed drug is causing an undesirable effect. The search of nearby help support represents the way used to help patients in the search of nearby services, resources, or people which may be useful for their care or wellness. This support can be a pharmacy which has a medicine with an affordable price, a public park with exercise equipment, or community
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
1599
classes for some kind of physical activity. None of the related works include this support type. This support is cited by CCMs like CCM [2], [19] and ICCC [18], and could help patients improve their self-management capability. Next section presents UDuctor, which contributes to the support in searching for nearby help, in addition to self-management and communication among patients, members of the community, and health organization that are already supported in the related works. IV. UDUCTOR MODEL This section presents the UDuctor model. First, we show how the model elements are organized and how they interact (conceptual model). Second, the middleware that implements the conceptual model is described. Finally, the section approaches a personal health assistant that uses the UDuctor middleware as an infrastructure to support care in NCDs activities. A. UDuctor Conceptual Model The UDuctor’s conceptual model is inspired by the abstraction model of the Continuum Project [25], and is composed by five elements: Position to Local Node Resolution Service (LRS), Local Node (LN), Personal Node (PN), Context, and Resource. In the UDuctor model, nodes are the entities responsible for sharing resources and context information. Resource is any content shared by a node that has capability to help UDuctor users in their activities. In some cases, the resources may represent a description of physical resources, like a scale in a pharmacy, or can be an electronic resource like a picture of a food guide pyramid stored in one node. Context is any attribute that can identify the situation of one entity [26], for example, the temperature of a location, or the blood pressure of a person. There are two types of nodes: LN and PN. An LN represents a place in a geographic region, i.e., a house, a store, or another type of identifiable location. The LN keeps references to people and others places, and shares resources and context information available in that place. For example, in a pharmacy, the drugs may have references that will represent them as resources, the pharmacist may be referenced as a person, and the local thermometer may have a reference that allows software to subscribe to it and receive temperature change notifications. The PN represents a person who has a mobile device (like a tablet or a smartphone) moving between places represented by LNs. A location change occurs when the PN receives an LN reference different from its current reference. This event makes the PN unbind its reference from the old LN and create a reference with the new LN, what makes the PN logically associated with the location represented by the LN. The PN can use the LN to search for entities that might help the users in their care activities. These entities can be another person who has knowledge in a certain care activity, a resource needed to accomplish certain activities, or a contextual information. Furthermore, PNs can share resources and contextual information in the same way the LNs can do. This allows caregivers to use a PN for real-time patient monitoring.
Fig. 1.
UDuctor example. TABLE II LEGEND OF THE UDUCTOR ELEMENTS OF FIG. 1
Item Number 1 2 3 4 5 6 7 8
Fig. 2.
Description
UDuctor element type
Neighborhood Drinking fountain Temperature Pharmacy Local resident Heart rate Pharmacist Medicine
Local Node Resource Context Local Node Personal Node Context Personal Node Resource
Hierarchical link of the UDuctor elements of Fig. 1.
Fig. 1 shows a real-world situation represented by UDuctor elements. The figure shows a hypothetical neighborhood, where the following items reside: a drinking fountain, a thermometer, a local resident, and his heart rate monitor; a pharmacy, a pharmacist, and a drug sold at the pharmacy. Table II relates the items from Fig. 1 to their element type. Fig. 2 presents an UML object diagram demonstrating how the UDuctor elements are hierarchically linked. The neighborhood is represented by an LN and linked to it is the drinking fountain, which is a local resource; the temperature context, which provides temperature measurement updates from the local thermometer; the pharmacy, which is represented by an LN; the local resident, which represents a PN that moves around the neighborhood, and provides context updates about his heart rate; and the medicine, which is a resource of the pharmacy. As the pharmacy is an LN, it can have PNs linked to it. In this case, the pharmacist is a PN linked to the pharmacy. The LRS is a service responsible for converting the geoposition data of a PN in an LN reference, thus helping the PNs to switch between LNs.
1600
Fig. 3.
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
UDuctor middleware architecture.
The next section will describe the UDuctor middleware architecture. This architecture is implemented in the nodes, providing a ubiquitous software infrastructure to them.
Fig. 4.
6)
B. UDuctor Middleware Architecture The UDuctor middleware is responsible for offering features for resource sharing, context notification, messaging, and access control. Each node of the model runs its own instance of it. The middleware has the following nine components (see Fig. 3): 1) Executable Modules: They are software applications created by developers and registered in the middleware. These modules have access to available features of the middleware as shared resources, context information, access control, messaging, bound nodes, and LN reference. This component allows the use of middleware features by applications with distinct goals. 2) Proxy: It checks if a node or executable module has authorization to access a requested middleware feature. The access authorization is managed by the Access Control Module. 3) Shared Resources: This module manages the resources shared by a node, enabling nodes to create, modify, query, and search for resources. This module is also responsible for notifying the executable modules when a resource is created, deleted, or updated. 4) Context: It allows other UDuctor nodes or executable modules to register themselves for receiving notifications about changes in attributes that identify the situation [26] of a node that runs the middleware instance. If the node represents a person, the attributes could be the body temperature, blood pressure, glucose, or any other relevant attribute that the person shares. If the node represents a place, the attributes may be the air quality index, relative humidity, ultraviolet radiation index, or any other relevant information shared by that place. Like so, a node maintains a context history or trail [27], allowing the applications that run on the middleware to anticipate situations that users may face, by inferring their context histories [28]. 5) Access Control: This module manages the access authorization of others UDuctor nodes, or executable modules, to a certain middleware feature. For example, the information indicating that a certain PN is allowed to receive temperature updates of an LN, or the information indicat-
7)
8)
9)
ChronicDuctor system overview.
ing that the nutritionist PN has access to pictures of meals stored in the PN of a patient. Messaging: This component is used to exchange messages between the nodes. UDuctor does not define a specific format for the messages, allowing the creation of protocols for the needs of each application. Bound Nodes List: It provides a list of references of nodes bound to the running instance of the middleware, and allows nodes to ask to be bound to (or unbound from) the running instance. Local Reference: It represents a reference to the LN to which a PN or LN is bound. The UDuctor nodes use the local references to access resources and context information shared by other nodes, and so enabling them to find opportunities of interest. RESTFul Interface: This interface provides a way for the nodes to remotely access the middleware features of context, shared resources, access control, messaging, local reference, and bound nodes lists. The interface is implemented using the REST architectural style [29].
C. ChronicDuctor App The ChronicDuctor is a personal health assistant that runs as an executable module using the UDuctor middleware to provide support for self-management, communication among patients, members of the community, and health organization, and search of nearby help to its users. These supports are made through the following functionalities: care plan creation support, recommendation of care resources, alert generation, input of vital sign data, and communication between people. As the ChronicDuctor has features from agent systems, i.e., it is autonomous and has goals, it does several things simultaneously, and has the need of change the way it act in accordance with the changing environment; it might be designed as such. Fig. 4 presents a system overview diagram that uses the Prometheus methodology showing a high-level view of the ChronicDuctor [30]. Four agents compose the system: plan manager, monitoring manager, activity manager, and message manager. These managers share responsibilities in order to reach the proposed goals. The plan manager schedules the activities based on the care plan when the system is started, or when a new plan is received. The plan manager is also responsible for notifying the activity
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
manager of activities that must be done, and for notifying the monitoring agent about updates made to the care plan. The monitoring manager receives the context data from the UDuctor middleware for monitoring the progress of user care. Once the care plan was informed, this manager takes care of monitoring the control data that the user might report through the system, for example, blood pressure, weight, or glucose. If the user fails to report the data for a certain period, this manager will ask the message manager to send a message to the responsible for the activity about the incident. Furthermore, the monitoring manager identifies if the user has reached any of the goals (or how long it will take to reach them) when it receives a new control data. The vital sign data are stored in the Context Repository which is managed by the UDuctor context component, so the monitoring manager can track the progress of user care. The activity manager notifies the user about the existence of a new activity that must be done, and searches for resources which might be offered to the user. For each activity, this agent will make a search for devices used for vital sign reading. This search is done so that the agent can build a form where the user can input vital sign data. For example, in the case of the activity be “weigh in,” this agent will use the UDuctor shared resources component, represented in Fig. 4 by the Resource Repository, to look up for resources describing weighing scales. Furthermore, the agent will use the location informed by the monitoring agent to look up for nearby help that can aid the user accomplishing the activity. Initially, the agent will search for help in the place where the user is, if no results are found, the agent will look up for help in the children places of the current place. If yet no results are found, the agent will look up for help in sibling places, and after that it will end the search. Finally, the message manager allows the user to exchange messages with other users nearby. V. IMPLEMENTATION AND EVALUATION A. Implementation Aspects The UDuctor middleware was implemented with Android for PNs and J2SE platform for LNs. This distinction was due to Android’s specific implementation of Java runtime environment [31], what causes some libraries to have different versions for each platform. For the development of the J2SE RESTFul Interface the Jersey package was used, which is an implementation of the JAXRS specification for Java RESTful Web Services. For the Android version, the RESTFul Interface was implemented with Restlet API, which allows the creation of an HTTP server on that platform. To allow semantic search of resources, the resources managed by the Shared Resources module were described with Turtle language (Terse RDF Triple Language), and stored in a RDF repository. The SPARQL language was used for querying this repository. The Jena-ARQ (for the J2SE platform) and AndrojenaARQoid (for the Android platform) were used to store and query data in the RDF repository. Due to a high ARQoid compilation time, the Shared Resources module was placed as a separated
1601
TABLE III CHRONIC CONDITION OF SUBJECTS Subject Number #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
Fig. 5.
High Cholesterol
X
Hypertension
Obesity
X
X X
X
Overweight
X X
X X
X X X
X X
X
Scenario floor plan.
process, communicating with the middleware instance through an AIDL interface. This was done in the Android version only. The Context and Messaging modules were developed using the same programming for PNs and LNs. The Bound Nodes List returns a JSON list of the nodes bound to the middleware instance, while the LN Reference returns a JSON representation of the node where the instance is. The ChronicDuctor was developed for the Android platform and implemented as a service. The communication with the middleware is performed through the AIDL interface of the Android platform. B. Evaluation Aspects Two experiments were conducted for the UDuctor evaluation. The first was a technology acceptance test [32], [33] performed by chronic patients. The second was an UDuctor alpha test, performed by a chronic disease patient for one month and a half. 1) Technology Acceptance: This experiment aimed at evaluating user acceptance of the model [32], [33]. The assessment involved ten volunteers who used the UDuctor and filled out a questionnaire. Table III shows their chronic condition. The experiment was performed in a scenario built at a site localized in the city of Nova Santa Rita, Rio Grande do Sul state, Brazil. The scenario simulates a hypothetical neighborhood using two buildings. The circles in Fig. 5 represent locations in the neighborhood. Each location had its own LN where care resources were distributed accordingly with their roles, for example, medicines are at the pharmacy and the restaurant offers meals. Table IV describes the types of resources that could be found in each place. The experiment was performed with each subject individually. A simple care plan was created using the ChronicDuctor
1602
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
TABLE IV RESOURCES LOCATED AT THE SIMULATION SCENARIO
TABLE V QUESTIONNAIRE STATEMENTS Assessment type Perceived usefulness statements
Perceived ease of use statements
Statement 1. It is possible to describe the care activities with a sufficient level of detail 2. The activities notifications are useful for the care routine 3. The alerts of reached goals are useful for the care routine 4. The progress alerts are useful for the care routine 5. The ability to locate nearby resources according to activity is useful for the care routine 6. The application offers the resources needed to care activities 7. The application helps in your care activities 8. The ability to find people nearby in accordance to the knowledge they have in relation to the activity is useful for the care routine 9. The ability to chat with nearby people is useful for the care routine 10. The ability to input vital sign data (for example, weight, blood pressure, glucose), is useful for the care routine 11. The care plan building form is easy to understand 12. The activity notification alerts are easy to understand 13. The alerts of reached goals are easy to understand 14. The progress alerts are easy to understand 15. It is easy to find people and resources with the application 16. It is easy to chat with people using the application 17. It is easy to input vital sign data (for example, weight, blood pressure, glucose) with the application
Fig. 6. ChronicDuctor activity example. (a) Patient’s activities list. (b) Vital sign input. (c) Caregiver’s notifications list. (d) Caregiver’s chat session. (e) Patient’s conversation list. (f) Patient’s chat session.
to demonstrate the application in NCDs care. At the care plan construction, it was possible to define activities which the subject should accomplish in a determined time, resources that each activity requires, and goals which the subject should reach. For example, in a case of hypertension care, one of the activities shall be “blood pressure reading.” This activity shall be set to search for blood pressure monitors, and the goals can be set to reach a systolic blood pressure measurement of 119 mmHg and a diastolic pressure of 79 mmHg. After the creation of the care plan, the subjects walked through the scenario, using the application in a smartphone, a Samsung GT-S5570B with Android 2.2. The research coordinator used the application in a different smartphone, a Motorola Spice XT300 with Android 2.1, simulating the role of a caregiver. Every time a new activity was detected it was put on top of the patient’s activities list [see Fig. 6(a)]. A new screen is showed after the patient selects the activity [see Fig. 6(b)]. In this screen, the patient is able to search for nearby resources or people, and to input the vital sign data. The caregiver receives a notification about the patient’s goal status as soon as the patient sends the vital sign data
[see Fig. 6(c)]. The chat button in this screen allows the caregiver to start a chat session with the patient [see Fig. 6(d)]. The messages received by the patient are grouped by person in the patient’s conversation list [see Fig. 6(e)]. When the patient selects the caregiver in the conversation list the chat session is restored, allowing the continuation of the conversation [see Fig. 6(f)]. After using the application, the subjects were asked to answer an assessment questionnaire. The questionnaire was prepared following the technology acceptance model (TAM) proposed by Davis [32] and applied and expanded by Yoon and Kim [33] in their study on the acceptance of wireless networks. In the TAM model, user satisfaction is measured through perceived usefulness and perceived ease of use. The first perception determines if the proposed technology can help the user to make a better work, while the second evaluates if the technology can be used with minimum of effort. The questionnaire was composed of 17 statements of five levels Likert items (“Strongly Disagree,” “Partially Disagree,” “Indifferent,” “Partially agree,” “Strongly agree”) [34]. Additionally, there was an open question for general comments and suggestions. The questionnaire statements are listed in Table V. They were divided in perceived usefulness statements and perceived ease of use statements. The statements were oriented to evaluate the satisfaction of the users in relation to self-management support (statements 1, 2, 3, 4, 7, 10, 11, 12, 13, 14, and 17), support to the search of nearby help (statements 5, 6, 8, and 15), and the support to the communication among patients, members of the community, and health organization (statements 9 and 16).
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
TABLE VI USER CARE PLAN
1603
TABLE VII USER’S GOALS
Activity
Frequency
Type
Used Resources
Context Type
Control Method
Breakfast Morning snack Dinner
Daily Daily Daily
Meal Meal Meal
Weight Diastolic blood pressure Systolic blood pressure
Achieve the goal set Achieve the goal set Achieve the goal set
Afternoon snack Supper
Daily
Meal
Carbohydrates; fruits Fruits Vegetables; white meats; carbohydrates Fruits
Daily
Meal
Weight control
Daily
Blood pressure reading Walking
Daily
Vital sign data entry Vital sign data entry Physical activity
Daily
% Completed at Test End -26,7% 100% 73,34%
Vegetables; white meats; carbohydrates Weighing scale Blood pressure monitor -
The responses to the statements oriented to self-management support showed a strong agreement of 96% in both statement types, perceived usefulness, and perceived ease of use. The support to the search of nearby help had a strong agreement of 93.3% in the perceived usefulness statements, and a strong agreement of 80% in the perceived ease of use statements. The support to the communication among patients, members of the community, and health organization had a strong agreement of 100% in the perceived usefulness statements, and a strong agreement of 80% in the perceived ease of use statements. The results showed a good general evaluation considering the high satisfaction of the users. However, the perceived ease of use assessment showed that the application needs improvements in some user interactions aspects, mainly in the localization of help resources and chat features. These results reflect suggestions given by some individuals in the open question. One of the suggestions asks for the “(...)possibility to organize important chats in folders(...),” other suggestion asks for “(...)a way to create more types of resources for search in the care plan builder and a way to create resources in locations (...).” 2) Real Application—Alpha Test: An UDuctor test was performed by a patient with hypertension and overweight. This test was carried out for one month and a half and covered the period from December 15, 2012 to January 31, 2013, aiming to identify issues related to the use of resource search functionality, vital sign data entry, activity information visualization, and goals progress visualization. The UDuctor was used to assist the user in her care activities through alerts of activities that should be performed, input of data control, and search for care resources that might be available close to where the user was located. The UDuctor was installed in the user’s smartphone, a Samsung GT-I81160L with Android OS version 2.3. The guidelines set by the user’s cardiologist and endocrinologist were transformed into an UDuctor care plan, which contained a list of activities and a list of controls for the user. Table VI lists the activities set in the plan, the frequency of these activities, the type of activity, and the types of resources that should be located to assist the user in carrying out each activity. Table VII lists the types of contexts that were controlled,
Fig. 7. Resource locations. (a) Area surrounding the user’s residence. (b) Area surrounding the user’s workplace.
the control method, and the percentage reached by the user at the test’s end. The resources required to fulfill the user’s activities were distributed between two LNs in areas of major user presence: the area surrounding the user’s residence, located at Nova Santa Rita town center [see Fig. 7(a)], and the area surrounding the user’s workplace, located at the Mathias Velho neighborhood in the city of Canoas [see Fig. 7(b)]. Both cities are located in the Rio Grande do Sul state, Southern Brazil. Table VIII shows the existing places in these areas and what type of resources each place offers. The LNs and the LRS services were hosted on a cloud service platform, so that the search and location features could be
1604
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
TABLE VIII MAPPING OF THE RESOURCES OFFERED BY LOCAL PLACES
available during the evaluation period. The OpenShift1 was the cloud platform provider used for that purpose. Upon completion of the test, the user filled out a feedback form. The user assessed the following features: location-based resource search, vital sign input feature, activities visualization, and goals progress visualization. Each feature was assessed in terms of usage frequency, usage frequency justification, usage difficulties, and positive aspects. For the assessment of the usage frequency, the following scale was used: never used, low (1– 4 times used), medium (5–8 times used), or high (more than eight times used). The user reviews are described below. 1) Opinions about location-based resource search feature: a) Usage frequency: Low. b) Usage frequency justification: “I used the locationbased search feature, but as the options that were demonstrated by the application became repetitive, the frequency of use was low.” c) Usage difficulties: “The number of options that the application demonstrated were few.” d) Positive aspects: “The positive aspect of locationbased search is the ease of use for the day-to-day, to keep the diet routine and to control the blood pressure.” 2) Opinions about vital sign input feature: a) Usage frequency: High. b) Usage frequency justification: “I used it daily to maintain control of blood pressure and body weight.” c) Usage difficulties: “To enter the data with good accuracy, I think that a drop-down list would be a 1 https://openshift.redhat.com
better option. In some moments, the system demonstrated the grouping of data to be inserted. For example, sometimes when I was supposed to insert blood pressure data, the fields for food consumed have appeared together.” d) Positive aspects: “Extremely important to control the blood pressure. It helped in my weight management since it requires that I enter my weight data, providing greater care in order to achieve my weight goal.” 3) Opinions about activities visualization: a) Usage frequency: High. b) Usage frequency justification: “Varied care is necessary in the high blood pressure and high cholesterol treatment. With the alerts was possible to manage the tasks better.” c) Usage difficulties: “I have not encountered any difficulties in this feature.” d) Positive aspects: “The alerts were of great importance to manage the ingested food. I could stick to a diet when using the application. Moreover, the alerts were extremely important to control blood pressure and intake of medications, which contributed to a significant improvement in controlling my blood pressure.” 4) Opinions about goal progress visualization: a) Usage frequency: Medium. b) Usage frequency justification: “As the usage process occurred in the Holiday season, my eating routine has changed a lot, I did not get much progress.” c) Usage difficulties: “It would be interesting if the application could show not only the last data entered, but a sample of the general progress.” d) Positive aspects: “The application encourages a positive control in the diet, and also in the control of blood pressure, since each data inserted shows the progress that has been achieved in the treatment.” Through the alpha test, it was possible to observe aspects and situations that had not occurred in the acceptance test. One of these aspects was the low use of the location-based resource search feature. However, this feature has been seen as useful both for users that have participated in the acceptance test, and for user who performed the alpha test. According to the statements given by the user who performed the alpha test, the low usage rate of the location-based resource search feature was due to the fact that there was no update of the resources presented in the search results. Thus, it would require the addition of new features to record locations and resources. The user reported a high use of features for input of vital sign data, and activities visualization. This is a hint that these features are relevant for the management of user’s care activities and shall be present in future works. The goals progress visualization was used sparingly by the user. According to the user’s opinions, it would require an improvement in the presentation mode of the goals progress data. Progress alerts were displayed along with other notices of the application. This grouping may have hindered the user to track
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
the progress of her care. The use of graphs for tracking progress was used in WD [20], [21] and it is an alternative that can be used to improve visualization. Table VII lists the results related to control of user goals. From the three controls performed, weight, diastolic blood pressure, and systolic blood pressure, she has succeeded only in controlling the diastolic blood pressure. She had achieved progress in controlling the systolic blood pressure but did not reach the goal. Moreover, she had a setback in her weight loss against the goal set for this control. It is not possible to draw a conclusion about the effectiveness of the model since the assessment was performed by just one user.
1605
The second experiment was an alpha test performed by a chronic disease patient for one month and a half. This test showed a high usage of functions for vital sign input and activity management, and a medium usage of the goal progress visualization function. Although this test demonstrated a good adherence of the application by the user in her routine, it is not possible to draw final conclusions due to specificities of the test performed by only one patient with hypertension and overweight. We intend to do a similar test with more users in the future. The improvement of user interactions aspects and effectiveness evaluation in NCDs care are other future steps of this paper. VII. ETHICS
VI. CONCLUSION The UDuctor is a model for ubiquitous care of NCDs which focuses on the integration of self-management support, nearby help search support, and patients, members of the community, and health organization communications support. That integration is relevant, being cited in the documentation of CCMs [18], [19], nevertheless, the proposed model is the only one that offers support for nearby resources, services, and people search, which enhances the patient’s care capabilities. Using a distributed architecture, based on the REST architectural style [29], it was possible to provide localized scalability in the access to resources and context information [6]. This is possible because the PNs are connected to LNs that represent the place where those PNs are physically present. The UDuctor architecture has some similarities with the domain model proposed in the architectural reference model for the Internet of things (IoT) [35], whereas Augmented Entities are similar to UDuctor nodes; and Network Resources are similar to the concept of UDuctor resource. On its way, the UDuctor architecture is more “lightweighted” and oriented in locating and sharing content, message exchange between nodes, and in sending and receiving context information updates. In its turn, the IoT reference architecture addresses much more issues like energy optimization, error detection and correction, and services orchestration and composition. The minimum requirements to run UDuctor are Internet access and a software development kit allowing the implementation of the model. Most of today’s phones conform to these requirements. We believe that the support for the implementation of this model by governments might help promote local well-being and help save health budget spent on hospitalizations caused by untreated NCD cases. To assess the model, two experiments were done. The first was a technology acceptance test based on a scenario involving community and health organizations resources. This scenario allowed ten individuals to find care resources and people that could help them in their care activities. The obtained results showed a good acceptance of the proposed model. An overall strong agreement of 95% was obtained in perceived usefulness acceptance assessment. However, users’ comments given in the open question showed that the application needs improvements in user interaction aspects.
This research was approved by the Brazilian National Committee for Research Ethics under number 09064712. 6.0000.5344, according to the 196/96 resolution of the Brazilian National Health Council. ACKNOWLEDGMENT The authors acknowledge the collaboration of the research subjects who offered their time and valuable suggestions. They would also like to thank Igor Vianna, from Supernova SCI, who contributed with his suggestions to improve the text, and Capes/Brazil (Coordination for the Improvement of Higher Education Personnel) and CNPq/Brazil (National Council for Scientific and Technological Development) for their support. REFERENCES [1] OMS, “Global status report on noncommunicable diseases 2010,” World Health Organization, Geneva, Switzerland, Tech. Rep., 2011. [2] E. H. Wagner, B. T. Austin, C. Davis, M. Hindmarsh, J. Schaefer, and A. Bonomi. (2001, Nov.). Improving chronic illness care: Translating evidence into action. Health Aff [Online]. 20(6), pp. 64–78. Available: http://dx.doi.org/10.1377/hlthaff.20.6.64 [3] E. H. Wagner and T. Grove, “Care for chronic diseases—The efficacy of coordinated and patient centred care is established, but now is the time to test its effectiveness,” Brit. Med. J., vol. 325, pp. 913–914, 2002. [4] T. Bodenheimer, E. H. Wagner, and K. Grumbach. (2002, Oct.). Improving primary care for patients with chronic illness. JAMA [Online]. 288(14), pp. 1775–1779. Available: http://dx.doi.org/10.1001/jama.288.14.1775 [5] M. Weiser. (1991, Sep.). The computer for the 21st century. Scientif. Amer., pp. 91–95, [Online]. Available: http://www.ubiq.com/ hypertext/weiser/SciAmDraft3.html [6] M. Satyanarayanan, “Pervasive computing: Vision and challenges,” IEEE Pers. Commun., vol. 8, no. 4, pp. 10–17, Aug. 2001. [7] J. L. V. Barbosa, R. M. Hahn, D. N. F. Barbosa, and A. I. d. C. Z. Saccol. (2011, May). A ubiquitous learning model focused on learner interaction. Int. J. Learn. Technol. [Online]. 6, pp. 62–83. Available: http://dx.doi.org/10.1504/IJLT.2011.040150 [8] L. K. Franco, J. H. Rosa, J. L. Barbosa, C. A. Costa, and A. C. Yamin. (2011). Mucs: A model for ubiquitous commerce support. Electron. Commerce Res. Appl. [Online]. 10(2), pp. 237–246, special Issue on Electronic Auctions: Strategies and Methods. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1567422310000700 [9] J. a. Tavares, J. Barbosa, C. Costa, A. Yamin, and R. Real. (2012). “Hefestos: A model for ubiquitous accessibility support,” in Proc. 5th Int. Conf. Pervas. Technol. Related Assist. Environments [Online], ser. PETRA’12. New York, NY, USA: ACM, pp. 27:1–27:8. Available: http://doi.acm.org/10.1145/2413097.2413131 [10] J.-E. Lim, O.-H. Choi, H.-S. Na, and D.-K. Baik. (2009, May). A contextaware fitness guide system for exercise optimization in U-health. IEEE Trans. Inf. Technol. Biomed. [Online]. 13(3), pp. 370–379. Available: http://www.ncbi.nlm.nih.gov/pubmed/19193515
1606
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
[11] A. K. Dey and D. Estrin, “Perspectives on pervasive health from some of the field’s leading researchers,” IEEE Pervas. Comput., vol. 10, no. 2, pp. 4–7, Feb. 2011. [12] J. E. Bardram and H. B. Christensen, “Pervasive computing support for hospitals: An overview of the activity-based computing project,” IEEE Pervas. Comput., vol. 6, no. 1, pp. 44–51, Jan.–Mar. 2007. [13] C. Holtmann, M. M¨uller-Gorchs, A. Rashid, Klausweidenhaupt, V. Ziegler, B. Griewing, and C. Weinhardt, “Medical opportunities by mobile IT usage A case study in the stroke chain of survival,” in Proc. Eur. Conf. eHealth, Bonn, Germany, 2007, pp. 115–130. [14] C. Orwat, A. Rashid, C. Holtmann, M. Wolk, M. Scheermesser, H. Kosow, and A. Graefe, “Adopting pervasive computing for routine use in healthcare,” IEEE Pervas. Comput., vol. 9, no. 2, pp. 64–71, Apr./Jun. 2010. [15] A. Rashid, F. Schl¨ufter, C. Holtmann, C. Kunze, K. Thaler, M. Dl¨aumer, S. Schlesinger, and B. Griewing, “Usage of accelerometers in home care for multiple sclerosis patients,” in Proc. Eur. Conf. eHealth, Bonn, Germany, 2007, pp. 177–192. [16] N. Agoulmine, M. Deen, J.-S. Lee, and M. Meyyappan. (2011, Sep.). U-Health smart home. IEEE Nanotechnol. Mag. [Online]. 5(3), pp. 6–11. Available: http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm?arnumber=5993590 [17] F. Buttussi and L. Chittaro, “Smarter phones for healthier lifestyles: An adaptive fitness game,” IEEE Pervas. Comput., vol. 9, no. 4, pp. 51–57, Oct./Dec. 2010. [18] WHO, “Innovative care for chronic conditions: Building blocks for action: global report,” World Health Organization, Geneva, Switzerland, Tech. Rep., 2003. [19] E. H. Wagner, “Chronic disease management: what will it take to improve care for chronic illness?” Effect. Clin. Pract., vol. 1, pp. 2–4, 1998. [20] E. Mattila, J. P¨arkk¨a, M. Hermersdorf, J. Kaasinen, J. Vainio, K. Samposalo, J. Merilahti, J. Kolari, M. Kulju, R. Lappalainen, and I. Korhonen. (2008, Jul.). Mobile diary for wellness management–results on usage and usability in two user studies. IEEE Trans. Inf. Technol. Biomed. [Online]. 12(4), pp. 501–512. Available: http://www.ncbi. nlm.nih.gov/pubmed/18632330 [21] E. Mattila, I. Korhonen, J. H. Salminen, A. Ahtinen, E. Koskinen, A. S¨arel¨a, J. P¨arkk¨a, and R. Lappalainen, “Empowering citizens for wellbeing and chronic disease management with wellness diary,” IEEE Trans. Inf. Technol. Biomed., vol. 14, no. 2, pp. 456–463, Mar. 2010. [22] V. G. Koutkias, I. Chouvarda, A. Triantafyllidis, A. Malousi, G. D. Giaglis, and N. Maglaveras. (2010, Mar.). “A personalized framework for medication treatment management in chronic care.” IEEE Trans. Inf. Technol. Biomed. [Online]. 14(2), pp. 464–472. Available: http://www.ncbi.nlm.nih.gov/pubmed/20007042 [23] F. Paganelli and D. Giuli. (2011, Mar.). “An ontology-based system for context-aware and configurable services to support home-based continuous care.” IEEE Trans. Inf. Technol. Biomed. [Online]. 15(2), pp. 324–333. Available: http://www.ncbi.nlm.nih.gov/pubmed/21075729 [24] F. Paganelli, E. Spinicci, and D. Giuli. (2008, Jan.). Ermhan: A contextaware service platform to support continuous care networks for homebased assistance. Int. J. Telemed. Appl. [Online]. 2008, pp. 4:1–4:13. Available: http://dx.doi.org/10.1155/2008/867639 [25] C. Costa, F. Kellermann, R. Antunes, L. Cavalheiro, A. Yamin, and C. Geyer, “Continuum: A service-based software infrastructure for ubiquitous computing,” in Proc. IEEE Int. Conf. Pervas. Comput. Commun., 2009, pp. 1–4. [26] A. Dey, G. Abowd, and D. Salber, “A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications,” Human-Comput. Interact., vol. 16, no. 2, pp. 97–166, Dec. 2001. [27] J. M. Silva, J. A. H. Rosa, J. L. V. Barbosa, D. N. F. Barbosa, and L. A. M. Palazzo. (2010, Jul.). Content distribution in trail-aware environments. J. Brazilian Comput. Soc. [Online]. 16(3), pp. 163–176. Available: http://www.springerlink.com/index/10.1007/s13173-010-0015-1
[28] C. Doukas and I. Maglogiannis, “Emergency fall incidents detection in assisted living environments utilizing motion, sound, and visual perceptual components,” IEEE Trans. Inf. Technol. Biomed., vol. 15, no. 2, pp. 277– 289, Mar. 2011. [29] R. T. Fielding and R. N. Taylor. (2000). Principled design of the modern web architecture, in Proceedings of the 22nd International Conference on Software Engineering, ser. ICSE ’00. New York, NY, USA: ACM, pp. 407–416. [Online]. Available: http://doi.acm.org/10.1145/337180.337228 [30] L. Padgham and M. Winikoff, Developing Intelligent Agent Systems: A Practical Guide. New York, NY, USA: Wiley, Jun. 2004. [31] A. Developers. (2012) What is android? [Online]. Available: http://developer.android.com/guide/>basics/what-is-android.html [32] F. D. Davis. (1989, Sep.). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Q. [Online]. 13(3), pp. 319–340. Available: http://dx.doi.org/10.2307/249008 [33] C. Yoon and S. Kim. (2007). Convenience and tam in a ubiquitous computing environment: The case of wireless LAN. Electron. Commerce Res. Appl. [Online]. 6(1), pp. 102–112. Available: http://www.sciencedirect.com/science/article/pii/S156742230600055X [34] R. Likert, “A technique for the measurement of attitudes,” Arch. Psychol., vol. 22, no. 140, pp. 1–55, 1932. [35] Deliverable D1.4 Converged architectural reference model for the IoT v2.0, European Commission, 2012. [Online]. Available: http://www.iota.eu/public/public-documents/documents-1/1/1/D1.4/at_do wnload/file
Henrique Damasceno Vianna received the M.Sc. degree in the Applied Computing Graduate Program of the University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo, Brazil, in 2013. He researches the application of ubiquitous computing applied to the care of chronic diseases at the Mobile Computing Laboratory (MobiLab/UNISINOS). He is also a Computer Technician at the Data Processing Company of the State of Rio Grande do Sul, where he works on developing solutions to aid public management. His research interests include public health informatics, mobile and ubiquitous computing, and software architecture for network-based applications.
Jorge Luis Vict´oria Barbosa received the M.Sc. and Ph.D. degrees in computer science from the Federal University of Rio Grande do Sul, Porto Alegre, Brazil, in 1996 and 2002, respectively. He is currently a Full Professor of the Applied Computing Graduate Program at the University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo, Brazil. Additionally, he is a Researcher of productivity at CNPq/Brazil and the head of the Mobile Computing Laboratory (MobiLab/UNISINOS). His research interests include mobile and ubiquitous computing, ubiquitous health and ubiquitous accessibility. Dr. Barbosa is a member of the Brazilian Computer Society.
1597
A Model for Ubiquitous Care of Noncommunicable Diseases Henrique Damasceno Vianna and Jorge Luis Vict´oria Barbosa
Abstract—The ubiquitous computing, or ubicomp, is a promising technology to help chronic diseases patients managing activities, offering support to them anytime, anywhere. Hence, ubicomp can aid community and health organizations to continuously communicate with patients and to offer useful resources for their self-management activities. Communication is prioritized in works of ubiquitous health for noncommunicable diseases care, but the management of resources is not commonly employed. We propose the UDuctor, a model for ubiquitous care of noncommunicable diseases. UDuctor focuses the resources offering, without losing self-management and communication supports. We implemented a system and applied it in two practical experiments. First, ten chronic patients tried the system and filled out a questionnaire based on the technology acceptance model. After this initial evaluation, an alpha test was done. The system was used daily for one month and a half by a chronic patient. The results were encouraging and show potential for implementing UDuctor in real-life situations. Index Terms—Collaborative work, noncommunicable diseases, public healthcare, ubiquitous computing, ubiquitous health.
providing continuous management, and have Internet access, enabling the connection with people and information systems that have the capacity to help in NCDs care activities. Considering the related works, it is possible to imply that still little attention is given to support the search of nearby resources and people that are able to help chronic patients in their activities. This paper proposes the UDuctor, a model for ubiquitous care of NCDs. The main focus of this proposal is to fill this gap. Additionally, UDuctor supports the features for self-management and communication with health organizations that are present in the related works. The paper is organized in six sections. Section II presents an introduction to ubiquitous health and chronic care models (CCMs). Section III addresses works which have applied uHealth in some activity of NCDs care. Section IV describes the UDuctor model. Implementation aspects are covered in Section V. This section also describes two practical experiments involving chronic patients and the results obtained with them. Section VI presents final remarks and directions for future works.
I. INTRODUCTION CCORDING to the latest global status report on noncommunicable diseases (NCDs) by the World Health Organization (WHO), the burden of these diseases continues to grow, especially in low and middle income countries [1]. These diseases can be caused by habits such as a sedentary lifestyle and smoking that result in “metabolic or physiologic changes” like, for example, high blood pressure, overweight, and obesity. The NCDs treatment must be done continuously, since there is no cure for most of those diseases. Therefore, patients need to be aware of their condition, follow the treatment planned by the medical responsible, and know how to act when needed. In some occasions, the patient may not have the required confidence to perform certain activities, requiring the collaboration of someone with experience [2]–[4]. In this way, it is possible to observe that smartphones merge two useful features for aiding the control of NCDs. They are always close to their owners,
A
Manuscript received May 16, 2013; revised September 11, 2013 and November 9, 2013; accepted November 17, 2013. Date of publication November 27, 2013; date of current version September 2, 2014. This work was supported by the Capes/Brazil (Coordination for the Improvement of Higher Education Personnel) and CNPq/Brazil (National Council for Scientific and Technological Development). The authors are with the Applied Computing Graduate Program (PIPCA), University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo-RS, 93022000, Brazil (e-mail: [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/JBHI.2013.2292860
II. BACKGROUND This section introduces the u-Health and CCMs subjects. These subjects contain the principles that guided the construction of the UDuctor model.
A. Ubiquitous Health The term ubiquitous computing, or ubicomp, was first used by Mark Weiser and his colleagues of Xerox, and may be understood as the use of several distributed computers seamlessly integrated to enhance physical environments [5], [6]. The ubicomp is applied in many areas, such as education [7], commerce [8], accessibility [9], and health. The use of ubicomp in health is also called u-Health or pervasive health [10], [11]. Most of u-Health applications are centered in hospital routine management [12]–[14], patients monitoring [14]–[16], or well-being [10], [17]. u-Health hospital applications focus on the enhancement of hospital staff routines such as medicine administration and prescription, medical team collaboration, and management of conferences, surgeries and emergencies rooms. Patients monitoring applications are commonly used for aiding the care of elder and chronic patients remotely. The well-being class encompasses those applications oriented to personal health management, such as diet management, personal training assistants, and games oriented to the practice of physical activities.
2168-2194 © 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications standards/publications/rights/index.html for more information.
1598
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
The NCDs care can be benefited by u-Health technologies. However, it is desirable that this support be based on existing CCMs. These models will be explained in the next section.
TABLE I RELATED WORKS COMPARISON
B. Chronic Care Models The rapid growth of chronic conditions cases resulted in the creation of models to support their management [2], [18]. The Chronic Care Model (CCM) [2], [19] and the Innovative Care for Chronic Conditions (ICCC) [18] are two models that may be used for chronic care management. The CCM describes practices to improve the interactions between patients and health providers. Thus, for patients to acquire the skills and confidence required to manage their conditions, they need to cooperate with their caregivers, providing information and assessments as a way to help the optimization of their care. In turn, ICCC is a WHO initiative to create a model that can be applied in the care of many chronic conditions. The ICCC breaks its components into three levels (micro, meso, and macro) on the assumption that to succeed, the model must comprise every level from patient to government. There is a strong integration between communities and health organizations in both models, so that patients can succeed in taking care of their own chronic condition. The next section will highlight some u-Health works that cover NCDs care in some way. III. U-HEALTH IN NCDS CARE We decided to focus our study of related works in proposals that contemplate the care of NCDs in the following aspects: self-management support; support for communication among patients, members of the community, and health organization; and support for the search of nearby help. These topics were chosen due to the importance given to them in the CCM and ICCC models. The wellness diary (WD) is a personal mobile application for wellness management based on cognitive-behavioral therapy concepts [20], [21]. Patients use self-monitoring to identify and learn which actions and behaviors influence their health condition. The WD has three components: users self-observations input, self-observations view graphs, and user activities calendar. In self-observations input, the users can add data about the consumption of food and drinks, weight, blood pressure, sleep quality, and stress. The self-observations view is composed by charts that let the users understand the results of their decisions. The activities calendar is used to schedule activities to the user and is integrated to the mobile device calendar. Koutkias et al. [22] propose a framework to use data collected by monitoring sensors to identify adverse effects of drugs in patients. The framework uses an ontology that describes concepts related to effects of drug use, e.g., goals related to drug use, or adverse effects which may be caused by this use. The system architecture has two components: the clinical subsystem and the mobile base unit (MBU). Information about substances, contraindications, adverse drug effects, and alert management resides in the clinical subsystem. The subsystem supports vitalsign monitoring rules which are used to control the medication
usage effects in patients. These rules are sent to the MBU which is responsible for vital sign data acquisition and monitoring. When a vital sign reading is outside the patterns defined by the rules, the MBU sends an alert message to the subsystem which forwards the information to the patient’s responsible. Paganelli and Giuli [23] present a context-aware system to support NCDs care and management. This system runs on top of a service platform to support continuous care of chronic conditions called ERMHAN [24]. The ERMHAN platform aids in the care for network actors, i.e., patients, relatives, and health organization members, which share responsibilities in care taking activities. The platform provides an environment for home monitoring and alert generation for the care network according to the rules entered into the system. A. Analysis of the Studied Works We compare the related works in the way they provide support for self-management; communication among patients, members of the community, and health organization; and search of nearby help. Table I shows the results of this comparison. The self-management support is determined by the goals and activities provided by a care team and should be performed by the patient. Support for these activities can be done by aiding the intake of healthy foods, physical activities, or reminders for tasks that should be done continuously. The communication among patients, members of the community, and health organization indicates if the work enables the connection with members of the community, or members from health organizations, as way to obtain support for some kind of NCDs care activity, or to alert that the patient needs help. For example, Koutkias et al. framework [22] sends an alert for the patient’s caregiver if the prescribed drug is causing an undesirable effect. The search of nearby help support represents the way used to help patients in the search of nearby services, resources, or people which may be useful for their care or wellness. This support can be a pharmacy which has a medicine with an affordable price, a public park with exercise equipment, or community
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
1599
classes for some kind of physical activity. None of the related works include this support type. This support is cited by CCMs like CCM [2], [19] and ICCC [18], and could help patients improve their self-management capability. Next section presents UDuctor, which contributes to the support in searching for nearby help, in addition to self-management and communication among patients, members of the community, and health organization that are already supported in the related works. IV. UDUCTOR MODEL This section presents the UDuctor model. First, we show how the model elements are organized and how they interact (conceptual model). Second, the middleware that implements the conceptual model is described. Finally, the section approaches a personal health assistant that uses the UDuctor middleware as an infrastructure to support care in NCDs activities. A. UDuctor Conceptual Model The UDuctor’s conceptual model is inspired by the abstraction model of the Continuum Project [25], and is composed by five elements: Position to Local Node Resolution Service (LRS), Local Node (LN), Personal Node (PN), Context, and Resource. In the UDuctor model, nodes are the entities responsible for sharing resources and context information. Resource is any content shared by a node that has capability to help UDuctor users in their activities. In some cases, the resources may represent a description of physical resources, like a scale in a pharmacy, or can be an electronic resource like a picture of a food guide pyramid stored in one node. Context is any attribute that can identify the situation of one entity [26], for example, the temperature of a location, or the blood pressure of a person. There are two types of nodes: LN and PN. An LN represents a place in a geographic region, i.e., a house, a store, or another type of identifiable location. The LN keeps references to people and others places, and shares resources and context information available in that place. For example, in a pharmacy, the drugs may have references that will represent them as resources, the pharmacist may be referenced as a person, and the local thermometer may have a reference that allows software to subscribe to it and receive temperature change notifications. The PN represents a person who has a mobile device (like a tablet or a smartphone) moving between places represented by LNs. A location change occurs when the PN receives an LN reference different from its current reference. This event makes the PN unbind its reference from the old LN and create a reference with the new LN, what makes the PN logically associated with the location represented by the LN. The PN can use the LN to search for entities that might help the users in their care activities. These entities can be another person who has knowledge in a certain care activity, a resource needed to accomplish certain activities, or a contextual information. Furthermore, PNs can share resources and contextual information in the same way the LNs can do. This allows caregivers to use a PN for real-time patient monitoring.
Fig. 1.
UDuctor example. TABLE II LEGEND OF THE UDUCTOR ELEMENTS OF FIG. 1
Item Number 1 2 3 4 5 6 7 8
Fig. 2.
Description
UDuctor element type
Neighborhood Drinking fountain Temperature Pharmacy Local resident Heart rate Pharmacist Medicine
Local Node Resource Context Local Node Personal Node Context Personal Node Resource
Hierarchical link of the UDuctor elements of Fig. 1.
Fig. 1 shows a real-world situation represented by UDuctor elements. The figure shows a hypothetical neighborhood, where the following items reside: a drinking fountain, a thermometer, a local resident, and his heart rate monitor; a pharmacy, a pharmacist, and a drug sold at the pharmacy. Table II relates the items from Fig. 1 to their element type. Fig. 2 presents an UML object diagram demonstrating how the UDuctor elements are hierarchically linked. The neighborhood is represented by an LN and linked to it is the drinking fountain, which is a local resource; the temperature context, which provides temperature measurement updates from the local thermometer; the pharmacy, which is represented by an LN; the local resident, which represents a PN that moves around the neighborhood, and provides context updates about his heart rate; and the medicine, which is a resource of the pharmacy. As the pharmacy is an LN, it can have PNs linked to it. In this case, the pharmacist is a PN linked to the pharmacy. The LRS is a service responsible for converting the geoposition data of a PN in an LN reference, thus helping the PNs to switch between LNs.
1600
Fig. 3.
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
UDuctor middleware architecture.
The next section will describe the UDuctor middleware architecture. This architecture is implemented in the nodes, providing a ubiquitous software infrastructure to them.
Fig. 4.
6)
B. UDuctor Middleware Architecture The UDuctor middleware is responsible for offering features for resource sharing, context notification, messaging, and access control. Each node of the model runs its own instance of it. The middleware has the following nine components (see Fig. 3): 1) Executable Modules: They are software applications created by developers and registered in the middleware. These modules have access to available features of the middleware as shared resources, context information, access control, messaging, bound nodes, and LN reference. This component allows the use of middleware features by applications with distinct goals. 2) Proxy: It checks if a node or executable module has authorization to access a requested middleware feature. The access authorization is managed by the Access Control Module. 3) Shared Resources: This module manages the resources shared by a node, enabling nodes to create, modify, query, and search for resources. This module is also responsible for notifying the executable modules when a resource is created, deleted, or updated. 4) Context: It allows other UDuctor nodes or executable modules to register themselves for receiving notifications about changes in attributes that identify the situation [26] of a node that runs the middleware instance. If the node represents a person, the attributes could be the body temperature, blood pressure, glucose, or any other relevant attribute that the person shares. If the node represents a place, the attributes may be the air quality index, relative humidity, ultraviolet radiation index, or any other relevant information shared by that place. Like so, a node maintains a context history or trail [27], allowing the applications that run on the middleware to anticipate situations that users may face, by inferring their context histories [28]. 5) Access Control: This module manages the access authorization of others UDuctor nodes, or executable modules, to a certain middleware feature. For example, the information indicating that a certain PN is allowed to receive temperature updates of an LN, or the information indicat-
7)
8)
9)
ChronicDuctor system overview.
ing that the nutritionist PN has access to pictures of meals stored in the PN of a patient. Messaging: This component is used to exchange messages between the nodes. UDuctor does not define a specific format for the messages, allowing the creation of protocols for the needs of each application. Bound Nodes List: It provides a list of references of nodes bound to the running instance of the middleware, and allows nodes to ask to be bound to (or unbound from) the running instance. Local Reference: It represents a reference to the LN to which a PN or LN is bound. The UDuctor nodes use the local references to access resources and context information shared by other nodes, and so enabling them to find opportunities of interest. RESTFul Interface: This interface provides a way for the nodes to remotely access the middleware features of context, shared resources, access control, messaging, local reference, and bound nodes lists. The interface is implemented using the REST architectural style [29].
C. ChronicDuctor App The ChronicDuctor is a personal health assistant that runs as an executable module using the UDuctor middleware to provide support for self-management, communication among patients, members of the community, and health organization, and search of nearby help to its users. These supports are made through the following functionalities: care plan creation support, recommendation of care resources, alert generation, input of vital sign data, and communication between people. As the ChronicDuctor has features from agent systems, i.e., it is autonomous and has goals, it does several things simultaneously, and has the need of change the way it act in accordance with the changing environment; it might be designed as such. Fig. 4 presents a system overview diagram that uses the Prometheus methodology showing a high-level view of the ChronicDuctor [30]. Four agents compose the system: plan manager, monitoring manager, activity manager, and message manager. These managers share responsibilities in order to reach the proposed goals. The plan manager schedules the activities based on the care plan when the system is started, or when a new plan is received. The plan manager is also responsible for notifying the activity
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
manager of activities that must be done, and for notifying the monitoring agent about updates made to the care plan. The monitoring manager receives the context data from the UDuctor middleware for monitoring the progress of user care. Once the care plan was informed, this manager takes care of monitoring the control data that the user might report through the system, for example, blood pressure, weight, or glucose. If the user fails to report the data for a certain period, this manager will ask the message manager to send a message to the responsible for the activity about the incident. Furthermore, the monitoring manager identifies if the user has reached any of the goals (or how long it will take to reach them) when it receives a new control data. The vital sign data are stored in the Context Repository which is managed by the UDuctor context component, so the monitoring manager can track the progress of user care. The activity manager notifies the user about the existence of a new activity that must be done, and searches for resources which might be offered to the user. For each activity, this agent will make a search for devices used for vital sign reading. This search is done so that the agent can build a form where the user can input vital sign data. For example, in the case of the activity be “weigh in,” this agent will use the UDuctor shared resources component, represented in Fig. 4 by the Resource Repository, to look up for resources describing weighing scales. Furthermore, the agent will use the location informed by the monitoring agent to look up for nearby help that can aid the user accomplishing the activity. Initially, the agent will search for help in the place where the user is, if no results are found, the agent will look up for help in the children places of the current place. If yet no results are found, the agent will look up for help in sibling places, and after that it will end the search. Finally, the message manager allows the user to exchange messages with other users nearby. V. IMPLEMENTATION AND EVALUATION A. Implementation Aspects The UDuctor middleware was implemented with Android for PNs and J2SE platform for LNs. This distinction was due to Android’s specific implementation of Java runtime environment [31], what causes some libraries to have different versions for each platform. For the development of the J2SE RESTFul Interface the Jersey package was used, which is an implementation of the JAXRS specification for Java RESTful Web Services. For the Android version, the RESTFul Interface was implemented with Restlet API, which allows the creation of an HTTP server on that platform. To allow semantic search of resources, the resources managed by the Shared Resources module were described with Turtle language (Terse RDF Triple Language), and stored in a RDF repository. The SPARQL language was used for querying this repository. The Jena-ARQ (for the J2SE platform) and AndrojenaARQoid (for the Android platform) were used to store and query data in the RDF repository. Due to a high ARQoid compilation time, the Shared Resources module was placed as a separated
1601
TABLE III CHRONIC CONDITION OF SUBJECTS Subject Number #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
Fig. 5.
High Cholesterol
X
Hypertension
Obesity
X
X X
X
Overweight
X X
X X
X X X
X X
X
Scenario floor plan.
process, communicating with the middleware instance through an AIDL interface. This was done in the Android version only. The Context and Messaging modules were developed using the same programming for PNs and LNs. The Bound Nodes List returns a JSON list of the nodes bound to the middleware instance, while the LN Reference returns a JSON representation of the node where the instance is. The ChronicDuctor was developed for the Android platform and implemented as a service. The communication with the middleware is performed through the AIDL interface of the Android platform. B. Evaluation Aspects Two experiments were conducted for the UDuctor evaluation. The first was a technology acceptance test [32], [33] performed by chronic patients. The second was an UDuctor alpha test, performed by a chronic disease patient for one month and a half. 1) Technology Acceptance: This experiment aimed at evaluating user acceptance of the model [32], [33]. The assessment involved ten volunteers who used the UDuctor and filled out a questionnaire. Table III shows their chronic condition. The experiment was performed in a scenario built at a site localized in the city of Nova Santa Rita, Rio Grande do Sul state, Brazil. The scenario simulates a hypothetical neighborhood using two buildings. The circles in Fig. 5 represent locations in the neighborhood. Each location had its own LN where care resources were distributed accordingly with their roles, for example, medicines are at the pharmacy and the restaurant offers meals. Table IV describes the types of resources that could be found in each place. The experiment was performed with each subject individually. A simple care plan was created using the ChronicDuctor
1602
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
TABLE IV RESOURCES LOCATED AT THE SIMULATION SCENARIO
TABLE V QUESTIONNAIRE STATEMENTS Assessment type Perceived usefulness statements
Perceived ease of use statements
Statement 1. It is possible to describe the care activities with a sufficient level of detail 2. The activities notifications are useful for the care routine 3. The alerts of reached goals are useful for the care routine 4. The progress alerts are useful for the care routine 5. The ability to locate nearby resources according to activity is useful for the care routine 6. The application offers the resources needed to care activities 7. The application helps in your care activities 8. The ability to find people nearby in accordance to the knowledge they have in relation to the activity is useful for the care routine 9. The ability to chat with nearby people is useful for the care routine 10. The ability to input vital sign data (for example, weight, blood pressure, glucose), is useful for the care routine 11. The care plan building form is easy to understand 12. The activity notification alerts are easy to understand 13. The alerts of reached goals are easy to understand 14. The progress alerts are easy to understand 15. It is easy to find people and resources with the application 16. It is easy to chat with people using the application 17. It is easy to input vital sign data (for example, weight, blood pressure, glucose) with the application
Fig. 6. ChronicDuctor activity example. (a) Patient’s activities list. (b) Vital sign input. (c) Caregiver’s notifications list. (d) Caregiver’s chat session. (e) Patient’s conversation list. (f) Patient’s chat session.
to demonstrate the application in NCDs care. At the care plan construction, it was possible to define activities which the subject should accomplish in a determined time, resources that each activity requires, and goals which the subject should reach. For example, in a case of hypertension care, one of the activities shall be “blood pressure reading.” This activity shall be set to search for blood pressure monitors, and the goals can be set to reach a systolic blood pressure measurement of 119 mmHg and a diastolic pressure of 79 mmHg. After the creation of the care plan, the subjects walked through the scenario, using the application in a smartphone, a Samsung GT-S5570B with Android 2.2. The research coordinator used the application in a different smartphone, a Motorola Spice XT300 with Android 2.1, simulating the role of a caregiver. Every time a new activity was detected it was put on top of the patient’s activities list [see Fig. 6(a)]. A new screen is showed after the patient selects the activity [see Fig. 6(b)]. In this screen, the patient is able to search for nearby resources or people, and to input the vital sign data. The caregiver receives a notification about the patient’s goal status as soon as the patient sends the vital sign data
[see Fig. 6(c)]. The chat button in this screen allows the caregiver to start a chat session with the patient [see Fig. 6(d)]. The messages received by the patient are grouped by person in the patient’s conversation list [see Fig. 6(e)]. When the patient selects the caregiver in the conversation list the chat session is restored, allowing the continuation of the conversation [see Fig. 6(f)]. After using the application, the subjects were asked to answer an assessment questionnaire. The questionnaire was prepared following the technology acceptance model (TAM) proposed by Davis [32] and applied and expanded by Yoon and Kim [33] in their study on the acceptance of wireless networks. In the TAM model, user satisfaction is measured through perceived usefulness and perceived ease of use. The first perception determines if the proposed technology can help the user to make a better work, while the second evaluates if the technology can be used with minimum of effort. The questionnaire was composed of 17 statements of five levels Likert items (“Strongly Disagree,” “Partially Disagree,” “Indifferent,” “Partially agree,” “Strongly agree”) [34]. Additionally, there was an open question for general comments and suggestions. The questionnaire statements are listed in Table V. They were divided in perceived usefulness statements and perceived ease of use statements. The statements were oriented to evaluate the satisfaction of the users in relation to self-management support (statements 1, 2, 3, 4, 7, 10, 11, 12, 13, 14, and 17), support to the search of nearby help (statements 5, 6, 8, and 15), and the support to the communication among patients, members of the community, and health organization (statements 9 and 16).
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
TABLE VI USER CARE PLAN
1603
TABLE VII USER’S GOALS
Activity
Frequency
Type
Used Resources
Context Type
Control Method
Breakfast Morning snack Dinner
Daily Daily Daily
Meal Meal Meal
Weight Diastolic blood pressure Systolic blood pressure
Achieve the goal set Achieve the goal set Achieve the goal set
Afternoon snack Supper
Daily
Meal
Carbohydrates; fruits Fruits Vegetables; white meats; carbohydrates Fruits
Daily
Meal
Weight control
Daily
Blood pressure reading Walking
Daily
Vital sign data entry Vital sign data entry Physical activity
Daily
% Completed at Test End -26,7% 100% 73,34%
Vegetables; white meats; carbohydrates Weighing scale Blood pressure monitor -
The responses to the statements oriented to self-management support showed a strong agreement of 96% in both statement types, perceived usefulness, and perceived ease of use. The support to the search of nearby help had a strong agreement of 93.3% in the perceived usefulness statements, and a strong agreement of 80% in the perceived ease of use statements. The support to the communication among patients, members of the community, and health organization had a strong agreement of 100% in the perceived usefulness statements, and a strong agreement of 80% in the perceived ease of use statements. The results showed a good general evaluation considering the high satisfaction of the users. However, the perceived ease of use assessment showed that the application needs improvements in some user interactions aspects, mainly in the localization of help resources and chat features. These results reflect suggestions given by some individuals in the open question. One of the suggestions asks for the “(...)possibility to organize important chats in folders(...),” other suggestion asks for “(...)a way to create more types of resources for search in the care plan builder and a way to create resources in locations (...).” 2) Real Application—Alpha Test: An UDuctor test was performed by a patient with hypertension and overweight. This test was carried out for one month and a half and covered the period from December 15, 2012 to January 31, 2013, aiming to identify issues related to the use of resource search functionality, vital sign data entry, activity information visualization, and goals progress visualization. The UDuctor was used to assist the user in her care activities through alerts of activities that should be performed, input of data control, and search for care resources that might be available close to where the user was located. The UDuctor was installed in the user’s smartphone, a Samsung GT-I81160L with Android OS version 2.3. The guidelines set by the user’s cardiologist and endocrinologist were transformed into an UDuctor care plan, which contained a list of activities and a list of controls for the user. Table VI lists the activities set in the plan, the frequency of these activities, the type of activity, and the types of resources that should be located to assist the user in carrying out each activity. Table VII lists the types of contexts that were controlled,
Fig. 7. Resource locations. (a) Area surrounding the user’s residence. (b) Area surrounding the user’s workplace.
the control method, and the percentage reached by the user at the test’s end. The resources required to fulfill the user’s activities were distributed between two LNs in areas of major user presence: the area surrounding the user’s residence, located at Nova Santa Rita town center [see Fig. 7(a)], and the area surrounding the user’s workplace, located at the Mathias Velho neighborhood in the city of Canoas [see Fig. 7(b)]. Both cities are located in the Rio Grande do Sul state, Southern Brazil. Table VIII shows the existing places in these areas and what type of resources each place offers. The LNs and the LRS services were hosted on a cloud service platform, so that the search and location features could be
1604
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
TABLE VIII MAPPING OF THE RESOURCES OFFERED BY LOCAL PLACES
available during the evaluation period. The OpenShift1 was the cloud platform provider used for that purpose. Upon completion of the test, the user filled out a feedback form. The user assessed the following features: location-based resource search, vital sign input feature, activities visualization, and goals progress visualization. Each feature was assessed in terms of usage frequency, usage frequency justification, usage difficulties, and positive aspects. For the assessment of the usage frequency, the following scale was used: never used, low (1– 4 times used), medium (5–8 times used), or high (more than eight times used). The user reviews are described below. 1) Opinions about location-based resource search feature: a) Usage frequency: Low. b) Usage frequency justification: “I used the locationbased search feature, but as the options that were demonstrated by the application became repetitive, the frequency of use was low.” c) Usage difficulties: “The number of options that the application demonstrated were few.” d) Positive aspects: “The positive aspect of locationbased search is the ease of use for the day-to-day, to keep the diet routine and to control the blood pressure.” 2) Opinions about vital sign input feature: a) Usage frequency: High. b) Usage frequency justification: “I used it daily to maintain control of blood pressure and body weight.” c) Usage difficulties: “To enter the data with good accuracy, I think that a drop-down list would be a 1 https://openshift.redhat.com
better option. In some moments, the system demonstrated the grouping of data to be inserted. For example, sometimes when I was supposed to insert blood pressure data, the fields for food consumed have appeared together.” d) Positive aspects: “Extremely important to control the blood pressure. It helped in my weight management since it requires that I enter my weight data, providing greater care in order to achieve my weight goal.” 3) Opinions about activities visualization: a) Usage frequency: High. b) Usage frequency justification: “Varied care is necessary in the high blood pressure and high cholesterol treatment. With the alerts was possible to manage the tasks better.” c) Usage difficulties: “I have not encountered any difficulties in this feature.” d) Positive aspects: “The alerts were of great importance to manage the ingested food. I could stick to a diet when using the application. Moreover, the alerts were extremely important to control blood pressure and intake of medications, which contributed to a significant improvement in controlling my blood pressure.” 4) Opinions about goal progress visualization: a) Usage frequency: Medium. b) Usage frequency justification: “As the usage process occurred in the Holiday season, my eating routine has changed a lot, I did not get much progress.” c) Usage difficulties: “It would be interesting if the application could show not only the last data entered, but a sample of the general progress.” d) Positive aspects: “The application encourages a positive control in the diet, and also in the control of blood pressure, since each data inserted shows the progress that has been achieved in the treatment.” Through the alpha test, it was possible to observe aspects and situations that had not occurred in the acceptance test. One of these aspects was the low use of the location-based resource search feature. However, this feature has been seen as useful both for users that have participated in the acceptance test, and for user who performed the alpha test. According to the statements given by the user who performed the alpha test, the low usage rate of the location-based resource search feature was due to the fact that there was no update of the resources presented in the search results. Thus, it would require the addition of new features to record locations and resources. The user reported a high use of features for input of vital sign data, and activities visualization. This is a hint that these features are relevant for the management of user’s care activities and shall be present in future works. The goals progress visualization was used sparingly by the user. According to the user’s opinions, it would require an improvement in the presentation mode of the goals progress data. Progress alerts were displayed along with other notices of the application. This grouping may have hindered the user to track
VIANNA AND BARBOSA: MODEL FOR UBIQUITOUS CARE OF NONCOMMUNICABLE DISEASES
the progress of her care. The use of graphs for tracking progress was used in WD [20], [21] and it is an alternative that can be used to improve visualization. Table VII lists the results related to control of user goals. From the three controls performed, weight, diastolic blood pressure, and systolic blood pressure, she has succeeded only in controlling the diastolic blood pressure. She had achieved progress in controlling the systolic blood pressure but did not reach the goal. Moreover, she had a setback in her weight loss against the goal set for this control. It is not possible to draw a conclusion about the effectiveness of the model since the assessment was performed by just one user.
1605
The second experiment was an alpha test performed by a chronic disease patient for one month and a half. This test showed a high usage of functions for vital sign input and activity management, and a medium usage of the goal progress visualization function. Although this test demonstrated a good adherence of the application by the user in her routine, it is not possible to draw final conclusions due to specificities of the test performed by only one patient with hypertension and overweight. We intend to do a similar test with more users in the future. The improvement of user interactions aspects and effectiveness evaluation in NCDs care are other future steps of this paper. VII. ETHICS
VI. CONCLUSION The UDuctor is a model for ubiquitous care of NCDs which focuses on the integration of self-management support, nearby help search support, and patients, members of the community, and health organization communications support. That integration is relevant, being cited in the documentation of CCMs [18], [19], nevertheless, the proposed model is the only one that offers support for nearby resources, services, and people search, which enhances the patient’s care capabilities. Using a distributed architecture, based on the REST architectural style [29], it was possible to provide localized scalability in the access to resources and context information [6]. This is possible because the PNs are connected to LNs that represent the place where those PNs are physically present. The UDuctor architecture has some similarities with the domain model proposed in the architectural reference model for the Internet of things (IoT) [35], whereas Augmented Entities are similar to UDuctor nodes; and Network Resources are similar to the concept of UDuctor resource. On its way, the UDuctor architecture is more “lightweighted” and oriented in locating and sharing content, message exchange between nodes, and in sending and receiving context information updates. In its turn, the IoT reference architecture addresses much more issues like energy optimization, error detection and correction, and services orchestration and composition. The minimum requirements to run UDuctor are Internet access and a software development kit allowing the implementation of the model. Most of today’s phones conform to these requirements. We believe that the support for the implementation of this model by governments might help promote local well-being and help save health budget spent on hospitalizations caused by untreated NCD cases. To assess the model, two experiments were done. The first was a technology acceptance test based on a scenario involving community and health organizations resources. This scenario allowed ten individuals to find care resources and people that could help them in their care activities. The obtained results showed a good acceptance of the proposed model. An overall strong agreement of 95% was obtained in perceived usefulness acceptance assessment. However, users’ comments given in the open question showed that the application needs improvements in user interaction aspects.
This research was approved by the Brazilian National Committee for Research Ethics under number 09064712. 6.0000.5344, according to the 196/96 resolution of the Brazilian National Health Council. ACKNOWLEDGMENT The authors acknowledge the collaboration of the research subjects who offered their time and valuable suggestions. They would also like to thank Igor Vianna, from Supernova SCI, who contributed with his suggestions to improve the text, and Capes/Brazil (Coordination for the Improvement of Higher Education Personnel) and CNPq/Brazil (National Council for Scientific and Technological Development) for their support. REFERENCES [1] OMS, “Global status report on noncommunicable diseases 2010,” World Health Organization, Geneva, Switzerland, Tech. Rep., 2011. [2] E. H. Wagner, B. T. Austin, C. Davis, M. Hindmarsh, J. Schaefer, and A. Bonomi. (2001, Nov.). Improving chronic illness care: Translating evidence into action. Health Aff [Online]. 20(6), pp. 64–78. Available: http://dx.doi.org/10.1377/hlthaff.20.6.64 [3] E. H. Wagner and T. Grove, “Care for chronic diseases—The efficacy of coordinated and patient centred care is established, but now is the time to test its effectiveness,” Brit. Med. J., vol. 325, pp. 913–914, 2002. [4] T. Bodenheimer, E. H. Wagner, and K. Grumbach. (2002, Oct.). Improving primary care for patients with chronic illness. JAMA [Online]. 288(14), pp. 1775–1779. Available: http://dx.doi.org/10.1001/jama.288.14.1775 [5] M. Weiser. (1991, Sep.). The computer for the 21st century. Scientif. Amer., pp. 91–95, [Online]. Available: http://www.ubiq.com/ hypertext/weiser/SciAmDraft3.html [6] M. Satyanarayanan, “Pervasive computing: Vision and challenges,” IEEE Pers. Commun., vol. 8, no. 4, pp. 10–17, Aug. 2001. [7] J. L. V. Barbosa, R. M. Hahn, D. N. F. Barbosa, and A. I. d. C. Z. Saccol. (2011, May). A ubiquitous learning model focused on learner interaction. Int. J. Learn. Technol. [Online]. 6, pp. 62–83. Available: http://dx.doi.org/10.1504/IJLT.2011.040150 [8] L. K. Franco, J. H. Rosa, J. L. Barbosa, C. A. Costa, and A. C. Yamin. (2011). Mucs: A model for ubiquitous commerce support. Electron. Commerce Res. Appl. [Online]. 10(2), pp. 237–246, special Issue on Electronic Auctions: Strategies and Methods. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1567422310000700 [9] J. a. Tavares, J. Barbosa, C. Costa, A. Yamin, and R. Real. (2012). “Hefestos: A model for ubiquitous accessibility support,” in Proc. 5th Int. Conf. Pervas. Technol. Related Assist. Environments [Online], ser. PETRA’12. New York, NY, USA: ACM, pp. 27:1–27:8. Available: http://doi.acm.org/10.1145/2413097.2413131 [10] J.-E. Lim, O.-H. Choi, H.-S. Na, and D.-K. Baik. (2009, May). A contextaware fitness guide system for exercise optimization in U-health. IEEE Trans. Inf. Technol. Biomed. [Online]. 13(3), pp. 370–379. Available: http://www.ncbi.nlm.nih.gov/pubmed/19193515
1606
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 18, NO. 5, SEPTEMBER 2014
[11] A. K. Dey and D. Estrin, “Perspectives on pervasive health from some of the field’s leading researchers,” IEEE Pervas. Comput., vol. 10, no. 2, pp. 4–7, Feb. 2011. [12] J. E. Bardram and H. B. Christensen, “Pervasive computing support for hospitals: An overview of the activity-based computing project,” IEEE Pervas. Comput., vol. 6, no. 1, pp. 44–51, Jan.–Mar. 2007. [13] C. Holtmann, M. M¨uller-Gorchs, A. Rashid, Klausweidenhaupt, V. Ziegler, B. Griewing, and C. Weinhardt, “Medical opportunities by mobile IT usage A case study in the stroke chain of survival,” in Proc. Eur. Conf. eHealth, Bonn, Germany, 2007, pp. 115–130. [14] C. Orwat, A. Rashid, C. Holtmann, M. Wolk, M. Scheermesser, H. Kosow, and A. Graefe, “Adopting pervasive computing for routine use in healthcare,” IEEE Pervas. Comput., vol. 9, no. 2, pp. 64–71, Apr./Jun. 2010. [15] A. Rashid, F. Schl¨ufter, C. Holtmann, C. Kunze, K. Thaler, M. Dl¨aumer, S. Schlesinger, and B. Griewing, “Usage of accelerometers in home care for multiple sclerosis patients,” in Proc. Eur. Conf. eHealth, Bonn, Germany, 2007, pp. 177–192. [16] N. Agoulmine, M. Deen, J.-S. Lee, and M. Meyyappan. (2011, Sep.). U-Health smart home. IEEE Nanotechnol. Mag. [Online]. 5(3), pp. 6–11. Available: http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm?arnumber=5993590 [17] F. Buttussi and L. Chittaro, “Smarter phones for healthier lifestyles: An adaptive fitness game,” IEEE Pervas. Comput., vol. 9, no. 4, pp. 51–57, Oct./Dec. 2010. [18] WHO, “Innovative care for chronic conditions: Building blocks for action: global report,” World Health Organization, Geneva, Switzerland, Tech. Rep., 2003. [19] E. H. Wagner, “Chronic disease management: what will it take to improve care for chronic illness?” Effect. Clin. Pract., vol. 1, pp. 2–4, 1998. [20] E. Mattila, J. P¨arkk¨a, M. Hermersdorf, J. Kaasinen, J. Vainio, K. Samposalo, J. Merilahti, J. Kolari, M. Kulju, R. Lappalainen, and I. Korhonen. (2008, Jul.). Mobile diary for wellness management–results on usage and usability in two user studies. IEEE Trans. Inf. Technol. Biomed. [Online]. 12(4), pp. 501–512. Available: http://www.ncbi. nlm.nih.gov/pubmed/18632330 [21] E. Mattila, I. Korhonen, J. H. Salminen, A. Ahtinen, E. Koskinen, A. S¨arel¨a, J. P¨arkk¨a, and R. Lappalainen, “Empowering citizens for wellbeing and chronic disease management with wellness diary,” IEEE Trans. Inf. Technol. Biomed., vol. 14, no. 2, pp. 456–463, Mar. 2010. [22] V. G. Koutkias, I. Chouvarda, A. Triantafyllidis, A. Malousi, G. D. Giaglis, and N. Maglaveras. (2010, Mar.). “A personalized framework for medication treatment management in chronic care.” IEEE Trans. Inf. Technol. Biomed. [Online]. 14(2), pp. 464–472. Available: http://www.ncbi.nlm.nih.gov/pubmed/20007042 [23] F. Paganelli and D. Giuli. (2011, Mar.). “An ontology-based system for context-aware and configurable services to support home-based continuous care.” IEEE Trans. Inf. Technol. Biomed. [Online]. 15(2), pp. 324–333. Available: http://www.ncbi.nlm.nih.gov/pubmed/21075729 [24] F. Paganelli, E. Spinicci, and D. Giuli. (2008, Jan.). Ermhan: A contextaware service platform to support continuous care networks for homebased assistance. Int. J. Telemed. Appl. [Online]. 2008, pp. 4:1–4:13. Available: http://dx.doi.org/10.1155/2008/867639 [25] C. Costa, F. Kellermann, R. Antunes, L. Cavalheiro, A. Yamin, and C. Geyer, “Continuum: A service-based software infrastructure for ubiquitous computing,” in Proc. IEEE Int. Conf. Pervas. Comput. Commun., 2009, pp. 1–4. [26] A. Dey, G. Abowd, and D. Salber, “A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications,” Human-Comput. Interact., vol. 16, no. 2, pp. 97–166, Dec. 2001. [27] J. M. Silva, J. A. H. Rosa, J. L. V. Barbosa, D. N. F. Barbosa, and L. A. M. Palazzo. (2010, Jul.). Content distribution in trail-aware environments. J. Brazilian Comput. Soc. [Online]. 16(3), pp. 163–176. Available: http://www.springerlink.com/index/10.1007/s13173-010-0015-1
[28] C. Doukas and I. Maglogiannis, “Emergency fall incidents detection in assisted living environments utilizing motion, sound, and visual perceptual components,” IEEE Trans. Inf. Technol. Biomed., vol. 15, no. 2, pp. 277– 289, Mar. 2011. [29] R. T. Fielding and R. N. Taylor. (2000). Principled design of the modern web architecture, in Proceedings of the 22nd International Conference on Software Engineering, ser. ICSE ’00. New York, NY, USA: ACM, pp. 407–416. [Online]. Available: http://doi.acm.org/10.1145/337180.337228 [30] L. Padgham and M. Winikoff, Developing Intelligent Agent Systems: A Practical Guide. New York, NY, USA: Wiley, Jun. 2004. [31] A. Developers. (2012) What is android? [Online]. Available: http://developer.android.com/guide/>basics/what-is-android.html [32] F. D. Davis. (1989, Sep.). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Q. [Online]. 13(3), pp. 319–340. Available: http://dx.doi.org/10.2307/249008 [33] C. Yoon and S. Kim. (2007). Convenience and tam in a ubiquitous computing environment: The case of wireless LAN. Electron. Commerce Res. Appl. [Online]. 6(1), pp. 102–112. Available: http://www.sciencedirect.com/science/article/pii/S156742230600055X [34] R. Likert, “A technique for the measurement of attitudes,” Arch. Psychol., vol. 22, no. 140, pp. 1–55, 1932. [35] Deliverable D1.4 Converged architectural reference model for the IoT v2.0, European Commission, 2012. [Online]. Available: http://www.iota.eu/public/public-documents/documents-1/1/1/D1.4/at_do wnload/file
Henrique Damasceno Vianna received the M.Sc. degree in the Applied Computing Graduate Program of the University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo, Brazil, in 2013. He researches the application of ubiquitous computing applied to the care of chronic diseases at the Mobile Computing Laboratory (MobiLab/UNISINOS). He is also a Computer Technician at the Data Processing Company of the State of Rio Grande do Sul, where he works on developing solutions to aid public management. His research interests include public health informatics, mobile and ubiquitous computing, and software architecture for network-based applications.
Jorge Luis Vict´oria Barbosa received the M.Sc. and Ph.D. degrees in computer science from the Federal University of Rio Grande do Sul, Porto Alegre, Brazil, in 1996 and 2002, respectively. He is currently a Full Professor of the Applied Computing Graduate Program at the University of Vale do Rio dos Sinos (UNISINOS), S˜ao Leopoldo, Brazil. Additionally, he is a Researcher of productivity at CNPq/Brazil and the head of the Mobile Computing Laboratory (MobiLab/UNISINOS). His research interests include mobile and ubiquitous computing, ubiquitous health and ubiquitous accessibility. Dr. Barbosa is a member of the Brazilian Computer Society.
