Dynamic Integration of Mobile JXTA with Cloud Computing for Emergency Rural Public Health Care.

OBJECTIVES: The existing processes of health care systems where data collection requires a great deal of labor with high-end tasks to retrieve and analyze information, are usually slow, tedious, and error prone, which restrains their clinical diagnostic and monitoring capabilities. Research is now focused on integrating cloud services with P2P JXTA to identify systematic dynamic process for emergency health care systems. The proposal is based on the concepts of a community cloud for preventative medicine, to help promote a healthy rural community. We investigate the approaches of patient health monitoring, emergency care, and an ambulance alert alarm (AAA) under mobile cloud-based telecare or community cloud controller systems.
METHODS: Considering permanent mobile users, an efficient health promotion method is proposed. Experiments were conducted to verify the effectiveness of the method. The performance was evaluated from September 2011 to July 2012. A total of 1,856,454 cases were transported and referred to hospital, identified with health problems, and were monitored. We selected all the peer groups and the control server N0 which controls N1, N2, and N3 proxied peer groups. The hospital cloud controller maintains the database of the patients through a JXTA network.
RESULTS: Among 1,856,454 transported cases with beneficiaries of 1,712,877 cases there were 1,662,834 lives saved and 8,500 cases transported per day with 104,530 transported cases found to be registered in a JXTA network.
CONCLUSION: The registered case histories were referred from the Hospital community cloud (HCC). SMS messages were sent from node N0 to the relay peers which connected to the N1, N2, and N3 nodes, controlled by the cloud controller through a JXTA network.

Introduction

At present the treatment methods for an accident case are as follows: the hospital admitting the patient should provide all the necessary basic tests which would be required for treating the patient, such as blood group, hemoglobin, etc.; however, these are time consuming when it comes to an emergency case. Assuming the patient record is already available in one hospital and the patient is taken to a specialist hospital due to a specific accident, is a scenario where the data transfer would be time consuming and the facility should be there whereby doctors can communicate with each other. Treatment would be more effective and efficient if the patient's history is known to the doctor when the patient presents as an emergency. This paper thus proposes a system which would help health institutions to promote and deliver a more effective emergency service, whereby the hospitals share a common database through cloud service technology. The proposal combines the feature of cloud services and peer-to-peer (P2P) networks that use JXTA for communication between a hospital's database and the next point (e.g. the ambulance) that is bringing the patient to hospital. The mobile P2P concept has recently attracted attention and is an area which could be targeted to improve marketing and interact personally with consumers/service users. Thus it has gained popularity and consumers are more satisfied with these types of services. P2P can be visualized as a host-to-host concept, where the client server architecture is overridden. A peer is simply an electronic device that is capable of network participation such as a mobile, computer, or laptop, that can communicate and share their contents among themselves within a group. Each device should be able to access the resources of any other device on the network while making its own resources available to others. JXTA is a platform specification developed by Apache open source model by Sun Microsystems (Santa Clara, California, USA) under the direction of Bill Joy and Mike Clary. The goals of the platform include the following:

Peers should be able to discover one another

Peers should self-organize into peer groups

Peers should advertise and discover network resources

Peers should communicate with one another

Peers should monitor one another

The platform should not require use of any particular

Authentication, security or encryption model

Computer language or operating system

Network transport or topology

JXTA services are handled by six protocols which are used to model the entire JXTA system. The protocols are: (1) Peer Resolver Protocol (PRP) which is used to send a query to any number of peers and to receive response from them. (2) Peer Discovery Protocol (PDP) which is used to advertise about its own resource and discover other available resources. (3) Peer Information Protocol (PIP) which is used to determine the current status of a peer. (4) Pipe Binding Protocol (PBP) which is used to create a communication path between peers. (5) Peer Endpoint Protocol (PEP) which is used to find the path from one peer to another peer. (6) Rendezvous Protocol (RVP) which is used to propagate messages within the peer network. Existing P2P models used to share and search over the Internet can be characterized as a distributed network system in which all the participating nodes have symmetric capabilities and responsibilities. All participants in a P2P system act as both clients and servers to one another, as mentioned earlier, surpassing the conventional client/server model and bringing all participants together with the purpose of sharing resources such as patient details, patient records, and past medical history. In a P2P JXTA network, the sharing systems set up a network or pool of peers on the Internet and provide facilities for searching and transferring data between them.

