the european commission 's health care telematics programme   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 .
the primary health care providers in the rural areas are mostly inexperienced . in india ,
about 70% of the population live in the rural areas while 75% of the doctors practice in the urban centers [ 3 , 4 ] .
all the above - mentioned facts make telemedicine an appropriate technology for developing countries , particularly india .  
the last decade has seen the emergence of many telemedicine setups all around the world [ 5 , 6 ] .
a typical system involves a small set of hospitals providing remote healthcare services to a small section of the population using satellite technology , nodal centers , mobile health units ,   and so forth .
large - scale systems enable a large pool of doctors and hospitals to collectively provide healthcare services to entire populations .
this significantly increases a patient 's chances of receiving high quality care even when specialist doctors are not available nearby .
a large - scale telemedicine system is more capable of supporting increasing numbers of patients and is more robust against failures and attacks .  
now , central server - based systems have single point of failure and can not scale to huge number of requests .
this was confirmed by a survey conducted by intel ( one of the project sponsors ) of the telemedicine infrastructure at narayana hrudulaya ( nh ) , a world - class cardiac hospital .
the nh telemedicine infrastructure is supported by the asia heart foundation and the indian space research organization ( isro ) to provide satellite connectivity between bangalore and several parts of india and even neighboring countries .
a nodal centre is created in a local hospital in these remote areas where doctors and patients can directly interact with specialists at nh .
the remote ecg unit can either directly dial into the nh server or access the internet and send its request to the nh server through an ftp interface . on an average day ,
80 ecg reports are received and processed at nh . however , as the number of telemedicine units ' increase , the nh centre at bangalore becomes a bottleneck .
besides , the doctor must be physically present at the hospital centre to deliver responses promptly .
this requirement ( of doctor 's physical presence at the hospital centre ) hampers the number of doctors that can provide service .
thus we conclude that a scalable solution must not be based on a central server and it must facilitate specialists to provide service from wherever they are .  
hence , we envision a large - scale telemedicine solution consisting of multiple hospitals ( across the country ) acting as peers . as of now , there is no dedicated infrastructure connecting all the hospitals in the country .
hence , we propose to support telemedicine services with p2p technologies using the internet as the backbone .
this will facilitate cost - effective utilization of the existing hardware resources and in future ( if at all ) an easy integration with dedicated infrastructure .
the recent advances in broadband technology for mobile phones add a new dimension to telemedicine by facilitating any time - anywhere computing .
now , the specialist located anywhere could use his mobile device to access the patient reports via the internet and provide advice .
with wimax / gprs capable of providing cheap internet access in rural areas , it is possible to provide mobility support even at the patient 's end .
this will enable a nurse - led mobile telemedicine unit and lead to better coverage in the rural areas .  
in this paper , we present arogyasree ( arogyasree means  good health  in sanskrit ) , a context - aware , p2p grid framework for mobile telemedicine .
this internet - based scalable system integrates multiple hospitals , mobile medical specialists and rural mobile units / clinics to form a large virtual enterprise . the current version of the telemedicine system is based on the store and forward model 
the bio - medical signals of the patient are stored in the data grid and then scheduled to an appropriate doctor .
health workers carry portable instruments for measuring vital health parameters such as blood pressure , ecg jacket , blood sugar , and weight .
these devices are wirelessly connected with a smartphone / pda , which uploads the data into the grid .
the context - aware grid scheduler matches the request context to the nearest available doctor and notifies him via email / sms .
the doctor then makes an evaluation of the measured data and provides consultations by telephone / internet .   
first , it discusses the design of a distributed context - aware scheduler ( using tuple spaces ) that considers parameters like proximity , patient history , severity of ailment , and so forth to locate appropriate doctors .
many existing telemedicine solutions have overlooked the problem of context - aware scheduling of patient requests or have addressed it minimally .
attempts like   to integrate vital sign sensors into textiles ( to continuously monitor the patient ) will generate huge amount of data , and hence locating an appropriate doctor becomes important .
second , the system provides an easy - to - program abstraction for building applications .
basically , it supports a persistent object - space abstraction for the storage of medical data on the grid .
third , it uses a unique - zone based overlay structure ( vishwa ) that ensures proximity in routing as well as storing data . the proximity - aware overlay structure and the scheduling mechanism
finally , the solution uses the existing internet infrastructure and supports mobility at doctor and patient ends . all the above features sum up to make arogyasree an appropriate architecture for large - scale p2p grid framework for telemedicine .
section 4 discusses the application scenarios , the implementation details , and limitations of the proposed system .
we compare arogyasree with the existing telemedicine solutions with respect to scalability , context - aware scheduling of patient requests , coverage of the system ( mobility enhances coverage of the system ) , telemedicine services , infrastructure ( dedicated versus nondedicated ) , and so forth .  
telemedicine solutions such as [ 5 , 6 , 10 , 11 ] use dedicated hospital nodes as centers for providing telemedicine service .
they require the specialist to be available at the centre whenever the data is received to ensure that the advice is sent within few minutes . but with the widespread use of mobile communication devices , the reports can be delivered on to the handheld of a specialist , who may be located , anywhere .
it also supports mobility in the patient side thereby improving the coverage in rural areas .
solutions like [ 1315 ] also support mobility in the patient side . in , they use wireless ad hoc networks and grids at the patient side
. however we have modeled the patient - side resource - constrained mobile device as external entities ( not as peers in the grid ) to improve the grid stability .
but our solution incorporates multiple hospitals working collaboratively within the grid providing a farther reach to the target community .
solutions like [ 16 , 17 ] also use interconnected hospitals to provide medical service .
both these solutions , however , do not support mobility on the doctor side as they use video conferencing as a primary mode of patient - doctor interaction .
additionally ,   requires dedicated communication infrastructure linking the hospitals whereas our solution is built on top of the internet . in
[ 11 , 15 ] , a central server is used to handle the incoming requests .
this makes them inherently nonscalable restricting their scope as a solution for a large - scale global health grid .
our solution uses multiple zonal servers from various zones to distribute the handling of requests , thereby providing scalability .
the solution in   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 solutions also differ in the manner in which patient requests are forwarded to the doctors . in ,
a dedicated medical call center comprising of medical practitioners attend to patient requests and forward them to appropriate doctors .
but the manual intervention in forwarding the requests makes the system expensive as well as less scalable . in another approach ,
the system 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 .
solution in   does not address the need of a patient - doctor meeting as its primary aim does not require it ( military application ) .
but in our case the patient may need to consult the doctor in person depending on the ailment .
hence scheduling is implemented in 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 is used in our solution .  
many of the solutions utilize medical grids for computational purposes only as in [ 19 , 20 ] .
but we have also used the grid for storage of patient records , request forwarding , and load balancing .
further , none of the above solutions effectively address the possibility of a group of hospitals becoming overloaded occasionally .
this requires the request to be stored temporarily to ensure proximity and later forwarded to the global grid after a specified time - out to ensure timely service .

				 in this section , we present the architecture of arogyasree , a large - scale p2p data grid framework for telemedicine .
we primarily focus on the overlay structure , persistent object - space abstraction , context - aware scheduling , and storage management .
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   and this is a unique opportunity to build one .  
the telemedicine system classifies resources into two types : data storage resources ( nodes contributed by hospitals ) and medical resources ( doctors with mobile device ) .
the data storage resources are modeled as peers in the telemedicine grid while the medical resources are modeled as external entities which contact or are contacted by the grid nodes for providing / accepting services .
the data grid provides a persistent object - space abstraction that allows us to model real - world entities like patients , doctors , and so forth . as objects and
we use a unique zone - based overlay structure ( a zone is formed by grouping geographically closer nodes ) like in vishwa .
the data of patients belonging to the geographical region covered by the zone is replicated on nodes within the zone to ensure replica proximity ( efficient updates to data ) .
few replicas are also maintained in other zones to ensure data availability in case the entire zone gets disconnected .
since the patient data can be distributed on the grid , the system provides clustering mechanisms to enable efficient retrieval of patient history and is discussed in section 3.3.3 .
the zonal server acts as patient request gateway or entry point for the patient requests .
the hospital representative ( per hospital ) provides an interface to the doctors to indicate their availability .
it also periodically advertises the aggregate availability information ( of doctors ) along with a list of capable nodes to the zonal server ( henceforth , referred as resource advertisement ) .
the idea is that the capable nodes in terms of cpu and memory utilization ( at that point of time ) will be used to serve the patient requests .
the grid nodes are nodes other than the zonal server and are used for storage and computation .  
we propose a distributed context - aware resource discovery mechanism to schedule the requests as centralized schemes do not scale with the increasing number of requests / resources and have a single point of failure . in our scheme ,
the zonal server ( request gateway ) accepts the location coordinates and the area of ailment and redirects the request to one of the capable nodes advertised by a proximal hospital within the zone .
that node receives the patient request object ( the upload bandwidth of the capable node is used to accept patient request file and not the zonal server 's ) .
it considers context parameters like patient history , language , severity of ailment ( emergency / normal ) , and so forth and selects an appropriate doctor from its local resource information for scheduling .
if there is none available , then tuple spaces are used for temporary storage and forwarding as discussed in section 3.4.2 .  

roughly , a zone spans across a state or a group of cities depending on the population of the region , the number of hospitals in that region , and so forth .
thus proximal nodes are part of the same zone . as seen in figure 3 , each node participates in two overlays , viz . , pastry   within the zone and chord   across zones .
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 .  
the number of nodes in a single pastry overlay is equal to the number of nodes in the zone .  
the number of nodes in the chord overlay is equal to the number of 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 
 ( 1)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  ( kz ) = log  ( n ) , which is the same as that of a single large overlay .
the benefits of such an overlay structure are as follows intrazonal routing ( i.e. , message routing between nodes belonging to hospitals within the same zone for replication or scheduling ) does not pass through nodes outside the zone , thereby saving bandwidth and ensuring proximity in routing interzonal routing : the message is first routed to the closest node in the same zone using pastry and then to the destination node using the chord finger table of the closest node .
more details are available in . 
					 in conclusion , this overlay structure ensures efficient routing . besides
, prefix - based routing in pastry is exploited for clustering the request objects of a patient ( patient history ) and load balancing as explained in section 3.3.3 .
chord is used across zones because it ensures correctness in routing even if very few routing table entries are correct ( lazy maintenance for the chord neighbors across zones ) .
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 .  
every object to be stored on the grid is assigned a unique identifier ( by prefixing the zone i d to a quasirandom identifier generated using sha-1 ) .
the object replicas are stored on k - closest nodes ( in the i d space ) within the zone ( pastry ) .
the object is also replicated on  c  successors in the chord ring to handle disconnection of the entire zone in the event of network outages / disasters .
the system also supports on - demand replication ( for optimization based on the access pattern ) .
the telemedicine grid provides a persistent object - space abstraction , that is , the patient profile , treatment profile , patient request , and doctor profile , and so forth can be modeled as objects ( inherited from a sharable class ) .
for instance , figure 4 shows the structure of patient profile , treatment profile , and request object used in the telemedicine system ( along with their id - generation mechanism for clustering ) .
the patient profile stores general information about the patient and references to other treatment profiles ( cardiology profile is one of such treatment profiles ) .
for example , the cardiology profile will maintain references to patient request objects containing ecg along with the corresponding diagnosis and prescription .
it also supports a generic ( attribute name , value ) field which 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 example , blood pressure value is a string , whereas ecg will be stored in a file .
however , dht - based storage mechanism does not support clustering ( patient objects may be stored anywhere on the grid ) because it uses consistent hashing techniques like sha-1 for key generation .
we modify the id - generation scheme in the telemedicine system as shown in figure 4 .
this clusters the patient data and also ensures almost uniform distribution of objects over the object i d space .
recall that prefix - based routing ( pastry ) is used within the zone . in pastry ,
two keys that differ only in the lower order bits ( say x ) will be stored within x hops of each other . in figure 4 ,
the patient profile object is assigned a random i d ( patient i d ) using sha-1 ( the last few bits are masked by zero ) .
the treatment profile ids are created by masking the last b bits of the patient i d with the treatment code ( every treatment area has a unique treatment code ) .
the patient request i d is generated by inserting the visit number after the p - bit random patient i d hash .
this ensures that the request objects are spread out in comparison to the treatment profiles because their i d prefix matches the patient i d in fewer bits .
this is the desired behavior since the doctor needs only aggregate history information available in the treatment profile while providing consultation .
now , statistical variation in the node ids and object ids as well as variation in the object sizes ( ex .
hence , the telemedicine system incorporates replica diversion and file diversion schemes similar to that in past .
thus context - aware scheduling attempts to schedule the patient request to an appropriate doctor by considering context parameters like severity of ailment ( normal / emergency ) , area of treatment , location of the patient , treatment history , language , and waiting time of the request .
the scheduling mechanisms must handle normal as well as emergency situations in a timely manner by scheduling themto the nearest available doctor.the system must also improve the doctor 's efficiency by reducing the system 's response time .
this calls for node capability - aware request placement , pre - fetching of patient history , client - side caching , and so forth are discussed in the following section .
the mobile doctors update their status ( free / busy ) through the mobile client application at the nearest hospital representative node .
the hospital representative periodically publishes the doctors ' availability information and a list of capable nodes at the zonal server .
the size of the advertisement is less than 100  bytes and the number of hospitals per zone is of the order of 10 .
hence , when a patient request arrives ( containing the location coordinates , area of treatment ) at the zonal server , it redirects the request to a capable node registered by a nearby hospital ( having free request slots ) .
thereafter , the capable node accepts the patient request object and simultaneously fetches the patient history from the grid ( dht - lookup with the patient i d ) .
next it composes the patient history and the request object into a single web page and locally hosts it .
at this point , it acknowledges the client application ( patient side ) with the patient request i d , thereby completing the request upload process .
next , it provides the context parameters to the hospital representative which returns an appropriate doctor ( doctor profile object is used for matching ) .
once the response is received , the request object is updated and the health worker is notified . since all of the above are short - running tasks , it is reasonable to assume that the node remains capable and ensures best response time to the clients .
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 ( preemptive way ) if it is an emergency ; or else some delay ( from field study ) is tolerable .
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 .
the doctor - side application informs him of the emergency and allows him to preempt the current request and serve the emergency .
if no doctor has downloaded the patient object within a threshold , then the request is rescheduled to double the number .   in the normal mode ,
if he recommends further consultation , then the specialist class field of that request is set and the request is rescheduled .
scenario 1 implies that the patient request can be immediately scheduled . in scenario 2 ,
so the capable node inserts the request tuple ( request i d , age ) into a location - wise tuple space .
( a ) realization of location - wise tuple spaceit is implemented on top of dht ( within the zone ) .
the request tuple is inserted with a key equal to hash   ( location , area of treatment ) .
the node to which the request tuple maps maintains a sorted list of tuples based on the age field .
now , every hospital polls the location - wise tuple spaces ( of nearby locations ) for any unfulfilled request with a frequency proportional to ( number of requests  average age of requests ) that location .
if the request has aged beyond a threshold , then that request is made available globally ( global tuple space ) .
thus , it acts as a hint to the zonal server to redirect requests from that location to some other hospital . 
 
the request tuple is inserted with a key equal to hash   ( location , area of treatment ) .
the node to which the request tuple maps maintains a sorted list of tuples based on the age field .
now , every hospital polls the location - wise tuple spaces ( of nearby locations ) for any unfulfilled request with a frequency proportional to ( number of requests  average age of requests ) that location .
if the request has aged beyond a threshold , then that request is made available globally ( global tuple space ) .
thus , it acts as a hint to the zonal server to redirect requests from that location to some other hospital . 

( b ) realization of global tuple spaceglobal tuple space is realized within and across zones for each area of treatment ( e.g. , eye , heart , etc . ) .
each area of treatment is assigned a treatment code which is hashed using sha-1 to produce a treatment hash . from every zone , the node whose i d is the closest to the treatment hash holds all the aged request tuples for that area of treatment in that zone .
we shall refer to it as local zone node i d . likewise , the zone whose i d is the closest to the first z  bits ( z is the number of bits in the zone i d ) from the treatment hash is chosen as the global zone for that area of treatment .
the node within that zone which is closest to the hash of the treatment hash ( rehashing ensures that the node chosen for global space within the zone and across zones is different ) stores the request load from all zones for that area of treatment .
henceforth , this node i d will be referred as global zone node i d .
the local zone nodes advertise ( zone i d , request load ) to the global zone node i d 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 only the request load is stored at the global zone node i d .
now , the zone having free request slots can query the global zone node i d to find out the overloaded zones and serve their pending requests .
but if every hospital node within a zone was to query the global zone node i d , then it would become a hot spot . to handle this , the local zone node within each zone acts as a request collector .
it accepts request subscriptions , that is , ( hospital node ip , free request slots ) from the hospital nodes .
periodically , it contacts the global zone node i d to fetch the overloaded zone ids and then fetches the request ids from the corresponding local zone node i d .
global tuple space is realized within and across zones for each area of treatment ( e.g. , eye , heart , etc . ) .
each area of treatment is assigned a treatment code which is hashed using sha-1 to produce a treatment hash . from every zone ,
the node whose i d is the closest to the treatment hash holds all the aged request tuples for that area of treatment in that zone
likewise , the zone whose i d is the closest to the first z  bits ( z is the number of bits in the zone i d ) from the treatment hash is chosen as the global zone for that area of treatment .
the node within that zone which is closest to the hash of the treatment hash ( rehashing ensures that the node chosen for global space within the zone and across zones is different ) stores the request load from all zones for that area of treatment .
henceforth , this node i d will be referred as global zone node i d .
the local zone nodes advertise ( zone i d , request load ) to the global zone node i d 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 only the request load is stored at the global zone node i d .
now , the zone having free request slots can query the global zone node i d to find out the overloaded zones and serve their pending requests .
but if every hospital node within a zone was to query the global zone node i d , then it would become a hot spot . to handle this , the local zone node within each zone acts as a request collector .
it accepts request subscriptions , that is , ( hospital node ip , free request slots ) from the hospital nodes .
periodically , it contacts the global zone node i d to fetch the overloaded zone ids and then fetches the request ids from the corresponding local zone node i d .
( c ) load balancing of the local zone node i d and global zone node idin the above scheme , the local zone node i d and the global zone node i d are potential bottlenecks .
this problem can be alleviated by choosing multiple node ids distributed in the node i d space as request collectors .
we exploit the property that two keys ( in pastry ) which differ in the higher order bits will be mapped to two different nodes that are wide apart in the node i d space .
we decide the number of leading bits ( say d ) based on the request load within the zone .
similarly , when the request load goes down , a merge process is initiated and a new value of d is calculated . the information stored at the global zone node
( zone i d , d ) does not change frequently and hence the global zone node replicates this information on its in - degree nodes .
thus queries from local zone nodes do not necessarily have to reach the global zone node and load balancing is achieved .
the local zone node i d and the global zone node i d are potential bottlenecks .
this problem can be alleviated by choosing multiple node ids distributed in the node i d space as request collectors .
we exploit the property that two keys ( in pastry ) which differ in the higher order bits will be mapped to two different nodes that are wide apart in the node i d space .
we decide the number of leading bits ( say d ) based on the request load within the zone .
similarly , when the request load goes down , a merge process is initiated and a new value of d is calculated . the information stored at the global zone node
( zone i d , d ) does not change frequently and hence the global zone node replicates this information on its in - degree nodes .
thus queries from local zone nodes do not necessarily have to reach the global zone node and load balancing is achieved .
details of this scheme are available in . standby nodes ( initially configured by administrator )
are maintained to recover from zonal server failures while the grid node failures are handled as in pastry and chord dhts .
the telemedicine report to congress   defines information privacy as  the ability of an individual to control the use and dissemination of information that relates to himself or herself  .
privacy is ensured by maintaining the confidentiality of patient data , which means that specific controls are exercised on access and disclosure of patient data .
security means protecting both the system and the information from unauthorized access ( misuse and damage ) . in the context of indian rural population ( where 1 out of 6 dies in rural areas due to lack of health care facilities ) saving lives is more important than the privacy of data .
so , we provide very basic authentication schemes as part of the prototype . however , we outline one scheme which we would like to incorporate in the near future . at a higher level
, the telemedicine grid preserves the anonymity of the patient as there is no direct interaction between the doctor and the patient . instead
, the interactions are patient - grid and grid - doctor ( unless during emergencies ) .
besides that , the patient data visible to the doctor does not include patient identifiable information like his name , address , and so forth .
minimally , the doctor , the health worker , and the patient are authenticated by the system before they can perform any operation .
we now identify the vulnerabilities in the telemedicine grid system and outline a security scheme for maintaining the confidentiality of patient data .
the patient data can be tampered / misused at the entry point ( health worker ) , during transit , or by the doctor or within the grid system .
basically , the vital parameters captured by the electromedic devices are transferred via bluetooth to the health worker pda , thereby eliminating any manual entry . at this point
next , the health worker 's session key is used to calculate the request message hash and transfer it to the grid .
this maintains the integrity of the patient request during transit ( data transferred from the health worker device ) .
now we are trying to integrate proxy re - encryption schemes like in   into the system . in this scheme ,
the patient data in the system is securely locked with the patient 's public key so that no intruder can access it .
while access needs to be given to the selected doctor , the patient computes the reencryption key from his private key and the chosen doctor 's public key .
the grid uses this reencryption key to provide access to the doctor without compromising the patient 's private key .
there are many variants of the proxy reencryption schemes some of which can allow access to the doctor only for a certain period of time .
our proposed telemedicine framework benefits both doctors and patients by improving their efficiency in terms of time , money and the medical consultation process .
this nonvideo telemedicine framework works well for most cases ( emergency / general consultations ) .
we present a comparison of the existing medical system and the change brought about by introducing our model .
people in rural areas approach local doctors for diagnosis of an ailment . if local doctors ( with limited knowledge ) are not able to diagnose the problem , they direct the patient to visit a specialist in the city .
this requires that the people from the rural area move to the city incurring huge cost and inconvenience . in most cases
, the aliment would not be severe enough for an advanced medical procedure . as a result
this inhibits the rural people from going to the city for further check - up and results in gross neglect of individual health . in case of emergency situations
a ( mobile ) health worker equipped with the basic medical kit is placed within the reach of rural masses .
now , the rural patient has the facility of remote consultation using our telemedicine grid where the details of the patient 's records are made accessible for the volunteering doctors .
consultation charge can be obtained from the patient to be reimbursed between the doctor and other entities involved .
but such an amount is considerably less than the costs incurred otherwise by the patient who visits a city doctor . on the other hand , forwarding the patient to the relevant doctor and following a hierarchy structure among the doctors result in optimal usage of their resources . in emergency cases
the health worker contacts those doctors who are in emergency - response mode to take their advice in giving first - aid treatment to the patients .
the hospitals which contribute resources to the grid can reach patients who require high - end medical treatment through remote consultations , thus improving their capacity utilizations .
such a grid also provides the patient with a choice of services from multiple hospitals .
the uniqueness of our system is in scalability , cost - effectiveness and reliability provided by using the grid .
grid technology improves the processes involved in providing telemedicine services while improving the scalability of the system and reducing the costs , which are the two critical factors in the success of a telemedicine system .  
phase i or pilot testing would mainly cater to rural areas , whereas phase ii would extend to urban areas and would even incorporate continuous monitoring of patient health using wearable devices .
the scheduling approach proposed in this paper can facilitate context - aware discovery of doctors for each of the above cases .
the end - to - end telemedicine system was demoed in cebit 2009   ( setup shown in figure 1 ) .
the arogyasree project is collaborative work with professor wilhelm stork 's team at the university of karlsruhe , germany .
the jacket supports a bluetooth interface that can transfer ecg data to the smart phone which can then upload it on the grid .
this jacket can also be used for the continuous monitoring of a patient 's ecg in a nonintrusive manner and without requiring hospitalization .
other vital parameter measuring devices like bp , and blood glucose are available as part of the biocomfort kit .
thus , ecg , bp , and blood glucose measurements are included in the current version of the telemedicine system .
the grid middleware is implemented in java and provides access to the patient records via web - based interface ( apache web server ) .
the patient data is stored in the form of xml files that can be aligned as per the hl7 cda architecture .
the system does not support real - time video conferencing and is based on a store and forward model .
however , if the necessary infrastructure is in place at the rural centre , it may be supported externally to the system .
we are looking at microhealth insurance models on the health grid as one of the approaches . integrating patient smart cards , easing the doctor registration , and so forth
the data size of the objects for mobile telemedicine can at most be few mbs , because of constraints of bandwidth for the mobile device .
in our case , the dual - channel ecgs captured for a period of 1 minute at 250  hz frequency are approximately 64  kb size .
the central server is a quad core with 4  gb ram , while the grid comprises of 6 nodes that include p4s , dual core machines with 1  gb ram each .
figure 7(a ) compares the average response time of the requests for the central server and the grid .
beyond 400 parallel requests , the response time slightly improves but the percentage of requests dropped increases as shown in figure 7(b ) ( the connection time - out is set as 10 seconds and so the requests are dropped ) .
around 600 parallel requests , the percentage of dropped requests becomes more than 35% for the central server , whereas for the grid of 6 machines with 1 machine acting as the zonal server and redirecting the requests to the capable node , the failure rate is under 6 percent for even 700 requests .
we deployed the telemedicine grid on 20 machines in our lab and measured the response time for fetching the patient history under different request loads ( 1001000 parallel requests ) with an average of 0.1 million objects per node ( total = 2 million objects in the grid ) .
it does not change significantly even if the average number of objects per node is increased to 0.5 million , since the grid is realized as a persistent object space and only the local disk access time increases with the number of objects stored .
the dht lookup time depends on the routing hops which is proportional to the log of the number of nodes in the overlay . for zone size of 1000
since most of the requests are satisfied within the zone , the routing overhead is low .   
typically , a zone would span a city , and hence interzonal requests ( across nearby cities ) will incur an internet delay ( typically ~50  ms ) .
so we emulated the internet delay for interzonal request by setting it around 50  ms .
next , parallel requests are started from a zone for objects stored in other zone and the lookup times are measured .
the average lookup time up to 150 parallel requests is shown in figure 9 .  
we observe that the average lookup time for interzonal requests is less than 5 seconds for up to 150 requests in parallel .
note that the interzonal routing occurs only when there are not enough resources in the zone .
we also presented the design of a distributed context - aware scheduler ( using tuple spaces ) that considers parameters like proximity , patient history , severity of ailment , and so forth to locate appropriate doctors .
the context - aware discovery of doctors can ensure timely fulfillment of requests and even reduce the cost .
it becomes more important in the case of continuous monitoring when alerts need to be suitably addressed .
next we presented the zone - based overlay structure that ensures proximity in routing and storage .
this zone - based architecture has been successfully used in our earlier work ( vishwa ) on p2p computational grids .
thus this architecture for a large - scale telemedicine grid will allow us to leverage the distributed resources for both data storage and computation , thereby aiding medical research communities .
our future work consists of conducting field trials , improving the user interfaces / security and integrating microhealth insurance models .
 a typical telemedicine system involves a small set of hospitals providing remote healthcare services to a small section of the society using dedicated nodal centers . however , 
 in developing nations like india where majority live in rural areas that lack specialist care , we envision the need for much larger internet - based telemedicine systems that would enable a large pool of doctors and hospitals to collectively provide healthcare services to entire populations . 
 we propose a scalable , internet - based p2p architecture for telemedicine integrating multiple hospitals , mobile medical specialists , and rural mobile units . 
 this system , based on the store and forward model , features a distributed context - aware scheduler for providing timely and location - aware telemedicine services . 
 other features like zone - based overlay structure and persistent object space abstraction make the system efficient and easy to use . 
 lastly , the system uses the existing internet infrastructure and supports mobility at doctor and patient ends . 
1. Introduction
2. Related Work
3. System Model
4. Application Scenario, Implementation, and Limitations
5. Performance Studies
6. Conclusion