You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just as there is a Max Bolus safety check and there is a Max Basal safety check, can there also be a Max Carbs safety check? Somehow an entry of over 200000 carbs appeared in my Loop setup at 11:33pm last night. Loop responded correctly by setting basal to as high as it could go until absorption was done (default of 180 mins, at more than triple my standard basal rate). At about 3 hours later my BG was below 40 and falling. 70g of carbs later I was finally able to reverse the trend. Since it was overnight, I was sleeping through most of it until the alarms on ALL my devices finally woke me up and I was able to treat.
Having a Max Carbs setting would have prevented that errant value. Alternatively, maybe a parameter defined to not allow more than 3 or 4 places of carb count (9999 is still a lot of carb, but significantly less than 200000).
I'm wondering if limiting it to < 100g would be ok, or if it would be too limiting. If you had > 100g in a meal, you could enter the meal as multiple entries.
I think 100 might be an adequate safety check, but too large for my own needs. Multiple entries would be a logical way for greater than 100 carbs.
Would it be possible to tailor it per person as a variable?
Thanks for considering it, Pete.
On Jun 15, 2017, at 10:52 PM, Pete Schwamb ***@***.***> wrote:
I'm wondering if limiting it to < 100g would be too limiting. If you had > 100g in a meal, you could enter the meal as multiple entries.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
As a data point, we have a configurable max COB setting in oref1, with an upper limit of 120. If you enter more carbs than the max COB, we cap COB at the max, and basically leave it there until enough carbs decay, or until the carb lookback runs out (4 hours later or so).
I'm not sure if the oref1 max COB implementation is ideal, especially for Loop, but something along the lines you're thinking probably makes sense.
If putting a limit in that is so close to what people regularly eat, I like @denvergail's idea for having it be an individually tailored value. If hard coding a limit, what about something more along the lines of 1000, 5000, or as @denvergail suggested 9999?
Right now when carbs are entered, the bolus screen shows up to bolus for the carbs that are coming down the line. In the case of requiring multiple carb entries, as I understand Loop and assuming that someone wants to bolus for those carbs, this would translate into having either to enter carbs multiple times and bolus multiple times (which means multiple interactions with Loop) or to enter carbs, cancel out of the bolus screen to enter more carbs, and then bolus once they have all been entered (which increases time spent interacting with Loop). Either way increases interactions/interaction time with Loop, which I don't find desirable. Maybe there would be a different way to set up the link between carb entry and bolus? That seems like more work, though, than an individually tailored limit.
While entering carbs multiple times could be used to add up to the desired amount, as someone who regularly enters >> 100 g CHO, I would find having to do multiple entries frustrating.
Since Maximum Basal Rate and Maximum Bolus are left in the hands of the user, it makes sense that Max Carbs could also be set by the user.
Also, with the Carb Ratios and Maximum Bolus being left to the user, there is already a way to calculate a soft "Max Carb". For example, my ratio throughout the day is 10g/U and my maximum bolus is set at 8 units. Therefore, the maximum amount of carbohydrates I reasonably expect to be able to cover in one bolus is ~80. (Less if there's a correction lumped in). If I am entering more than 80 carbs at a time, something is probably up and it would be nice to have a safety check against something like @denvergail described.
If there were safety concerns, perhaps a compromise could be that the default value of Max Carbs could be set as max(Carb Ratios) * Maximum Bolus with the ability of the user being able to manually adjust it (higher or lower) to their needs.
Reacted by Scott Leibrand, Michael Pangburn, Matteo Neri and Joe Moran
Activity
ps2 commentedon Jun 16, 2017
I'm wondering if limiting it to < 100g would be ok, or if it would be too limiting. If you had > 100g in a meal, you could enter the meal as multiple entries.
denvergail commentedon Jun 16, 2017
scottleibrand commentedon Jun 16, 2017
As a data point, we have a configurable max COB setting in oref1, with an upper limit of 120. If you enter more carbs than the max COB, we cap COB at the max, and basically leave it there until enough carbs decay, or until the carb lookback runs out (4 hours later or so).
I'm not sure if the oref1 max COB implementation is ideal, especially for Loop, but something along the lines you're thinking probably makes sense.
eszcloud commentedon Jun 16, 2017
If putting a limit in that is so close to what people regularly eat, I like @denvergail's idea for having it be an individually tailored value. If hard coding a limit, what about something more along the lines of 1000, 5000, or as @denvergail suggested 9999?
Right now when carbs are entered, the bolus screen shows up to bolus for the carbs that are coming down the line. In the case of requiring multiple carb entries, as I understand Loop and assuming that someone wants to bolus for those carbs, this would translate into having either to enter carbs multiple times and bolus multiple times (which means multiple interactions with Loop) or to enter carbs, cancel out of the bolus screen to enter more carbs, and then bolus once they have all been entered (which increases time spent interacting with Loop). Either way increases interactions/interaction time with Loop, which I don't find desirable. Maybe there would be a different way to set up the link between carb entry and bolus? That seems like more work, though, than an individually tailored limit.
While entering carbs multiple times could be used to add up to the desired amount, as someone who regularly enters >> 100 g CHO, I would find having to do multiple entries frustrating.
jessiepusateri commentedon Jun 17, 2017
Since Maximum Basal Rate and Maximum Bolus are left in the hands of the user, it makes sense that Max Carbs could also be set by the user.
Also, with the Carb Ratios and Maximum Bolus being left to the user, there is already a way to calculate a soft "Max Carb". For example, my ratio throughout the day is 10g/U and my maximum bolus is set at 8 units. Therefore, the maximum amount of carbohydrates I reasonably expect to be able to cover in one bolus is ~80. (Less if there's a correction lumped in). If I am entering more than 80 carbs at a time, something is probably up and it would be nice to have a safety check against something like @denvergail described.
If there were safety concerns, perhaps a compromise could be that the default value of Max Carbs could be set as max(Carb Ratios) * Maximum Bolus with the ability of the user being able to manually adjust it (higher or lower) to their needs.
Kdisimone commentedon Oct 19, 2018
There is a max carb entry of 250g coded into LoopKit currently https://github.com/LoopKit/LoopKit/blob/de1fbe04134cc271ff7cb9b490eea5d6f0affa68/LoopKitUI/CarbKit/CarbEntryEditViewController.swift#L30
Merge pull request #494 from tidepool-org/ps2/LOOP-4028/diy-sync