JXTA enables interoperable P2P mobile cloud applications that:

Finds other peers on the network with dynamic discovery

Allows file sharing across the JXTA network

Allows creation of a peer group

Allows the cloud controller to remotely monitor peer activities

Ensures secure communication with peers in the JXTA network.

Proxied peers

Proxied peers connect to a JXTA network through relay peers. Customer's mobile nodes which have less capability and limited resources connect to the JXTA network with the help of relays. The relay peers represent the hospital, blood bank, and the patient's relatives. Relay peers help proxied peers in the following ways:

By listening and responding to the message.

By storing the message for the proxied peers

By translation of the message, so the proxied peers can understand it.

Proxyless peers

Ambulance nodes are the peers which are directly connected to the JXTA network. No relay peer is required. These peers perform input–output TCP communication through the pipe.

Cloud computing

Cloud computing plays an important transition and paradigm shift in health care services. Surveys have shown it can be used for key technologies, partition offloading and context-based services. It provides a computing paradigm that enables shared information of virtual, dynamically configurable, and managed health care resources to be delivered on demand to doctors over JXTA GPRS and other available networks. The advances in technologies of mobile cloud computing has become integrated into the fabric of our everyday life. With increased mobility, users need to run stand-alone and/or access remote mobile applications on mobile devices. The information available in the “Cloud” can be processed by a cloud controller. Hence patient data are distributed among medical staff. Cloud mobile emergency management is an upcoming and a most necessary concept for the present and future. This paper integrates the concepts of a JXTA network and a cloud database. The former is used for communication between the nurse who attends the patient in the ambulance and the doctor available in the selected hospital, where both ends have a JXTA-installed handheld device (e.g. a laptop or mobile phone). The nurse and the doctor will have a unique ID during their communication. The peers are not required to remain on the JXTA network for any specified period. Peers using the services cannot be guaranteed that a peer will remain on the network until its services are no longer needed, and hence the doctor can any time leave the network once the patient has reached the destination. The cloud database is used to store, maintain, and retrieve the patient's information across several hospital databases which are administered and controlled by a cloud controller (which also controls the ambulance).

Materials and methods

Literature review

