Architecture for an Internet-scale Telemedicine Grid Sriram Kailasam, Santosh Kumar, and D. Janakiram, Dept. of CSE, IIT Madras. email: [email protected], [email protected], [email protected]

Abstract According to a survey by Indian Council of Medical Research, an abysmally low number of people living in rural India have access to specialist care and advice. The telemedicine grid aims to fill up this gap by integrating multiple hospitals to form a large-scale enterprise collaboration to deliver services to all those areas which lack specialist care. We present a P2P, scalable and fault-tolerant architecture for realizing such an internetscale telemedicine data grid. Shared object space abstraction makes it easier to develop applications while location and context-aware scheduling ensures that the requests (from patients) are served by the best available resource (doctor) at that moment. The system facilitates anytime, anywhere computing by supporting mobility at patient as well as doctor ends. 1. Introduction The European Commission’s health care telematics programme [1] defines telemedicine as "rapid access to shared and remote medical expertise by means of telecommunications and information technologies, no matter where the patient or relevant information is located." Telemedicine has a prime importance especially in developing nations such as India, wherein an abysmally low number of people (living in rural India) have access to specialist care and advice. However the sheer number of underprivileged masses calls for the implementation of a large-scale telemedicine solution capable of providing services across the country. This poses several requirements like scalability, robustness, costeffectiveness, wide coverage, context-awareness etc. Now, P2P systems have been shown to be scalable and robust. Hence, a large scale telemedicine solution calls for a P2P grid based architecture integrating hospitals as centralized schemes cannot scale to such huge number of requests. The distributed nature of peer to peer overlay network increases robustness in case of failures whereas a central server becomes a single point of failure. The formation of a grid of hospital nodes with internet as the backbone will also enable cost-effective utilization of existing hardware resources. The lack of infrastructure particularly in the rural areas and the fact that more than 80 percent of the world population live in areas with mobile phone coverage, make the provision of mobility both at the patient and doctor side necessary. Support for mobility at the patient's end will improve the coverage of the telemedicine solution whereas mobility at the doctor’s end would enable a doctor located anywhere to access the patient reports via internet and provide the required advice. The next important requirement in a large-scale distributed telemedicine solution is the context-aware scheduling of patient requests or in other words the dynamic discovery of relevant resources (doctors) to serve the requests. Considering the context parameters like location, patient history, severity of ailment etc. while scheduling would enable the requests to be served effectively.

In this paper, we propose a P2P, scalable and fault-tolerant architecture for context-aware mobile telemedicine. Figure 1 shows the high-level view of the proposed telemedicine system.

Figure 1: Bird’s eye view of the telemedicine system The health workers visit the rural areas equipped with vital parameter measuring devices (referred as sensors in figure 1) like Blood Pressure meter, Blood Sugar meter, ECG jacket etc. forming a ZigBee / Bluetooth network with a PDA. They measure the vital parameters and then upload them onto the data grid. The grid scheduler matches the request context to a nearest available doctor and notifies him via email / SMS. The doctor can then look at the request on his PDA and give consultation. The proposed system provides a persistent object space abstraction for the storage of medical data on the grid (formed by the nodes contributed by the participating hospitals). An object space provides an easy-to program abstraction for building applications while the distributed nature of storage (on the grid) makes it highly available as well as resilient to failures. The system uses a unique zone-based overlay structure that ensures proximity in routing as well as in storing data. The zones are formed by grouping geographically closer nodes and an efficient DHT-based routing (O (log N) hops) is realized within zone using Pastry [2] and across zones using Chord [3]. The patient requests are scheduled to appropriate doctors by a distributed context-aware scheduler that considers context parameters like proximity, patient history, severity of ailment etc. The scheduler first tries to schedule the request by using its local resource information (about the available doctors). If no resource is free, it inserts the request into a location-wise tuple space thereby enabling nearby hospitals to pick it up. After a timeout the request is made available globally by using a global tuple space. Thus, the solution emphasizes on timely fulfillment of patient requests as well as proximity of service. The proximity aware overlay structure and the scheduling mechanism minimize the data movement cost and improve the efficiency of the system. The solution uses the existing internet infrastructure and supports mobility at doctor and patient ends.

At present there is only very minimal computerized patient health record management facility in [26] India especially, in rural areas. Thus, the introduction of the new solution won't lead to any backward compatibility issues and will also enable computerized medical record management. Hence, telemedicine can become a means for data collection and creation of health records for patients in India. This will pave the way for realizing the grand vision of a scalable context-aware health grid in the country. The remaining of this paper is organized as follows: section 2 explains the requirements of large-scale telemedicine. Section 3 discusses the related work while section 4 explains the system model. Section 5 presents the preliminary evaluation of the system and we conclude in section 6. 2. Requirements of large-scale telemedicine Telemedicine has a prime importance especially in developing countries because of several reasons. As [4] points out, the primary health care providers in the rural areas are mostly inexperienced. Taking the specific case of India, [5] and [6] show that 70% of the population in India lives in the rural areas while 75% of the doctors practice in the urban centers. Overall, there is only one doctor for every 15,500 people. Further, as [4] mentions, the telecommunications infrastructure in India is continuously improving. All the above mentioned facts make telemedicine an appropriate technology to be used in developing countries, particularly in India. With large underprivileged population in the country, the telemedicine system must be scalable. The conventional model of telemedicine wherein the nodal centers from the remote areas (rural clinics) connect to a big city hospital for telemedicine fails to scale up. This is because the centre at the big hospital becomes a bottleneck as the number of remote nodal centers increase. Also, the current telemedicine infrastructure requires the specialist to be available at the centre whenever the data is received to deliver quick advice. However, this constraint on the specialists to be always available at the hospital centre may not be feasible as the number of requests increase. With the recent advances in broadband technology for mobile phones, it is now possible for a specialist located anywhere to use his mobile device to provide remote consultation to the patients. Hence, the telemedicine solution must support mobility at the specialist end as this will offer flexibility and improve the availability of the specialist. The remote nodal centers (small in number) do not have the penetration that a nurse-led mobile unit can achieve. Besides, it may not always be possible for a patient to come to a nodal centre. Instead, a health worker may go to the patient with vital parameter measuring devices and his/her mobile device. This can improve the reach of the telemedicine system. Hence, the telemedicine system must support mobility at the patient end. The telemedicine system must be robust i.e. the patients must be able to depend upon the telemedicine system even during emergencies. For this, the system must guarantee service despite partial infrastructure failures.

