Design and Implementation of a Set-Top Box–Based Homecare System Using Hybrid Cloud

Abstract

Introduction: Telemedicine has become a prevalent topic in recent years, and several telemedicine systems have been proposed; however, such systems are an unsuitable fit for the daily requirements of users. Materials and Methods: The system proposed in this study was developed as a set-top box integrated with the Android™ (Google, Mountain View, CA) operating system to provide a convenient and user-friendly interface. The proposed system can assist with family healthcare management, telemedicine service delivery, and information exchange among hospitals. To manage the system, a novel type of hybrid cloud architecture was also developed. Results: Updated information is stored on a public cloud, enabling medical staff members to rapidly access information when diagnosing patients. In the long term, the stored data can be reduced to improve the efficiency of the database. Conclusions: The proposed design offers a robust architecture for storing data in a homecare system and can thus resolve network overload and congestion resulting from accumulating data, which are inherent problems in centralized architectures, thereby improving system efficiency.

Introduction

Storing large volumes of information is an emerging concern among medical service providers. Database efficiency is crucial for systems used for delivering services such as online data storage and online shopping. However, few studies examining homecare systems have focused on the efficiency of the entire system. In the present study, a system for storing medical data by using a combination of local and remote storage services was designed to reduce system loading.

Numerous studies have explored homecare systems that feature TVs and set-top boxes. Compared with personal computer (PC)-based¹ or mobile-based² systems, TV-based homecare systems are more user-friendly. However, few previous studies have discussed data storage designs and the problems associated with accumulating medical data over time. Given the increased amount of personal information stored in medical systems, methods for managing and analyzing big medical data have become an increasingly critical research topic in recent years, particularly because of advancements in medical technology and healthcare systems.³ Thus, solving the network-overloading problems that result from using big data is critical. To address these concerns, this study proposed a set-top-box–based homecare system and a novel type of hybrid cloud architecture.

Regarding data storage location, the systems examined in previous studies can be classified into the following three categories: (1) set-top box systems, (2) cloud-based systems, and (3) hybrid set-top box and cloud systems. The advantages and disadvantages of each system are discussed below.

In 2010, Lim et al.⁴ and Kuusik et al.⁵ proposed homecare systems based on a set-top box. The feature of these systems is that the medical information, such as blood pressure, weight, blood glucose levels, etc., was stored locally but not automatically transmitted to a remote cloud. An advantage of this type of architecture is that it provides adequate protection for personal privacy. However, such architectures create closed telemedicine systems because the limited interaction with medical staff makes it difficult for physicians to evaluate current developments in a patient's condition. Consequently, such systems are more suitable for personal measurement than for use in telemedicine.

Numerous studies^6–14 have researched systems that store data on a cloud instead of locally. Such systems update information immediately, thereby facilitating information exchange between medical staff and patients, which can assist physicians with diagnosing and managing their patients' conditions. However, despite this apparent convenience, data loss can occur when network failure occurs. Moreover, too many users retrieving medical data at the same time can cause network congestion and database overloading.

In 2012, Pan et al.¹⁵ stored data locally on a set-top box and remotely on a cloud server. The primary feature of this system is the local storage and set-top box, which duplicated the data and transferred them to a remote server. However, because this architecture stores redundant data (i.e., on the client and server sides), storage capacity becomes constrained by accumulating data over time. When the amount of data—particularly video and image data for monitoring patients—stored on a cloud server exceeds a certain limit, cloud overloading can occur.^16,17

To resolve the data overloading and network congestion problems reported by relevant studies, this study proposed a hybrid cloud system architecture comprising a set-top box and cloud system. The proposed system not only provides a friendly and interactive user interface, but it also resolves the problem of data overloading in homecare systems.

Materials and Methods

The proposed system was developed on a BeagleBoard-xM (BeagleBoard.org) integrated with the Android™ (Google, Mountain View, CA) operating system for the set-top box platform. The system receives vital signs from medical devices, such as sphygmomanometers and weighing scales, and stores these data locally on a secure digital card on the board. Figure 1 depicts the proposed system architecture. The subsequent sections discuss the hardware, software, and hybrid cloud architectures of this system.

