Keywords

1 Introduction

Advances in healthcare sector show that a shift from the established doctor-centric model to a patient-centric model to meet the rising demand for healthcare services of different population groups and at the same time to reduce the costs of delivering healthcare services is required. The vision of patient-centric model can be achieved integrating Ubiquitous Healthcare (UH) and the notion of personalization in healthcare services.

In the patient-centric model, UH is essential in order to provide effective treatment, disease prevention, proactive actions and life quality improvement at the right time, right place and right manner without limitations on time and location. The adoption of cloud computing technology can be the underlying technology for achieving UH in patient-centric model. Cloud computing, according to the National Institute of Standards and Technology (NIST) is defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [1]. Thus, cloud computing technology can enable the creation of the appropriate environment where efficient ubiquitous healthcare systems to be deployed.

The personalization of healthcare services plays a very important role to make the patient-centric model a reality. Personalization can be enabled making use of user profiles that store the preferences and the interests of the user as well as contextual and bio information related to the user. Recently, a number of personalized healthcare systems based on user profiles have been deployed. The deployment of personalized healthcare systems is based on profile management [2].

In this paper, we propose a profile management system in UH cloud computing environment. The main objective of the proposed profile management system is to increase the efficiency and the quality of the provided UH services exploiting the advantages of the cloud computing technology and the smart card technology. Furthermore, we propose generic healthcare profile structures that correspond to the main classes of the participating entities in a UH cloud computing environment. The profiles of the participating entities, which are based on the proposed five generic structures, are created and managed dynamically by the proposed profile management system [3, 4].

2 Related Work

Several platforms have been proposed that focus on cloud computing implemented in the healthcare domain. MoCAsH [5] is an infrastructure for assistive healthcare. It inherits the advantages of cloud computing and embraces concepts of mobile sensing, active sensor records, and collaborative planning.

In [6], McGregor presents Artemis Cloud, a cloud computing based Software-as-a-Service and Data-as-a-Service approach for the provision of remote real-time patient monitoring and support for clinical research. This research is demonstrated using a neonatal intensive care unit case study supporting clinical research for earlier onset detection of late onset neonatal sepsis. In [7] the active monitoring scheme is integrated with the cloud-based healthcare platform to provide the UH monitoring service. It investigates the approaches of patient monitoring and care under the cloud-based telecare system. By considering the scenarios for fixed and mobile users, the cost-effective health promoting methods are proposed and simple experiments are conducted to verify the effectiveness of the methods. Finally, in [8] Balboni et al. make analysis and recommendations in order the mobile cloud computing technologies to help the growth of the European eHealth Sector.

Personalization and user profile management holds the promise of improving the uptake of new technologies and allowing greater access to their benefits [2]. In a typical profile management scenario, there are multiple profile storage locations. Many of these locations will not store the total profile but only components that apply to a device, an application or a network/service function. Different locations may have different persistence and priority levels. Although the user profile data are distributed amongst a range of devices, applications and services, ideally, all profile data should always be available, overall networks, from all supported devices and services, including fixed and mobile services allowing service continuity and optimal user experience [2]. In [9], Sutterer et al. introduce a user profile management approach that provides means for managing and delivering context-dependent user profiles for several applications, decouples the application development from context processing taking into account the re-use and sharing of application-related user data between different applications in ubiquitous computing environments. In [10] a user profile management framework is proposed, in which the user’s desires, needs and preferences for services are managed through a wearable personal station, a terminal device worn by users. Finally, [11] presents a wider view of personalization and user profiles, making the preferences available to a range of services and devices. More specifically, this paper focuses on the architecture work within the standardization activities in the personalization and user profile management area performed at ETSI by the Specialist Task Force 342.

In [12], a smart card based healthcare information system is developed. The system uses smart card for personal identification and transfer of health data as well as provides data communication via a distributed protocol which is particularly developed for this study. Two smart card software modules are implemented that run on patient and healthcare professional smart cards, respectively. In addition to personal information, general health information about the patient is also loaded to patient smartcard. Healthcare providers use their own smart cards to be authenticated on the system and to access data on patient cards. System is developed on Java platform by using object oriented architecture and design patterns.