The telemedicine system must enable discovery and teleconsultation with a doctor located within shortest distances. This helps in cases when the patient is advised to travel to the nearest hospital. Besides this, the system must schedule the request to a doctor who has treated the patient previously and belongs to the current area of consultation because he would quickly diagnose the problem. Hence, the collaboration needs to be set up dynamically based on these contexts. Finally, the telemedicine system must be secure, cost-effective and easy to use. The following table summarizes the requirements of large scale telemedicine and enlists the corresponding IT research challenges. Sno. 1

Requirement

Scalability

2

Location and context-aware scheduling of patient requests. Scheduling

3 Robustness

4

5

Workflow based-scheduling to empower non-specialists to share a good proportion of load Effective load-balancing and faulttolerance mechanisms to ensure timely service despite partial infrastructure failures.

Maximize coverage of the telemedicine system

Support for mobility at the doctor’s end (would facilitate anytime anywhere access). Support for mobility at the patient's end

Cost-effectiveness

Use internet as a backbone and exploit the wide spread of mobile phones

Secure

Effective security mechanisms for the telemedicine system. Mechanisms for circumventing firewalls to allow access.

Hide complexity from end user

Intuitive UI for patient and doctor applications.

6

7

IT Research Challenges Integrating telemedicine hospitals, mobile medical specialists and rural mobile units/clinics to form a large virtual enterprise Even distribution of data, processing and load among experts

3. Related work There are several solutions for telemedicine currently available differing in various design aspects. Many of the solutions as [7], [8], [9], [10], [11] are having dedicated hospital nodes acting as centers for providing telemedicine service with the doctor being present in the hospital for consultation. But with the widespread use of mobile communication devices among the doctors, the service of doctors can be availed even without their presence in the hospital through mobile devices. The concept of mobility in the part of the medical practitioner as in [12] is used in our solution. Considering mobility in the patient side, solutions as [12] limit the patient mobility to the hospital premises. But in our solution, mobility is also offered in the patient side thereby making the system reach for the needs of the rural community having insufficient medical infrastructure. The support for mobility in the patient side is present in [13], [14], [15] and [16]. Some solutions use the technology of wireless ad hoc network and grids at the patient side as in [15], but in our solution we kept the patient-side resource constrained mobile devices out of the grid to improve the grid stability. Certain solutions address the need of a single hospital and associated patients as in [12]. But our solution incorporates multiple hospitals working collaboratively within the grid providing a farther reach to the target community. Solutions like [17], [18] uses interconnected hospitals to provide medical service. For handling the requests incoming from various patients and processing it, the solutions like [10], [11], [16] use a central server. This makes the solutions inherently non-scalable restricting their scope as a solution for a large scale global health grid. Also, the central server becomes a single point of failure. Our solution uses multiple zonal servers from various zones to distribute the handling of requests thereby providing scalability. The solution in [7] uses a different approach for the above problem by using a dedicated server farm to provide request handling. But this leads to underutilization of the computing resources of the nodes present in various hospital nodes and limits scalability. The various solutions differ in the manner in which patient requests are forwarded to various doctors. The solutions as in [15] use the service of a dedicated medical call center comprising of medical practitioners for attending patient requests and forwarding them to appropriate doctors. But the manual intervention in forwarding the requests make the system expensive as well as less scalable. In another approach, solution [19], accepts the symptoms from the patient and uses artificial intelligence to route it to the appropriate specialist. In our solution we used a simple automatic forwarding of the requests through the zonal servers based on the specialization as specified in the request. The solution also allows for internal forwarding of the patient requests among multiple specialists. Thus we have achieved a simple, scalable and cost-effective solution. Many of the solutions utilize medical grids for computational purposes as in [20], [21]. But we have also used the grid for request forwarding, load balancing in terms of patient requests as well as storage of patient records. The solution [19], do not address the need of a patient-doctor meeting as its primary aim does not require it (military application). But in our solution the patient may need to consult the doctor in person depending on the

ailment. For addressing this, the scheduling is implemented in such a way that as far as possible, the patient requests will be forwarded to the nearer hospitals depending on availability. For this the presence of geographic proximity-based zones and local tuple spaces for handling surplus requests are used in our solution. But such proximity-related issues are not addressed in solutions as [22], [23]. Further, none of the above solutions effectively address the possibility of a group of hospitals becoming overloaded occasionally. This calls for a need for the request to be stored temporarily to ensure proximity and later forwarding to the global grid after a specified timeout to ensure timely service. Our solution effectively addresses this possibility by incorporating a global tuple space and multiple local tuple spaces for each specialization. The concepts of proximity based clustering of patient records to minimize data movement and the distributed context-aware scheduling prioritizing various factors like proximity, specialization, load etc. are also unique. Vishwa, a reconfigurable peer to peer middleware for grid computing [24] is used as the overlay network unlike other solutions. All the above lead to a zone based health grid architecture with distributed context-aware scheduling. 4. System Model An internet-based, secure, context-aware P2P data grid framework integrating hospitals distributed across the country fulfils all the requirements of large-scale telemedicine. P2P systems have been shown to be scalable and robust. Using internet as a backbone makes the telemedicine system cost-effective while adding context-awareness and security to it makes it dependable. Support for mobility at the doctor end provides flexibility and increases the availability of the specialist while mobility at the patient end increases the penetration of the system. Besides, a large-scale grid can provide an infrastructure for storing huge amounts of data as well as massive computational power. Earlier in [26], we described the use of mobile technologies in the telemedicine system. In this paper, we present the architecture of a large-scale data grid for telemedicine. 4.1 System overview The telemedicine system makes the following assumptions: • The nodes in the telemedicine system are contributed by the participating hospitals. Every node shares a minimum amount of storage space as per an agreement signed by all participating hospitals. • The administrative policies governing these nodes are aligned as per a common agreement between the hospitals. This is feasible since there is no large-scale computerized patient health record management in India [27] and this is a unique opportunity to build a scalable and robust patient data storage system. • Churn rate is not very high since the nodes contributed by the hospitals are more or less dedicated. Also, the system does not provide any explicit mechanisms for handling byzantine node failures. • Mobile clients (doctor PDAs, patient-side PDAs etc.) have internet connectivity. The nodes contributed by the hospitals (henceforth, referred as static nodes or simply nodes) act as data storage and compute resources, while the doctors equipped with PDA

