Geeks! Could we build an open-source big data pancreas-brain?

Diabetes Technology
21

Elsa, I think you are on the right track. Many of us have similar, if sometimes vaguer, notions about what we want and need, but I see a convergence of views. There are additional publications from Marling's group that make for interesting reading and discussion:
http://oucsace.cs.ohiou.edu/~marling/smarthealth/pubs/

as well as other information:
http://oucsace.cs.ohiou.edu/~marling/smarthealth/
http://oucsace.cs.ohiou.edu/~marling/

Please check out the github repository that Ben West (bewest) started. This is a good start to centralizing efforts:
https://github.com/medevice-users/diabetes

For myself, I also favor an incremental, open approach. For instance, I see the first goal would be to simply replicate the plotting and statistics functionality of all the disparate, archaic software packages out there in a modern web app.

Presently their are only crude software tools that are proprietary to either the insulin pump, CGM, or Blood Glucose (BG) fingerstick companies. Many of them can export to XML or CVS files. Almost all of the interesting ones only have software that runs on Windows XP or 2000 believe it or not, and lately Win 7. No Mac software.

Endocrinologists are confronted with printouts of logs, bad graphics, and only 20 minutes to suggest improvements to pump parameters that need to be used by the "smart" pumps to calculate basal inulin rates and boluses that are given with meals. None of them have any good software tools to do a rational analysis of the data. Usually the decisions are done by intuition alone with too little time, as we all know. Depending on the skill of the doctor and the dedication of the patient, most patients do not achieve optimal control

