[Novalug] Diabetes Software chance

Sun Jul 22 18:32:18 EDT 2007

The reason I mention Java is 1) I know the language, 2) it's portable,
3) it has GUI tools for all platforms. I don't like the idea of a
compiled program at all; it's going to be too tied into the particular
platform.

>> I wrote Abbott Diabetes Care - who produces the meter I use myself and
>> asked. And they're more than open to the suggestion of releasing the
>> specifications/protocols to talk with the Freestyle family meters.
> 
> This is actually very good of them. I have no idea what that meter looks
> like and how it communicates, but it's all bits and bytes, so when you
> have the specs you should be able to convert whatever it gives
> you (presumably, blood glucose levels, in some coded form).

Yes, I was VERY surprised that they're open for this. They surely
deserve kudos for that move. I've only had 3 different meters; they've
all used a serial interface. The meters are pretty small. In the last 5
years they've gotten to the size of a wrist-watch. They have a little
display on them, and keep a short list of the history of the tests
you've done. Most meters even show you an average. Some can even show
you morning, afternoon and evening averages. The meters used to be very
dumb - with time they're getting smarter. They can't visulize trends.
And their small LCD display are very limited. Because the meters must be
simple to use, they have few buttons.

The software on the computer compensates for this. It downloads the
data, binary I assume (I don't know) with timestamps and meter
configuration information, that shows what unit of measure has been used
and sometimes a few meter specific configuration information. There are
meters where the software can actually configure setup information, such
as date/time, unit of measure and preset times to "beep" to remind the
user to take blood samples. The software makes it easy for the user to
set it up, instead of pushing small buttons on the meter.

Most records are pretty straight forward: date/time/result

> My suggestion? ascii. What you want from your meter is, presumably,
> a number, the glucose level in whatever units you want (I'd favor
> kg/m^3, but I'm sure the medical community uses some weird, non-standard
> unit like mg/l). You can call it something like 'glucose.dat'.
> You can read it with an editor: no further coding necessary, and it's
> not even necessary to plot it out. You can add a time and date stamp,
> your body temperature, or anything else that you may want.

While ASCII is a good suggestion, it has several short comings. But an
open format is a must.  I'm thinking XML for now, or some other easily
read format. One of the short comings of ASCII is the lack of character
set encoding. XML solves that.

However, since the data needs to be diesected by the software, I was
thinking a small database like feature was needed. Not necessarily a
MySQL or full blow SQL solution, but something that makes
searching/collecting data in a large data file easy; and something that
makes it possible to store the data on multiple platforms.

> With other meters you'd have to figure out what their
> bits and bites coming into the computer mean, and convert this to
> glucose data. So, you'd need their protocols too, but, once you
> are done and you got your ascii file, you are done.

Correct - each meter will be coded to a common interface. Java makes it
easy to make those kind of plugins (i'm sure that's a feature of other
languages too).

But it needs to be in one application. Not a mix/match of 3-4 different
applications a user must use individually. That won't sell for doctors
and patients, unless they happen to be bitten by the same geek gene as I
am. If you can't download the meter by simply going to the menu and
choose 'download' that will exclude most potential users. Once the
specification and classes have been done, making a runtime interface
from the command line is pretty easy.

> From what I read on Abbott's Co-Pilot page (is that the unit you have?),
> their program does little more than plot the data, as a line graph, a
> bar graph, a pie chart, whatever. GNU/linux comes with various
> plotting packages that take ascii files. The one I use is xmgrace
> (in /usr/bin/xmgrace: type 'xmgrace' a the prompt, 'man xmgrace', etc.,
> the usual linux stuff).

Abbotts software is one of the worsts I've seen. The only interesting
aspect is that a doctor can use it to register multiple patients. But
since he can't import individual meters from files, and requires
physical access to each meter, I doubt very much any doctor is really
using it. And when you as a user have to register yourself as a
"patient" things sorta gets a little iffy ;)

There's more to it than just graphs. There's disecting data on "last
week", "last month" etc., calculating averages, min, max, and plotting
trend lines. To my knowlege there are Java modules to create graphs too.
But how would you integrate external programs like xmgrace into a common
application?

>> features for diets and other medical records could be added.
> 
> That's something else. Presumably, those data are available and all
> you'd have to do is to copy them, and have a program to call up the
> relevant ones (like: if the glucose level is this high, then look
> at that file). This is where it gets complicated, and I bow out.

No, only meter data is available on the meter. The rest would be the
user entering. Such as weight, meals and meal times etc. If it later
could calcuate nutritional value of the meals it would improve even
further the QOL for the user. Most type II diabetes people like me,
manage via diet and a little bit of medicine.

Thanks for your good suggestions ...

Regards
  Peter Larsen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGo9ryHbLDna3OFD0RAqPBAJ9dteypvKxbt5ALyRzl+PwwBv9FrQCgiTc5
H36+fQ4aQB9zhHFmOIuV4fA=
=HYf6
-----END PGP SIGNATURE-----