In this study, the authors deal with wireless health care monitoring solutions based on secure technology in a hospital context. Radio frequency (RF) networks can present electromagnetic disturbances in hospital environments. Therefore we have investigated an alternative solution based on infrared (IR) technology. As patient movement is inevitable, the focus is on mobile IR communications considering line-of-sight (LOS) propagation between the transmitters coupled with medical sensors and the receiver. The authors study different mobility scenarios, one in two dimensions (2D) for a fixed transmitter height and another in three dimensions (3D) by considering transmitter height variations. In each case, they analyze the distributions of channel gain to find the statistical model of the mobile IR channel for a given distribution of the patient locations within the room (uniform or Gaussian). Mobility on data rates and quality of service needed for this application in the case of an on–off keying (OOK) modulation before concluding on the reliability of the studied mobile health care monitoring system [1]. Patients are monitored remotely and diagnose the patients condition. This is possible thanks to the low cost facility to exchange data through the web (Cloud) with data processing servers. One concept that has been developed is to monitor, record, and analyze a patient's heart rate through a digital stethoscope. The design enables a physician to develop customized analysis and monitoring to collect key indicators or to set alerts without a need for infrastructure implementation to store or transfer the data [2]. MedBook provides patients, health care providers, and health care users a platform for exchange of information about electronic patients record (EHR), billing activities, and benefits inquiries. Software-as-a-Service (SaaS) is an application built on top of open source technologies and running on an Infrastructure-as-a- Service platform. The client applications are mobile apps run from iPhone and iPad devices (Apple Inc., Cupertino, CA, USA) [3]. Alert management mechanisms have been included in back-end health care centers to initiate various strategies for automatic emergency alerts after receiving emergency messages or after automatically recognizing emergency messages [4]. The privacy and security issues which are essential in e-health care systems are covered using these devices. Design challenges in the fulfillment of conflicting goals are given by an example scenario, where a wireless body sensor network is leveraged, and a sound solution is proposed to overcome the conflict [5]. This is an analysis of energy consumption in cloud computing. The analysis considers both public and private clouds, and includes energy consumption in switching and transmission as well as data processing and data storage. Energy consumption in transport and switching can be a significant percentage of total energy consumption in cloud computing. Cloud computing can enable more energy-efficient use of computing power, especially when the computing tasks are of low intensity or infrequent. Cloud computing can consume more energy than conventional computing where each user performs all computing on their own personal computer (PC) [6]. Mobile Cloud Computing integrates the cloud computing into the mobile environment and overcomes obstacles related to the performance which includes battery life, storage, and bandwidth, environment (e.g., heterogeneity, scalability, and availability), and security (e.g., reliability and privacy) [7]. Single- and multi-cloud security addresses possible solutions. The use of multi-cloud providers to maintain security has received less attention from the research community than the use of single clouds. This work aims to promote the use of multi-clouds due to their ability to reduce security risks that affect the cloud computing users [8]. Emergency medical transportation is guided by the criteria and protocols provided by regulatory authorities, e.g. Spain's Emergency Medical Service (SEM). According to the SEM criteria, patients receive a transportation priority, with “0” being the highest. Each priority level requires an ambulance to arrive at the patient's location within a particular response time. Lower-priority patients and higher-priority patients are assessed [9]. A review of recent e-emergency systems included wireless technologies used, as well as the data transmitted (electronic patient record, bio-signals, medical images, and video, subject video, etc.). Furthermore, emerging wireless video systems for reliable communications in these applications are presented. Anticipating health e-emergency systems will significantly affect the delivery of health care; however, their exploitation in daily practice still remains to be achieved [10].

High levels of security and privacy within a cloud environment are important when enabling sharing health records and access rights along the patient pathway. One study has helped in evaluating and demonstrating the usefulness of a cloud-based integrated health care system [11]. Cloud Computing protocol management model provides multimedia sensor signal processing & security as a service to mobile devices. The approach suggests multimedia data and security operations can be performed in the cloud, allowing mobile health service providers to subscribe and extend the capabilities of their mobile health applications beyond the existing mobile device limitations [12]. A cloud computing protocol management model is intended to provide multimedia sensor signal processing and security as a service to mobile devices. Multimedia and security operations can be performed in the Cloud, allowing mobile health service providers to subscribe and extend the capabilities of their mobile health applications beyond the existing mobile device limitations [13]. A comparative performance analysis was validated in two experimental m-health test bed systems for both mobile WiMAX and HSUPA networks. The experimental results have shown an improved performance of mobile WiMAX compared to the HSUPA using the same cross-layer optimization approach [14]. Some of the challenges and future implementation issues from the evolved m-health perspective. It will also present some of the concepts that can go beyond the traditional “m-health ecosystem” of the existing systems illustrating the multidisciplinary nature of this important and emerging health care delivery concept [15]. A privacy-preserving emergency call scheme (PEC), enables patients in life-threatening emergencies to quickly and accurately transmit emergency data to the nearby helpers via mobile health care social networks (MHSNs). Once an emergency happens, the personal digital assistant (PDA) of the patient runs the PEC to collect the emergency data including the location of the emergency, the patient's health records, as well as data regarding the patient's physiological condition [16]. With regard to the health care industry and their underlying link technologies, the BlackBerry platform (BlackBerry Limited, Canada) and its associated infrastructure (i.e., BlackBerry Enterprise Server) is a logical and practical solution for eHealth, mHealth, sensor and machine-to-machine (M2M) deployments [17].

