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
{{ message }}
Repository navigation
Use PrimePumpEvent to disregard primed insulin #240
I see in chat a lot of people needing to remove 30min of insulin data so that Loop doesn't count a prime as injected insulin. Could Loop use the amount field in the PrimePumpEvent to account for it differently?
Loop doesn't use event history in its calculations unless it sees a reservoir rise. This is the problem that has caused these primes to be seen as IOB when some people are priming without a reservoir refill/change. Issue #221 has a similar complaint. It sounds like some extra use of history is needed to avoid this.
Is anyone actively working on this? I've just started using Loop with my daughter. She goes through ~ 15 units of insulin a day so our process has generally been to fill a reservoir and then change sites several times on that same reservoir (less wasted insulin from priming a full length of tubing.)
I'm interested in tackling this issue, though I am completely green with Loop and iOS dev in general.
@outerim I don't believe anyone is. If you only change a site and not the reservoir with loop it is recommended to just reuse the tubing and then just fill the site. It seems in event history mode that the fixed prime is not counted so make sure to leave it on that mode and maybe do some testing to check that it isn't accidentally counting it.
We use Sure-T, so it takes roughly 2-3 units to fill the new site. I had a slightly older build of Loop but I was definitely in event history mode and it showed up as IOB. Deleting a history event or two seemed to ‘fix’ it.
@outerim I don't believe anyone is. If you only change a site and not the reservoir with loop it is recommended to just reuse the tubing and then just fill the site. It seems in event history mode that the fixed prime is not counted so make sure to leave it on that mode and maybe do some testing to check that it isn't accidentally counting it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@outerim Are you doing those 2-3 units as fixed or manual prime? Manual will count them as IOB fixed won't I don't think. Not an ideal solution and I agree we should address this issue properly.
It was a fixed prime. Technically 2 primes of 1.5U each (initially wasn't sure how much I needed to prime). I wonder if the fact that there were 2 prime events is what threw it off. Might have to play with that some more.
I just ran into this yesterday again. A fixed prime of 1 unit to fill a cannula was counted as IOB even though I have Event History set as preferred data source. @Kdisimone thinks that primes less than 1 u aren't counted but I couldn't find that in the code. Does anyone know where in the code I might look to start tracking down what this might take to change? More specifically is there a part of the code that deals with pump history? I see reservoir stuff in Loopkit/InsulinKit/InsulinMath.swift but nothing about pump events in there.
I've really been digging through the code again freshly on this and I'm not seeing the one unit reference. Perhaps my memory was errant on that. I'm also not seeing anything specific to prime event being singled out separately, so I'm wondering if that's not an errant assumption at this point.
Basically, the only thing I see in the code attempting to eliminate a prime bolus from counting as IOB is in the LoopKit's insulinMath.swift where it sets a maximum delivery rate expectation of 6.5 units/min...and then checks to see that the volume drop between reservoir readings is less than the max delivery rate * minutes. The problem with that is that fetching reservoir readings with a 5 minute break between readings kind of dilutes, in essence, that max rate and means that the reservoir drop has to be above 32.5 units minimum in order for a prime to NOT be counted.
I'm thinking that the quickest reliable fix might be to add an interface for users to enter how much they primed, and then track that as a negative dose and decay it in the same way as other doses. It would need 1) an interface to enter; 2) a structure to keep track of it; and 3) modest code changes in the insulin math to read from both dose structures and apply the appropriate sign. It's not as elegant as parsing the event history, but that seems more challenging to implement. If people thought this was a reasonable way to go, I'd be willing to start working on it.
We are already parsing event history, and can calculate IOB from it. That is precisely what happens when you delete a half hour of reservoir data from Loop; it triggers a failover to using the history parsing code.
One drawback to this method is that boluses are only fully recorded in the history when they are done delivering. This can be a long time, especially on x22 pumps with large boluses.
We could mitigate that last issue by storing unconfirmed boluses in DoseStore, and eventually expiring them out if they never materialize in history.
This issue has been active again in Gitter chat, so it's back on my mind. Wondering if the simplest way to tackle this in the short term would be to implement an "I just primed" button. We could just have the button delete 30 minutes of reservoir data, as users now do manually. This isn't a fix per se - you still have to remember to do it - but would be simpler to implement. There could also be secondary functionality added to the button action, namely uploading prime event to Nightscout, and setting a site change alert in the future.
Activity
walker0 commentedon Oct 30, 2016
Loop doesn't use event history in its calculations unless it sees a reservoir rise. This is the problem that has caused these primes to be seen as IOB when some people are priming without a reservoir refill/change. Issue #221 has a similar complaint. It sounds like some extra use of history is needed to avoid this.
beached commentedon Oct 30, 2016
I think the logic could be if loop hasnt bolused but sees a drop larger
beached commentedon Oct 30, 2016
I think the logic could be if loop sees a drop larger than basal + boluses it knows about check history for reason
walker0 commentedon Oct 30, 2016
That sounds like a good idea to me.
outerim commentedon Nov 14, 2016
Is anyone actively working on this? I've just started using Loop with my daughter. She goes through ~ 15 units of insulin a day so our process has generally been to fill a reservoir and then change sites several times on that same reservoir (less wasted insulin from priming a full length of tubing.)
I'm interested in tackling this issue, though I am completely green with Loop and iOS dev in general.
walker0 commentedon Nov 14, 2016
@outerim I don't believe anyone is. If you only change a site and not the reservoir with loop it is recommended to just reuse the tubing and then just fill the site. It seems in event history mode that the fixed prime is not counted so make sure to leave it on that mode and maybe do some testing to check that it isn't accidentally counting it.
outerim commentedon Nov 14, 2016
We use Sure-T, so it takes roughly 2-3 units to fill the new site. I had a slightly older build of Loop but I was definitely in event history mode and it showed up as IOB. Deleting a history event or two seemed to ‘fix’ it.
walker0 commentedon Nov 14, 2016
@outerim Are you doing those 2-3 units as fixed or manual prime? Manual will count them as IOB fixed won't I don't think. Not an ideal solution and I agree we should address this issue properly.
outerim commentedon Nov 15, 2016
It was a fixed prime. Technically 2 primes of 1.5U each (initially wasn't sure how much I needed to prime). I wonder if the fact that there were 2 prime events is what threw it off. Might have to play with that some more.
elnjensen commentedon Nov 25, 2016
I just ran into this yesterday again. A fixed prime of 1 unit to fill a cannula was counted as IOB even though I have Event History set as preferred data source. @Kdisimone thinks that primes less than 1 u aren't counted but I couldn't find that in the code. Does anyone know where in the code I might look to start tracking down what this might take to change? More specifically is there a part of the code that deals with pump history? I see reservoir stuff in Loopkit/InsulinKit/InsulinMath.swift but nothing about pump events in there.
Kdisimone commentedon Nov 25, 2016
I've really been digging through the code again freshly on this and I'm not seeing the one unit reference. Perhaps my memory was errant on that. I'm also not seeing anything specific to prime event being singled out separately, so I'm wondering if that's not an errant assumption at this point.
Kdisimone commentedon Nov 25, 2016
Basically, the only thing I see in the code attempting to eliminate a prime bolus from counting as IOB is in the LoopKit's insulinMath.swift where it sets a maximum delivery rate expectation of 6.5 units/min...and then checks to see that the volume drop between reservoir readings is less than the max delivery rate * minutes. The problem with that is that fetching reservoir readings with a 5 minute break between readings kind of dilutes, in essence, that max rate and means that the reservoir drop has to be above 32.5 units minimum in order for a prime to NOT be counted.
elnjensen commentedon Nov 26, 2016
I'm thinking that the quickest reliable fix might be to add an interface for users to enter how much they primed, and then track that as a negative dose and decay it in the same way as other doses. It would need 1) an interface to enter; 2) a structure to keep track of it; and 3) modest code changes in the insulin math to read from both dose structures and apply the appropriate sign. It's not as elegant as parsing the event history, but that seems more challenging to implement. If people thought this was a reasonable way to go, I'd be willing to start working on it.
ps2 commentedon Nov 26, 2016
We are already parsing event history, and can calculate IOB from it. That is precisely what happens when you delete a half hour of reservoir data from Loop; it triggers a failover to using the history parsing code.
One drawback to this method is that boluses are only fully recorded in the history when they are done delivering. This can be a long time, especially on x22 pumps with large boluses.
We could mitigate that last issue by storing unconfirmed boluses in DoseStore, and eventually expiring them out if they never materialize in history.
elnjensen commentedon Feb 11, 2017
This issue has been active again in Gitter chat, so it's back on my mind. Wondering if the simplest way to tackle this in the short term would be to implement an "I just primed" button. We could just have the button delete 30 minutes of reservoir data, as users now do manually. This isn't a fix per se - you still have to remember to do it - but would be simpler to implement. There could also be secondary functionality added to the button action, namely uploading prime event to Nightscout, and setting a site change alert in the future.
Kdisimone commentedon Dec 30, 2017
Closing, addressed #472
nate/fix/LOOP-1890/watch-button-state-colour (#240)