I wonder if anyone out there has tried to reverse engineer/develop/hack the communication protocols (especially the wireless ones) on their diabetes devices? pumps, CGMs, etc. I love the idea of tinkering with a receiver that could generate twitter feeds, light up a light on my bedstand, etc. etc. - of course it opens the door to people trying to make their own closed-loop systems, which would be wicked cool, if probably deadly. ;)

Views: 891

Replies to This Discussion

Does anyone have any experience hacking low level glucometer logic? Like a possible direct interface to the strips themselves? I would love to try my hand at a sort of 'open glucometer platform'. Access to a record of previous test results is useful, but imagine how much you could do if you had programmatic access to the microcontroller ON the glucometer, at the time of test. Glucometers like the ContourUSB allow you to attach contextual information to readings, and set reminders, but if you had a programmable interface to the strips themself, you could go so far beyond this, adding dosage annotations, keeping track of inactive insulin (like some pumps), interfacing directly to online carb databases and glycemic index databases, while you are in the process of monitoring and correcting. A 'PDM', without being tied to any specific treatment method. That would be awesome.
I think some glucose meters that use strips allow for you to get the data through a PC link (RS-232, IR or USB), and use that data for graphing, set reminders, etc. If none of them offer that feature, I think it's a very interesting technolgical suggestion in your part.

As far as adding programmability to the strips themselves, my guess is that would make the strips a lot more expensive.
No no, not add programability to the strips, but rather have a glucometer that is programmable. Or, more to the point, have a programmable device, with a test strip port.

The logical interface to any given type of strip is what i am interested in, though preferably an accurate one. It would be very easy to desolder the strip port and incorporate it into a custom device, or simply fashion a port after it. Almost every glucometer i have seen, other than those that are integrated into a pump system, are about as complex as a desk calculator from the late 60s. Simply having access to the data isnt sufficient, unless it is access at the time of testing. The idea is to be able to include more annotative data, at the moment the reading is collected to give a bigger over all picture of management, and real-time feedback from a portable device to minimize error in self treatment.
Sorry. I don't understand what you're trying to explain.

I'll give it one more shot: The strips don't have intelligence (i.e. no microprocessor nor software). They are just an analog circuit (each maker is different) and each require a different type circuitry (hardware) on the glucometer side. There's no way to "interface" via software or programmability to the strips.
Right, I don't think you'll really gain anything useful by trying to manipulate the raw information and processing that the meter is doing. The meter companies might not be good at being interoperable or flexible in terms of modern "Web 2.0" standards, but they do a very good job at reading the electrical measurements from their own strips and applying their calibration curves to provide readings as accurately as they can.

I think the idea of an "open glucometer" that could read every strip out there with open firmware is a nice one. But, having all the different slots to accept different form factor strips might make such a device kinda unwieldy. If it were possible to make a useful, cheap, and moderately accurate glucose test strip at home that isn't patented, so you could truly make an open glucometer, now that would be a cool project in my opinion.

You might find the following paper interesting, titled "Glucose Test Strips and Electroanalytical Chemistry in the Undergraduate Laboratory", describing the basic function of a meter:

http://www.basinc.com/library/presentations/pdf/JOH-01.pdf

Cheers,
David
Do not confuse 'open' with 'portable'. When i said 'any given strip', i meant choosing one, not supporting all of them. Manipulating the raw data would just be an unavoidable consequence if you want to create a device that needs the data delivered in a manner that glucometers do not support. I have actually seen one glucometer (MyGlucoHealth Bluetooth Glucometer) that looks to deliver the results in real time to an external device, but i seriously question the devices accuracy. The fact that it only interfaces with one specific piece of software, that only runs on one cellphone manufacturers hardware, makes it almost unusable to me.