are the medical resources. The former are modeled as peers in the telemedicine grid while the latter are modeled as external entities which contact or are contacted by the static nodes in the grid for providing/accepting services. Modeling the mobile PDAs as external entities and not as peers effectively masks the resource constraints of these devices in terms of bandwidth, storage and intermittent connectivity. They are only used to store the request object while providing consultation. Permanent storage is provided by the static nodes in the telemedicine grid which is realized as a persistent object space. An object space provides an easy-to program abstraction for building applications. It allows us to model real world entities like patients, doctors as objects. The details regarding different kinds of objects used in the telemedicine system are discussed in section 4.3.2. The static nodes in the telemedicine grid are responsible for routing, scheduling of requests and providing fault-tolerant data storage by replication mechanisms. Now, proximity-aware routing makes routing efficient while proximity in storing data replicas enables efficient propagation of updates among the replicas. We use a unique zone-based overlay structure that ensures proximity in routing as well as data storage. The zones are formed by grouping geographically closer nodes and making them part of a Pastry [2] overlay within the zone. These nodes also participate in a Chord [3] overlay across the zones. Though, each node is part of two overlays, the unique overlay structure ensures efficient routing with the same routing table size as would have been were there a single large overlay. The data of patients belonging to the geographical region covered by the zone are replicated on nodes within the zone thereby ensuring replica proximity. Few replicas are also maintained in other zones to ensure data availability in case the entire zone gets disconnected. The system also clusters the patient data by manipulating the idgeneration mechanism for different objects of the patient. The clustering of data per patient enables efficient retrieval of patient history while scheduling the request to a specialist. Section 4.2 discusses the unique features of the overlay structure while section 4.3.3 describes the clustering of objects. The nodes in the telemedicine system assume different application roles dynamically based on requirement. The different application roles are zonal server, hospital representative and grid nodes. The zonal server enables bootstrapping of nodes within the zone. It also acts as patient request gateway or an entry point for the patient requests. The hospital representative represents a particular hospital and provides an interface to the doctors to indicate their availability for serving requests. Besides, it also maintains a set of capable nodes (high bandwidth, CPU and memory) for serving the patient requests received by that hospital. Now, each hospital representative within the zone periodically aggregates the doctor availability information and advertises the same along with the list of capable nodes to the zonal server (henceforth, referred as resource advertisements). The grid nodes are used for storage and computation. Every node other than the zonal server acts as a grid node. We discussed earlier that many existing telemedicine systems are centralized and hence do not scale as the number of requests increase. However, centralized systems have an advantage of complete resource information and hence resource discovery and subsequent scheduling of requests is not a problem. In our case, the telemedicine system

is a large-scale virtual enterprise comprising of multiple hospitals and mobile doctors. We adopt a hierarchical context-aware resource discovery mechanism to schedule the requests. The zonal server (request gateway) accepts the initial context parameters of the patient request like location and area of treatment, and redirects the request to a proximal hospital within the zone by referring to the resource advertisements. Now, the proximal hospital node (one of the capable nodes advertised by the hospital representative) receives the patient request object and replicates it on the DHT while maintaining a temporary local copy for the duration of scheduling. This node then considers the detailed context parameters like patient history, language, and severity of ailment (emergency/normal) to choose an appropriate doctor for scheduling. If the request is not marked as an emergency, then it is first scheduled to a non-specialist and only if he recommends a specialist, then the request is rescheduled. This way the system empowers the non-specialists to share a good proportion of load. If no request slots are free in that hospital, then a request tuple containing the request id and context hint is inserted into a location-wise tuple space to enable other hospitals near that location to serve that request. If no nearby hospital picks up the request within a threshold, then that request is made available globally so that any hospital with free request slots can serve it. This is achieved by inserting the pending request ids into a global tuple space. The details of the tuple space realization are discussed in section 4.4.4. This policy of scheduling the request to proximal hospitals (within zone) minimizes the data movement across the zones. However timely fulfillment of requests is favored over proximity in case the request is not served within a threshold by making it available globally. Figure 2 shows the architecture diagram. The following sub-sections explain the details of the different components.

Figure 2: Architecture of telemedicine grid 4.2. Overlay The logical grouping of nodes into zones mirrors geographic distribution i.e. nodes from a particular region are mapped to a zone designated for that region. Roughly, the zone could span across a state or a group of cities depending on the region population, the number of hospitals in that region etc. It is assumed that the mapping of regions to zones is done by the system administrator. The objective is to make zones more or less self sufficient in terms of medical as well as storage resources but at the same time not making it too big to lose the advantage of proximity. The exact details of zone formation need to be studied considering usage patterns etc. after implementation and hence are out of the scope of this paper. Every zone has a zonal server that is used to bootstrap nodes into the system. Now, any node that wishes to join the telemedicine grid must contact the zonal server responsible for that region. It uses a location-zone mapping service (given a location, it returns the zonal server address) deployed at well-known web locations for this purpose. On contacting the zonal server, the node is assigned a unique node id by prefixing the zone id to a quasi random identifier generated using SHA-1. Each node then becomes part of two overlays viz. Pastry [2] within the zone and Chord [3] across zones as shown in fig. 3. This overlay structure has been used in Vishwa [24], a P2P computational grid. The bootstrapping details are available in [28]. The important thing to note is that the Chord finger table entries for each joining node are filled with the closest matching nodes (by masking the zone id of the joining node with the remote zone’s id) from the 2k zones. This ensures that every joining node gets different set of nodes from the neighboring zones as part of the Chord ring. This increases the number of entry points into the zone. It will be clear when we discuss inter-zonal routing.

Figure 3: Overlay structure Now, both Pastry and Chord are DHT-based routing substrates and provide lookup guarantee of O (log N) hops, where N is the number of nodes in the overlay. We use Pastry within the zone because efficiency is an important concern for intra-zonal routing, and Pastry can ensure that routing is done to the node responsible for a given identifier (id) and is nearest (in terms of network distance). Besides, prefix matching based routing in Pastry is exploited for clustering and load-balancing as explained in section 4.3.3. Chord is used across zones because it ensures correctness in routing even if very few

routing table entries are correct (lazy maintenance is facilitated for the Chord neighbors across zones). We make three observations from fig. 3: „ The number of nodes that are part of a single Pastry overlay is equal to the number of nodes within the zone. „ The number of nodes in the Chord overlay is equal to the number of zones. „ Each node is part of an independent Chord ring across zones Thus, if we assume that the total number of nodes in the entire system is N, the number of zones is Z and the average size of each zone is K, then the routing table size per node in our overlay is shown below: Pastry routing table size = O (log K), Chord routing table size = O (Z) Hence, total routing table size per node ~ (log K + log Z) = log (K*Z) = log (N), which is same as that of a single large-overlay. Thus, with the same routing table overhead as any single large overlay, we gain proximity in routing and storage by using this overlay structure. Now, in inter-zonal routing, the message is first routed to the closest node (by masking the zone id of the destination node with the current zone’s id) in the same zone using Pastry and then to the destination node using the Chord finger table of the closest node. Since each node is part of an independent Chord ring, it increases the number of entry points into the zone thereby helping in the distribution of incoming requests from other zones. 4.3. Storage management Storage management aims at clustering the patient data for fast retrieval while simultaneously maximizing the storage utilization of the grid (nodes may have heterogeneous storage capacities). It also ensures high availability by replicating the objects within as well as across zones. Though it is highly unlikely that sensitive systems like the telemedicine system will be operated at high levels of storage utilization, storage load-balancing schemes similar to that in PAST [29] are used for robustness. 4.3.1. Object replication Every object to be stored on the grid is assigned a unique identifier (by prefixing the zone id to a quasi random identifier generated using SHA-1). We have seen that proximity while storing data replicas enables efficient propagation of updates among them. But at the same time too much proximity can cause all replica-storing nodes to fail simultaneously in the event of network outages or disasters. Thus, we need to spread the replicas within the zone. Now, every node within the zone is assigned a random identifier. Hence, by storing the replicas on k-closest nodes (in the id-space) within the zone (Pastry), the replicas get spread. Besides, the object is also replicated on ‘c’ successors of the target node in the Chord ring to handle disconnection of the entire zone. Target node is a node within the zone which is closest to the object id.