Fig. 1.

Architecture of the proposed system. DTV, digital TV; HDMI, high-definition media interface; PC, personal computer; RFID, radiofrequency identification; BT, Bluetooth.

Hardware Design and Specification

On the client side, patients can operate the proposed system by using a remote control. Vital parameters are measured using medical devices and transmitted to the BeagleBoard-xM via Bluetooth^® (Bluetooth SIG, Kirkland, WA). To differentiate among family members, the system is activated by radiofrequency identification (ID) messages that identify individual family members using one system. On the server side, a PC was used as a remote server, housing the public cloud and hosting the Web server.

Software Architecture

The Android software application for the client side was written in Java, and the server-side application was scripted in hypertext preprocessor (PHP) and managed using MySQL. The data measurements were simultaneously stored on a private cloud database and transmitted to the public cloud. The public cloud first determines whether new information from the private cloud outdates the information stored on the public cloud by more than 30 days. Accordingly, outdated information is replaced. The rationale for setting the time frame at 30 days was based on discussions with physicians who expressed that they generally prefer to view the most recent monthly health information (e.g., weight and blood pressure) from their patients. By providing physicians with the option of selecting the frequency at which they receive patient data, the proposed system can reserve storage space for the latest data.

A security mechanism was also developed for storing personal information and vital data. As an example, Table 1 shows the data structure for a sphygmomanometer. In particular, using an ID number ensures that users are identified, thereby protecting their personal information when hospitals exchange medical information.

Table 1.

Data Format for a Sphygmomanometer Medical Record

ATTRIBUTE	SIZE (BYTES)
Identification	4
Date	3
Time	3
Blood pressure
Systolic	4
Diastolic	4
HR	4
Normal	1

HR, heart rate.

The operation of the back-end system in the public cloud is described as follows (Fig. 2 displays its functions). First, a user logs on to the back-end system through a browser, and the system authenticates the user's ID. Subsequently, patients and doctors can individually update and manage their personal information and relevant accounts. When an update is completed, new personal information is transmitted to the set-top box when the set-top box is next initiated, thereby synchronizing the client- and server-side systems. Patients can select which physicians are authorized to view their personal information, and they can manage their family information through the back-end system on the public cloud. Physicians can log on to the system to view their patients' health records, provide prescriptions, and remind patients about any upcoming outpatient treatments. This system facilitates both patient–physician communication and information exchange among hospitals because the data can be converted into XML format to be cross-platform compatible. Furthermore, this design resolves the privacy problem because patients can authorize which physicians may view their information.

Fig. 2.

Functions of the back-end management system.

Hybrid Cloud Architecture

This section describes the database design. The proposed hybrid architecture combines a local system and remote server to resolve the problem of data overloading. Previous studies have used similar architectures in the field of homecare. In 2014, Wang et al.¹ proposed an electrocardiograph monitoring system that featured a hybrid mobile cloud system that reduced the computational complexity for mobile devices by using public and private cloud systems. Yu et al.² proposed a distributed solution to reduce the amount of stored data and enhance the efficiency of cloud-based healthcare systems. The results of that study showed that combining two databases can enhance data retrieval and reduce loading, thereby improving system efficiency. Although the aforementioned studies were referenced and their hybrid architectures were adopted to design the storage center proposed by the current study, traditional hybrid cloud designs are typically focused on reducing only the system loading; however, storing duplicate information in two storage centers potentially wastes storage space.

To address this problem, this study used a cache to reserve frequently accessed data. Figure 3 depicts the design of the proposed hybrid cloud architecture. The most recent 30-day records are accessed more frequently than older information in general medical informatics systems; thus only these data were preserved on the remote server. If a user requests data from within the previous 30 days, then the data are retrieved from the public cloud (i.e., the remote server); otherwise, the data are retrieved from the private cloud (i.e., the local database).