Sure there would be some wheel reinventing, but i have no problem with that. If you are working with a wheel off of a bicycle, it would be unwise to move it unmodified to a ferarri. The usefulness of the whole idea to me, is that there would be a cooperative platform for actual software developers, who may also be diabetic themselves, to write less awkward treatment management software for. I dont think that these kind of things are best left to device manufactuers, because the quality of what i have seen so far is not that great. And if their devices do not work well with anything other than their very narrowly scoped software, then I dont think its unreasonable to make a better wheel.
I understand. And yes, there is a way to interface via software and programability to the strips; The glucometer. However, rather than work around pre-existing glucometers, i am wondering about the feasablity of engineering one from scratch, using a micro-controller and an analog sensor interface.

I know the strips work differently, which is why i would focus on one reliable type. The abbott Precision Xtra strip has a very simple interface, and incorperates 1 strip interface for both blood ketone measurement and blood glucose. I did actually find a whitepaper on _basic_ 3 contact test strips. Interfacing with the strip is not rocket science at all.

I think the 'logical interface to the strip' part is what you are getting hung up on. I am not implying that there is a computational component 'on' the strip, just that it would not be difficult to create your own device to interface 'with' the strip.
I totally agree! And yes, that is a good idea to focus on a single strip type but make the device your own. I'd say this conversation is the beginning of the low-level glucometer hacking you seek.

The paper that I recently linked to describes several of the pieces that go into reading blood glucose concentrations electrochemically and then manipulating the readings into a useful number. It might be easier to start by just trying to interface with the micro on a meter and to use an oscilloscope.

It would be a really fun project! I don't see why an Arduino couldn't handle it.
Just started on the new Veo (Paradigm 754) here in Canada. It does have new functions including trending functions with alarms, and the ability to set these at several different levels.
There's also pretty good pdf's out there on the calibration algorithms used on the machine.
I haven't dug into it, but the info on the Carelink site is also available in CSV mode, so at least there's the possibility of working with that data to test your own algorithms rather than altering any machines. I'd rather mess up an Excel spreadsheet than any part of this (extremely expensive) mess.
Rigging a device to read the rf signal is really interesting. I'm going to save all the info on the frequencies! At least that helps us to know better what might mess with it.
I'm marginally let down that there doesn't seem to be any way the manufacturer can update software on the pump, so you would need to buy a new device to get any improvements in, say, a year's time. Also the software doesn't seem to use any user history older than 1 day to set anything like a profile. Even 20 years ago we had inventory programs that could develop profiles and forecast orders for new merchandise in the retail sector. That software was way better than what seems to be running these machines.

turnershells
I like the idea of doing software upgrades for the pumps or PDMs out there, by connecting it to a PC and the web to get a software update. There were talks about that at Insulet but I don't know if they are planning on offering that feature.
AndyRozman,

Yes, it would be great if the protocol you mentioned (to communicate with the PC) were standard. That way you could get the data from different devices with the same PC software, graph it, etc. It would be nice if some of the device companies agreed on that, since it does not offer any safety hazards.
There has been a significant amount of effort poured into standard methods for sharing medical data electronically. Some examples are HL7 and IEEE 11307. Check them out on Wikipedia. I'm sure there are more, but I have no idea how far along any of these protocols are from acceptance by vendors and any actual products supporting them.

The best thing we can do right now, if you don't work directly with the development of these standards or medical devices, is to tell your diabetes vendor that you want these features in their next product! Consumer medical technology will grow and will need to have useful features like all the other modern technologies we use so we can learn more about ourselves and better manage our lives.

RSS

Advertisements



TuDiabetes Team

DHF STAFF


Manny Hernandez
(Co-Founder, Editor, Patient)
Andreina Davila
(Co-Founder, Patient Spouse)
Emily Coles
(Program Manager, Patient)
Emily Walton
(Office/Volunteer Coordinator)

DHF VOLUNTEERS


Lead Administrator
MelissaBL

Administrators
Bradford
Gerri
Lorraine
Marie B
Teena

Spread the word

Loading…

This website is certified by Health On the Net Foundation. Click to verify. This site complies with the HONcode standard for trustworthy health information: verify here.

© 2012   A community of people touched by diabetes, run by the Diabetes Hands Foundation.

Badges  |  Contact Us  |  Terms of Service