4.3.2. Types of storage objects The storage objects in the telemedicine system can be classified into the following types • Patient profile object, • Treatment profiles, • Patient Request object and • Doctor profile object The patient profile object is created when the patient uses the telemedicine system for the first time. It contains his general information like name, date of birth, blood group etc. which is static. It also contains references to other treatment profiles. Each treatment profile contains treatment details of a particular area of treatment. For e.g. the cardiology profile will maintain references to patient request objects containing ECG along with the corresponding diagnosis and prescription. The patient profile object also maintains a Visit number which indicates the number of times the patient has been treated by the system. This number is used for statistical reasons and also for generating the Request ids.

Figure 4: Structure of patient and treatment profiles, request object The patient request object is created when a patient request is submitted to the telemedicine system. It consists of patient id, area of treatment, location (co-ordinates) from which the request was made, severity of ailment (emergency/normal), category of specialists to whom the request must be scheduled (optional), the patient’s contact information (email/mobile no. where the response must be sent) and a set of pairs. If the category of specialists is not indicated, then the request may be assigned to a general doctor who is the lowest in the hierarchy of specialists. The last field viz. the pair holds the vital-parameter name and the corresponding vital-parameter measurement (or a pointer to it). The vital-parameter measurement could be a string or be stored in a file. For e.g. Blood Pressure value is a string, whereas ECG will be stored in a file. Figure 4 shows the structure of the different objects along with their id generation mechanism which is discussed in section 4.3.3. The doctor profile object contains profile information about the doctor like name, mobile/email, area of specialization (e.g. Cardiologist), current location, languages known etc. This information is used for context-ware scheduling as discussed in section 4.4.1.

4.3.3. Clustering of objects In general, clustering objects that are accessed together helps in answering queries efficiently. However, DHT-based storage mechanism doesn’t provide any support for clustering. This is because the DHT-key generation using consistent hashing techniques like SHA-1 produces random keys. This removes all the context information present in the object. But due to the random key generation, DHTs provide inherent load-balancing. Thus, it can be seen that DHTs provide inherent load-balancing but not clustering. If clustering is required, then locality preserving hash functions [30] must be used for generating keys. But, this will need explicit load-balancing since the distribution of keys in the id space is skewed in practice. The storage mechanism in the telemedicine system provides clustering of patient data while simultaneously ensuring almost uniform distribution of objects over the object id space. Prefix-based routing i.e. Pastry is used within zones. Hence, modifying the lower order bits (say x) of the id to generate a new id will ensure that the resulting id matches the original id in n-x bits. This implies that the objects corresponding to the original id and the resulting id will be stored within x hops of each other. As shown in figure 4, the patient profile object is assigned a random id (patient id) using SHA-1. The last few bits are masked by zero. This ensures that the patient profile objects are distributed uniformly on the DHT. The ids for the treatment profiles are created by masking the last b bits of the patient id with the treatment code (each area of treatment has a unique treatment code). This ensures that the patient profile objects and the treatment profiles are clustered. The Patient Request id is generated by inserting the visit number after the p-bit random patient id hash as shown in the figure. This ensures that the request objects are spread out in comparison to the treatment profiles because their id prefix-matches the patient id in fewer bits. This is the desired behavior because the doctor needs only the aggregate history information while providing consultation. This is available as part of the treatment profile. Thus, any query for retrieving records by patient id (like patient history) can be answered efficiently. Additional indices may be maintained on top of DHT for supporting queries based on different criteria like type of ailment etc. The telemedicine system doesn’t provide these indices in the current version. 4.3.4. Storage load balancing Storage load-balancing is required to deal with • Variation in the storage capacity of individual nodes • Statistical variation in the assignment of node Ids and object Ids. Besides in our case, the request Ids are generated explicitly for clustering. • Variation in the object sizes (E.g. High resolution retinal images have a higher size as compared to ECG) Node heterogeneity in terms of storage is handled by requiring the high storage node to split and join under multiple node ids. The multiple node ids represented by a single node are not administratively independent and hence a failure of such node will have the same effect as multiple node failures. However, if the number of nodes represented by a single node is very small compared to the total number of nodes and also by ensuring that the multiple node ids are not part of the same leaf-set, this effect can be mitigated. The

telemedicine system uses load balancing mechanisms similar to that in PAST [29]. Every node maintains two thresholds viz. tdivert and tdivert_accept. If the incoming object size (o) is large enough to decrease the node’s available storage space (s) by more than the threshold, (o/s > tdivert), then it finds an alternate lightly loaded node from the leaf-set and diverts the replica there and maintains a reference to it. The alternate node uses threshold value as tdivert_accept (tdivert_accept < tdivert to ensure that a node doesn’t accept a large portion of diverted objects) to decide whether or not to accept the incoming object. In case no such node is found, then an insufficient storage failure is reported to the client. The client node rehashes the object and repeats the insertion operation. It is ensured that a single node is not chosen for storing multiple replicas of the same object. If the insertion fails for the second time, then the object is redirected to a neighboring zone for storage. It is important to note that the replica diversion mechanism increases the routing by only one hop. The reference to the diverted replica is also replicated in the k+1th closest node. This is to ensure that the reference to the diverted replica is not lost upon the referring node’s failure. In case, both the referring node as well as the k+1th node fails simultaneously, then the reference to the diverted replica is lost. Thus the node which is actually storing the object replica is no longer referred to by any node. To take care of this scenario, the referred node checks the liveliness of the referring nodes and purges the orphaned replicas. The replica purging mechanism can be initiated periodically or when the ratio of the storage space allocated to replica diverted objects to normal object replicas is more than a threshold. The details regarding replica purging mechanism are out of the scope of this paper. 4.4 Scheduling Many existing telemedicine solutions have overlooked the problem of large-scale context-aware scheduling of patient requests or in other words the dynamic discovery of doctors to serve the requests. With attempts like [31] to integrate vital sign sensors into textiles which can continuously monitor the patient, we believe that there will be huge amount of data generated and the problem of locating an appropriate doctor to interpret the data in case of emergencies becomes important. Thus, in this section we present context-aware scheduling in the proposed telemedicine grid architecture. 4.4.1. Objectives of context-aware scheduling Context is information that can be used to characterize the situation of the entity. Thus context-aware scheduling attempts to schedule the patient request to an appropriate doctor (available at that moment) by considering the context parameters of the request. The context parameters considered while scheduling are as follows: • severity of ailment (normal / emergency), • area of treatment, • location of the patient, • treatment history, • language, and • waiting time of the request

