It's based on beaglebone and node.js. Basic prototype consists of reverse port forwarding via ssh the port that tty.js is running on to a location of my choosing. From there, I can browse to the "control panel" and run the insulaudit python scripts to produce log files. This proof of concept is a bit of a mind-bender but demonstrates more than enough control for anyone to build this kind of device using commodity, off-the-shelf parts, available today.
An embeddable device, running linux
We currently favor the Beaglebone. The Angstrom distribution, and
embedded build system have been fantastic to work with, and the default
images come primed for this kind of development.
A 3g modem
We like the Sierra 3g modems from Ting. Our needs here are rather modest,
really, 2g will do. We attempt to dial
#777 to establish ppp, so
as long as that works, any modem will likely do.
We intend to provide testable code implementing data transfer for as many medical devices as possible. They are rather trivial to implement.
An insulin pump
Well, I hope you don't need one of these. But if you are like me, then you do need one, and you need the data. We almost have the Medtronic protocol decoded, but need help. Some more captures, and we are confident we can completely control the pump.
I use Medtronic's pump, they refuse to share the data I own with me. As a result, we are pursuing all options we can imagine. Help us capture some more data, and help us solve this problem once and for all.
We believe that after we can show some modest utility from patients having control of their devices, that all vendors will be pressured to follow suit. Please let me know if you disagree.
This is the kind of thing that certain forces have a way of routing around. If we cannot get existing vendors to work with us to help protect patients, and put an end to the unnecessary exposure to harm and risk, then someone will eventually build an open insulin pump. Making one makes perfect sense, it's simply a question of who and when. It will be interesting to see which happens first.
A blood pressure monitor, fitbit
It will be trivial to add support for Omron blood pressure monitor, since the protocols are known, and the basic framework works the same way.
Any other serial device
You may plug in this kind of device to any "legacy" device with an accessible serial port, in order to get it "up and on the web," available for management.
There is a chicken and egg problem here, in that no broker exists to manage a suite of such services for specific to domains to arbitrary devices that are known to fulfil those services. Many existing devices are trivial to adapt into internet-enabled, "cloud-managed" devices, we haven't provided any innovation here except to snap together a few lego blocks in the right way. You can too.
Without the devices demanding to be managed, there is no one reason to service a variety of internet enabled devices, and there are few outlets to send the resulting data for analysis. Without the services to manage them, the number of devices that can work this way, remains limited, while commercial interest naturally prefer to simply build a better mouse trap. However, the internet of things is already here, and there is a long tail of devices ready to be plugged in, ready to enable more mindful use of our technology where it serves us instead of slaving away for the machines others have designed.
We need lots of documents, ranging from technical analysis, to arguments for getting access to our data.
You can edit the wiki, make a fork and submit patches, or simply use http://gist.github.com/ and let me know. I'll find a way to use your contribution.
You will need some basic python experience. I'm doing my best to provide
libraries that hide many of the nasty and tricky bits of massaging data and
protocols, but the work on decoding is incomplete, and I'm hesitant to add
many features beyond "hello world" until we understand the complete protocol.
Let me know if you disagree with my priorities. To that end, much of my
progress is halted on getting historical logs of insulin dosings, which is a
puzzle with an incomplete solution, still,
The idea is to have a rich set of test suites to prove and document in "literate code" that we understand the protocol, and can verify the observations of therapy. Once this is done, there are lots of people eager to run all kinds of math against this data, but we need access, first.
Who is we?
See contributors among
many many others. I (
~bewest) merely funnel many disparate parts to
synthesize compassionate or lovely things. My immediate problems are getting
access to my pump data, so that others can write algorithms for us to better
manage by type 1 diabetes, and so that I can communicate with my doctor on my
therapy with high fidelity. There are many people interested in this type of
activity, for a variety of reasons.
We have clean builds of this running on beagle bone circa
Fri Jan 18 23:33:57 PST 2013
decoding medtronic insulin pumps
The main effort of
decoding-carelink is to independently and
reproducibly download medical records.
The insulin pump is a machine providing therapy. It keeps a log of it's actions at all times. In order to correctly and wisely make decisions, patients need unfettered access to these logs.
successfully downloads pages along with many other settings history from insulin pumps.
I've tested with a 515, and would appreciate further help testing and
verifying the work.
As you can see the data with my custom binary parser is starting to line up with the CSV exports.
Once we can align all the records correctly with carelink's exported CSV, the features developed in decoding-carelink will be folded into insulaudit. Think of decoding-carelink as a proving ground for reverse engineering the carelink protocol
At this point, almost anyone could help simply by running:
# fork the repo on github # clone the repo $ git clone firstname.lastname@example.org/<yourname>/decoding-carelink.git $ cd decoding-carelink $ git checkout -b <yourname> $ ./insert.sh # will ask for sudo to configure usbserial for the stick # ./status-quo.sh [[<path>|/dev/ttyUSB0] [<serial>|208850]] eg: $ ./status-quo.sh /dev/ttyUSB0 208850 $ git commit -avm "here is my data <yourname>" $ git push -u origin <yourname>
Then send me a note, and I'll take a look at your results!
Where to send the data?
You will need to know how to exercise control of how and where to send your data. See TODO for more info.