Here's the idea. Please, tell me what you think. Do you know people who could do this? (I'm less interested in regulatory feasibility than in technical feasibility.)
PROBLEM: Every day, several times a day, we take our lives in our hands when we decide on insulin, food or exercise activities. No one is smart enough, certainly not me, to use even the limited data sets we have to effectively or accurately treat ourselves. Poring over charts and graphs is not my forte. There are way too many variables (e.g., food type, amount, mix, recency; time of day; exercise type, amount, recency; stress level; insulin type, amount on-board, basal levels, bolus levels; personal data like weight, BMI, and work environment, etc.), they are all in constant flux and their relationships are often (apparently) inconsistent.
SOLUTION: Crowdsource, anonymize and aggregate all that data from Type 1 geeks and smartphone users globally. Analyze it for patterns, and feed relevant insights back to individuals in the crowd for them to use to help them decide what to do now - in the situation they find themselves in. Should they eat, bolus, walk, run? And how much of each?
APPROACH: We could collect much of this data: some passively, some actively. Let's assume that there are smartphone apps that can passively gather some exercise data (pedometers, Nike+), that the new Sanofi/AgaMatrix can gather BG test data, and that appropriately incentivised users would employ exercise and diet apps apps to share food, stress, personal and exercise data points. With all this data from thousands of people posting more data every day, I have to believe that we would all benefit.
Could we do this? How? What are the hurdles? How could we get over them?
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
Yes, we're working on this:
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.
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.
Here's a sensor platform for Raspberry Pi/Arduino: http://www.cooking-hacks.com/index.php/ehealth-sensors-complete-kit...
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.
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.
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, 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:
Please check out the github repository that Ben West (bewest) started. This is a good start to centralizing efforts:
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.
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!
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...
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.
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.