Also, the newer CGM data is collected every 5 minutes during the week(s) of sensor life. That large data stream is too much for cursory analysis and is not coupled to the insulin pump data (I don't use the Medtronic system so cannot comment on that).

I would like to:

- Firstly, to establish a presence and a "platform", take exported data, replicate the useful graphics and sstatistics of the various commercial software available, as well as develop newer graphics based on current published medical literature. This is to establish a "looks great" and uniform alternative to the clunky software that most people cannot even run because they lack the correct operating system software.

- synchronize the pump data streams (basal rates, injection times and doses, food intake, timing of meals, exercise times, etc) to the blood glucose data stream. Apply rational algorithms (to be developed from conservative best practices as a starting point) that suggest optimized parameters that can be programmed into the pump to improve outcomes. Machine learning techniques might be useful here.

- down the road: analyze anonymized data uploaded by interested patients with a variety of medical products used. This would possibly illuminate other better practices. We own our data and we can share our data if we choose.

- decode proprietary binary data files instead of needing to export the data first (python lib "hachoir" perhaps https://bitbucket.org/haypo/hachoir/wiki/Home )

Right now I am focusing on the Python, iPython, Pandas, matplotlib, etc stack. I have not had time to devote much time to this other than reading a lot of literature, but I hope to make the pieces of this available as they develop.

If you want to talk further please contact me.

Mark

22

Hi, Mark!

Thanks so much for your insightful reply here. I would definitely love to talk to you. Will get in touch!

I have to say, this community is thriving and an excellent resource for us to coordinate and work together. Wahoo!

Elsa

23

Mark, I've decoded the binary medtronic files.
I looked at hachoir, scapy, and several other libraries.
I'd be interested in writing plugins for those tools.

You can see decoded output here: https://github.com/bewest/decoding-carelink/tree/rewriting/analysis/bewest-pump
And the source to decode the history.data files is here: https://github.com/bewest/decoding-carelink/blob/rewriting/pump/history.py.

This is the script I used to produce the decoded files: https://github.com/bewest/decoding-carelink/blob/rewriting/list_history.py

Finally, I'm putting all the visualisations I've started on in a "middleman" static web page app. Middleman is kind of like jekyll and similar tools, should make it easier to put together a comprehensive web and visualisation style guide for diabetes.

I like matplotlib a lot, but have been focusing on d3.js instead. You can do a lot with a static web page... using WebRTC, you can even connect and audit the insulin pump directly from js...

24

Ben, which .py module is the latest you use to communicate and capture the USB data? I'd like to try it with the new Dexcom G4 and the Omnipod. Thanks.

25

Hi Mark!

The decoding-carelink scripts only work with the minimed carelink protocol, not the Dexcom or the Omnipod.

I have access to an omnipod, but have not acquired the time to attempt implementing it yet. I do not have access to a Dexcom.
See: https://github.com/medevice-users/diabetes#decoder-rings for a list of the different types of decoders... unfortunately, I haven't had time to implement anything except the medtronic pumps so far.

Do you know how to sniff the communication that happens between the device and your PC when you use the Dexcom/Omnipod software? If you could upload that/send it to me somehow, it would help quite a bit. I've been toying with the notion of creating some python scripts which could perform this spying on windows/mac/linux. If I got something like that started, do you think you could help test/modify it to sniff your devices? What are you using, and do you prefer js or ruby vs some other language.

Also please consider joining the mailing list, https://github.com/medevice-users/diabetes#help-wanted which is devoted to technical issues, end to end of the diabetes technology "stack."

Working on an "html5" toolkit that makes the pump's physical buttons and UI a kind of last resort for when you can't use the full blown safety/patient/context-oriented UI in your browser.

26

I'd like to adapt whichever of you python scripts is used to communicate directly with the device, and I can try to adapt it for the Dexcom and Omnipod (if I understand correctly what you are doing exactly). Maybe you can describe the exact steps you are taking and any 3rd party software you may use to sniff the data.

I have a Mac that can run XP in bootcamp for the Omnipod (VMs crash the pod controller) and Win7 VM for the Dexcom, but I can run any linux VM. I use the Python stack for coding.

27

Oh, the Dexcom and Omnipod and Medtronic devices are all unique. Re-using anything between them is like sharing data between an Android phone and a Windows phone and an Apple phone; they all have unique ideas about who and what you are and how they work inside.

Currently I have no idea how the Dexcom or omnipod work. First step is to observe the vendor software exchanging messages with the device using something like usbspy or similar. Once that's done I can provide another set of APIs which makes what you describe possible.

Basically I need the output from a tool like usbspy or similar. It might be possible to use pyserial or socat to create a tool which performs the same job: merely mirror and copy what is currently happening to a file somewhere -- but I'm not sure. Mac has a usb debug tool as part of their xcode/development install, but I haven't had time to try that either. I've read that the ideal setup for this type of detective work is a linux host with a windows VM. The linux host can have debug usbmon enabled, which makes it very easy to see everything that is happening; also, no time.

Collecting this data will inform me of how to "talk" to the devices. Once I understand that, I can give you a standard set of APIs for all devices, as you described.

28

The reason it's secret is primarily because these companies don't want other companies to sell new products or services built on integrating with these devices without getting an opportunity to get revenue from licensing, at least.

Patient access to details like this is not viewed as an issue. My argument is that our access to this is paramount to safety. :-) I could use some help developing a set of questions to use to file support cases. My understanding is that vendors must respond to support tickets with factual information; if we can get the ball rolling, we can make data sharing the norm. If you can help me sniff the omnipod, in particular, that would be very helpful. Does omnipod work on linux or mac?

29

OK, I will check out the usb sniffing. I think the omnipod controller actually mounts as a device on the Windows XP machine with an intermediate binary file object that then gets fetched by the software. I can deposit that for you. I don't have the new Omnipod system yet. My omnipod only works on Windows XP or 2000, which is just insane. The Dexcom will take some more doing.

I worry that if we have some success, the companies will quickly go to encryption. That's why I first want to build analysis tools for the human readable exported CSV and XML files.

30

Guys, I have already built a lot of this, with live coaching (ManageBGL.com). It doesn't necessarily need to be aggregated - the key really is that it is personal, as everyone is so different.

31

Big data does not always work.