Disable Loop when glucose readings detects Noise

[prakashdevadas69]

Hi, Is it possible to detect the Noise from glucose readings and take appropriate action. Sometimes, we have noticed that due to compression of CGM, readings go out of range and at that time, noise value changes. During this condition, loop abruptly cuts off insulin or release insulin.

Pls review and check for any possibility to incorporte suitable changes/settings

Regards Prakash D

[selcuko]

what would the condition look like? also what's this UI?

[thecosas]

+1 for this. As an example, here's some compression lows overnight and the insulin suspension/delivery as a result.

I understand it's tricky since rises and falls can happen due to real-world situations (food/exercise/etc).

[prakashdevadas69]

what would the condition look like? also what's this UI?

Hi, This UI is from Tomato App fetching readings from Miao Miao Bluetooth transmitter. What we have seen due compression especially in the night while sleeping, the sensor is getting pressed and readings are not proper which inturn shows as noise.

[prakashdevadas69]

+1 for this. As an example, here's some compression lows overnight and the insulin suspension/delivery as a result.

I understand it's tricky since rises and falls can happen due to real-world situations (food/exercise/etc).

Yes, the changes happens quickly due to excercise/bathing/food are when you are awake and can be monitored. But compression and false readings in the night is not known to us and finally end up with very high / very low when we wake up.

[sarusso]

Well, to the best of my knowledge this is more about "anomaly detection" rather than noise. It is quite an interesting topic IMO, I have done some work in the area.

For example, while physical activity could be easily considered as "normal" at 2 PM, it is probably unlikely to happen at 2 AM. Anomaly detection models usually work by building a notion of what"normality" is, which is often automatically learned from the data.

Each data point can then be tagged with an "anomaly index", representing the probability of some anomaly going on. An idea could be to make Loop take no actions if such anomaly index is above a certain threshold (say, 80% chance that glucose readings are anomalous).

All the work I have done in the area is with Python though, and I am still very new to Loop and developing apps on iOS so I have no clear idea about how this could be implemented within the app itself. I was thinking (at least in the beginning) about an external service over the Internet, which clearly comes with the big con of requiring an Internet connection to work, but it also has some great pros (as fast prototyping and the option to use server-side computing resources for model training).

Is anyone interested in working on this?

[elnjensen]

I agree that

• This is an interesting problem, and
• It's really hard to do accurately, and safely.

Take compression lows as an example. How would we judge if a drop in blood sugar is real or not? One of the most important things Loop is doing is cutting off insulin when BG drops and is going low. Since that has high priority in Loop's design, you would have to err heavily on the side of assuming that a drop is real, because the safety cost of getting that judgment wrong is really high.

I'm not averse to seeing ideas about this discussed (in fact I think it would be interesting) but in my opinion we'd have to keep short-term safety (hypo prevention) in the discussion.

[sarusso]

Oh, 100% agreed. TBH I am not sure if I would enable it for myself in case of "anomalous" low readings, I'd rather go a bit high. What happened in the screenshot posted here would indeed not be such a big issue for me, given the risk of not correcting a real hypo. But the general concept of anomaly detection might be interesting to explore.

Also, just few days ago I had the opposite problem: my Dexcom measured a much higher glucose level. The problem is that I corrected based on that, so I was approaching an hypo really fast. And in the aftermath, by having a look at the data and combining a strange vertical raise with not so much carbs, you could tell that something was off, i.e. a good anomaly detection model would have probably spotted it. And in this case I might have wanted it to prevent a strong correction, or at least to warn me.

However, maybe this is not the right place to explore this topic, as it is not exactly about Loop but more about CGM data processing/analysis in general...

[thecosas]

In my screenshots there are boluses due to erratic rises after "compression" lows, which eventually lead to a lower BG (~75 mg/dl) than my target.

Perhaps there's a way to approach this to tend toward not bolusing during erratic rises, while still suspending during erratic drops?

[sarusso]

I was wondering that, if there is a relatively "stable" physiological rationale that limits glucose variations, we could just use that to detect a sensor issue and let Loop react accordingly (keeping in mind what @thecosas mentioned above). As simple as computing a two or three-point variation and setting a threshold. My professional work focuses on learning this kind of dynamics automatically from the data, but in this case, maybe the old "threshold" approach informed by physiology could do the trick in a much more clear and explainable way... Just an idea for now, I have not evaluated pros and cons.

[motinis]

Oh, 100% agreed. TBH I am not sure if I would enable it for myself in case of "anomalous" low readings, I'd rather go a bit high. What happened in the screenshot posted here would indeed not be such a big issue for me, given the risk of not correcting a real hypo. But the general concept of anomaly detection might be interesting to explore.

Also, just few days ago I had the opposite problem: my Dexcom measured a much higher glucose level. The problem is that I corrected based on that, so I was approaching an hypo really fast. And in the aftermath, by having a look at the data and combining a strange vertical raise with not so much carbs, you could tell that something was off, i.e. a good anomaly detection model would have probably spotted it. And in this case I might have wanted it to prevent a strong correction, or at least to warn me.

However, maybe this is not the right place to explore this topic, as it is not exactly about Loop but more about CGM data processing/analysis in general...

Right - this would be a greater concern for me. Note there is missing meal notification.

I think that one could talk about how confident Loop is (i.e., how big is the deviation from expectation) in terms of mitigating how much insulin it gives in particular, but on the hypo side I'd really rather it err on the side of safety. Sudden drops happen for all sorts of reasons. And low alarms do exist; compression lows suck but insulin is significantly more effective the lower you go so I would be very very wary about adding insulin in that state.

[sarusso]

I found a screenshot that I took some time ago when my sensor broke and started reading way too high glucose levels (as mentioned in one of my previous posts). You can clearly see that:

1. first there is some missing data, and then
2. the values get (apparently) very high, more than 400, capped in the screenshot.

The issue here is that Loop corrected with much more insulin than required, which was causing me to get to hypo pretty fast (last part of the screenshot).

I am not sure if such a raise in glucose is even compatible at a physiological level (which could be an approach for detecting a sensor issue, as I mentioned here), but when evaluated together with a data loss event, it could have definitely told Loop (and in turn the user) that something suspicious was going on.

How about we consider to just "prepare" Loop to deal with uncertain data? We could pretend to have each glucose reading tagged with a "trustable", or "confidence" index (in the range 0-1, where values close to zero mean a lot of uncertainty while when they are close to one it means that the reading can be trusted well).

This way we can split the problem, and one one side start thinking about how Loop should deal with uncertainty (also in terms of UX), and on the other focus on how to estimate it.

[motinis]

This sounds to me like a nice side project someone could do - generally speaking I think this should be driven by NS and use some kind of reinforcement learning - e.g., the system presents some point in time with the curve as a question and the user should rank how confident the system should be. Based off that a model could then be built that could be incorporated in Loop or other APS systems

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.