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

19th
Oct 2015
Peter Miller
@ochenmiller
Oct 19 2015 01:10
I think I found an interesting issue last night. The PWD and openaps loop seemed to "oscillate" for a few hours. The loop would detect a rise, apply a basal for about 20 minutes. At the end of that time, the blood sugar would start to come down at greater than | BGI/2 | . The loop would then return the basal to the normal profile. Because there were long acting carb - I think - the normal basal profile wasn't enough to manage things, so the glucose would go back up. This seemed to repeat on about a about 20 to 30 minute cycle. A manual bolus broke the cycle and brought blood sugars down to range within an hour. I'm going to play with relationship between maxbasal and BGI/2 to see if there's a sweet spot. Would welcome any thoughts.
Scott Leibrand
@scottleibrand
Oct 19 2015 01:29
I would expect that any oscillation caused by OpenAPS would have a period of at least DIA/2 (peak insulin activity time)...
would love to look at the raw data with you and see if we can identify anything it should've done differently.
We have seen some oscillation when basal is too high, requiring an extended low glucose suspend, and then causing BG to rebound. It seems to be a dampened oscillation, though, and results in much better results (avoided hypo) than normal basal schedule would have.
Scott Leibrand
@scottleibrand
Oct 19 2015 01:35
Only scenario I can think of where it'd make an oscillation worse would be if DIA was configured to be way too short, or sensitivity way too low, but even in those cases I think the BGI/2 and deviation stuff would mostly dampen it.
Peter Miller
@ochenmiller
Oct 19 2015 01:37
@scottleibrand, my logs are pretty messy, I'll clean them up, then pm to you.
Scott Leibrand
@scottleibrand
Oct 19 2015 01:45
Might be worth just pulling a multi-day pump and CGM history and sending those first.
If we have any questions about why it did or didn't do something we can check the log file or git history.
Peter Miller
@ochenmiller
Oct 19 2015 01:46
Oh, that'll be way easier...
You've done this before
Dana Lewis
@danamlewis
Oct 19 2015 01:49
:)
Scott Leibrand
@scottleibrand
Oct 19 2015 04:11
@ochenmiller so looks to me like openaps isn't causing an oscillation, it's just being conservative about when to high-temp when BG is high but falling.
generally I haven't optimized the algorithm for being turned on when BG is super high with insufficient IOB. it sort of assumes that either you will have done a correction bolus when you turn it on, or the loop has been running for hours, and high-temping the whole way up.
the one tweak we should probably make is some sort of incorporation of just how far above target eventualBG is. right now it assumes that the IOB and BGI will start out appropriate for bringing BG back within range, so BG dropping faster than that is grounds to cancel the high-temp and see how it plays out.
but if you never got enough IOB in the first place, that assumption no longer holds, and it's more appropriate to maintain the high-temp until eventualBG gets closer to target
we also need to fix the reasons to reflect the fact that sometimes it's the avgdelta that controls what it does, rather than the 5m delta.
for example:
Eventual BG 153>100 but Delta +1 < BGI -10.38 / 2; no temp to cancel
{"delta":1,"glucose":296,"avgdelta":-10.666666666666666}
in that case "Delta +1 < BGI -10.38 / 2" is incorrect, and it should say "Avg. Delta -10.7 < BGI -10.38 / 2" or something.
it's doing the right thing, just not explaining itself well
Peter Miller
@ochenmiller
Oct 19 2015 16:00
@scottleibrand, that all makes perfect sense to me. I'll think about a separate way to address coming down from high - perhaps work with the BGI/2 ratio to something more agressive like BGI*.75 . Or a sliding scale as it comes down. Also, we've been coming on and off openaps, so starting high is more challenging.
Scott Leibrand
@scottleibrand
Oct 19 2015 16:02
I was thinking last night of a sliding scale, where it goes from full extra insulin at +0 to no extra (cancel) at BGI. Also considering using a modified BGI that takes into account how much BG needs to fall every 5 minutes to get eventualBG down to max_bg over DIA.
So if eventualBG is 300, target is 120, and DIA is 3h (180m), then we'd adjust BGI by -5 mg/dL per 5m.
Oliver Schumacher
@oschumac
Oct 19 2015 16:28
@ochenmiller Holgi13 and I tried to set isf *0.75 . By filtering an Hypo status mode which means BG higher than 200 for more than 2h. + avgdelta >= -2. and no Bolus Insulin active. Will make more testing this days. See if it is okay or to agressive. But maybe there are some more solutions.
What i like most is filtering BG data to Szenarios. Like sensing hight BG Level or Sensing a low BG Level. Other Stuff would be to filter a strong rising BGcurve.
To catch more szenarios then make everything in a liniear algorythm.
Scott Leibrand
@scottleibrand
Oct 19 2015 16:35
I worry our algorithm is already starting to get too complex to be easily understandable and testable.
So trying to minimize the amount of additional complexity required to address situations like this.
Peter Miller
@ochenmiller
Oct 19 2015 16:44
I really like the current design aspects that take into account the fact that blood sugar can drop based on factors that determinebasal doesn't know. So, I agree that continuing to add insulin when blood sugar has begun to drop carries risk.
Oliver Schumacher
@oschumac
Oct 19 2015 16:49
@scottleibrand -> Yes it is so complex like diabetes self. But maybe there is a way to make something like plugins. Modules which are closed and testet.
Holger Sanft
@holgi13
Oct 19 2015 17:09
@scottleibrand your right - better safety first. But the idea is to split the ranges in three modules, like high, normal and low. Every Modul with own factors? What do you think?
Scott Leibrand
@scottleibrand
Oct 19 2015 17:14
I think we can accomplish the same goal with fewer discrete states and more continuous formulas
that way if BG is persistently high and we're high-temping, and it starts to fall, we can gradually reduce high-temp, rather than constantly switching it off and back on
Oliver Schumacher
@oschumac
Oct 19 2015 17:52
The basic idea behind Hypo mode is that if BG remains on a high level ketone begin to start their work and the insulin gets less power. Remaining on a high level means you will not get back to target. So there is the need to feed more insulin. If BG is starting to fall the ketone will go and insulin get its old strenght back. But this could not be measured. There is only a good estimate possible.
Manualy we do something like if BG is on a high level for a longer time period. We put 50% on the regular bolus. To get BG down. We have this several times cause of my son is only 6 yo . He is producing ketones very fast.
Scott Leibrand
@scottleibrand
Oct 19 2015 17:55
IMO OpenAPS should not be compensating for BG levels that high. That should be up to the PWD to bolus properly to correct.
It should of course continue to correct for high BG, and keep giving additional insulin until BG comes down, but you also don't want it to cause a crash if he starts coming down from it...
we want OpenAPS to keep BG levels in range, not compensate for under-bolusing etc.
Oliver Schumacher
@oschumac
Oct 19 2015 17:57
Yes in the end it must be still save.
Scott Leibrand
@scottleibrand
Oct 19 2015 17:58
have you ever seen him get that high overnight while running OpenAPS?
Oliver Schumacher
@oschumac
Oct 19 2015 17:58
Underbolus isn't that prob.
YES !!!
Scott Leibrand
@scottleibrand
Oct 19 2015 17:59
we should look into ways to get OpenAPS to administer enough insulin on the way up to prevent him from riding high
ideally by the time he gets high, he'll already have enough IOB to eventually bring him back down
Oliver Schumacher
@oschumac
Oct 19 2015 18:02
Would it be that easy only give alway the right amount of insulin. I don't need Openaps.
Scott Leibrand
@scottleibrand
Oct 19 2015 18:04
heh
Oliver Schumacher
@oschumac
Oct 19 2015 18:04
I friend of mine has a daughter 2,5 YO T1D She has an ISF of 400 !!! Lars has an ISF of 200. That means there reactions in food or insulin are just exorbital.
Sorry maybe i cannot explain in English good enough. :-)
Scott Leibrand
@scottleibrand
Oct 19 2015 18:07
so by "normal" bolus calculator math, over the course of a 100-point rise we should administer an additional 0.5U of insulin. is that likely to be sufficient?
also, what basal rate does he normally run?
I'm not very familiar with kids' ratios and rates
Oliver Schumacher
@oschumac
Oct 19 2015 18:12
I would not give an constant amount. We do something like 50% extra on Bolus expert. But only if BG is up for a longer time. When first correction has failed and the BG remains at same high value.
I have send you the link on our nightscout. On Profile you will se our params.
Scott Leibrand
@scottleibrand
Oct 19 2015 18:14
heh, if I can figure out the german. ;-)
ah, found the English setting . :)
what have you seen when running openaps overnight? it should be high-temping him all the way up when he has a rise like that, and then continue high-temping intermittently as long as he stays high...
Oliver Schumacher
@oschumac
Oct 19 2015 18:28
Yes openaps will do that.
I saw it several times.
But i need an extra dose of insulin to get him down. If he stays for a longer time high.
t1s_joke.jpg
I just love this one :-)
Scott Leibrand
@scottleibrand
Oct 19 2015 18:37
heh
if openaps were more aggressive high-temping on the way up, and when he first gets high, would that preclude the need for the extra dose to get him down?
wondering what is preventing openaps from giving enough insulin to bring him down
we probably still need to tweak the BGI/2 thing to be a sliding scale instead of an on/off switch, but I wonder if we could also increase the max basal or max iob to allow it to do enough insulin to avoid the riding-high scenario
Oliver Schumacher
@oschumac
Oct 19 2015 18:49
In the example i'll send you. max IOB is 1.5 and maxbasal also 1.5 . Basal at night is 0.25 which means the safebasal is set to 1 U.
Evetual BG is near target.
Ben West
@bewest
Oct 19 2015 20:16
ok, I think we're ready to release everything
Scott Leibrand
@scottleibrand
Oct 19 2015 20:18
I assume you're talking about the dev branch of openaps-js? how do we want to deal with documentation and communication? and what about the openaps-js to oref0 rename?
Ben West
@bewest
Oct 19 2015 20:18
right
I want to release openaps, decocare, openaps-js
for openaps-js, there are two optinos
push the "rename" button in github
dev branch is "prepared"
so people would need to upodate bookmarks, we need to update docs
but that's easy
second option is to simply create new repo
called oref0
and post the dev branch as the master there
in that scenario, we can just mark openaps-js as "old" with a see oref0 notice
Scott Leibrand
@scottleibrand
Oct 19 2015 20:20
I kinda like option #2
Ben West
@bewest
Oct 19 2015 20:20
yeah
Scott Leibrand
@scottleibrand
Oct 19 2015 20:20
seems less dramatic for people using openaps-js master
and since everyone is gonna have to do work to upgrade anyway, best to let them do it at their own pace
Ben West
@bewest
Oct 19 2015 20:21
right, not sure how many people are doing that
but yeah
in terms of links and stuff #2 is easier
Scott Leibrand
@scottleibrand
Oct 19 2015 20:21
for newbies, we can make the openaps-js readme say DEPRECATED in big font. :)
we could also duplicate the openaps-js repo as oref0 to preserve all the history
Scott Leibrand
@scottleibrand
Oct 19 2015 20:24
which it looks like you just did. :)
Ben West
@bewest
Oct 19 2015 20:25
yeah, git don't care ;-)
do you have fuser installed
docs might need tweaking to get that installed
might be worth doing a docs subdirectory in oref0
and using that as the place to document the reference spec
or maybe on the wiki there
John Males
@johnmales
Oct 19 2015 20:32
What does oref0 signify? BTW finally feel like a bit of progress happening after a few hiccups. Able to generate all the reports needed reasonably realiably with data that looks plausible.
Dana Lewis
@danamlewis
Oct 19 2015 20:35
Docs sub in oref0? How would that link to the other docs?
Ben West
@bewest
Oct 19 2015 20:35
it would specifically be the docs for the reference design needed to implement the reference design
links work same way as every where else
I can make the web version look like whatever...
those are just some html templates, very very easy
the name of the website can likewise be any domain
there are different kinds of docs to fulfill different purposes
I haven't seen any docs/spec or anything that provides enough information for someone to implement their own get-profile, calculate-iob, etc...
there need to be docs somewhere that explain how to implement those things, and then oref0 is the canonical implementation
these docs are useful to eg, mobile developers who might want to put together a mobile version
Scott Leibrand
@scottleibrand
Oct 19 2015 20:38
@johnmales oref0 is OpenAPS Reference Design 0: new name for openaps-js to differentiate it from core openaps toolkit.
Ben West
@bewest
Oct 19 2015 20:38
I think having a single "docs" repo is going to get confusing... we need different docs for very targeted things
getting set up on rpi has nothing to do with diabetes, and barely anything to do with openaps
John Males
@johnmales
Oct 19 2015 20:39
@scottleibrand thanks
Dana Lewis
@danamlewis
Oct 19 2015 22:13
Good stuff @tghoward :)