Add the ability to Bolus without CGM data

[trixing]

(As a fork of the discussion in https://github.com/LoopKit/Loop/issues/223)

For the case where the CGM sensor is broken or not worn it would be great to use the iPhone and Rileylink as a remote control of the pump. For that it needs to support calculating a Bolus based on entered data alone. There are two scenarios I'd like to make work:

1. Bolus for newly taken carbs without BG value. Essentially just do carbs / carbRatio = bolus. Doesn't need to care about IOB or predicted glucose.

2. Bolus for newly taken carbs with user provided BG value. Still has to ignore the prediction but needs to take into account IOB. Essentially the result of the calculation max(0, (currentBG-targetBG) / ISF + carbs / carbRatio - IOB )

Case (2) is a strict superset of (1) so I'll aim at supporting (2).

I'm actually toying around with the code a bit and the simplest thing seems to be to change the CarbEntryTableViewController to also take a current BG measurement (if no cgm data is available) and then change addCarbEntryAndRecommendBolus in LoopDataManager to handle the case where there is no prediction available.

Question is: This could either be a completely separate code path from there, or it could re-use recommendBolus by - I guess - running the prediction loop with out blood glucose value. I guess from scanning the code, only the getRecentMomentumEffect from glucoseStore won't produce a reasonable result in this case?

Thoughts?

[scottleibrand]

(1) seems dangerous. If basal IOB is already high relative to actual BG, doing (1) could easily result in hypoglycemia.

If you do this, I would recommend only supporting (2).

[trixing]

Both cases only are considering a case without CGM, so basal rates would just be the default and don't need to be taken into account. It would actually be very exactly the same as how current "dumb" pumps are operated.

[scottleibrand]

I don't know of any reputable bolus wizard that will operate without a BG input. Blindly bolusing for food, without respect to current BG, is dangerous, whether you have a CGM running or not. Either way you need to know if BG is too low, and subtract off current IOB from the recommended bolus.

[eyim]

Every single Medtronic pump as well as the Omnipod (at least the old ones that we had) works that way. No bg is required.

[trixing]

Animas Ping as well (ezCarb). It's also what they tell you for needle / pen - only do the BG correction before lunch and after not having eaten for ~3 hours.

[walker0]

I agree with @scottleibrand a big advantage of loop is that it is inherently safer as long as you use reasonable values and case 1 doesn't really agree with that, case 2 is marginal. I agree that if IOB were used that it would be ok but in loop cgm communications trigger the loop to run and pull history data, so without cgm data you won't have up to date IOB (unless using medtronic cgm).

Loop has a bolus wizard already and if you want to override the values that it is suggesting you can do so whenever you want.

[scottleibrand]

I stand corrected on how existing pumps work. I guess that is considered ok because with most pumps you won't end up with IOB you don't know about (and therefore the advice is "don't stack boluses").

@walker0 brings up a good point, that if we want to do (2) properly, we should also update Loop to be able to trigger a read-only loop run even in the absence of CGM data, so we know what the current IOB actually is before doing any bolus wizard calculations.

[Kdisimone]

As a parent, I support Option (2). It would be great that my kid was always bolusing off Loop settings. I realize we should always update pump settings at the same time as we make any changes on Loop (but on a practical basis, that medtronic interface sucks and there are times where we don't want to touch it). We are working hard to make sure we do keep them in sync...but life happens and safety would be on the side of use still using Loop settings over pump settings.

[trixing]

I'm actually surprised that the data collection doesn't work without cgm data? I don't have a dexcom running right now for my son and it still displays most of the data. I didn't check though if it calculates IOB.

I don't really consider (1) unsafe. It is based on additional carb intake, which - if the carbratio is correct - should just stack on top of the rest going on. There is obviously always the risk of getting the carbs wrong (or kid not eating well) but that's just the usual risk, no?

I agree that (2) shouldn't happen without knowing a recent IOB.

[walker0]

@trixing I think it will work without cgm data if you have dexcom share configured

[trixing]

I coded up some basic functionality for this yesterday. I don't like the solution though as it skips the complete Loop prediction math. Do you think it is feasible to have the loop algorithm do a prediction based of a single point in time glucose measurement? Then it could re-use most of the existing code without special casing this too much. My current solution has essentially a completely separate code path doing the calculation as sketched above. I'm worried about this being out of sync with the primary dosing math.

[Kdisimone]

Closing this issue. The origin of the post appears to have been, at least in part, related to the frustrations of bolusing below target. Since the addition of minimum BG guard/suspend threshold to Loop, that is moot. Bolusing without CGM data is available is available as a manual entry in Loop, also a part of the original post.

[trixing]

Well, this is about providing functionality to do what "EZCarbs" and other (traditional) bolus assistants are doing in case of manual BG measurements. It is really helpful in practice if for whatever reason CGM is not available (sensor torn off, broken, swimming, etc) to Bolus through the normal Loop interface and don't have to explain your kid / caregivers how to use a different interface.