Thus, the system must provide mechanisms to handle normal as well as emergency situations in a timely manner. The system must improve the efficiency of the doctor by reducing the system’s response time. This calls for node capability-aware request placement, pre-fetching of patient history etc. and are discussed in the following section. Scheduling must also minimize the data movement across zones while simultaneously reducing the waiting time of the request. Hence, a hierarchical scheduling policy is followed wherein the system first attempts to schedule it to the nearest doctor within the zone and only if none of them are available and the waiting time of the request has exceeded a threshold, it is made available globally. 4.4.2. High-level view of scheduling The mobile doctors are the medical resources in the telemedicine system. They update their status (free/busy) through the mobile client application at the nearest hospital representative node. The nearest hospital node address can be found from the zonal server if it is not already known to the client application. The hospital representative node maintains a set of capable nodes for scheduling the patient requests. It replicates the doctor’s status information in the capable set. Capability based node selection is facilitated by the HPF propagation mechanism (heartbeat algorithm) as discussed in Vishwa [24]. HPF [25] is a measure of the capability of the node in terms of free CPU and memory. Periodically, the hospital representative node publishes a resource advertisement object containing the number of free request slots for each area of treatment, along with a list of capable nodes at the zonal server. Since the size of these advertisements is less than 100 bytes and the average number of hospitals per zone is of the order of 102, a single zonal server is adequate enough to receive the resource advertisements. Thus, the zonal server has total information about the number of free request slots at each hospital within the zone. The Zonal Server also knows the location co-ordinates of every hospital within the zone. Thus, when a patient request arrives at the zonal server (only the location and the area of treatment is sent to the zonal server), it redirects the request to one of the capable nodes registered by a proximal hospital node (having free request slots). Thereafter, the capable node accepts the patient request object. It simultaneously fetches the patient profile from the grid by issuing a DHT-lookup with the patient id. Since the size of the patient profile (less than a KB) is very less as compared to the patient request object (few hundred KB to 1 MB), it can be expected that the patient profile is fetched before the object upload completes. The visit number in the patient profile is used to generate the request id as explained in section 4.3.3. It then replicates the patient request object on the grid. If the current node were to fail, then the request object can be fetched from the DHT. However, the status of the request must be known to the other nodes in the capable set of the hospital representative so that one of them handles the request upon the current node’s failure. So, it informs the other nodes about the request and then acknowledges the client.

The capable node then forms a composite page comprising of the patient profile, treatment history and the patient request object and locally hosts it. It then considers the detailed context parameters like area of treatment, patient history etc. and obtains a lock on a particular doctor. Recall that the hospital representative node replicates the doctors’ status information on its capable set. Hence, the contention for a doctor is restricted only among the nodes in the capable set. Next it sends him an SMS or Email with the object URL and waits for his response. It should be noted that these are short-running tasks and hence it is reasonable to assume that the node remains capable for the short duration. This ensures best response time to the clients viz. the health worker while uploading the patient request, and the doctor while downloading the patient request object, and submitting his response. Once the response is received, the request object is updated on the grid and the response is relayed to the patient. If a further referral is required then the specialist class field of that request is set as per the doctor’s recommendation and the request is rescheduled. 4.4.3. Operational Modes of the scheduler A patient request can be classified as emergency or normal, based on the value of the ‘severity of ailment’ flag. The request must be immediately scheduled (pre-emptive way) if it is an emergency; else some delay is tolerable. The tolerable delay can be figured out only after field study. Thus, based on the request type, the scheduler gets into an emergency mode or a normal mode. In the emergency mode, the request is immediately scheduled to more than one ready specialist (availability status = FREE). They could be idle or busy serving some request from the grid at that moment. If an emergency request is received by someone who is already serving another request, then the client application informs him of the emergency. Now, he has an option to pre-empt the current request and serve the emergency. If more than one specialist responds, then the client will receive duplicate responses (they can be filtered out on the client-side based on Request id). If no specialist has downloaded the patient object within a threshold, then the request is rescheduled to double the number of doctors. In the normal mode, scheduling mimics the day-to-day prevalent practice of hierarchical consultation viz. the patient first visits a non-specialist for consultation; later, if recommended by the non-specialist, he visits a specialist. This policy of hierarchical scheduling empowers the non-specialists to share a good proportion of the load. This is realized by a hierarchical workflow in the telemedicine system. The workflow for every area of treatment is specified as an xml schema and then stored in the grid. The node responsible for scheduling refers to the workflow schema and schedules the request. Figure 5 shows the hierarchy of specialists for heart ailment.

Figure 5: Hierarchy of specialists for heart ailment 4.4.4. Push-based and Pull-based scheduling mechanism Once the patient request object is uploaded at the capable node, it needs to schedule the request to a free doctor. There can be two possible scenarios. 1. Free request slots are available in that hospital (to which capable node belongs) at that moment. 2. No request slots are free. Scenario 1 implies that the patient request can be immediately scheduled. This is referred as push-based scheduling. It can be seen that the efficiency observed in push-based scheduling is as good as any centralized solution. When the zonal server receives the initial context parameters of the request, it determines the nearest set of hospitals and forwards it to the one that has free request slots. Thereby, the request is immediately scheduled. Scenario 2 implies that the request needs to be stored until a doctor becomes available. In this case, the capable node inserts a request tuple into a location-wise tuple space. Realization of location-wise tuple space within a zone Location-wise tuple space is realized over DHT. The node produces a hash based on the location and the area of treatment specified in the request. It then inserts this request tuple with that hash into the DHT. The age field indicates the time (granularity of time is in minutes) the request has spent in the system. The dynamic node to which the request tuple maps to, maintains a sorted list of request tuples based on the age field. Any hospital mapped to this location and having free slots can pick the requests from the tuple space. This ensures that the request is served at the earliest. Now, each hospital is mapped to a set of locations. So it checks these location-wise tuple spaces for any unfulfilled request with different frequency for each location. The objective is to ensure that too many requests do not get stacked at a particular location. Thus frequency is calculated based on the (number of requests * average age of requests) at that location. This also ensures that an aging request has a higher probability of getting fetched. If the ‘age’ field for a request has exceeded a threshold, then that request is made available at a global level. This also implies that a group of hospitals responsible for that