Mobile cloud JXTA network architecture

Mobile devices and PDAs play an important role in health care, and are becoming the norm where people are more dependent on handheld devices. As people become more health conscious this has led to the growth of such mobile applications ensuring and enabling better patient care by the hospitals. This architecture is only for patients who are registered users, whereby his/her information will be stored in any one of the hospital databases which will be referred as the “Hospital community cloud” throughout this paper. Each Hospital community cloud is controlled by a cloud controller. Firstly, the cloud controller is responsible for retrieval of patient information and sending it to the nurse in the ambulance. Secondly it suggests the nearest appropriate specialized hospital within the accident area where the patient should be taken to; for example if a patient had a leg fracture, he/she would be taken to an ortho specialist for treatment. The cloud controller also plays a vital role in identifying the hospital of specialization. The cloud controller also manages and controls the communication between the ambulance and itself. The following figure summarizes the activities that take place in such an emergency situation. The process that takes place will be explained in the forthcoming section “Work at ambulance”.

Work at ambulance

This section explains the scenario that takes place within the ambulance. Node 0, Node 1, Node 2, and Node 3 are the peers in the architecture that are mentioned in Figure 1.

Figure 1

JXTA network architecture.

Node 0 is the nurse peer group within the ambulance.

Node 1 is a peer group within which there are three other groups and they are as follows: 1.1 is the peer group of doctors working in the hospital1.2 is a group of specialized doctors for the purpose of emergency consultation1.3 is a peer group of nurses for assistance who may called to the required hospital as and when needed.

Node 2 is a peer group of blood banks.

(Note: the Peer group at Node 1 can communicate with the Peer group at Node 2 and vice versa)

Node 3 is a peer group of a list of relatives retrieved from the Hospital community cloud.