Fig. 3.

If the medical records are older than 30 days, the Web page is generated using data from the private cloud only.

Regarding the hybrid architecture, a Web page is hosted on the public cloud. The user can request data from specific dates that are stored on the back-end system. Regarding the partitioning of data sources, the 30-day limit was set as the default threshold. In cases where a user or physician requests medical data from within the latest 30 days, the back-end system immediately retrieves the medical data from the database in the public cloud and displays the relevant information on the Web page. In cases where a user or physician request medical data from more than 30 days ago, the requested data are retrieved from the private cloud. For example, if a user requested blood pressure records from the previous year, the back-end system would access the stored data on the private cloud and display the requested information on the Web page.

This design can improve system performance and assist with managing big medical data. This cache design is aimed at preserving the most recent medical data, which are viewed the most frequently, in the public cloud to facilitate efficient access for both physicians and patients. Furthermore, reducing the number of stored medical records can reduce the required database bandwidth for the public cloud, thereby improving network performance when medical data are being retrieved.

Results and Discussion

System Evaluation

Several system evaluations were conducted to show that the performance of the proposed system is superior to those proposed in previous studies. The evaluations were conducted using a Toshiba (Tokyo, Japan) laptop (Windows^® [Microsoft, Redmond, WA] 7 Operating System, Core i5 2.5 GHz CPU, and 8 GB DRAM) as the public cloud. Apache was adopted to manage the Web server, and MySQL was used to manage the data storage center. First, the quantity of data was determined, and PHP was used to generate database content for simulating various conditions. Subsequently, the evaluations were conducted in three parts: (1) determine the time cost for the public cloud when patients and physicians access the back-end system; (2) calculate the storage increments of the public cloud corresponding to a specific time; and (3) determine the time cost for patients when they access their personal information or historical data, which was stored in video format. For these three evaluations, we used blood pressure records (Table 1) as test data because we had more blood pressure records than weight records.

The first and second experiments were conducted to evaluate the system performance based on the number of users (Fig. 4) and the temporal range of the data (Figs. 4 and 5). The first experiment was conducted to evaluate the access time for retrieving the data in the latest 30-day interval. User information was generated using ID numbers to represent each user. This experiment was conducted to test a user population comprising 1, 10, 100, 1,000, and 10,000 persons, and the temporal range of the data was set at 1, 3, 6, and 9 years, respectively. The results in Figure 4 show that the proposed system outperformed a centralized cloud system in all of the scenarios.

Fig. 4.

Comparison of access times based on the number of users and the temporal range of the data.

Fig. 5.

Comparison of storage capacity based on the number of users and the temporal range of the data.

In addition to access time, the storage capacity the various architectures was evaluated. For the second experiment, the capacity of the datasets shown in Figure 4 was calculated to be 23 bytes per blood pressure record, and the size of the individual databases was then calculated. Figure 5 shows that the proposed architecture required less storage space than the centralized architecture did.

The third experiment was conducted to evaluate the performance of the proposed client-side system. In this evaluation, the time users spent accessing their personal health records stored in video format was considered. The accumulated test data of 1,000 users for a period of 9 years were preserved in the database and prepared for testing. The access time for retrieving information from the database was determined based on how long a typical use would take to select and view a given medical record. The results in Figure 6 indicate that the proposed hybrid architecture has a lower time cost than the centralized architecture when the user viewed identical records.

Fig. 6.

Comparison of access time between the centralized system and the hybrid cloud system when using the set-top box to view medical records.

Discussion

The first and second evaluations showed that the hybrid architecture outperformed the centralized architecture and required less storage capacity (Figs. 4 and 5).

