Replies to This Discussion

Permalink Reply by Craig on July 25, 2012 at 9:35pm

Mark, thank you for pointing me to so much great information. I'm still working my way through it. So far, I found the OpenSourceDiabetes.net Optimal Insulin Pump Settings Tool to be really interesting and the closest to what I'm talking about.

To me, the challenge is not in understanding what general regimen or rule-set will work for the average person most of the time. The challenge is to recommend specific action(s) in realtime to a person with particular characteristics in a defined 'current' situation. Basically, answer the question "What do I do now?" Like having an endocrinologist on your shoulder whispering in your ear. So, all the general "regimens" and "rules" could be written into the program as a hypothetical foundation, but they will be used only to the extent that they are the best set of rules for the user's scenario. Otherwise, the system will infer a set of rules on the fly, based on the huge base of data. Based on those rules, it will be able to offer recommendations.

It seems to me that the fundamental differences between medical research regarding insulin regimens and the concept of a "virtual pancreas" are in three areas: 1) the continual aggregation of data into a shared warehouse (rather than analysis of one-time batches of data), 2) frictionless, realtime collection of data that is not limited to the variables monitored by a CGM+pump+meter (i.e., exercise, stress, physiological info, disease history, etc.) and finally, 3) that the output is meant for use at a given instant in time (not as a learning tool for future consideration or analysis). But most importantly, it is not structured as a theorem leading to a proof and a fixed algorithm, but as a query to a database to solve for a particular scenario, based on patterns detected in the aggregated data. And data from the individual could be incorporated into those calculations with greater weight.

Bottom line is, I think that people with diabetes (and their caretakers) should be provided with simple, crystal-clear support for the many day-to-day decisions they face in managing their diabetes. We need to eliminate gut feel, guessing, compliance, calculating, charts, and graphs and ratios. My suggestion is that this decision support would take the form of specific recommendation options accompanied by rationale and/or examples. As I described above.

That's the idea. I believe it can be done and, as was done at OpenSourceDiabtes.net, I'd like to get it built and see how it works. 

Permalink Reply by Damon on December 30, 2012 at 5:58pm

I have had the same thought about what we could do with all that data, although I think there's a lot of steps to getting there. I worked on making a diabetes management application for my thesis project at college and then just needed to go back and start again.

Right now I'm working on the idea of creating a standard way to store diabetes information so that it can be easily transferred from one program to another: http://sanguinediabetes.com/opendatabetes

Permalink Reply by bewest on January 5, 2013 at 11:10pm

Yes, we're working on this:

* https://github.com/bewest/decoding-carelink/commits/rewriting
* https://github.com/bewest/insulaudit/tree/master/hacking

We have 3g-enabled prototype, need to get the protocol to be more robust.
Please help. Will hopefully add pictures and more instructions soon.

We are working in conjunction with DUBS https://github.com/bewest/diabetes-understanding-by-simulation / http://code.google.com/p/diabetes-understanding-by-simulation/ to build predictions based on similar events.

Permalink Reply by Nyadach on January 27, 2013 at 9:14am

More I keep on thinking, makes me wonder if it's possible to make a super pump using an Andrino board of a Raspberry Pi. Looking at the components of a normal pump they are pretty basic and can be picked up for less than $50 off the component sites. If it was possible to get some kind of CGM system, maybe a dual chamber pump (some are appearing on the market now and as expected are silly money) for both insulin and glucagon, maybe a heart rate monitor to spot exercise, blood pressure monitor maybe for stress gathering info, and heck any other sensor that's needed possibly temperature to bring in environmental variables. It would be possible using a processor like those on the Andrino or Pi given enough data it would gather, the possibility of doing this kind of thing. Or am I just over simplifying things here?

Heck, an open source pump reference design. Talk about a great way to shake up the over charging medical companies and get something in the hands of everyone.

Permalink Reply by morgdan on January 30, 2013 at 11:17pm

Here's a sensor platform for Raspberry Pi/Arduino: http://www.cooking-hacks.com/index.php/ehealth-sensors-complete-kit...

Permalink Reply by Nyadach on January 31, 2013 at 1:06am

Ohhh now that's the thing! Thanks Morgdan. Will have to see about getting one of those to tinker with and possibly order up some parts for a pump mechanism to add to a board.

