PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK Pervasive Personal Healthcare Service Designed as Mobile Social Network https://doi.org/10.3991/ijim.v10i4.5913 V. Miskovic1, Dj. Babic2 1 Slobomir P University, Bijeljina, Bosnia and Herzegovina 2 University Union, Belgrade, Serbia Abstract—A global phenomenon of population ageing and an increasing number of patients with chronic diseases place substantial additional pressure on healthcare systems. A possible solution for this problem is a new emerging sort of pervasive personal healthcare service that is focused on the patient and allows the patient to be actively involved in his or her own health care. In this paper, we propose the archi- tecture of the pervasive personal healthcare service which is based on the existing technologies available to almost every- one. Along with the conventional request-response synchro- nous communication, the proposed system features asyn- chronous communication based on the publish-subscribe- notify model. In order to perform asynchronous communi- cation, a web application server is integrated with the Google Cloud Messaging service. The communication be- tween mobile device and servers is carried out through the available Wi-Fi or mobile networks, whereas Bluetooth protocol is a conventional for Body Sensor Networks con- sisting of wearable sensor devices. We also present a mobile application which has been developed with the use-case driven approach for both patients and medical personnel. The introduced application has a form of a nonintrusive customized mobile social network. We explain usage scenar- ios that clarify the required functions and present conclu- sions based on the system test. Index Terms—body sensor networks, medical services, per- vasive computing, ubiquitous computing. I. INTRODUCTION According to the data from Continua Health Alliance [1] worldwide today: one billion adults are overweight, 860 million individuals are struggling with chronic diseas- es, 600 million are of age 60 or older and even 75-85% of the healthcare spending goes to chronic health manage- ment. Predictions for the following period are even more alarming, therefore plenty of research has been conducted in the field of systems for patient monitoring. The goals of such systems are: make the health service more effective, patients must be actively involved in the treatment pro- cess, reduce the number of unnecessary checkups and field interventions, provide the elderly more comfortable life, become preventive and persuasive, and much more. This new emerging sort of healthcare service is focused on the patient and the patient is actively involved in his or her own health care. Pervasive healthcare technologies will be part of a fundamental change in the delivery of healthcare services. Today, the healthcare services are moving from a highly centralized and specialized model to a much more decentralized and personal model [2]. Pervasive healthcare should not be expensive and should be made available to anyone and anywhere. The development of the network technologies makes this vision realistic. Fig. 1. illustrates a simplified common network architecture for the health monitoring with widespread mobile net- works, Wi-Fi networks and wireless personal area net- works (WPANs). From patients to medical personnel, the healthcare sys- tem consists of the next components: 1. WPANs, which in the case of wearable or implanta- ble sensors are called Body Sensor Networks (BSNs). 2. Technologies for acquisition of raw sensor data that offer the advantage of plug-and-play interoperability, which are: Bluetooth Low Energy 4.0 –BLE Health De- vice Profile (HDP) [3] and ZigBee Health Care [4]. Both rely on the standardization effort done by the Continua Alliance. The Continua Health Alliance is a non-profit, open industry coalition of leading health care and technol- ogy companies. Procedures for the data exchange between medical devices and data formats for different types of medical devices (Pulse Oximeter, Thermometer, Weigh- ing Scale, etc.) are based on the IEEE 11073 standard. However, Bluetooth Serial Port Profile (SPP) [5] is still widely used in medical devices, whereas every manufac- turer has its own exchange procedures and data formats. The main advantage of HDP is the fact that all of its dif- ferent aspects — from connection establishment to data representation and exchange — are standardized, thereby resulting in better interoperability [6]. 3. Mobile phones which are aggregators of sensor data. The modern middleware based software design uses methods of encapsulation to separate hardware dependent sensing code and client code. The middleware based ap- proach introduces a layered architecture with the intention of hiding low-level sensing details [7]. 4. Technologies for data transmission, sharing and stor- age on central servers are widely versatile, but they need to provide: request-response synchronous and store- forward asynchronous interaction for designed system applications [8]. 5. The most important component of such a system is a mobile or/and web application which is used by medical personnel and patients. In order to successfully design new medical technologies, acceptance issues and user needs and wishes should be considered [9]. The most important usage criteria determined as the result of the questionnaire in [9] are: ease of use, controllability (con- trol of data transmission) and communication comfort. It seems that people have an unspecific uneasy feeling and concerns about data security and loss of control. iJIM ‒ Volume 10, Issue 4, 2016 65 PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK Figure 1. Simplified common network architecture for health monitor- ing II. RELATED WORK The various applications of monitoring patients can be divided among the following categories: prevention, healthcare maintenance and examinations, home care (assisted living) [10-12]; intelligent hospital [13-14]; inci- dence detection, emergency intervention [15]; and perva- sive healthcare applications [16-21]. The systems for the pervasive healthcare support different scenarios, such as: continuous monitoring of the elderly in their homes and geriatric centers; monitoring of patients in the postopera- tive period, with the possibility of generating an alarm in the case of medical emergency; periodical data acquisition from patients whose condition is not life-threatening but it is preferable to analyze warning signs in order to intro- duce appropriate treatment and thereby avoid health dete- rioration. Similar classification is given in many related articles on healthcare as in Center for technology and aging (CTA) [22]: 1) chronic disease management and post-acute care management, and 2) patient safety. Nowadays, the most of these applications, particularly pervasive ones, use Body Sensor Networks (BSNs). BSNs consist of a set of wearable or implanted sensors, which monitor the vital signs or movements of the human body in a ubiquitous computing environment [23]. Modern context-aware applications that enrich user interaction and interpersonal communication [24] use BSNs as sources of raw data. This kind of intelligent applications is essential to monitor human health, where the proper assessment of the health condition is extremely important. A certain kind of mobile device gathers this data / polls sensors and it acts as gateway to the central server or it processes data locally. There has been significant number of research projects in this area. In [25] a wearable computing platform, called Mithril, with sensors that can continuously monitor the vital signs, motor functions, social interaction, sleep quali- ty, and other health indicators, has been proposed. Mithril is used to study human behavior and to recognize different behaviors for creating the context–aware interface with the computer. A project called Ubiquitous Monitoring Environment for Wearable and Implantable Sensors [16] has a goal to provide continuous and undisturbed health monitoring system. The system consists of five main components: BSN nodes, local processing unit (LPU), central server (management), patient database and work- station (monitoring). Wireless sensors that can be used here are: ECG sensor, SpO2 sensor (oximeter), accelera- tion sensor etc. In addition, the Compact Flash card was developed for a Personal Digital Assistant (PDA), where all collected sensor data are transmitted through a Wi- Fi/GPRS network for long-term storage and trend analy- sis. Further examples of similar projects are MobiHealth, European Commission [17] and HealthService24, Erics- son Enterprise [18] with the difference in the fact that the processing of data is not performed at the LPU, but the data is forwarded to a remote server where the processing is done. BASUMA [19] is also a similar project but it suggests the use of intelligent sensors in the mesh sensor network. In [19], an ad-hoc sensor network for transfer- ring vital signs to the health care providers has been pre- sented as a result of CodeBlue project. There, the use of an adaptive spanning-tree multi-hop routing algorithm has been explored. ActivePal, PAL Technologies [26] is a commercial example of a system that is used to visualize data from Ambient Assisted Living Services (AALS). It provides a visual representation of data about the activities of the patient during the day. The principles of context awareness are also studied in ActivePal - PAL Technolo- gies [26], Tunstall's ADLife - Tunstall Healthcare [11] and QuietCare - Intel-GE Care Innovations [12] system. Social networking is to the current era what online ac- cess was just 20 years ago – a transformational change in how information is accessed and shared [27]. Public, In- ternet-based social networks can enable communication, collaboration and information collection and sharing in the health care space. A lot of people go online to search topics related to their health and sign up for social net- works in order to find fellow patients and discuss their conditions. PatientsLikeMe [28] and MedHelp [29] allow participants to upload detailed information about their condition and receive information from similar patients. There are researchers that utilize different platforms with the model of a social network [30] or social network is an additional method for information sharing [23], [31]. So- cial networks (SNs) with all positive factors represent high level of continuous activities. Therefore, functions of the system proposed in this paper correspond to relations in social networks, but with subset of the SNs functions required for healthcare scenario. Social networking is already consuming our precious time; therefore our sys- tem tries to be nonintrusive user-friendly but dedicated to its task. The system proposed in this paper supports the chronic disease management scenario. Here, we propose the archi- tecture of the pervasive personal healthcare service which is based on the existing technologies available to almost everyone. Along with the conventional request-response synchronous communication, the proposed system fea- tures asynchronous communication based on the publish- subscribe-notify model. In order to perform asynchronous communication, a web application server is integrated with the Google Cloud Messaging (GCM) service. Roles and communication of participants in the proposed system are defined on the basis of SIMPLE publish-subscribe- notify model presented in [32]. We also present a mobile application which has been developed with the use-case driven approach for both patients and medical personnel. The presented application has a form of a nonintrusive customized mobile social network. A mobile application is used by both, patients and medical personnel. The mobile application communi- 66 http://www.i-jim.org PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK cates with the servers via mobile or Wi-Fi networks, and wireless communication between mobile device and sen- sor devices is based on Bluetooth. Along with the conven- tional request-response synchronous communication, the proposed system features asynchronous communication based on the publish-subscribe-notify model. Google offers a service called Google Cloud Messaging for An- droid (GCM) [33] which enables developers of Android applications to send messages to mobile devices from an application server. The mobile device has synchronous communication with the application server, and GCM allows one to send asynchronous messages between sys- tem and mobile phones. PHP application server has been developed using Larman’s method and software patterns [34] with MySQL database for data storage. III. MATERIALS AND METHODS In this Chapter, we present the implemented system ar- chitecture and explain in details the most important use cases implemented within the proposed mobile applica- tion. We illustrate use cases scenarios, and give several illustrations of GUI. A. Implemented System Architecture The Subscribe-Publish-Notify model is a framework which guarantees the accuracy of information in the form of immediate forwarding of relevant information between subscribers, which have an observer-publisher relation- ship. SIMPLE [32] specifications describe in detail this model for the purpose of sending presence data via SIP protocol in SIP-enabled IP networks, such as IP Multime- dia Subsystems (IMSs). The aforementioned model is adopted for the proposed system for monitoring of pa- tients and it is illustrated in Fig. 2. A role of observer (called also watcher) is dedicated to medical personnel, family or friends, while publisher (called also presentity) is a patient. The observer sub- scribes in order to observe a set of patients. In this way, all observers create their own patients list. Every patient has the right to grant or to reject the request for observing. Thus patients can create their own watchers list. When a patient reveals new data, the data is forwarded to author- ized watchers in the form of notification following publish – notify principle. In order to avoid sending many mes- sages, it is better to notify an observer by producing an alarm only if the data is to be considered. It is also possi- ble to introduce certain modifications in this model, such as that the medical personnel can send certain advices to patients, i.e., publish / notify in the opposite direction. Besides these examples of asynchronous messaging, the system should support synchronous communication (re- quest-response): registration, login, logout, manual data sending, request for review of patient data in predefined period etc. It can be concluded that the hybrid variant of asynchronous / synchronous communication is a universal principle suitable to meet any requirements of different scenarios for monitoring of patients. Figure 2. Sequence of asynchronous communication Google Cloud Messaging for Android (GCM) is a push service similar to SMS. This is opposed to the majority of systems which offer a continuous polling from the server in order to solve the problem of push messages. The push service explained above can be implemented using Web- socket protocol [35] which enables a full-duplex commu- nication between client and server over single TCP con- nection. However, Websocket protocol has not come to a final mature version yet. Its benefits have been recognized and new versions of Internet browsers and server plat- forms have support for its current specifications. Howev- er, in our system we use the above mentioned reliable Google technology and roles / relationships defined in the SIMPLE model. The proposed system consists of the following compo- nents: 1. mobile device with Android application using GCM, 2. application server which has communication with the central database and which asynchronously sends messages over the GCM service to the Android ap- plication, and 3. the third component is the GCM server responsible for sending messages to mobile devices. Figure 3. Main system components and their communication (dotted lines represent synchronous, dashed lines asynchronous messaging, and solid lines indicate the process of obtaining the registration ID that will be later used for message forwarding) The application server is developed using one of the ex- isting technologies. In this contribution, we use the PHP server with compatible MySQL database. When one regis- ters to use the GCM services then he or she receives send- er ID and API key. The mobile device sends sender ID and application ID, which is a package name from the application manifest, to the GCM server and if they are correct, it will receive a registration ID. This process is illustrated in Fig. 3 with arrows 1 and 2. When a user tries to log in to his or her account for monitoring service by entering his or her user name and password, the registra- tion ID is sent as additional information to the PHP server, as illustrated in Fig. 3 with arrow 3. If the user is success- fully logged in, the server stores the sent ID with other user data in the database, as shown in Fig. 3 with arrow 4. Whenever there is a need to send a message to the user, the PHP server sends the registration ID and message to the GCM. The API key is included in the header of POST requests that send messages. The GCM forwards the mes- iJIM ‒ Volume 10, Issue 4, 2016 67 PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK sage to the corresponding mobile device, based on the registration ID. This is depicted in Fig. 3 with arrows between PHP server, GCM and mobile device. If the user failed to log in to the GCM service, then messages from GCM cannot be sent him. During logging out, the PHP server deletes the registration ID. In order to preserve valuable messages when the user is offline PHP server saves them. When the user goes online again, the server sends him or her all stored messages and removes these messages from the database. An UML sequence diagram, shown in Fig. 4, gives the sequence of messages that are passed between system components. Figure 4. Main system components and their communication - System sequence diagram The PHP server also provides synchronous HTTP POST request/response communication to the Android application. This type of communication is used in order to perform actions as: login/logout to the system, getting profile data, obtaining information about the patient's health (heart rate, temperature) and similar. In contrast to the synchronous request-response actions, the asynchro- nous communication allows one to send a message when an event occurs, for example: patient has approved / blocked some of the observers; observer has requested to watch a particular patient; user status has been changed online / offline. This type of communication gives more interactivity and new services which can be offered by the system. Medicals can send messages in order to support, advise or warn the patient. For example: they can alert someone not to forget to take his or her medication. These push mes- sages enable the system to deal with an alarm scenario. The alarm is triggered when the patient's condition is critical based on the system assessment. In the proposed system, we can identify the following five events: patient, watcher, status, advice and alarm. At the moment, we have implemented the first four events in the proposed system. After the system upgrade with the ability to esti- mate the patient's condition, the alarm event will be im- plemented, too. For the acquisition of vital signs, a mobile device com- municates with health devices using Bluetooth Serial Port Profile (SPP) [5] and using Bluetooth Low Energy (BLE) Health Device Profile (HDP) [3]. Heart Rate Monitor (pulse meter) that supports Bluetooth 3.0 [36] or Blue- tooth Smart Heart Rate Monitor [37] with Android 4.3 or later and thermometer for temperature measurement, which also supports Bluetooth 2.1 + EDR [38] are three biosensors selected for testing. Since the communication for SPP, i.e. messages that are exchanged, is not standard- ized, every manufacturer has its own specifications. In order to control Bluetooth communication for two chosen devices we have designed two different managers. This is a legacy way to communicate with health devices, where- as BLE HDP solves this problem and other requirements of sensor communication. Current Android versions im- plement BLE HDP and can act as sink which can be used to talk to health devices. The manager for BLE HDP is simply added to the existing infrastructure. The user ac- tively participates in this process only if he/she wants to manually send data and while he/she is choosing the sen- sors. In this way, the patient is not disturbed by this pro- cess and the patient can decide whether to send the sensor data. Figure 5. PHP server software design According to Larman’s method for software develop- ment, the system requirements are described by using Unified Modeling Language - UML Use-Case Model. The obtained architecture is the three-tier architecture com- posed of presentation tier (mobile application), business or data access tier (in PHP), and data management tier (MySQL). The business tier consists of controller, domain classes (system structure), business logic (system opera- tions) and database broker. The controller is organized as a facade pattern which forwards the requirements of the proposed application to the appropriate system classes that will execute it. The controller is also responsible for call- ing GCM server. It receives HTTP POST requests with name and arguments of requested system operation and user’s authorization data. The controller generates HTTP response to the mobile application based on returned re- sults of requested system operation. B. Use cases implemented in the mobile application Although the presented mobile application may not be in a running state, it is possible that the mobile device receives the messages as long as the application has an associated permission for receiving messages and regis- 68 http://www.i-jim.org PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK tered broadcast receiver for Google GCM service. When the user activates other applications that require some space in memory, the application switches to the state onPause() but the application still exists and can receive messages. New received message activates application again (onResume() -> Running ). GCM forwards raw data to the mobile application, which has full control over how the data is processed. For example, an application can initiate a notification service and add a new notification or perform data synchroniza- tion in the background. The notification system, which is the component of the Android OS, gives us the infor- mation such as that a new SMS is received. The same system is used by the proposed application in order to inform the user. The message can be indicated by beeping and/or vibrating. In order to use the proposed application it is necessary to: • Enable Bluetooth; • Enable a mobile Internet service or set up Wi-Fi net- work for packet data transmission; • Mobile phone should be registered into a Google ac- count, if the version of Android is less than 4.0.4; • Sensors must be turned on for the purpose of collect- ing data. Main application features are further represented by use cases and the accompanying graphic interfaces. Currently, all functions are assigned to the single generic user, but the real application will be profiled specifically for pa- tients, medical personnel and family members. A use case (UC) describes a set of scenarios, i.e. a set of desired system utilizations by the actors. UC consists of main and alternative scenarios. The scenario describes the desired use of the system by the actors. The scenario is described through a sequence of actions and interactions between actors and the system. An actor is the external user of the system. The user requests from the system one or more system operations based on pre-defined script. There are 5 types of possible actions in a common se- quence of UCs [39]: 1. Actor prepares inputs for a system operation (APISO) 2. Actor calls system to perform a system operation (ACSO) 3. Actor performs a non-system operation (ANSO) 4. The system executes the system operation (SO) 5. The result of the execution of the system operation is sent to the actor (OA) In a sequel, we give an overview of implemented use cases. Activities noted in italic represent the system func- tions that depend on the GCM service. The use cases are: UC1 User registration UC2 User login: change of status is sent to all observ- ers and patients, and if they are dealing with the lists of contacts, the lists will be updated with new statuses UC3 Management of user profile data UC4 Manually sending data UC5 Overview of the patient UC6 Editing access rights of observers • pending requests, • approved observers, • blocked observers Actions: approve, block, delete and show profile of ob- server, send observer a message about the decision that the patient has just made UC7 Patient as an observer • editing list of all patients Actions: show profile, delete a patient from the list and send a message to the patient, send patient a compliment, advice or warning • add new patient, send patient request for observa- tion UC8 Sensors control: When sensing devices are cor- rectly placed on the patient's body application can connect with them. Upon successful connection application polls the associated sensors and automatically sends this data to the server. An alternative way is to send patient data man- ually UC9 User logout: the change of status is sent to all observers and patients, as in the case of login 1) Use Case 1 (UC1): User registration Name of UC1 is User registration. The UC1 has the fol- lowing preconditions: the patient has never been signed up. The patient can choose from the optional menu item Sign Up / Register. Then the signup form, displayed in Figure 6., is opened and user can enter personal and ac- count data. The main UC1 scenario consists of the following: 1. The patient enters the required data (and / or selects a profile picture from the phone image gallery) (APISO); 2. Patient confirms signup by clicking the Sign up but- ton (ACSO); 3. The application sends data to the PHP server. Server verifies the validity of the data and then stores it in the database (SO); 4. The application displays a message about successful signup (OA). Alternative scenarios: 2.1. User gives up the signup (Cancel). 4.1. If the user name already exists, or the name and password are shorter than 5 characters, then a message that an error occurred will be displayed (OA). A login/ logout use cases (UC2 and UC9) initiate the following system activities. All system users who are associated with the user who performed login/ logout get a GCM message with changed status and user ID. User's status can be seen in the patient/observer lists, i.e. green for online and red for offline status (See Fig. 7. b)). If the application determines that the user is already logged in, this step is skipped and the user receives the display of the main menu which is illustrated in Fig. 7. c). The user can remain logged in until he/she logs out. iJIM ‒ Volume 10, Issue 4, 2016 69 PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK a) b) Figure 6. a) Sign up option b) Form for editing profile data 2) Use Case 4 (UC4): Manual data sending Name of UC4 is Manual data sending. The UC4 has the following preconditions: The patient is logged in, thus the main menu is displayed to him. The main UC4 scenario consists of the following: 1. One of the options is to send data manually (ACSO); 2. The application requests list with types of sensors that are supported (SO); 3. The application shows the user form for data sending with selection list to choose the type of sensor (OA); 4. The patient selects the type of indicators from the se- lection list and enters data to send (measured value) (APISO); 5. Patient sends data by pressing the OK button (ACSO); 6. The application sends data to the server and the serv- er stores the patient’s data (SO); 7. The application displays a message about successful data sending (OA). Alternative scenarios: 3.1. There is a problem in receiving the list of sensors supported by the system, in this case show error message instead of entry form (OA). 7.1. If there is an error, then the application displays a message. With arrow key the user can go back to the main menu and give up the changes (OA). 3) Use case 5 (UC5): Overview of the patient Name of UC5 is Overview of the patient. The UC5 has the following preconditions: The medical personnel or family member is logged in, thus the main menu is dis- played to the user. Patients can view their own data or their friends' data. Relatives and medical personnel review the data of their patients / relatives. The main UC5 scenario consists of the following: a) b) c) Figure 7. a) Login form b) Patient status online/offline c) Main menu 1. Patient chooses overview of patients’ data (ACSO); 2. Application requests a list of patients that a user is authorized to observe (SO); 3. The application displays a form with parameters for querying patients’ data (OA); 4. The patient selects period for overview, in such a manner that he/she first selects a date from the calen- dar, in addition enters a number of days for the over- view, and selects a patient with arrow keys. In the proposed system, weight, temperature and pulse are enabled data types. The review can be aggregated by seconds, minutes or hours. If one chooses aggrega- tion by hours, then the application activates the input field for number of days, respectively, if one chooses minutes or seconds, the application activates the in- put field from/to hh:mm. The overview by hours and minutes shows an average of all values recorded in the selected intervals, and the overview by seconds shows just recorded values in selected moments (APISO); 5. The patient sends a request for review by pressing the Show me preview button (ACSO); 6. The application sends a query made by the user to server which processes the query and sends results back to the application (SO); 7. The application displays a chart with temperature and pulse / weight of the patient (OA) (Fig. 8). In the meantime, the progress bar is shown. Alternative scenarios: 3.1. If the list of patients is empty, then a warning mes- sage will be displayed to the user and not the input form (OA). 7.1 If the application cannot display the data due to any error, then a message is shown to the user. The user can use arrow key to go back to the previous screens (OA). 70 http://www.i-jim.org PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK a) b) Figure 8. Samples of charts with: a) temperature (in °C) displayed with green line and hart rate (in beats/min) displayed with blue line (average values in minutes) b) weight of the patient (current shown with blue arrow, min and max values shown with green needles) 4) Use Case 6 (UC6): Editing access rights of observers Name of UC6 is Editing access rights of observers. The UC6 has the following preconditions: The patient is logged in, thus the main menu is displayed to him/her. One of the options is to edit the access rights. Observers can be in one of the following states: approved, pending and blocked. The first state means that the observer is approved by the patient; the second state means that the observer is still waiting for the patient’s response; and third state means that the observer is rejected by the pa- tient. The main UC6.1. scenario consists of the following: 1. The patients selects Pending observers (ACSO); 2. The application sends the patient’s request to the server which searches for pending list. (SO); 3. The application shows the list of found observers. For each observer a record contains his/her name, status icon meaning online/offline, and role in the system: doctor, family and friend as another pa- tient (OA); 4. The patient can select one of the items from the list and then from the context menu he/she selects one of the listed options: view profile, delete or approve observer (ACSO); 5. The application executes activity via server (SO); 6. List of pending requests is reloaded and the mes- sage about the success of the action is displayed (OA). Alternative scenarios: 3.1. If there is an error or the list is empty, then the ap- plication displays a message (OA). 5.1. If the user selects the option to view the observer’s profile, then the observer’s basic data will be obtained from the server (OA). 6.1. If an error occurs, while performing the procedure, then the patient receives an error message (OA). A prerequisite for the Use Case 6.1. is the following system event. The observer can be found in the pending list only if the observer’s request for observation has been sent. When such a request exists the system forwards it to the patient. In the case when the patient is logged in, the patient receives a notification immediately. If this is not the case, then the notification is obtained at next logging in. By clicking the notification, the patient opens use case UC6.1. (pending observers), which can be seen in Fig. 9. (a). Fig. 9. (b) illustrates an opposed situation when an observer deletes his patient. Confirmation/blocking /deleting of observers has the consequence where the system sends a message to the observer that the patient changed his status (Fig. 9. c)). 5) Use Case 7 (UC7): Patient as an observer Name of UC7 is Patient as an observer. The UC7 has the following preconditions: The user is logged in, thus the main menu is displayed to him/her. One of possible options is to manage list of patients. The patients’ data is stored on the server. A user can add new patient or see its list of patients. The main UC7.1. scenario called Editing list of all pa- tients consists of the following: 1. The user selects the list of patients (ACSO); 2. The application sends patient’s request to the server which searches for the patient list (SO); 3. The application shows the list of found patients. For each patient, the record contains his/her name, status icon showing online/offline status and atti- tude toward the observer: active, blocked or pend- ing (OA); 4. The patient can select one item from the list and then he/she selects from the context menu one of the listed options which are: view profile, delete, and send message (the third option is active only if the patient approved this observer) (ACSO); 5. The application executes activity via server (SO); 6. List of patients is reloaded and the message about the success of the action is displayed (OA). a) b) c) Figure 9. a) Observer requested to watch patient b) Observer deleted patient from his/her list of patients c) Patient approved observer. Alternative scenarios: 3.1. If there is an error or the patient list is empty, then the application displays a message (OA). 5.1. If one chooses to send a message, then he/she en- ters the message and confirms it. After login, the patient receives the message. This is an event that requires asyn- chronous communications, which is illustrated in Fig. 10. (OA). 6.1. If an error occurs, while performing the procedure, the patient receives an error message (OA). The main UC7.2. scenario called Add new patient con- sists of the following: 1. The observer enters the patient’s username (the observer must know the usernames in order to add the patient) (APISO); 2. The observer confirms operation by clicking Add button (ACSO); iJIM ‒ Volume 10, Issue 4, 2016 71 PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK 3. The application executes activity via server (SO); 4. The application displays a message about the suc- cess of the action (OA). Alternative scenarios: 3.1. If the observer does not confirm the action, then he/she stops its further execution. 4.1. If an error occurs or the patient doesn’t exist in the database, then the observer receives an error message. a) b) Figure 10. a) Observer is sending a message b) Patient has received a message 6) Use Case 8 (UC8): Sensors control Name of UC8 is Sensors control. The UC8 has the fol- lowing preconditions: The user is logged in, thus the main menu is displayed to him/her. One of the options from the main menu is to manage the sensors which are connected to the mobile application in order to transfer sensor data automatically to the PHP server. The patient receives the screen, shown in Fig. 11., which shows a list of sensors that can be connected to the application. If Bluetooth is disabled, the user gets a message that Bluetooth should be enabled in order to use the sensor devices. These devices need to be paired, in same way as for any other Bluetooth devices. The main UC8 scenario consists of the following: 1. The user (patient) checks the sensors. The sen- sors should be placed at the correct location and started (APISO); 2. The patient confirms operation by clicking OK button (ACSO); 3. The application links with the sensors through Bluetooth and establishes communication for sending and receiving sensor data. This data is automatically sent to the PHP server (SO); 4. The application displays the notification that the sensors are successfully connected (OA). An alternative scenario: 4.1. If an error occurs while performing the operation then the patient receives an error message. If the applica- tion is not able to connect to the sensor or the connection is interrupted during communication, the patient receives a message that the connection is lost and it is necessary to repeat the described scenario (OA). As described above, the mobile application has a form of dedicated social network. This social network is dedi- cated to a particular topic - improving own health. Its participants communicate with each other by posting new information (vital signs), sending messages to each other, by viewing profile information of other participants and permitted health information. Depending on the system role each participant maintains own list of friends: patients or doctors or family members. Linking the system to the existing social networking sites, such as Facebook, would expose highly private vital signs to large number of people who could misuse them. Social network users are rarely enough educated to undertake all security measures and existing security mechanisms in order to adequately pro- tect their private information. Creating a dedicated closed system, such as the proposed one, protects patients and doctors from malicious persons and provide a greater sense of security / privacy to its users. a) b) c) Figure 11. Sensor control: a) Control table b) Patient selected sensors c) Notification that connection with sensors has been established II. RESULT AND DISCUSSIONS Three categories of patients were selected for testing the proposed system for healthcare monitoring. We select- ed 4 patients for each category. The first category consist- ed of elderly people of age of 60 or older. The second category consisted of patients that need periodical moni- toring (25-60 years old). And, the third category consisted of patients that require continuous monitoring (25-60 years old). In the first category, approximately half of the selected population had no computer skills but had mobile phones, and the other half used computers and mobile applications for communication with relatives. The first and the second category used sensors only at specified intervals of five minutes (morning, afternoon, before bed- time). They could use option for manual data sending, as well. The third category was supposed to constantly carry sen- sors underneath clothes. Furthermore, the third category was supposed to use the manual data sending only if there was a malfunction with the sensors. Patients were not required to make interaction with each other. In other words, they could accept only medical personnel as an observer. All members involved in testing attended the demonstration class, where it was explained how to use the application through described use case scenarios from Section 3. After a day of testing an interview was per- formed. The interviewees were asked to comment on the certain statements about usage criteria of the proposed healthcare system [9]. It was possible for them to agree or disagree with offered statements, and/or give additional opinions. The obtained results are shown in Table I and Table II. 72 http://www.i-jim.org PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK TABLE I. THE SYSTEM IS USER FRIENDLY Statement I – Elderly II – Periodical monitoring III – Continuous monitoring Basic tasks such as: sign up, log in, log out, control sen- sors and manual data sending are intuitive. 3/4 4/4 4/4 Managing lists of observers and fellows is easy to navi- gate and to accomplish. 1/4 4/4 4/4 System notifications (similar to SMS messages) have a suitable form for sharing information. 2/4 4/4 3/4 Process of patient data over- view is complex. 2/4 0/4 1/4 TABLE II. INTRUSIVE/NONINTRUSIVE SYSTEM Statement I – Elderly II – Peri- odical monitoring III – Continuous monitoring The system interferes with your daily activities. 0/4 1/4 2/4 Using the adapted social network among the partici- pants interferes with your precious free time. 1/4 0/4 1/4 The exchange of information and motivating messages from observers annoy you. 2/4 0/4 1/4 A process of data collection through sensors is uncom- fortable. 0/4 0/4 3/4 A process of sending sensor data is not more effective than conventional manual data sending. 2/4 1/4 0/4 It is hard to maintain mobile and sensor devices. 2/4 0/4 0/4 III. CONCLUSION The presented pervasive healthcare system is based on social networks and their usage scenarios which are proved to be very accepted and their popularity suggests that such communication model is widely used by the consumers worldwide. The ability to send messages, mon- itor statuses and give suggestions from friends and not just by medical personnel and other care providers should make these systems less repulsive. The patients do not have the feeling that they have lost control over private data, because they determine who can view them and when the data is sent. Medical personnel have a constant overview of their patients in the list and they can also contact them and write a warning message or an advice. In this way, the proposed system saves time and energy of all participants. The category of patients that have been con- tinuously monitored complains about the inconvenience of wearing sensors constantly. The category of elderly pa- tients can use the system; however, several patients were afraid of new technology. The proposed system should be upgraded in order to be able to make inferences about the patient's condition upon which the alarm messages can be sent to observers, which makes this the next goal of our research. REFERENCES [1] Continua Health Alliance, “The Next Generation of Healthcare: Personal Connected Health & Wellness,” Source: World Health Organization; McKinsey, 2010. [Online]. Available: http://www.continuaalliance.org/ [2] J. E. Bardram, “Pervasive Healthcare as a Scientific Discipline,” Meth. of Inform. in Med., vol. 47(3), pp. 178-185., 2008. http://dx.doi.org/10.3414/me9107 [3] Bluetooth Medical Devices WG, “Health Device Profile,” 2012. [Online]. Available: https://www.bluetooth.com/specifications/adopted-specifications [4] ZigBee Alliance, “ZigBee Health Care profile specification,” 2010. [5] Bluetooth, “Serial Port Profile,” 2012. [6] J. Noueihed, R. Diemer, S. Chakraborty, and S. Biala, “Comparing Bluetooth HDP and SPP for Mobile Health Devices,” Proc. 2010 Int. Conf. on Body Sensor Networks (BSN 2010), Singapore, Sin- gapore, June 7-9. 2010, pp. 222 – 227, http://dx.doi.org/10.1109/BSN.2010.40 [7] M. Baldauf, S. Dustdar, and F. Rosenberg, “A survey on context- aware systems,” Int. J. of Ad Hoc and Ubiquitous Comput., vol. 2, pp. 263-277, 2007. http://dx.doi.org/10.1504/IJAHUC. 2007.014070 [8] D. Vouyioukas, and I. Maglogiannis, “Communication Issues in Pervasive Healthcare Systems and Applications,” Pervasive and Smart Technologies for Healthcare: Ubiquitous Methodologies and Tools, edited by Antonio Coronato and Giuseppe De Pietro, United States: IGI Global, pp. 197-227, 2010. http://dx.doi.org/10.4018/978-1-61520-765-7.ch010 [9] M. Ziefle, and C. Rocker, “Acceptance of pervasive healthcare systems: A comparison of different implementation concepts,” Proc. 4th Int. Conf. on Pervasive Comput. Technol. for Healthcare (PervasiveHealth), Munich, March 22-25. 2010, pp. 1-6, doi: http://dx.doi.org/10.4108/ICST.PERVASIVEHEALTH2010.8915 [10] A. J. Fraile, J. Bajo, and J. M. Corchado, “Context-aware and Home Care: Improving the quality of life for patients living at home,” Actas de los Talleres de las Jornadas de Ingenieríadel Software y Bases de Datos, vol. 3, pp. 102-111, 2009. [11] Tunstall Healthcare, “Assisted living,” [Online]. Available: http://www.tunstall.co.uk/what-we-do/assisted-living [12] Intel-GE Care Innovations, “QuietCare,” [Online]. Available: http://www.careinnovations.com/quietcare/ [13] J. E. Bardram, “Applications of context-aware computing in hospital work: examples and design principles,” Proc. 2004 ACM symp. on Applied comput., Nicosia, Cyprus, March 14-17. 2004, pp. 1574-1579. http://dx.doi.org/10.1145/967900.968215 [14] S. Mitchell, M. D. Spiteri, J. Bates, and G. Coulouris, “Context- aware multimedia computing in the intelligent hospital,” Proc. 9th workshop on ACM SIGOPS European workshop, Kolding, Den- mark, September 17-20. 2000, pp. 13-18. http://dx.doi.org/10.1145/566726.566730 [15] P. Hu, J. Indulska, and R. Robinson, “An Autonomic Context Management System for Pervasive Computing,” Proc. 6th of the Annu. IEEE Int. Conf. on Pervasive Comput. and Commun., Hong Kong, China, March 17-21. 2008, pp. 213-223, http://dx.doi.org/10.1109/PERCOM.2008.56 [16] Ubimon, Imperial College London, “UbiMon: Ubiquitous Moni- toring Environment for Wearable and Implantable Sensors,” 2004. [17] MobiHealth, European Commission,”News and Media: Overview Presentation,” 2004. [Online] Available: http://www.mobihealth.org [18] HealthService24, Ericsson Enterprise AB – project coordinator, “Publications,” 2006. [Online] Available: http://www.healthservice24.com [19] T. Falck, J. Espina, J.P. Ebert, and D. Dietterle, “BASUMA - The Sixth Sense for Chronically Ill Patients,” Proc. Int. Workshop on Wearable and Implantable Body Sensor Networks, April 3-5. 2006, pp.60-64, http://dx.doi.org/10.1109/BSN.2006.12 iJIM ‒ Volume 10, Issue 4, 2016 73 PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK [20] V. Shnayder, B. Chen, K. Lorincz, T. R. F. Fulford-Jones, S. Dawson-Haggerty, and M. Welsh, “CodeBlue: An Architecture for Medical Sensor Networks,” 2004. [21] U. Varshney, “Pervasive healthcare and wireless health monitor- ing,” Mobile Networks and Applications, Springer-Verlag, New York, vol. 12, pp. 113-127, 2007. [22] Center for technology and aging – CTA, “Technologies for remote patient monitoring for older adults (Position Paper),” 2010. [Online]. Available: http://www.phi.org/resources/ [23] M. Carmen Domingo, “A Context-Aware Service Architecture for the Integration of Body Sensor Networks and Social Networks through the IP Multimedia Subsystem”, IEEE Commun. Mag., vol. 50, pp.102-108, 2011, http://dx.doi.org/10.1109/MCOM. 2011.5681022 [24] F. Toutain, A. Bouabdallah, R. Zemek, and C. Daloz, “Interper- sonal Context-Aware Communication Services”, IEEE Commun. Mag., vol. 50, pp. 68-74, 2011, http://dx.doi.org/10.1109/MCOM. 2011.5681018 [25] Mithril, MIT University, 2003. [26] ActivePal, “PAL Technologies Products - activPAL™,” [Online]. Available: http://www.paltechnologies.com/ [27] P. H. Keckley, and M. Hoffmann, “Social Networks in Health Care: Communication, collaboration and insights,” Washington: Deloitte Center for Health Solutions, 2010. [28] PatientsLikeMe [Online]. Available: https://www.patientslikeme.com/ [29] MedHelp [Online]. Available: http://www.medhelp.org/ [30] E. Gasca, J. Favela, and M. Tentori, “Assisting Support Groups of Patients with Chronic Diseases through Persuasive Computing,” J. of Universal Comput. Sci., vol. 15, pp. 3081-3100, 2009. [31] D. López-de-Ipiña, I. Díaz-de-Sarralde, and J. García-Zubia, “An Ambient Assisted Living Platform Integrating RFID Data-on-Tag Care Annotations and Twitter,” J. of Universal Comput. Sci., vol. 16, pp. 1521-1538, 2010. [32] J. Rosenberg, “SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Ses- sion Initiation Protocol (SIP), RFC 6914”, Internet Eng. Task Force (IETF), 2013. [Online]. Available: https://tools.ietf.org/html/rfc6914 [33] Google, “Google Cloud Messaging: Overview,” [Online]. Availa- ble: https://developers.google.com/cloud-messaging/gcm [34] C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd ed., New Jersey: Prentice Hall, 2004. [35] I. Fette, and A. Melnikov, “The WebSocket Protocol, RFC 6455”, Internet Eng. Task Force (IETF), 2011. [Online]. Available: http://tools.ietf.org/html/rfc6455 [36] Polar Electro, WearLink (2016) Polar WearLink transmitter with Bluetooth, Available at: http://www.polar.com/en/products/accessories/Polar_WearLink_tr ansmitter_with_Bluetooth [37] Polar Electro, H7 (2016) Bluetooth Smart H7 heart rate sensor, Available at: http://www.polar.com/en/products/accessories/H7_heart_rate_sens or [38] Ithermometer (2016) Specification, Available at: http://www.ithermometer.info/specification.php [39] S. Vlajic, Projektovanje softvera (eng. Software design), Faculty of Organizational Sciences, Belgrade, Serbia: University Belgrade, 2009. AUTHORS Vanja Miskovic is with the Faculty of Information Technology, Slobomir P University, Bijeljina, 76 300, Bosnia and Herzegovina. Assistant Professor (e-mail: vanja.elcic@ gmail.com). Djordje Babic is with the School of Computing, Uni- versity Union, Belgrade, 11 000, Serbia. Associate profes- sor (e-mail: djbabic@raf.edu.rs). Submitted, 05 June 2016. Published as resubmitted by the authors on 29 September 2016. 74 http://www.i-jim.org iJIM – Vol. 10, No. 4, 2016 Pervasive Personal Healthcare Service Designed as Mobile Social Network