location is busy. Hence, the zonal server must redirect requests from that location to some other hospital. This hint is conveyed to the zonal server. The request is made available globally by inserting it into a global tuple space which is realized over the DHT at two levels viz. within zone and across zones. Realization of global space within zone For every area of treatment, the treatment code is hashed using SHA-1 to produce a treatment hash. A dynamic node with the closest node id takes the responsibility of the global space within zone for that area of treatment. All those nodes which are responsible for the location-wise tuple space for that area of treatment forward the request tuples which have aged beyond the threshold value to this node id. Thus, the dynamic node responsible for the global space holds all the aged request tuples within the zone. Henceforth this node id will be referred as local zone node id. Realization of global space across zones It is always possible that few zones are overloaded with requests whereas others are relatively free. Thus the system must provide load-balancing at the global level. This is achieved by using global load advertisements. For each area of treatment, a particular zone is chosen as the global zone. This is done by extracting the first z bits (the number of bits allotted for zone id) from the treatment hash. The zone which is the closest successor to the extracted id takes the responsibility of handling the global space across zones for that area of treatment. The responsible node within the zone is dynamically chosen by rehashing the treatment hash and then routing it using Pastry. This is done to ensure that the dynamic node chosen for global space within the zone and across zones are different. Henceforth the zone responsible for handling the global space across zones is referred as global zone and the node id within the global zone used for this purpose is referred as global zone node id. Now, the node handling the local zone node id within each zone advertises its to the node handling global zone node id if the number of pending requests is beyond a threshold. It is important to note that the request tuples are still retained within each zone and the node handling the global zone node id only maintains a gross indicator (relaxed consistency) of the request load across overloaded zones. Now the zone that has free request slots can query the global zone node id to find out the overloaded zones and subsequently share the request load from the overloaded zones. But if every hospital node within a zone that has free request slots queries the global zone node id, then it would become a hot spot. To handle this scenario, the node handling the local zone node id within each zone acts as a request collector. The hospital nodes place their request subscriptions i.e. in the local zone node id. Periodically, the local zone node contacts the global zone node and fetches the zone ids of the overloaded zones. Later, it contacts the local zone node id of the overloaded zones and fetches the request ids. It is then disseminated to the hospital nodes. Hierarchical realization of the global space is shown in figure 6.

Figure 6: Realizing global space within and across zones Load-balancing within the local zone In the above scheme, the node handling the local zone node id becomes a bottleneck if the number of requests within a zone is large. This problem can be alleviated by choosing multiple node ids as request collectors and distributing them in the node id space. Recall that in Pastry, two keys that differ from each other in the higher order bits will be mapped to two different nodes that are way apart from each other in the node id space. This property can be exploited while computing the local zone node ids as follows: Let x denote the request load within the zone (i.e. x = Pending requests/ Total Request Slots within the Zone) and t be the threshold value for the number of requests that can be handled by a single local zone node. Find value of d (number of leading bits that must be modified) such that t * 2d ≤ x < t * 2d+1, this ensures that the load is distributed across 2d nodes. It is important that the value of d does not become arbitrarily large. If the value of d has reached the upper limit, the zonal server must start redirecting the requests to other zones. The details of threshold calculation will depend on the request service rate for each type of request, most frequent request types, availability of doctors etc. and is beyond the scope of this paper. It would be clear only after field studies. Once the value of d is known, the treatment hash h’ is calculated by concatenating r with n-d lower order bits of the original treatment hash (h) as shown in figure 8.

Figure 7: Generating treatment hash value for load-balancing r denotes a d-bit value which is determined as follows: 1. Initialize r to a random d-bit number 2. Subsequently, r = (r + 1)mod2d Calculating r in a round-robin fashion ensures that the request tuples are equally distributed across the 2d nodes. More importantly, it prevents concentration of aged requests at one particular node. Now the node responsible for the original local zone node id publishes at the global zone node id. Thus the contacting nodes from the free zones get the value of d for a zone from the global zone node id. They create the treatment hash in a similar manner and contact the corresponding node from the destination zone. Thus, the load is balanced

across multiple nodes within the zone. Since the request tuples are also fetched in a round robin fashion, the request tuples in each of the 2d nodes depletes to a similar extent. Thus, when the node responsible for the local zone node id detects that the request load has reduced (to a threshold), it initiates a merge. It calculates the new value of d (say d’) and sends it to the zonal server and also publishes it in the global zone node. Each node (out of the 2d) calculates the id (c’) to which they must send their request tuples as shown in figure 6.

Figure 8: Calculating the request collector id as part of merge Load-balancing in the global zone The dynamically chosen global zone node stores only the zone id and a gross indicator of the request load viz. d for a zone. Since this information does not change frequently, the global zone node replicates this information on its in-degree nodes (nodes that have global zone node in their routing tables) within zone as well as on neighbors in c successor zones. Thus any local zone node querying for this information can get it from a node in the routing path. Thus queries from local zone nodes don’t necessarily reach the global zone node. Thereby load-balancing is achieved in the global zone. Query load balancing A single zonal server can become a bottleneck if the number of patient requests increases. Besides, to handle failures of the zonal server, a set of standby nodes is maintained. The zonal server periodically publishes the information regarding the zonal server as well as the standbys in the location-zone map. Thus the mobile client picks up one of these nodes at random and submits its request. Besides, the zonal server can periodically find out the load information from the successor zones and redirect excess requests there. Thus zones can load-balance with its successors. Also, since the objects are replicated in the c successor zones, the neighboring zones can find the relevant patient data within their zones. 4.5. Fault-tolerance Fault-tolerance plays a very important role in a critical system like telemedicine. Node failures must be effectively masked to provide uninterrupted services. As discussed earlier, the nodes fulfill different responsibilities based on their role in the system. The following sections discuss the failures and how they are handled for each role. 4.5.1. Failure of Zonal Server: K-standby nodes are maintained per zonal server to mask zonal server failures. The updates to the zonal server viz. the publishing of resource advertisements (more frequent) are lazily propagated to the standby nodes, while the information regarding new node joins/leaves (less frequent) is immediately propagated. When the zonal server fails, one of the standby nodes takes over. The lack of accurate knowledge of the resource advertisements for the standby node (due to lazy propagation) doesn’t affect scheduling

