Subject: How this might fit into Jini

From: Saleh Elmohamed <[email-masked]>
Date: Sun, 16 May 1999 20:29:21 -0400

Hi Michael,

It was nice chatting with you a month or so ago after your
talk here in Syracuse at the open house.

I was talking with some colleagues at the medical school about
some work that they are trying to propose. After our conversation few
ideas came to mind ...

It is about medical/life-saving intelligent devices to monitor insulin
flow for diabatices, monitor the level of cholesterol in th blood, and
those 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 beat 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 or the patient without causing any discomfort whatsoever.
The second (B) will be a hand-held 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 life 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 use of its power and knowledge
to not only advice 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 it memory or DB, will come up with a decision/advice that will be
communicated back to B, simultaneously also be sent to the patient
doctor, the nearest hospital to the patient, and 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 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 has 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. 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. 

In a nutshell, that is a condensed summary of the idea...

This probably an old hat. Any comments on how this might
connect/work/operate in/directly within the Jini programming model,
are quite appreciated.

best regards,
Saleh

---

From: Mike Jones <[email-masked]>
Date: Mon, 21 Jun 1999 11:05:05 -0400

> talk here in Syracuse at the open house.

Hello; please accept my apology for taking so long to respond to this. I
mis-filed it in my torrent of email and was horrified to discover it
when I was going through some old messages.
 
> those that monitor the overall condition (heart beats, etc.) of the heart.

This sounds to me (admittedly not a Jini "expert) like a *terrific*
application for Jini.

...description snipped...

> connect/work/operate in/directly within the Jini programming model,

My knowledge of Jini is mostly conceptual; in my current job, I'm not
really involved directly with development. I'd suggest starting with
http://www.sun.com/jini and http://www.jini.org. The jini.org site
includes a lot of information about developer communities, which is
probably the best place to look to see if anyone else is working on
something similar.  If you don't find those resources very useful, let
me know and I'll see if I can find a contact in the Jini group for you
to talk to directly (and I promise it won't take so long).
-- 
	Mike Jones
	Sr. Systems Engineer
	Albany, NY
	(518) 782-1038