Noticed yesterday in the press, how they were basically using a normal pump with some new software which predicts random events (yes that sounded odd at the time and looked even worse when I read up on the maths behind it) to deal with dosing for a pump connected to a CGM. The issue they seem to be causing hypo's, which is quiet possibly down to as we all know the inaccuracy of CGM's and the number of outside factors which make one calculation to rule them all for working out doses not really possible. Am quiet surprised a project like this hasn't looked at other sensor information though.

Artificial Pancreas in news: http://www.cam.ac.uk/research/news/art...

Permalink Reply by bewest on February 4, 2013 at 12:22pm

Good suggestion. I've documented it here: https://github.com/medevice-users/diabetes#hardware

Please suggest/add more. I have some arduino stuff burried in the insulaudit project. For beaglebone, we have an open-embedded image, and we have an H8 OE build kind of stubbed out ;-)

We really are doing this... we can change the names per suggestion, but there are definitely more than enough people actually hack the full stack, and we'll need even more people to help document it all. Regardless of your expertise, we're going to break down all these problems so that one of them is a well formed question for your particular expertise.

Permalink Reply by elsa_k on April 5, 2013 at 11:12am

Hello Craig and fellow geeks with diabetes!

I am a type 1 with a background in consumer research for product development, knowledge management, and information mapping. This topic elicited a WOW! response in me when I read it. It is so well considered. I believe if we put our heads together, we can create something within the next year that will yield the results we seek.

The challenge to this, after some deep diving into the nitty gritty and speaking with stakeholders at the device companies, research programs involved in algorithm development and models of virtual patients for simulations, and software developers, seems to be a knowledge brokering one. In sum, it looks like we could pool our knowledge to get this done. We have the technology, the expertise and the user requirements between us. Plus, others in the field have done some compelling work to develop this type of solution (for instance, 4DSS - Wiley, Marling, Schwartz et al).

I have devoted my masters thesis work (to conclude shortly) to this need, focusing on knowledge transfer and coordination of stakeholders (we the patients!!! and others) in order to map out the tools, knowledge, and people that would need to come together for such a concept to be brought to fruition.

I am also working on concepts to submit for the Sanofi data design diabetes challenge (deadline April 7). http://www.datadesigndiabetes.com. The basic ideas supporting the concepts are:

1. We have the knowledge and technology to achieve smarter data management software that actually helps us make decisions as Craig describes above.

2. There is currently too much of a tradeoff between lifestyle flexibility, self-management effort, and good results. To live life the way we want, whether as a foodie, an athlete, or any type 1 diabetic looking to develop strategies for situations from responding to emotional stress or understanding the impact of disconnecting for a long bubble bath. We need the ability to run self-experiments and obtain intelligible feedback in the form of integrated data in order to develop personal strategies. Success in this disease depends on patients' ability to self-manage, as well as minimizing the opportunity cost of managing our disease. We need smart software to free us from the burden we currently face.

3. We need solutions that are compatible with human intelligence and the real scarcity of attention and time to deal with this. Current software is not used by the majority of insulin pumpers, and obstructs both our ability to develop adequate understanding of the disease in our own bodies and our ability to collaborate with our physicians.

My questions for you are:

Where are we in understanding the application of technology (such as the use of Arduino or Raspberry Pi-style boards to enable sniffing of data from our devices, machine learning or big data analytic tools to help us make sense of our data, or apps to self-track with speed, accuracy and convenience (e.g. quantified self-style tools that would help us get around duplicate and triplicate work to document the variables we personally need, whether it's food intake, sleep, medication, activity, et cetera)?

Would you be interested in contributing any knowledge to the development of such a software system in the next year (or joining a crack team of user researchers, data visualization experts, statistical programmers or engineers in order to combine forces)? If so, what knowledge do you possess? What knowledge would you like to gain from others to help you in any efforts you may have underway?

What questions do we have in this community that, if answered, could help us collectively or separately tackle this challenge?

Thanks to all, and all the best!

Elsa

Permalink Reply by Mark on April 6, 2013 at 9:36am

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

Permalink Reply by elsa_k on April 6, 2013 at 2:00pm

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

Permalink Reply by bewest on April 6, 2013 at 2:37pm

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...
And the source to decode the history.data files is here: https://github.com/bewest/decoding-carelink/blob/rewriting/pump/his....

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

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...

Permalink Reply by Mark on April 12, 2013 at 10:04am

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.

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page