Finally, [13] combines benefits of Open Services Gateway Initiative (OSGi) and Smart card technologies in embedded devices for developing middleware application for home appliances. More specifically, it describes an electronic-prescription system currently under development for home-based telemedicine. It also notes aspects or bundles in OSGi, which is used, XML as a means of data storage format, smart card technology for storing and accessing patient prescription and personal information, and a wireless PDA interface for remote access to the home gateway (set-top box).

3 UH Domain

As Fengou et al. presented analytically in [15, 16], a UH domain (UH-domain) should be composed, at least, by the following classes of UH entities (UH-entities):

  • Patient, i.e. the receiver of healthcare personalized services. The health status of the patient is continuously monitored using real time collected contextual and bio information, which is gathered by wearable or implanted biosensors as well as by environmental arrays of sensors. Patient is considered as a user in the UH domain.

  • Healthcare Provider, can belong to one of the two main categories; Medical Professionals and Caregivers. The category of Medical Professionals includes medical doctors, nurses and other medical personnel that provide medical services in a systematic way to patient. The category of Caregivers consists of trainee persons (e.g. relatives, volunteers, etc.) with discrete roles at the healthcare provision to patients. Healthcare Provider is considered as a user in the UH domain.

  • Living Environment: The residence of patients that guarantees safe and qualified living conditions.

  • Working Environment: A place that allows patients to work safely through the control of critical environmental conditions.

  • Outdoor Environment: The city of residence or the country surrounding the patients.

  • Hospitalization Environment: The unit where the patients are hospitalized whenever they are in critical situation.

  • Vehicle: The transport means of the patients.

  • Alarm Center: A computerized office that collects alarm messages and activates health monitoring services, whenever the patients are in critical situation.

Based on the above, the UH-domain is modelled as following described.

The entity “patient” is the core UH-entity. The UH-domain should ensure continuous care to patients, through UH services (UH-services). A healthcare service is characterized as UH-service, if it is provided everywhere and always. Additionally, it is characterized as personalized if it is tailored upon patient’s therapeutic and monitoring medical protocols as well as patient’s preferences.

The health status of any patient is characterized by discrete states, such as normal, crisis, etc. Each state refers to a different range of bio-signal values and poses determinative considerations upon the type and the way of UH-service provision (global or personalized).

The daily activities of the patients take place in specific environments, such as mentioned above (living, working, outdoor, hospitalization and vehicle). Patients move between environments and perceive each environment through the collecting contextual information. The perception and sense of contextual information differs among patients, due to their different health status. For example, the same contextual parameters (humidity, noise, temperature, etc.) of an office may have different influence in the health status of two workers performing the same activities.

The “Alarm Centre” handles a pool of patients. It holds extended archives (case records) of them, and it is always aware about their health status, position and activities. An evaluation mechanism, inside the Alarm Centre, processes the acquired data per patient and estimates his/her health status. If the status is stable, no action is required. If the status changes towards a more precarious state, an alarm is set and a UH-service is activated. Providing of this UH-service must be continuous and independent of patient’s environmental conditions and activities.

The main aim of the Alarm Centre is to ensure the continuous and uninterrupted provision of UH-services. This is powerfully tied up with the “healthcare provider”. For this reason, beyond the serving patients, the Alarm Centre handles also a pool of healthcare providers. A subset of the them is always alert and hastens to help, whenever it is called by the Alarm Centre. Whenever an alarm is set, the Alarm Centre assess first properly the health state of the patient and then activates the appropriate sum of healthcare providers. During the provision of the UH-service, each healthcare provider plays a predetermined role. In this way, during the provision of a UH-service, different healthcare providers may be involved, each one playing a different role.

It is obvious that the provision of a UH-service is an application dependent task. By default, UH-service balances between the need for fast estimation of the patient’s situation, on one hand, and the fast selection and the high performance of the healthcare providers, on the other hand. Per case, the Alarm Centre must be flexible for:

  • assessing the collected information (bio/context);

  • monitoring the patient’s health status;

  • choosing, in each case, of the best healthcare providers;

  • accurate description of the healthcare providers’ attributes, such as skills, roles, preferences;

  • controlling and synchronizing of all entities involved in the provision of UH;

