[Enhancement] Warning when long temp BR 0 due to low faulty BG sensor data

[T-o-b-i-a-s]

I am using a Libre Sensor with a bluereader device on top. As the sensor was not designed to have something sitting on top of it, the adhesive does not have enough power to keep the sensor in place and (without additional tape) it slowly moves downwards and the sensor 'needle' is partially pulled out. This results in lower glucose values reported which tend to be rather flat over time.

In my case this situation resulted in AAPS switching to 0 temp BR for a longer period of time, even though the real blood glucose has already reached a hyperglycemic level. If the reported blood glucose is below the set target and above the hypoglycemia alarm, the faulty sensor data might remain unnoticed for a whole night without insulin.

Even though many factors must come together to become critical, a warning alarm message like 'Blood glucose is flat low for a long time, please verify value by doing a bloody measure' might give a valuable hint and increase security.

The following factors might trigger the message:

• Temp BR 0 for more than 2 hours
• BG below target for more than 2 hours
• Insulin on board 0
• Rise of BG below predicted rate

Maybe there are better indicators to identify the situation described above, this is just a starting point for discussion. Does any kind of limitation for temp BR 0 already exist?

I am now always applying additional tape to the sensor to avoid this situation.

[thomasmenges]

@T-o-b-i-a-s Yes, it may be helpful to get an alarm in certain cases, but sometimes it can be annoying. You won't get the pump quiet anymore! I'm using Libre Sensor with MiaoMiao (wich is located besides the sensor). Holding the sensor is done with the adhesive of MioaMiao and additional with "Kiwi Slim – Shell for MiaoMiao (Libre): NO Armband" from shapeways.
I love it.

[T-o-b-i-a-s]

Hello @thomasmenges, you are right that any additional alarm will annoy people. However, I think it is a critical risk that a situation can occur where AAPS stops delivering insulin altogether without the user noticing it, because everything seems to work well. I would enable an alarm triggered by the data mentioned above by default and allow the user to disable it or modify the thresholds. I know it is an edge case and only occurs when the sensor is not working well, but still a safety feature. Do you have another idea how to fail safe in that scenario?

[thomasmenges]

Hello @T-o-b-i-a-s , I understand your concern but I'm not sure if the described factors are enough to create a message issue for the right reason. The described factors could be normal (if the basal rates vary and are not optimized). That's the reason that I often have 0% temp basals for a longer time because my BG is near to the lower target of BGs. And here, I like that 0% temp basals are created automatically (by the way --> here the sensor is OK)

You're right. For safety reasons it could be helpful to have an notification / alarm. But In my opinion this should defined by time. I would like to have this alarm only in the night. During the day I would prefer only a notification because I notice my BG, temp basals … several times a hour.

[AdrianLxM]

The current idea would be to have a minimal IOB and an alarm if the IOB passes that threshold.

[T-o-b-i-a-s]

My original idea was that multiple/all criteria mentioned above must be true. An alarm just based on IOB might ring too often and too many triggers will maybe miss the really critical situation. Maybe the idea and situation is too specific to be implemented as a generic alarm. There are other similar cases where no alarm protects you like leakage of insulin or defective insulin, while others are caught by alarms like occlusion or pump unreachable.

@AdrianLxM, is there any security feature already in place that limits the time where no insulin is delivered at all?

[larsqvd]

Had the same issue yesterday on the omnipod branch but this is core. Libre giving an error, picked up as low glucose level but actually being hyperglycemic. Is this Xdrip code or AAPS code that needs to be changed to pick up the error early/correctly? That would tackle the issue rather then adding an alarm.

[ArthurusDent]

This has been mitigated in oref0 version 0.7.0 [release notes] https://github.com/openaps/oref0/releases/tag/v0.7.0 [issue] https://github.com/openaps/oref0/pull/1258 and will be part of the upcoming release of AndroidAPS 2.7.

[T-o-b-i-a-s]

Gold to know there is a mitigation coming. Thanks for the information, @ArthurusDent . @larsvandoremalen , as I have switched to Dexcom in the meanwhile, I do not completely understand the "error" that Libre is giving. When I was using Libre1 with blue reader, any error lead to no blood glucose values arriving at AAPS at all. Are you using the patched Libre2 App, which shows an error? I would assume the Libre2 data is then forwarded to xDrip+. Does xDrip show a numeric blood glucose value or LOW in the error situation? If that is the case, you would need to make sure that the error case is correctly forwarded to xDrip+, probably by modifying the patched Libre2 app. If xDrip shows the error, but AAPS still receives a numeric or LOW (which is equivalent to 39mg/dl, I think) value, this would be a serious bug and would need to be fixed in xDrip, as AAPS cannot identify it is a "buggy" value.

[larsqvd]

I am using libre1 + MM so the last case is true actually. Combination of Libre way of handling errors and xdrip interpretation at the root. Hard to test/resolve as I only had 2 faulty libres in one year.