When the patient is taken inside the ambulance, the nurse identifies the patient details with the help of Node 0 that communicates to the Hospital community cloud via the cloud controller he/she belongs to. Depending on the patient status he/she will be taken to the nearest appropriate specialized hospital and the available doctor, both of which are identified with the help of Node 0. The shortest path will be found using a GPRS-enabled device fixed near the driver seat of the ambulance. A movable camera can capture the image of the patient and sent to the doctors peer group. Node 0 immediately sends messages to the doctor peer group Node 1.1, and the specialized doctors in the peer group Node 1.2 can be contacted by doctors at Node 1.1 for any first aid to be given to the patient. Depending on the status of the patient the doctors in the peer groups 1.1 and 1.2 may send first aid messages to the nurse who is in the ambulance. In the case of heavy blood loss or if surgery is required the doctor in peer group 1.1 may suggest the number of units of blood required to treat the patient and send a message to Node 2. Then Node 1 communicates to the Node 3 peer group (the patient's relatives) about the accident, based on the data available in the Hospital cloud community. Figure 2 shows the internal view of the ambulance.

Figure 2

Internal view of ambulance.

Emergency care in the ambulance

The internal view of the ambulance and the work done in the ambulance is represented in Figure 3, with different nodes. The standard model of an ambulance includes the patient's berth, space for a nurse, first aid, a life support system, a fire extinguisher, and the driver's area. A proposed model in Figure 4 with a JXTA networked mobile device or a laptop is included with an operator, a movable camera, and speakers. The mobile or laptop in the ambulance will be at node N0 (i.e. operator) in the JXTA network. The laptop at Node 0 will establish the connection with the doctor peer group (Node 1), blood bank peer group (Node 1) and relative peer group (Node 3). The current information and condition of the patient will be instantly sent to Node 1. In the case of injury where is excess blood loss, or surgery is required, the information will also be sent to Node 2. Node 0 communicates to Node 3 about the accident to the patient's relatives, with the help of data available in the Hospital community cloud. In the case of pregnancy, accidents, or depending on emergency status, movable cameras could be used to start a video conference so that doctor can see the current situation of the patient and instruct the nurse regarding taking necessary steps to control the situation until the ambulance reaches the hospital (communication between Node 1 and Node 0) (Figure 4).

Figure 3

Ambulance connecting nodes.

Figure 4

Ambulance alert alarm.

Algorithms implemented for the activities:

Electronic patient health record

For each person who visits a physician, a record is created through JXTA in a database. Data from different professionals are linked together to obtain a complete data set. Data records from laboratories, hospitals, and pharmacies are obtained with either of the following methods of identification: mobile number, SSN and/or reference ID. A family physician maintains the record set on an individual so the data transfer is easy and avoids a long time delay. Health professionals form a peer group and can select the type of data available online, as well as confidential data. Direct downloads are possible from central cloud servers, which store the data.

Ambulance alert alarm

Ambulance alert alarms (AAAs) are placed on all the traffic lights in the city, or in case of rural areas, they are spaced every 5 km. At Node N0 the operator finds a path to the nearest hospital and fixes the location on the map and relays it to the driver's cabin. The activated JXTA or GPRS network message is passed by the operator at Node 0. An alert signal or command is passed to the nearest or first set of traffic lights which will alert the traffic about the ambulance approaching, and paves the way for the ambulance to pass. The signal or command will then be passed on to the second or next set of traffic lights and the process continues until the ambulance reaches the hospital, which reduces the time delay to an appreciable extent.

Results

Implementation details

We developed a Cloud mobile JXTA emergency application and a server architecture test bed to simulate a proposed solution, prove its feasibility, and evaluate its performance. Implementation was done with Zend studio (Santa Clara, CA, USA) 10.0.0 with phpcloud for designing a Hospital community cloud. A cloud controller with Datacenter1 and Datacenter2 were administrators in the cloud. For development of the JXTA mobile application we used a Java SE (Sun Microsystems in 2001) environment and JXTA Shell. The main reasons for choosing the JXTA Shell as Mobile developer platform for the application were because it is compatible with Java code and can be widely implemented on almost all mobile Android and Windows platforms, it can process data locally on a mobile device and reduce network traffic, and can implement flexible applications. A Mobile Information Device on the ambulance at Node 0 supports the creation and use of a JXTA Cloud connection and enables mobile application signing. The ambulance node is divided into four zones through the JXTA network: (1) the ambulance alert alarm (AAA), (2) hospital which includes the doctor peer group, specialized doctors and nurses peer group, (3) blood bank peer group, and (4) the relatives peer group. The cloud controller performs authentication of the user for the access gateway, the same role as described before for all mobile users.

Cloud set-up and server configuration

Creating an account with phpcloud.com

Create cloud container (cloud health care)

Download access private key

Install Zend studio 10.0.0 version

Database configuration

Each application container is provided with a database record that can be used as back-end storage for PHP applications. The database record is fully compatible with MySQL 5.1, and we can create multiple tables within the one schema (database) provided to us. From within the PHP code, you can access the database using one of PHP's MySQL interfaces (MySQL, mysqli, or PDO_MYSQL), or of course using Zend_Db with one of the PDO_MYSQL or MySQLi adapters. Assuming our container name is my container, you should use the following credentials to connect to the database (Figures 5–7):

Database host: mycontainer-db.my.phpcloud.com

Database port: 3306

Database schema name: my container

Database user: my container

Database password: our container password

The Hospital community cloud can be accessed from the webpage http://cloudhealthcare.my.phpcloud.com/hospital/index.html

The proxy server is implemented on a WAMP server and is used as a proxy in communication with the cloud. The authentication server represents the CC in our test environment. Because the patients' information is registered and implemented in the Cloud environment there is no need to make an additional manual document with a third party entity regarding patient record functionality. In our test bed we developed a proxy application server in a Cloud JXTA platform and deployed it with phpcloud and ZendStudio on a WAMP server.

Performance analysis

In the financial year 2012–13 under the Tamilnadu Health system project 108 emergency ambulance services, we examined the weekly performance reports as a starting point for our proposed system.

From the study, Figure 8 shows the time spent in various states such as connection time, secure socket layer (SSL), waiting time, domain name server (DNS) time, receive time, and send time. This was obtained online during testing of the application performance on tools.pingdom.com. Figure 9 compares the time spent per domain, e.g. on my.phpcloud.com (this is the cloud application container), s3.amazonaws.com, and Google etc. It shows the page size with respect to the request count of that page throughout the user log session in the academic cloud ecosystem (Figure 10). Table 1 shows the weekly report on 108 ambulance services and Table 2 shows the budget allotted in the financial year.

Figure 8

Time spent to connect.

Figure 9

Php cloud vs. other domains.

Figure 10

Indicates different stages of request.

Table 1

Tamil Nadu Health Systems Project, 108 – Emergency Ambulance Services. Weekly Performance Report

SI. No.	Details	Performance
		During FY 2012-2013	From Sep 15, 2008 to Jun 24, 2012
1	Number of Districts covered under 108 Services	32
2	Total no. of Vehicles on road	470
3	Total Number of Medical Emergency Calls	160,745	1,856,454
4	Total Number of Beneficiaries	129,034	1,512,877
5	Total Number of Pregnant Mothers transported	35,844	403,544
6	Total Number of Trauma cases transported	37,020	453,131
7	Total Number of beneficiaries under Neonatal Emergency Ambulance care	474	1194
8	Total No. of Inter Facility Transfer cases transferred among Govt. Hospitals	31,363	228,414
9	Critical lives saved	6430	62,834
10	Number of cases lifted by an imbalance In a day	3.25	3.25

FY = Fiscal year.

Table 2

Budget allocation

Years	2008–2009	2009–2010	2010–2011	2011–2012	2012–2013
Allocation in crores	29.29	55.13	90.24	94.6	106.5

Implementing a performance management infrastructure also helps you to provide better service, improve communication, and deliver greater responsiveness. Operational decisions can be improved by making information easily accessible to caregivers, staff, and management. Ambulance clinical performance can be strengthened by identifying opportunities for improvement. In developing countries the death rate increases every year due to lack of emergency treatment in rural areas. This proposed approach will help us to overcome this situation and to provide an efficient system to treat emergency patients in rural areas and help to reduce the death rate.

Discussion

This paper confirms the necessity of a cloud computing system for emergency rural health care in order to reduce the death rate due to the time delays during patient transportation and appropriate and timely first aid not being given. Patients' medical records and their past medical histories (without cloud computing) have been studied and were used to propose a modified emergency health cloud care system for maintaining patient information with assured authentication and security. This system will be reliable, readily available, synchronized, communicable and completely removes the risk of loss of files or documents. It enhances the emergency treatment that can be given to anyone in any city or any place where needed. There are many key challenges in this system including automatic resource provisioning, power management, and security management, which are starting to receive attention from the research community. It is essential that there are appropriate service level agreements with upper boundaries between Cloud operators and users.

Algorithm 1

Retrieve patient information initiated at Node 0

Input	Patient identification number
Output	Patient health history
Procedure	1. Send_patient_id () // to the Hospital community cloud like SSN.2. Get_patient_history () // patient basic history from cloud controller.3. Find the hospital where the patient has to be taken with help of a GPRS-enabled ambulance vehicle.

Algorithm 2

Send the status of the patient to Node 1

Input	Patient image (captured by movable camera)
Output	First aid messages
Procedure	1. Send_patient_image () // to Node 1.2. Send_bloodUnits_required () Node 1 sends information to Node 2 peer group if blood is required.3. Get_Firstaid_Messages () // Node 1.4. Nurse treats the patient as per the first aid messages.

Algorithm 3

Patient's relatives' details retrieval

Input	Patient identification number
Output	Patient immediate relative list
Procedure	1. Send_patient_IdentificationNumber () // Node 0 sends to the cloud controller.2. Get_Relative_List () // Cloud controller sends to Node 0.3. On receiving list of relatives, Node 0 sends to Node 3 which in turn sends accident message to relative list.