ISSN ONLINE(2320-9801) PRINT (2320-9798)

All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

Efficient Cloud Platform Providing an Omnipresent Healthcare Services

Kalaiprasath.R1, R. Udayakumar*2 and R. Elankavi3
  1. Research Scholar, Bharath University, Chennai, India
  2. Associate Professor, Department of Information Technology, Bharath University, Chennai, India
  3. Research Scholar, Bharath University, Chennai, India

  4. *Corresponding Author & Research Supervisor
Related article at Pubmed, Scholar Google

Visit for more related articles at International Journal of Innovative Research in Computer and Communication Engineering

Abstract

Health care is the diagnosis, treatment, and prevention of disease, illness, injury, and other physical and mental impairments in humans. Healthcare Services refers to the work of health care professionals who act as a first point of consultation for all patients within the health care system. Cloud computing owns the pervasive and on-demand service-oriented natures, which can fit the characteristics of health- care services. But in the case of general cloud, there arise few challenges which are providing persistent personalized service by keeping high concurrent online analysis to the public, and the abilities in dealing with multimodal, heterogeneous, and non-stationary physiological signals. In this paper, we proposed a private cloud platform architecture that consists of six layers according to the specific requirements with plug-in algorithm. This platform utilizes message queue as a cloud engine, and each layer thereby achieves relative independence by this loosely coupled means of communications with publish/subscribe mechanism. Also the massive semi-structure or unstructured medical data are accessed adaptively by this cloud architecture. This proposed cloud platform can be robust, stable, and satisfy the high concurrent requests from omnipresent healthcare services.

Keywords

Cloud computing, healthcare services, plug-in algorithm, ubiquitous.

INTRODUCTION

According to the World Health Organization report, the incidence of the suboptimal health status (SHS), which is also called “the third state” (between health and disease), accounts for 75% of the world population . Only in China, there are estimated 900 million people in such status . Some of them would pay close attention to their health hoping to get preventive health examination. Moreover, with the aging population growing, we also have to take measures to launch chronic disease surveillance for elder people. Therefore, to satisfy the demands of “SHS” groups and aging population, the healthcare system is proposed and becoming more and more popular, which can provide selfmonitoring of healthy status, early warning of disease, and even an instant report of the physiological signal analysis for individuals. Until now, such health monitoring systems have been widely implemented with traditional management information system (MIS) mode, which could no longer meet all the requirements of the healthcare system. For instance, Leel et al. propose a service-oriented architecture
(SOA)-based system to integrate the data from a personal health device and customize services for users, but somewhat lack concurrency and persistent service capabilities; Kulkarni and Ozturk developed a system named mPHASiS, which claims an end-to-end solution. However, it re- lies on the particular programming language, Java, which will result in less efficient of system due to the performance of Java virtual machine (JVM). Nowadays, as an emerging state-of-theart technology, cloud computing can provide pervasive, economical, and on-demand services for customers. Many pieces of research on medical information have been involved into the cloud recently. It can fulfil the flexibility and scalability of service-orientated systems, just like the healthcare system infrastructure should have, which is very different from the transaction-oriented MIS mode. Cloud computing inherited the features of high-performance parallel computing, distributed computing, and grid computing, as well as the further development of these techniques to achieve location transparency to enhance the user experiences over the Internet. More and more applications are migrated onto the cloud platform, which can provide services for various application scenarios. Such a platform generally comprises a number of diverse groups of components, no matter they are open source or not. Consequently, how to design a model with optional components to meet the needs of flexibility and scalability is one of the critical issue when constructing a cloud platform. In the case of the solution for this healthcare system, we presented a six-layer deployment architecture and proposed a message queue (MQ) as cloud engine as well as fundamental cloud storage based on the open-source components, which can be obtained freely and timely from Internet communities. Also, a plug-in algorithm framework was developed with pub- lish/subscribe mechanism to implement this healthcare system for the community people. The expandable feature of the pub- lish/subscribe communication model can meet the needs of a health cloud platform in high concurrent performance. Details about the implementation are depicted in Section III after the analysis of the practical requirements of healthcare in Section II. The results of performance test of the system are given in Section IV, and the Section V draws a conclusion and foresees the future work.

SYSTEM REQUIREMENTS ANALYSIS