Traditionally in E-Health domain, the healthcare provision was based upon the medical information (e.g. symptoms, examinations, etc.) that was included in the electronic Medical Health Record (e-MHR). In the UH-domain however, the UH-service provision requires the dynamic manipulation of attributes of all UH-entities being involved. Therefore, we have set the following fundamentals:

  • each class of UH-entities is characterized by a dedicated profile’s structure;

  • each UH-entity is the occupant of a profile that contains a personalized group of attributes, such as identifiers (e.g. capabilities, skills, infrastructure, etc.), contextual information, groupware rules (e.g. costs, responsibilities, performance roles, etc.), behavioral descriptors (e.g. preferences, time scheduling, etc.), etc.;

  • common management tools are used for the creation, modification, and deletion of all classes of profiles;

  • common delivering facilities are used for communicating of profiles within the UH-domain;

3.1 Profile Management System in UH Cloud Computing Environment

The proposed profile management system is applied in a UH cloud computing environment for providing personalized healthcare services to patients. The UH cloud computing environment integrates a wide spectrum of the participating UH-entities of the UH-domain, such as patients, doctors, nurses, family members, hospitals, smart homes, offices and vehicles. The UH cloud computing environment, where the proposed profile management system is applied, is depicted in Fig. 1.

Fig. 1.
figure 1

UH cloud computing environment.

Full size image

Each participating UH-entity has its own profile that follows the structure corresponding to one of the proposed generic healthcare profile structures according to the main category to which the participating UH-entity belongs. Hence, the proposed profile management system makes use of the User Healthcare Profiles, Hospitalization Environment Profiles, Living Environment Profiles, Vehicle Profiles, Working Environment Profiles, Outdoor Environment Profiles and Alarm Center Profiles [35]. The data of each profile are stored in distributed databases in the UH cloud computing environment.

The infrastructure of the proposed profile management system, depicted in Fig. 2, includes a Profile Provider, a number of Service Providers and a Broker.

Fig. 2.
figure 2

Infrastructure of the proposed profile management system in UH cloud computing environment.

Full size image

Profile Provider: is the main entity of the proposed profile management system. It receives the profile data and dynamically integrates them in order to generate the user profile. When the user profile is created, it is stored in a User Profile Registry.

Service Provider: incorporates databases in the cloud computing environment containing profile data that are used for the creation of the user healthcare profile.

Broker: is the intermediate component between the user and the Service Provider as well as the user and the Profile Provider. The Broker possesses a catalogue with the URLs of all the Service Providers that have profile data that may be included in the profile. It also communicates with the Profile Provider who possesses the User Healthcare Profile Registry where the user profiles are formed and stored before sent to the user who has requested them. The Broker is part of the Profile Provider and its main objectives are to (a) manage the user’s requests, (b) gather the corresponding data from the Service Providers and (c) send them to the Profile Provider.

Each user makes use of their personal device (e.g. PDA) to communicate, to process their profile data and request a profile. In the personal device, an Agent is incorporated that communicates with the Broker in order to send the user’s requests and receive notifications. The personal device also includes a smart card. The smart card contains all the URL information pointing to the locations where the user’s profile data are hosted.

The proposed profile management system is deployed within the Service Providers and the Profile Provider. It manages three different cases: the creation of profile, the update of the profile (modification, deletion) and the profile extension. The key components of the proposed profile management system are:

Profile Editor: through the Profile Editor the user can make changes (insertion, modification and deletion) to his profile and alert the Personal Assistant Agent for these.

Context Information Agent: its function is related with the context of the user. For example, the Context Information Agent can collect the biosignals of the patient and alerts the Personal Assistant Agent when deterioration in the patient’s health condition is detected. Furthermore, the Context Information Agent can send the user’s current location.

