oref0
oref0 copied to clipboard
openaps
0.7.1 dev branch. OpenAPS is often turned off due to the function of detecting too flat glucose.
@scottleibrand
My sugar stays steady for a long time, Openaps is often inactive due to the function of detecting too flat glucose..
As mentioned in #1257 issue, a teenager has a faulty CGM. Let's look at the picture of this sensor more closely.
-
First. CGM sensor started about 2 am at night. The calibration of sensor was at 10 am in the morning. From the direct line of basal insulin, I can conclude that the teenager learned about the faulty CGM about 7 pm at the evening. From this we can conclude that the teenager did not know that his sensor was not working for seven hours. He was continuing using of OpenAps!
-
Second. The teenager did not make sure that his sensor was working properly. From this fact and the first point, it follows that the teenager uses the Openaps system without monitoring what is happening.
-
Third. You can see that from six o'clock in the morning to ten o'clock in the morning, the sugar was below 4 mmol / L or 72 mg / dl. I can conclude that the teenager did not set a low sugar alarm.
-
Fourth. Let's assume that the sensor would first show low values and grow all the time. Constant growth and UAM can lead to much worse consequences than a long time without changing glucose.
-
Fifth. We know that the teenager often forgets to make a bolus for food. Why didn't the teenager take measures not to forget to inject boluses? Boluses can be pricked before eating.
Thus, I believe that this case is a consequence of carelessness. We will never be able to write OpenAPS that protects against all possible manifestations of the human factor.
- Consider my situation. I specified too few carbohydrates for dinner.
OpenAPS was often turned off from unchanged sugar during the red line segment.
As a result, OpenAPS injected insulin much less often than it could without determining too flat glucose.
As you can see, sugar decreases very hard. The function of detecting too flat sugar only hinders in this situation. The effect of flat glucose is very often repeated on MDT sensors.
Expected behavior I suggest making it possible to enable or disable too flat glucose detection. Or making it possible set time of too flat sugar, after reaching which to turn off Openaps. I suggest to add that option in preferences.json.
Smartphone: Xiaomi Redmi Note 5A.
Setup Information:
- Pump type: Medtronic 722, v. 2.4A firmware
- CGM type: MDT
- Rig type: Edison/Explorer Board rig
- oref0 version: 0.7.1-dev
I'm going to have breakfast. But the sugar is flat. I can't use OpenAPS.
My sugar is on the glucose meter at this time was 6.5.
you could revert commit c2e85b92a13b9159969a9c6c2068b91dd322d75e for your personal use.
@mountrcg, I do not want to use a personal code base. I suggest making the time customization too flat sugar or the ability to turn off the detection of too flat sugar. I suggest to add one of these options to the preferences.json file.
@scottleibrand I could not wake up today from the sound signal about low glucose.
OpenAPS was unable to maintain zero basal insulin until glucose normalization.
You can see that the sugar was low and flat. The function for detecting too flat glucose does not allow OpenAPS to work normally.
In the code, the definition of too flat glucose does not work at a glucose of 60 mg / dl or lower.
However, the authors of this function did not think that CGM can show glucose above 60 mg / dl, which does not cancel the fact of hypoglycemia.
Is Dexcom CGM an option in your case? It appears that the Medtronic CGM you're using is behaving very differently than a Dexcom would, making it very hard to distinguish whether the sensor is working.
Ok. If you (or anyone following) would like to put together and test out a MDT-specific PR, there are likely ways that we can preserve the safety check without so many false positives there.
I have not upgraded to 7 Yet, but this is one of the features I hate the most. I use MDT, and when I get a High OpenAPS stops working, It used to not be that way. it would just give me a BG of 400 and OpenAPS would treat it that way. This worked out great as it would completely bring my Blood Suger back down to normal within a few hours. Without me realizing once I started feeling like crap and have to massive dose myself to get myself down, before APS will work again. Same would be said when its low. I would prefer the system not turn off, and when a High or Low was detected great it as 400 or 40, and not shut off OpenAPS. I know we had tried to make changes to make the 400 and 40 work for highs and lows, but that actually stopped working again with another update and I never fought it anymore. But I have not jumped over to 7 so I can't speak to the newer stuff.
Guess it time for me to upgrade a rig or two.
There are three different scenarios discussed in this thread: a faulty sensor reporting bogus (but changing) data, data not changing because it's above the CGM's ceiling, and data not changing (while in normal range) because of how Medtronic's CGM does smoothing. I think the commonality to these cases is that oref0 should have a way to prompt the user to take a fingerstick, and should be able to adjust its behavior based on when fingersticks have been provided and how they compare to the CGM data.
For the teenager with the faulty CGM: There's a messaging/training issue here, where as soon as he saw a fingerstick that was wildly different from the CGM reading, he should've fallen back to non-looping diabetes habits. But not everyone has those habits, and people get rusty. Ideally, when he entered a calibration that was too far off from the last CGM reading, he would get a Pushover notification with a link to a guide about what to do in that scenario. (What he should have done was turn off his rig, calculate a correction bolus using his ISF, check the IOB in Nightscout and subtract that from the correction bolus, manually administer that correction bolus, and set an alarm to take another fingerstick in an hour. And not turn the rig back on until the sensor starts passing calibration checks, or has been replaced.)
When glucose is flat because it's above the CGM's ceiling, something similar should happen. It's risky to correct that far without a fingerstick, but also risky to not correct if no fingerstick is available. Ideally users would have good habits about what to do when they get high-glucose alarms, but in practice it's kind of like carb entries: it's the user's fault when they fail, but we do expect them to fail sometimes and still want to make the best of that scenario.