A. Application Scenarios
This system is planned to serve hundreds of families residing in the city for health monitoring via Internet, and will sup- port thousands of potential customers including physicians and whoever care about health of themselves in the near future. So, higher concurrent transactions and shorter response time are the requirements to our system. Certainly, visualization of the results is also compute-intensive tasks usually with large- scale graphic drawing, which need to be stored and accessed in an efficient way to provide instant services to individuals. The multimodal and non-stationary characteristics of special med- ical signals, such as electrocardiogram (ECG), photoplethys- mograph (PPG), and electroencephalograph (EEG), are very trivial for storage and may lead to a synchronous problem on GlusterFS. Hence, these large numbers of semi-structured or unstructured health records, as well as companied with trivial files, are all adapted to NoSQL databases instead of traditional relational ones. These fundamental characteristics are very different from the features of grid computing which aimed at special applications and difficult to operate for unprofessional users (e.g., scientific exploration projects). Further- more, the method of service delivery is another important factor which affects the usability of the system. In addition to a mobile phone as an appropriate front-end device , TV set is another friendly interface for aging people. So, with the assistance of set-top box, services would be delivered through a TV cable ubiquitously.
B. Overview of the Data Flow
There are two main activities of users: upload the raw data and browse the results of diagnosis. Upload activities are di- vided into two steps: the first is to transmit physiological data, which are collected by sensors, to the gateway through short- distance transmission by a wired USB or a wireless Bluetooth. The second is to deliver the data from the gateway to the cloud servers through IP networks. Set-top box (for USB) and mo- bile phone (for Bluetooth) play the important role of gateway to relay data, respectively. We have developed three types of interfaces to users including TV cable, Wi-Fi/Ethernet, and cel- lular networks (2G/3G). All of these forms are interacted with cloud servers via Internet at the end. Browsing the results on a TV or a mobile phone is very straightforward. As aforemen- tioned, all of the physiological data should be collected in a distributed database cluster as the reservoir for data mining. Although the data may possibly be lost by accident (e.g., power failure) during operation, it must be restored from the databases in cloud. Therefore, to avoid a single point of failure, we utilize a primary/secondary scheme provided by a database to maintain enough replicas of data. Keep-alive mechanism is also adopted in this scheme and switch back and forth if the heart-beat signal is missing between primary ones and secondary ones. Fig. 1 shows the overview of our ubiquitous healthcare service system.

SYSTEM ARCHITECTURE AND IMPLEMENTATION

Considering the application requirements and the data of the inconsistent format, we improved our previous work and proposed a hybrid model which simplified the one derived from the National Institute of Standards and Technology (NIST) and Jericho models . Being everything can be treated as a service (XaaS) , we can also choose component as a ser- vice to take very efficient way to develop this specific private cloud architecture. The philosophy of this private healthcare cloud inherited the software as a service (SaaS) of the NIST model and introduced the insource/outsource concept into our cloud platform development. Outsource products include open- source components and commercial software, whereas the core data mining models are developed by ourselves as an insource product. The whole cloud platform comprised of several build- ing blocks according to functionality requirements. Fig. 2 shows the six-layer architecture of the healthcare cloud platform while each layer’s content and function are interpreted as follows.
1) Service interaction is a top layer where users can inter- operate with the terminals such as 3G mobile phone and set-top box, and browser on a computer, etc., to collect and upload original physiological data, as well as down- load the analysis results from the cloud servers.
2) Service presentation can be regarded as an interface with various kinds of services such as wireless application protocol (WAP), Web, image provider, etc. In addition, the node balancer also works on this layer, which can provide high concurrency capability. Some run-time information is also reserved at this level.
3) Session cache stores the user sessions on one hand, which maintains the authentication and certification status at the first time when the user accesses the services, i.e., service interaction through the presentation layer. On the other hand, memory cache is adopted to expedite the result data access. In fact, this session’s architecture is a big hashed key/value table.
4) Cloud engine is a dispatcher to cooperate the compo- nents with each other to make the cloud running by us- ing message-driven mode via MQ. The functionalities of the management for the queue are provided by this layer, which is regarded as a critical core for scheduling tasks.
5) Medical data mining is clusters of algorithms, including data pre-processing, data analysis, mining algorithms, and visualization processing. This layer can handle the data transmitted from the front end and generate the results back to database. Other algorithms can also be easily plugged in if needed.
6) Cloud storage provides data resources for the entire health cloud platform, including user information, vital signs, health records, and graphic data for processing. Physiological data collected from body area networks and massive graphic data for distributed processing of such data-intensive tasks are the primary contents. Using the distributed file storage system, like Hadoop Distributed File System with semistructural database, can provide more extensible and efficient access. Moreover, sharding is another major characteristic of this distributed database to gain higher availability. Redundancy among these pieces of shards and different views of the same data provide the consistency to a large extent. This mechanism can guarantee the integration of global data and transparency to users.
There are two key components addressed here: the first one is MQ, which is a kind of component that provides asynchronous communication protocol to achieve the independence between message sender and receiver. Queue is utilized for storing the event message generated by a sender (publisher), and all of the listeners (subscriber) who are interested in this kind of event can fetch this message to process a predefined routine. All commu- nication parties should follow the same protocol (e.g., advanced message queue protocol), and utilize available MQ application program interface fvto operate the queue. It is not necessary that two parties must know the existence of each other. After a message is inserted into a queue, it will be preserved and not deleted in the MQ until the corresponding subscriber reconnects to the system. Messages can be exchanged on the level of process, application, or even intercloud. Queue resides in cloud just as an engine to drive the system. Addition, different message head identifies the analysis algorithm and indicates the subsequent behaviours of cloud. The second one is the plug-in algorithm framework developed with respect to the extendibility of various services, which is based on the publish/subscribe mechanism to provide customized functions conveniently, not only for healthcare but also for other services. The whole system can reduce the module coupling by adopting this algorithm. For instance, various data mining algorithms, such as analysis of peripheral vascular function, instantaneous heart rate, and chaotic characteristics of power spectral density, etc., should be adopted to perform automatically according to different analyzed signals. Every different function can subscribe the different theme of mes- sage, which is classified by a message head. Accordingly, we designed an abstract core class named CoreStubClass, includ- ing a private attribute analysisKind, and an abstract method handleRequest(int). This class communicates with Message via MQ, and the other kinds of concrete implementation classes extended the CoreInterface, e.g., SignalFilterCore, ECGAnaly- sisCore, and other data mining classes. Fig. 3 shows the class framework of the plug-in algorithm.

