These are chat archives for nightscout/intend-to-bolus

Jan 2015
Jan 26 2015 02:29

So for me, it all starts with the WinBUGS code published in "Estimating postprandial glucose fluxes using hierarchical Bayes modelling" or in the publicly viewable dissertation, "External Artificial Pancreas for Type 1 Diabetes: Modeling and Control" (search in Google). This solves for parameters based on CHO intake, including endogenous glucose production EGP0. Not all of the code is available, but all of the information needed for implementation, however it is done, is in the papers, in general. It is going to involve passing function to function to solve for things.

This is going to require open-source WinBUGS (with WBDiff, GeoBUGS, and WBDev installed as patches). All of this can be interfaced with MATLAB, via toolbox extensions, as an inline function calling WinBUGS, which will be used for the model predictive control.

This belongs in a gist/blog/whatever, like @bewest has recommended in the past, and I am doing so right now.

Ben West
Jan 26 2015 02:29
I've been gisting a lot lately
Jan 26 2015 02:32
Yeah, indeed. :D . I will make it public. Anyways, I am concerned about some things, although they don't seem major problems, with my design and implementation. It says in the paper with the models that I am using: Absence of insulin measurements (as in insulin levels in the blood--plasma), as in outpatient studies, is likely to exacerbate identifiability issues and might require guidance with use of more informed prior distributions. Further investigations are warranted. (however, the Cambridge AP has been used in outpatient studies, so I am not extremely concerned).
I doubt the issues are serious though, or I would honestly be freaking out, trying to figure out what needs to be done.
However, they were talking about "stochastically e-cloning" the patients in outpatient studies, too, not just the 12 patients that they used for simulations that they have been "stochastically e-cloning". That's one of the reasons I am not too worried about it.
Chris Oattes
Jan 26 2015 04:02
I still think you're thinking about it too hard :P Code it, test it. If it works, great, if it doesn't, try something else
Jan 26 2015 04:20
Correct. Yeah, I have started the coding. Been doing it for over a day now :) . I am thinking about it too hard, but it still is a requirement of doing this particular work using Hovorka's Models (like I have in the past). All bases have to be covered, or you end up getting lost in the work. From a programming perspective, it's kind of a brute-force method that has to be tested out repeatedly, until you know it works. It's ultimately a design project. "Fail often, succeed sooner.", as the design firm IDEO says it.