Service Provider’s Agents: Each Service Provider contains the following agents: Processing Agent, Query Agent, Repository Agent, and Database Creation Agent.

Profile Provider: The Profile Provider contains the following agents: Processing Agent, Query Agent and Repository Agent.

The operation of the Agents as well as all the processes for the management of the profiles (creation, modification, deletion and extension) are analytically presented in [16].

4 Implementation

After comparing open source cloud computing platforms in order to select the most suitable platform for the deployment of the UH cloud computing environment, where the profile management system is applied., the Eucalyptus platform [14] was selected as the most appropriate platform to deploy our profile management system [16].

Figure 3 presents the proposed profile management system based on Eucalyptus architecture. The adopted hierarchical approach on the control and management is more reliable and reduces human intervention.

Fig. 3.
figure 3

The proposed profile management system based on the eucalyptus architecture.

Full size image

The main components within which profile management system is deployed are the Profile Provider and a number of Service Providers.

The Profile Provider has the Cloud Controller (CLC) and the Walrus as it is responsible to create the user profile and store it in a User Profile Registry respectively. CLC provides high-level management of the cloud resources, user accounts and client requests. It also provides a web interface for cloud management.

Walrus is the storage service which allows storing persistent data. It provides a bucket-based object store. It shares a Java-based database holding user account information with the CLC, and accesses metadata of buckets and objects similarly stored in databases. The storage space for buckets and objects is mapped to a single, non-shared file system directory mounted on the machine on which Walrus runs. In this file system the user profiles are stored. Both users outside the cloud and user applications running on compute nodes in the cloud upload and download data through the REST interface of Walrus.

The Cluster Network consists of many cloud nodes; in each cloud node there is the Service Provider containing specialized nodes to provide storage and management services. Each cloud node runs one or more virtual machine images, each equipped with at least one local disk to store the host OS and hypervisor software.

Each Service Provider has the Cluster Controller (CC) and the Storage Controller (SC) as it has databases in the cloud containing profile data that are used for the creation of the user profile.

CC is the front-end for each cluster defined in the cloud and is responsible for managing the entire virtual instance network controlling specific VM instances. The CC maintains all the information about the NC that is grouped in the cluster. It performs per cluster scheduling and networking. It gathers information from each NC and schedules client requests to individual NCs. The CC is in the same Ethernet broadcast domain as the nodes it manages.

SC provides block storage services. Τhe data storage service, is responsible to manipulate VM images delivering them to NCs when a client instantiates a VM. It is particularly suited as it supplies database, file system, or access to raw block level storage.

The Private Network of each Service Provider contains a pool of physical computers that provide generic computation resources to the cluster and a number of NCs in each of these machines.

NC is responsible for fetching VM images, starting and terminating their execution and managing the virtual network endpoint. NC communicates with the OS and the hypervisor running on the node on one side and the CC on the other side. NC requests the Operating System running on the node to find out the node’s physical resources, the size of memory, the number of cores, the disk space available. It also learns about the state of VM instances running on the node and broadcasts this data up to the CC. It controls the hypervisor on each compute node configuring it, sets up VMs on it and hosts OS as directed by the CC. It executes in the host domain (in KVM) or driver domain (in Xen).

5 Conclusions

In this paper, we have proposed a profile management system in a UH cloud computing environment. It aims to increase the quality and the efficiency of the provided UH services exploiting the advantages of the cloud computing technology, the smart card technology and the notion of user profile in the context of the patient-centric model. Furthermore, we have proposed generic profile structures corresponding to the main classes of the participating entities in the UH cloud computing environment.

The profile management system that we propose in this paper is focused only on User Healthcare Profiles (i.e. Patients and Healthcare providers). We intend to continue our research in this direction in order to deploy a profile management system incorporating the profiles of all possible participating entities in a UH cloud computing environment. Thus, as future work, we plan to implement a profile management system integrating the creation and management of User Healthcare Profiles, Hospitalization Environment Profiles, Living Environment Profiles, Vehicle Profiles, Working Environment Profiles, Outdoor Environment Profiles and Alarm Center Profiles.