Pervasive Personal Healthcare Service Designed as Mobile Social Network

—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 architecture of the pervasive personal healthcare service which is based on the existing technologies available to almost every-one. Along with the conventional request-response synchronous communication, the proposed system features 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 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 consisting 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 scenarios that clarify the required functions and present conclusions based on the system test.


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 diseases, 600 million are of age 60 or older and even 75-85% of the healthcare spending goes to chronic health management. 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 process, 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 networks, Wi-Fi networks and wireless personal area networks (WPANs).
From patients to medical personnel, the healthcare system consists of the next components: 1. WPANs, which in the case of wearable or implantable 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 Device 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 technology companies. Procedures for the data exchange between medical devices and data formats for different types of medical devices (Pulse Oximeter, Thermometer, Weighing 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 manufacturer has its own exchange procedures and data formats. The main advantage of HDP is the fact that all of its different 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 approach introduces a layered architecture with the intention of hiding low-level sensing details [7]. 4. Technologies for data transmission, sharing and storage on central servers are widely versatile, but they need to provide: request-response synchronous and storeforward 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 (control of data transmission) and communication comfort. It seems that people have an unspecific uneasy feeling and concerns about data security and loss of control. The various applications of monitoring patients can be divided among the following categories: prevention, healthcare maintenance and examinations, home care (assisted living) [10][11][12]; intelligent hospital [13][14]; incidence detection, emergency intervention [15]; and pervasive healthcare applications [16][17][18][19][20][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 postoperative 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 introduce appropriate treatment and thereby avoid health deterioration. 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 quality, 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 workstation (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 analysis. Further examples of similar projects are MobiHealth, European Commission [17] and HealthService24, Ericsson 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 transferring vital signs to the health care providers has been presented 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 Technologies [26], Tunstall's ADLife -Tunstall Healthcare [11] and QuietCare -Intel-GE Care Innovations [12] system.
Social networking is to the current era what online access was just 20 years ago -a transformational change in how information is accessed and shared [27]. Public, Internet-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 networks 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]. Social 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 system 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 architecture 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 features asynchronous communication based on the publishsubscribe-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-subscribenotify 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-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 sensor devices is based on Bluetooth. Along with the conventional 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 Android (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 system 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 architecture and explain in details the most important use cases implemented within the proposed mobile application. 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 relationship. 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 Multimedia Subsystems (IMSs). The aforementioned model is adopted for the proposed system for monitoring of patients 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 subscribes 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 authorized watchers in the form of notification following publish -notify principle. In order to avoid sending many messages, it is better to notify an observer by producing an alarm only if the data is to be considered. It is also possible 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 (request-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. 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 Websocket protocol [35] which enables a full-duplex communication between client and server over single TCP connection. 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 platforms have support for its current specifications. However, 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 components: 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 application, and 3. the third component is the GCM server responsible for sending messages to mobile devices. The application server is developed using one of the existing technologies. In this contribution, we use the PHP server with compatible MySQL database. When one registers to use the GCM services then he or she receives sender 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 registration ID is sent as additional information to the PHP server, as illustrated in Fig. 3 with arrow 3. If the user is successfully 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-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. 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 asynchronous 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 messages 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 estimate the patient's condition, the alarm event will be implemented, too.
For the acquisition of vital signs, a mobile device communicates 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 Bluetooth 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 standardized, 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, whereas BLE HDP solves this problem and other requirements of sensor communication. Current Android versions implement 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 actively participates in this process only if he/she wants to manually send data and while he/she is choosing the sensors. In this way, the patient is not disturbed by this process and the patient can decide whether to send the sensor data. According to Larman's method for software development, the system requirements are described by using Unified Modeling Language -UML Use-Case Model. The obtained architecture is the three-tier architecture composed 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 operations) 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 calling 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 results 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-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 synchronization in the background. The notification system, which is the component of the Android OS, gives us the information 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 network for packet data transmission; • Mobile phone should be registered into a Google account, if the version of Android is less than 4.0.4; • Sensors must be turned on for the purpose of collecting 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 patients, 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 sequence 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 functions that depend on the GCM service.

) Use Case 1 (UC1): User registration
Name of UC1 is User registration. The UC1 has the following 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 account 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 button (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.

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 selection 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 server 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 displayed 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: 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 calendar, in addition enters a number of days for the overview, 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 aggregation by hours, then the application activates the input field for number of days, respectively, if one chooses minutes or seconds, the application activates the input 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 message 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).

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 patient.
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 patient (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 message 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 application 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 patients 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. 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 enters the message and confirms it. After login, the patient receives the message. This is an event that requires asynchronous 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 consists 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); 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 success 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 following 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 sensors 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 application 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 dedicated 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 protect 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. Three categories of patients were selected for testing the proposed system for healthcare monitoring. We selected 4 patients for each category. The first category consisted of elderly people of age of 60 or older. The second category consisted of patients that need periodical monitoring (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 bedtime).
They could use option for manual data sending, as well. The third category was supposed to constantly carry sensors 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 performed. 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. PAPER PERVASIVE PERSONAL HEALTHCARE SERVICE DESIGNED AS MOBILE SOCIAL NETWORK

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, monitor 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 continuously monitored complains about the inconvenience of wearing sensors constantly. The category of elderly patients 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.