TEST RESULTS AND ANALYSIS

As a result, Fig. 4 shows the upload interface on a TV while collecting user’s psychological signals for 2 min. Results of analysis are viewed by a Web browser as shown in Fig. 5, which can also been shown on a TV. To perform stress and load tests on our system, we designed two test cases to verify the capabilities of cloud platform: simulating initial 100 users for uploading activity lasting for 10 min, as well as 300 users for browsing lasting for 30 min. Table I shows the overall of the testing statis- tics. Use four servers with the same configuration (2.93-GHz Intel Xeon CPU with 4G RAM) as front-end clusters to provide visualization services under the Tsung testing environment. Tsung can generate many sessions and make concurrent requests to a server automatically. It starts with the initial user count and reports the performance in detail when testing is over. A new HTTP request generated within a given interval of 0.02 s repre- sents that a new user connection happened, and a session will be created according to the probability presented in the testing configuration file. The mean response time and count (for page, request, etc.) for the whole test are computed, which generated 16 3011 and 57 3683 concurrent requests for the two activities, respectively, as shown in Mean Time and Count columns. Re- sponse time less than 1s is tolerable for user experience. The actual number of concurrent users is nearly 30 000 during the experiment as the Users_count column of Table II shows. It is acceptable to us.By comparison, Table III shows the reading performance of Amazon’s simple storage service (S3) with different page sizes (writing data to S3 takes about three times as long as reading data) . Ignoring the slight differences of hardware, the us- ability of our system is satisfied in terms of Bandwidth, which is at least double of that in S3 (compare the last row of Table II with that of Table III). Response Time is also better obviously. Over- all, it demonstrates that this document-oriented cloud storage architecture is more appropriate for the environment of health- care services with a large number of trivial files, rather than nondocumentoriented ones such as S3. Furthermore, due to platform capabilities of linear extendibility, we simply increase the number of servers if there are more potential users’ requests in the future.

CONCLUSIONS

In this paper, we propose a six-layer architecture of the pri- vate cloud platform associated with the technologies such as MQ, load balance, plug-in algorithm, and cloud storage. This platform can manage the semistructure, unstructured, and het- erogeneous physiological signal data very well. Testing results show that it can cope with the issues about high concurrent re- quests in ubiquitous healthcare service and dispose of tasks for massive physiological signals analysis rapidly, as well as owning robust, instant, and efficient features. Particularly, it demands not much for hardware, and most of those integrated components such as NoSQL databases and MQ are open-sourced and free, whereas the commercial portfolio of software is always veryMexpensive. So, it is also an appropriate low-cost solution with respect to the effectiveness. In the future, we will further explore the security issues and add novel trustworthy module to protect user’s privacy.

Tables at a glance

Table icon Table icon Table icon
Table 1 Table 2 Table 3
 

Figures at a glance

Figure 1 Figure 2 Figure 3 Figure 4 Figure 5
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5
 

References