Subject: An idea and Jini model

From: Saleh Elmohamed <[email-masked]>
Date: Mon, 24 May 1999 16:58:33 -0400

Hi Mike,

Jim Waldo pointed out to some of your interesting work and 
mentioned that your group is looking into the use of Jini infrastructure
for some of the intelligent devices you have.

Well, I mentioned to Jim an idea I had after a conversation with some
colleagues at the informatique section of the medical school. I sought
some comments from him on how it might fit into the Jini model. 
He suggested to get in touch with you for more insightful comments about
it.
I hope you don't mind a condensed summary of it. It is probably an
old hat but here it is ...

It is about intelligent devices to monitor insulin
flow for diabatices, monitor the level of cholesterol in th blood, and
others that monitor the overall condition (heart beats, etc.) of the
heart. 

I'm sure such portable devices currently exist in the market but I don't
think they are small enough, or have enough comm/computational
power and smart software to be quite effective. Let's elaborate a 
little more here. Take those heart monitoring devices. They will
consist of two or perhaps three communicating devices. One (A) will be
small enough and light enough to be easily strapped around one of 
the arms or legs of the patient without causing any discomfort whatsoever.
The second (B) will be a hand-held (e.g. PamPilot-like) device that will
be in constant communication with A, at short as well as a reasonablely
long distance. Since both A and B will accompany the patient where s/he
goes, this aspect of communication and the protocol involved should not be
a problem. 

Ideally, through device B, the patient will be able to determine the
condition, adjust A to obtain different kind of diagnosis, blood flow
in and out, the degree of abnormality, etc. B needs to able to control A
with minimal interference from the patient, since s/he usually won't
have the necessary medical training to do the task. So, in addition to
displaying in real time data/information about the condition of the heart,
B will also have the capability to communicate with a third (C) remote
device.  
C will be stationary and at some distance from A and B. Also, C will
possess perhaps more knowledge and computional power than A and B. Since
B usually will be with the patient, it will make use of its power and
knowledge to not only advise A but also the patient in what to do in any
potential emergency case. Now, if it determines that it really doesn't
have enough info to make a judgement one way or another, it will
communicate the info it has to C. This information will include spatial or
rather geographical information on where the patient is currently. Again,
the comm protocol between B and C could be similar to that of A and B, or
may be different. Perhaps, C might be located far away from the patient,
but really distance should not be a major factor in the future. 

The job of C is to rapidly analyze the incoming data, and using the data
in its memory or DB, to come up with a decision/advice that will be
communicated back to B, simultaneously also be sent to the patient's
doctor, the nearest hospital to the patient, and perhaps to the nearest
emergency transportation services. All this has to occur within a very
short period of time. If the situation is not quite critical (a judgement
also must be made by A, B, or C) then an advice on what to do next will
either originate from B, or from C and sent to B, or from other sources
directly  communicating with C, such as the hospital, etc. 

It is possible to make do without C, just have A and B. In this case B
not only needs to have a higher computation/comm ability but also
more functionalities. In this case, B will operate without any 
interference from the patient, displaying info when desired and also
accepting input.
These type of devices may have to have:
1. CPU with high clock rate, a 32-bit inst. set will do but 64-bit
   is preferrable. Large on-chip cache (L1) and L2.
2. Perhaps, fairly large main memory.
3. Quite efficient computational/search/retrieve processes (based on
   efficient time/space algorithms).
4. High emphasis on locality, that is, very low communication between one
   side of the chip to the other so not to affect performance. 
5. Intelligent software to not only tackle the medical situation at hand 
   but also based on the current information is to decide on whether to
   communicate or not to communicate and just deal with it locally. 
6. Interface to the outside for I/O, etc.
7. If we are dealing with many devices then better if each cluster operate
   in a somewhat fedareted fashion. 
8. ...

In a nutshell, that is pretty condensed version of it. 

Any insightful comments on how this might connect/work/operate in/directly
within the Jini programming model, are quite appreciated.

best regards,
Saleh