much. This is because the resource advertisements are published periodically. It may only cause few requests that arrive (before the next resource advertisements) being handled as a pull rather than a push. The recovery process can be summarized as follows. When a zonal server failure is detected by a standby node, it broadcasts this failure information to the other standby nodes along with its node id. If multiple standby nodes detect the failure simultaneously, then the one which has the least node id takes over as the new zonal server. The new zonal server updates its IP address against its zone id in the location-zone mapping servers and also informs the other zonal servers (viz. the ones which are part of the Chord routing table for this zone) during a periodic ping. It then chooses another capable node as a standby as explained in section 4.5.3. Since the hospital nodes know the IP address of the standby nodes, they can contact any one of them. The standby node that receives the resource advertisements from the hospital node piggybacks the new set of standby nodes along with the acknowledgement. In general, the zonal servers and the standby nodes are reliable nodes. They are initially configured by an administrator by considering uptime of the node, capability etc. The failure of the standby is handled similar to that of zonal server failure. 4.5.2. Failure of hospital representative The hospital representative replicates the doctor’s status information on the capable set. Whenever the hospital node fails or becomes incapable, a new node among the capable set is chosen as the hospital representative. The process is similar to the selection of a new zonal server from the standbys. Additionally, the new hospital node’s IP address is broadcasted to all nodes in the neighborhood within a distance of k-hops. This ensures that the nodes in the proximal neighborhood (within the same hospital) know the hospital node’s IP address. This is useful if a doctor contacts a non-hospital representative to report his availability. That node can redirect those messages to the hospital representative. 4.5.3. Failure of the nodes in the capable set while scheduling requests The nodes in the capable set are responsible for scheduling the patient request objects to the available doctors. The sequence of steps in request scheduling is as follows I. Locally storing the patient request object and replicating it on the grid II. Fetching the patient profile, creating a composite page comprising of the patient profile and the patient request object and locally hosting it III. Notifying the doctor by sending the request URL by SMS or email IV. Updating the patient treatment profile with doctor’s response V. Sending doctor’s response to the patient-side mobile device The node can fail at any of the above steps. The fault-tolerance mechanism must ensure that the current status of the request is recovered and the scheduling process is continued. If the node had failed in step I, then the client mobile device won’t get any acknowledgment, and attempts to upload the object again. If the node had failed in any of the steps from II-V, then it could result in some scheduling operations being done more

than once. For e.g. if the node had failed after step V, but before sending the status information to the capable set, then the new node that replaces the failed node would send one more SMS to the client mobile device. Duplicated messages however are filtered out by the client-side application using the request id. The nodes in the capable set periodically ping each other and update the status information of all requests in progress. The status information of the requests is piggybacked along with the ping messages to minimize network traffic. A version number is assigned to each of these status information messages to keep track of freshness. The node in the capable set that detects another node’s failure initiates the selection of a new node to replace the failed node. The new node selection algorithm is as follows: 1) The node which detects the failure broadcasts a node failure message to all the other nodes in the capable set. The node failure message includes the failed node’s IP address along with the request status version number (of failed node) known to the detecting node. 2) More than one node may detect the failure simultaneously. The following protocol is used to decide which node should take the responsibility of recovering the failed node. a) Once a node receives the failure message, it sends a positive or a negative acknowledgement. It compares its own values for the following parameters with that which is available in the node failure message to decide. i) Request status version number (for the failed node) ii) Current load on the node iii) Node id values: If the above parameter values are equal for both the nodes, then the one with a lower node id takes over. b) The node which receives positive acknowledgements from all live nodes in the set chooses a new node from its capable node list. It ensures that the new node is not one already present in the capable set. 4.5.4. Failure of Grid node The grid nodes are part of the Pastry overlay within zone and the Chord overlay across zones. They periodically monitor the nodes in the leaf set (within zone) and their finger table entries (across zone). They update their routing table entries, leaf set entries and finger tables upon node failure as explained in Pastry [5] and Chord [7]. The Chord routing table entries are altered lazily for performance reasons. This is because most of the communication happens within zone. Data items are stored on the grid nodes. K-replicas are created for every data item within the zone. When a node fails, all the objects stored on that node must be replicated on a new node to maintain the K-replicas per object invariant. The failure recovery within the zone is similar to that in PAST, while that across zones is similar to that in CHORD.

5. Implementation overview P2P data grid middleware has been realized in java. The object schemas are represented using xml. The composite object consisting of the patient request and the treatment profile (patient history) is prepared by applying XSLT to the xml source files. The composite object URL is then sent via SMS / email to the doctor. Java servlets are used for the web interface while the mobile client application (midlet) is done using J2ME with MIDP profile. The screenshots of the prototype application using Nokia Series-40 Emulator are shown in figure 9. The doctor can look at the ECG on his mobile phone and submit his response to the grid. The prescription is updated on the grid and relayed to the patient.

Figure 9: Screenshots of the prototype system at the doctor-end Though the telemedicine application is web-based, the client-side application on the mobile is required to effectively mask node failures (exception handling) from the doctor. Besides, the mobile client application also pre-fetches the patient request object before intimating the doctor. This eliminates the waiting time of the doctor thereby improving his efficiency. This also separates the doctor’s concerns from the system concerns. Wireless Messaging API (JSR-120) is used for receiving SMS while Clickatell SMS gateway is used to send SMS notification to the doctor. The J2ME midlet (doctor side) is registered to a PUSH registry for listening on a particular port. When an SMS arrives on that port, the midlet is automatically invoked. The midlet application processes the SMS, fetches the request object from the grid, stores it locally and then notifies the doctor about the arrival of the request. An SMS is sent to a specific port by setting the UDH (User Data Header) in the SMS gateway. As far as the electromedic devices are concerned, we collaborate with Karlsruhe University in Germany for Bluetooth/Zigbee enabled measuring devices like ECG jacket to be used in the project. Biocomfort [32] is a commercial realization. In the pilot realization, vital parameters like ECG, BP, and Blood Glucose would be used to target cardio-vascular diseases among the rural areas. 6. Conclusion and Future work