The third evaluation involved assessing the amount of time users required to access the system via the set-top box and view their medical information in video format. The results in Figure 6 show that the proposed hybrid architecture outperformed the centralized architecture. Regarding the hybrid architecture, the data queries were performed locally on the set-top box, which contained the data of users in a single family only. For the centralized architecture, certain data may need to be downloaded from the remote server, and querying the remote database would increase the time cost because it involves searching through a considerably larger database; thus, using the hybrid cloud architecture as the principal method of data storage improved the system performance and reduced the number of medical records stored in the database. For the sake of comparison, Table 2 lists the results for the local and centralized cloud systems used in related studies and those for the hybrid system proposed in the present study, demonstrating that the proposed hybrid architecture attained the optimal performance level. Although local storage architectures are private and secure, storing medical information locally can lead to difficulties in sharing medical records; consequently, using such systems in telemedicine would be untenable. Therefore, incorporating a cache design into the hybrid architecture can solve the problems associated with data capacity and access.

Table 2.

Comparison of Various Data Storage Architectures

CHARACTERIZATION	LOCAL4	CENTRALIZED9	HYBRID (PROPOSED)
Device	Set-top box
OS	Windows XP Service Pack 3	Linux-based OS	Android version 2.2
Data storage	Local	Remote	Local and remote
Security	High	Low	Normal
Privacy	Best	Poor	Normal
Immediacy	Very poor	Better	Better
Capacity of remote cloud	No	Large	Very small
Time cost for accessing latest information	Slow	Slow	Fast

OS, operating system.

Although the individual medical records were small, the performance difference between centralized cloud systems and the proposed hybrid cloud is clear. Moreover, the difference in efficiency becomes even clearer when data stored in video format are accessed. For example, Zhou et al.¹⁸ conducted an activity analysis by monitoring the indoor activities of people. The system involved using a camera to track a person's activity for a month (approximately 200 h), generating approximately 600 GB of video data. Given this amount of data, recording a person's daily activities for a year would generate approximately 7.2 TB of data when using the centralized cloud architecture. However, because the proposed hybrid architecture stores data on the server side only from the most recent 30 days, the difference in efficiency and capacity between these systems is apparent. In the future, experiments will be conducted to compare the proposed system with the centralized cloud system to demonstrate the benefits of using the proposed system to access video data.

This study involved designing a novel architecture for storing and managing medical data. A set-top box was used to test the proposed architecture. Certain concerns regarding this platform could be addressed as follows: (1) using Health Level Seven and XML formats to standardize information and exchange information among hospitals; (2) designing the system so that it can connect to additional medical devices via Bluetooth; (3) considering network traffic and the simultaneous use of several set-top boxes; and (4) approaching physicians and patients for them to use and evaluate the system and then improving the system based on their feedback. The aforementioned concerns and system functions are currently undergoing development in collaboration with physicians.

Conclusions

The proposed homecare system was designed based on hybrid cloud architecture. Several evaluations were conducted to demonstrate that the proposed system resolved the following problems associated with current telemedicine systems: (1) Systems using only local data storage do not provide immediate access to data and are effectively closed medical systems. (2) Centralized cloud architectures cause privacy and overloading problems. Because the proposed system used a public cloud acting as a cache, the load on the public cloud was reduced. (3) Using both public and private clouds may generate data redundancies and overloading, thus requiring a high storage capacity. In contrast to the amount of data stored in distributed architectures, minimal data are stored in the public cloud of the proposed system. Thus, the drawbacks of centralized cloud architectures were eliminated, expediting data queries in the proposed system. In addition, the proposed system provides a user-friendly interface and personal identity verification process, rendering it suitable for homecare applications. Furthermore, the back-end system facilitates exchanging information among hospitals, converting data into XML format, and completing forms when requested by medical staff. Thus, the proposed system based on hybrid cloud architecture is suitable for achieving the goals of homecare telemedicine.

Acknowledgments

This research was partly supported by the Ministry of Science and Technology in Taiwan (Republic of China) through grants MOST 103-2218-E-305-001 and MOST 103-2218-E-305-003. This research was also partly supported by Chi-Mei Medical Center, Tainan, Taiwan.

Disclosure Statement

No competing financial interests exist.