In this paper, we proposed a P2P, scalable and fault-tolerant architecture for the telemedicine grid. The data grid can be seen as a nation-level distributed database of patient medical records. We believe that by integrating a context-aware scheduling mechanism and supporting mobility at both the doctor and patient ends, such a grid will provide rapid access to remote medical expertise no matter where the patient or relevant information is located. Such a grid means lot of data and computational power for the medical research community. Prediction models can be built on top of the grid to forewarn the occurrence of epidemics. The next step is to integrate a suitable economic model into the telemedicine grid. This is important in India where health insurance is not wide-spread in the rural areas. Besides this, we wish to integrate a whole lot of medical services like blood banks, ambulance etc. into the grid, so that we have a full-fledged health grid spanning across the country. Such a health grid will be of immense help to the developing nations and this forms part of our future research. Acknowledgement We thank Intel Research and Indian Council of Medical Research for sponsoring the telemedicine project. We also thank Harisankar from IIT Madras for his suggestions and help in doing the survey. We also thank Rahul Mourya from IT-BHU for helping in the development of the doctor side mobile application 7. References [1] Research and technology development on telematics systems in health care. Annual technical report on RTD in health care. CEC DG XIII. Brussels: AIM, 1993. [2] A. Rowstron and P. Druschel, “Pastry: Scalable, decentralized object location and routing for largescale peer-to-peer systems,” IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, pp. 329-350, November, 2001. [3] Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications,” in Proc ACM SIGCOMM, San Diego, pp. 160-177, Aug 2001. [4] A. Pal et al., “Telemedicine diffusion in a developing Country: The case of India (march 2004),” Information Technology in Biomedicine, IEEE Transactions on 9, no. 1 (2005): 59-65. [5] E health Initiatives in India, S K Mishra, United Nations Economic and Social Commission for Asia and the Pacific (UNESCAP), 9-11th October 2007, Bangkok, Thailand [6] G. Harris, “India: telemedicine's great new frontier,” Spectrum, IEEE 39, no. 4 (2002): 16-17. [7] Medintegra. Available: http://www.telemedicineindia.com/medint_web.html [8] Center for Connected-Health at Partners Healthcare, Massachusetts General Hospital, Boston, MA, USA. Available: http://www.connected-health.org/ [9] BELGIUM-HF - the largest belgian telemedicine clinical trial on congestive heart failure http://www.belgium-hf.be/ [10] “Development of ICT-Based Mobile Telemedicine System with Multi Communication Links for Urban and Rural Areas in Indonesia — Asia-Pacific Development Information Programme,” http://www.apdip.net/projects/ictrnd/2005/l53-id/proposal. [11] S. Pavlopoulos et al., “A novel emergency telemedicine system based on wirelesscommunication technology-AMBULANCE,” Information Technology in Biomedicine, IEEE Transactions on 2, no. 4 (1998): 261-267. [12] C. O. Rolim et al., “Towards a Grid of Sensors for Telemedicine,” Proceedings of the 19th IEEE Symposium on Computer-Based Medical Systems (2006): 485-490.

[13] M. V. M. Figueredo and J. S. Dias, “Mobile Telemedicine System for Home Care and Patient Monitoring,” in Proc. 26th Annu. Intl. Conf. of the IEEE EMBS, San Francisco, CA, 2004, vol.2. pp. 3387 – 3390. [14] J. Mikael Eklund, Thomas Riisgaard Hansen, Jonathan Sprinkle and Shankar Sastry, “Information Technology for Assisted Living at Home: building a wireless infrastructure for assisted living,” in Proc. 27th Annu. Conference, Shanghai, China, 2005. [15] T. Tang and J. Ku, “Mobile Care: Telemedicine Based On Medical Grid and Mobile Network,” Wireless Communications, Networking and Mobile Computing, 2007. WiCom 2007. International Conference on (2007): 3155-3158. [16] O. J. Gibson et al., “A GPRS MOBILE PHONE TELEMEDICINE SYSTEM FOR SELFMANAGEMENT OF TYPE 1 DIABETES,” Proceedings of 2nd IEEE EMBSS UK and Republic of Ireland Postgraduate Conference in Biomedical Engineering and Medical Physics (2003): 14-16. [17] Telemedicine on the Grid Project at University of Cambridge Available: http://www.escience.cam.ac.uk/projects/telemed/ [18] L.S. Satyamurthy, “ISRO’s experience in Telemedicine with special reference to Mobile Telemedicine system,” November 2007. Available: http://www.aprsaf.org/data/aprsaf14_data/day1/CSA05_APRSAF-14%20-%20Telemedicine.pdf [19] May, Jerrold H., “Global Grid Telemedicine System: Expert Consult Manager”, Annual rept. 1 Oct 1999-30 Sep 2000, PITTSBURGH UNIV PA, Defence Technical Information Center. [20] G. Berti, S. Benkner, J. Fenner, J. Fingberg, G. Lonsdale, S. Middleton, and M. Surridge, “Medical Simulation Services via the Grid,” in 17th International Parallel and Distributed Processing Symposium (IPDPS 2003), Nice, France, April 2003. [21] The GEMSS Project: Grid-Enabled Medical Simulation Services, EU IST Project, IST-2001-37153. Available: http://www.gemss.de/ [22] G. Graschew et al., “VEMH-Virtual Euro-Mediterranean Hospital and Medical Grid,” Proc. of Interoperability for Enterprise Software and Applications Conference (I-ESA'06), March (2006): 2224. [23] C. Barratt et al., “Extending the Grid to Support Remote Medical Monitoring,” Proceedings of the 2nd UK e-Science All Hands Meeting (2003). [24] M. Venkateswara Reddy, A. Vijay Srinivas, Tarun Gopinath and D. Janakiram “Vishwa: A reconfigurable P2P middleware for Grid Computations,” in Proc Intl. Conf. on Parallel Processing (ICPP'06), pp. 381-390, 2006. [25] D. Janakiram and R.K. Joshi, "Anonymous remote computing: A paradigm for parallel programming on interconnected workstations," IEEE Trans. on Software Engineering, vol. 25, no.1, pp. 75-90, 1999 [26] Sriram Kailasam, Santosh Kumar and D. Janakiram, “Mobile Telemedicine using Data Grid,” presented in International Conference for Communication, Convergence and Broadband Networking (ICCBN 08), July 2008. [27] K. Ganapathy and A. Ravindra, "M Health, A potential tool for Health Care Delivery in India," presented in Making the ehealth connection: global partnerships, global solutions, United Nations Organization, Rockefeller Foundation, Bellacio, Italy, Jul. 2008. [28] Antony I. T. Rowstron, Peter Druschel, “Storage Management and Caching in PAST, A Large-scale, Persistent Peer-to-peer Storage Utility”, ACM Symposium on Operating Systems Principles (SOSP) pp.188-201, 2001. [29] Anwitaman Datta, Manfred Hauswirth, Renault John, Roman Schmidt, Karl Aberer: “Range queries in trie-structured overlays”, In P2P Computing, pp. 57-66, 2005 [30] Tae-Ho Kang, Carey Merritt, Burcak Karaguzel, John Wilson,Paul. Franzon, Behnam Pourdeyhimi, Edward Grant, and Troy Nagle, “Sensors on Textile Substrates for Home-Based Healthcare Monitoring,” in Proc. 1st Distributed Diagnosis and Home Healthcare (D2H2) Conference, Arlington, Virginia, USA, April 2-4, 2006. [31] BioComfort Health Manager. Available: http://www.biocomfort.com