AndroidAPS
AndroidAPS copied to clipboard
MilosKozak
[Feature Request] Include a parameter for a BG below which basal is forced to 0 (zero)
- Issue Statement: in several posts (mine and from others) I have seen reports of instances where the user is in hypoglycemia and yet the app switches basal insulin to high values. This typically happens when there is a positive delta in BG (or COB or a negative IOB) which makes the algorithm predict a high future BG. It turns out that sometimes that prediction is wrong and your BG comes down again – but now you have more insulin in your body to makes things worse. I have been told to double check my basals. I did and these are fine. They work most nights. But every now and then this happens.
- My mathematical analysis as to why this behavior is wrong/dangerous. hypoglycemia may happen (in my experience these are the main reasons) due to reasons that are unknown to the user and to the machine. 1 – when carb counting is not done rigorously (e.g. you are at a restaurant without a scale and you don’t know how the cooking was exactly done) 2 – when the carb counting was done by the book but mother nature is not always the same (e.g. we count carbs of apples as if all apples were the same but we know some are sweeter than others) 3 – Sudden changes in insulin sensitivity for now apparent reason (growth hormone during sleep, nightmares, etc). Note that here I am excluding physical exercise in which the user may know and may inform the machine. In situations 1 and 2 the machine will keep its prediction based on wrong carbs, and insituation 3 the machine will count IOB based on the basal profile which has suddenly become wrong. And the variable that calculates sensitivity (shown as AS on the app) is not of good use here.
CONCLUSION So it means that in a hypoglycemia situation we are generating predictions based on wrong inputs, which the user has no way o knowing that these are wrong, and generating new basal based on those predictions. In my case I would set that parameter to 80 or 85. Although I could conceive more aggressive users to do a 75, or that for little kids you would do like a 90. It would make sense to me to be a value between 70 and 100.
Can I suggest you provide some of the mathematical analysis that you specify? That will help others try and work through the behaviours you have described qualitatively in a quantitative fashion to determine what might be happening.
My point is that there is no "quantitative fashion" that can help us here because the context of hypoglycaemia is, sometimes, caused by quantitative inputs that are wrong but the user (or the app) are not aware of that. Future BGs or expected dealtas (lets call these "Y") are a function of COB and IOB (among other variables). COB are a function of the carbs we informed the machine that we ingested (among ther things), and IOB is a function of IOB_basal. We agree that if Y=F(X) and X is wrong, then Y will be wrong. Our X is a set of variables in which the following can be very wrong in the context of hypoglycaemia IOB_basal: if i get an unexpected sensitive increase that was caused for no reason (i.e. it is not due to sports or stuff like that - it just happened) the app will consider i have negative IOB_basal because it will consider the basal profile. I find this happens a lot in children (i manage two 6 year olds) at night when their growth hormone peaks at arround 10PM. Every day is a different day and we simply can't predict. COB: lets say you go to a restaurant and you believe you ate 100g os carbs but in reality you just ate 80. Lets say you are in hypo, you drunk some orange juice you believe had 15 carbs but it only had 10. Or lest say you ate a fruit bowl that you carefuly weighted and calculated carbs of 30g but, because not all apples are equaly sweet, it only had 25g. Your future calculations will be made uppon wrong COB (which are less than what you introduced).
You may say that "oh but mistakes can happen all the time". Sure. i agree. But in the context of hipo they are more important because 1 - It is the mistake that can lead to the hipo itself. So in hipo the likeability that there was "a mistake that you did not realize" is higher. 2 - a mistake in hipo leads to greater consequences that in normal ranges.
As i said before, i dont argue for an improvement of the calculations because that is impossible (due to the mistakes we don't know we did). What i argue is is a safety variable, at the choice of the user, of a BG below which no basal or SMB are given.
hope these examples help.
This is still the wrong repo to discuss the base algorithm of OpenAPS.
Before we close this issue here, could you still please double-check that you actually see a way how COB would affect LGS directly? The expected delta should be based on bgi of (the negative in this case) IOB only.
If you still have positive IOB - or only slightly negative - as you have given insulin for the food you miscalculated, LGS should still be a simple cutoff at the threshold.
Adrian, let me answer in pieces [adrian]This is still the wrong repo to discuss the base algorithm of OpenAPS. [Miguel] i disagree. My point is NOT to change the algorithm. It is simply to add an parameter below which no insulin is given. You have plenty of safety parameters in the app. This is just another one.
[adrian] Before we close this issue here, could you still please double-check that you actually see a way how COB would affect LGS directly? The expected delta should be based on bgi of (the negative in this case) IOB only. [Miguel] As i see in the code, COB can afect the threshold. Even if id didn't, i also alert that hipo is caused by unexpected change in sensitivity which makes the IOB_basal to be wrong. But anyway, here is how i see COB affect LGS (espectially as you add carbs when you are on hipo) LGS is a function of Expected Delta Expected Delta is a function of eventual_BG. Eventual BG is a function of minguardBG minGuardBG = fractionCarbsLeft*minCOBGuardBG + (1-fractionCarbsLeft)*minUAMGuardBG;
[adrian] If you still have positive IOB - or only slightly negative - as you have given insulin for the food you miscalculated, LGS should still be a simple cutoff at the threshold. [Miguel] This is incorrect for 2 reasons. 1) there may be an increased sensitivity and that is what is causing the IOB_basal to be (wrongly) very negative; 2) in the case you thought you were eating 100carbs but you only ate 70, you dose for 100, you tell the machine you ate 100, but you only ate 70. So when you are in hipo the machine will think you are with way more COB than what you actually have and this, to my point above, generates a wrong estimate of expected delta.
Let me simplify things please. All i am suggesting is a safety feature, optional to the user, of "with BG<x dont give me any insulin". Isn't it obvious enough that when i am 60, i dont get any insulin? Or at least to have that choice? It has happened to me in the 60s and the other day there was a post from someone else in the 50s where the app kept giving him insulin. In the facebook discussion people already flagged how this is possible today (i.e. do an automation that moves you to a profile where basal is 0). I am just asking to make it easier, for everyone's safety.
Could you please show the trace where that happens? I'd consider that a bug.
eventualBG used to calculate the target should depend on the naive eventual BG and the deviation.
@GrapesAfonsoGithub in the case you thought you were eating 100carbs but you only ate 70, you dose for 100, you tell the machine you ate 100, but you only ate 70. So when you are in hipo the machine will think you are with way more COB than what you actually have and this, to my point above, generates a wrong estimate of expected delta.
In this case, the algorithm would observe you dropping faster than it expects when you have cob and iob, and the deviation from the expected Delta would cause the system to zero temp. While you may have told it what to expect, it doesn't use CoB as the only data when looking at its behaviour.
Adrian is right - we need to see the nightscout Trace with OpenAPS pill highlighted and if you have them, the logs, to understand what's happening.
Team, i dont want to get into the details of openAPS as i dont see the algorithm needs to be fixed. Nor would i be an expert to sugest any fixes on it. Let me reinstate the core issue i opened in the words of Marcus Lindorfs who in FB explained it better than i probably could: "I simply fail to see the reason why a 'hard stop' couldn't work in every single scenario. If there was a parameter that said "If the current (not future) value is below X mmol/mgdl, do not under any circumstances switch on the insulin". (Zero temp for 15-30 mins and check every 5) What would be the harm in that?"
Just to make developers lifes easier, i add here another idea from the FB discussion which could be a low hanging fruit for everyone
Dan Evans One other reflection - if devs not keen to implement a '0 temp if bg under x' feature then alternative could be to allow an automation action to set explicit tbr for a certain time. thus allowing someone to set an automation to achieve the above, but without it coming across as a formally endorsed aaps workflow
"If the current (not future) value is below X mmol/mgdl, do not under any circumstances switch on the insulin". (Zero temp for 15-30 mins and check every 5) What would be the harm in that?"
The harm in that is fairly simple: withholding insulin for longer than necessary causes more of a rebound, which can cause BG to rise above target, result in more insulin dosing, and subsequent roller coaster BGs.
Oref0 already has a minGuardBG threshold that prevents high temps or microboluses when BG is too low. We explicitly avoided the approach of disallowing insulin delivery entirely in that situation, and instead allow neutral basal to resume when IOB is highly negative and BG is rising. This helps prevent rebounds and rollercoasters, while avoiding dosing too much for a rise as long as BG is too low.
Other things to consider:
- oref0 doesn’t dose excessively for just-entered carbs, and will only dose for carbs as long as both the current BG and predicted future BGs (based on the currently observed rate of carb absorption) are above the minGuardBG threshold.
- excess sensitivity should be detected by autosens (after a few hours) and autotune (after a few days). If you haven’t run autotune recently, please do, and make sure basals aren’t too high and ratios aren’t to strong (low).
One other point: if you want to propose and test an algorithm change like this, the way to do that would be to fork the oref0 repo, make some modifications that change the behavior when a preference is changed, and then use the oref0 simple-simulator to backtest your change against historical data from Nightscout to see whether or not it would’ve likely made things better or worse. Feel free to just over to the OpenAPS/oref0 Slack or Gitter channels if you need help figuring out how exactly to do that.
this is not a proposal of algorithm change or fork. It is an incremental safety feature. When you say scott, that it may drive future highs: maybe. But the point is to privilege safety now Vs high in the future.
You’re proposing to change the rules by which insulin is dosed. The rules by which insulin is dosed are the dosing algorithm, by definition. However simple or straightforward you think your change might be, it is a change. We now have a way to test whether that change would make things better or worse. I suggest you use it.
testing it is way beyond my technical skills, unfortunately. Regarding the change: the app already has a ton of safety features, this is just another one (not saying it is easy). Also, if you say the algorithm is already conservative in the context of hypo, it should not make a lot of difference, right?
I don't have great technical expertiese but I'm happy to do a fork (this will be of the aaps omnicore variant but i think the other pumps are still existant in there too so if it works it should be multi-use), either to attempt to implement a 'if below x then tbr=0 for 15 mins'; or (ir easier) to add a 'set tbr=x for y mins' automation action. As an easy start I migjt just hardcode in the former as a test (clearly then it will need more work to allow it selectable/variable etc). To help me with that, can anyone give me pointers to which bit of aaps code I should be looking at? Many thanks.
You won’t be able to properly backtest such a change directly in AndroidAPS. You’ll instead want to fork and update https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js
Here you have a fresh example of why this safety feature is needed. Context: hipoglicemia with a temp target of 150. The BG moves from 54 to 59 and the algorithm says "predicted is below target BUT as he delta of 5 is above the predicted then lets put basal at 100%"
The BG was at 59!!!
By the way, my minBG is 100.
How do you explain this and how do you think this is safe? (and no, it is not that my parameters are wrong, they work most days)
What did BG end up at 60m after that? Remember, insulin activity is slow: anything you dose now won’t affect BG for the next 30m, and its peak activity will be 60-90m later. Also, note how much insulin is actually delivered during each 5m faster-than-expected uptick: 0.6 U/h * 5 minutes / 60 minutes/hour = 0.05U, which is only enough to drop BG by 5 mg/dL over 4h+ with your 100 mg/dL/U ISF.
This is my daughter's app. I don't user her as a guinea pig. And no, she was not rising. After that 59 it came down again. So ofcourse i gave her juice and she is coming up.
But your reply is very helpful, scott because on FB i had lots of answers trying to tell me that what just happened could not happen.
So, in short, and to the AAPS developers
- The algorithm can actually give insulin when someone is at 59 with a target of 150 and a minBG of 100 - do you find this safe? I dont think there is nothing else i can say to sustain that an automation to zero-basal is needed, helpful, and a good safety feature. I leave this to your good judgement but certain that it is in the best interest of everyone to at least have this option.
Thank you for all your efforts!
You say “I don’t use her as a guinea pig”, but you want to make untested changes to the dosing algorithm and apply those changes to your daughter without any testing?
If you’re willing to make those sort of dosing algorithm changes, then set a 150 target to get absolutely no insulin for an extended period, you’re risking DKA. I don’t know of any parents who want that. Rather, the proper thing to do is exactly what you did and do: administer carbs and allow insulin delivery to resume. When you do that, continuing to withhold insulin until BG rises above threshold would be far more likely to cause a more severe rebound, and require far more positive IOB to correct that than the tiny amount delivered while BG is rising.
Scott, sorry, what you say is medically and factually incorrect. 1 - cutting insulin in the context of hypoglycemia (especially a severe one as a 59) is one of the most basic medical recommendations you will find all over the medical literature. 2 - what you don't find anywhere is studies of insulin delivery in the context of BG=59 3 - a target of 150 is exactly what i did. But the algorithm considered the delta of 54 to 59 to be more important and therefore started giving basal. 4 - for you to have DKA you need to be in hiperglicemia. so your argument does not make sense 5 - Yes, you may have a big rebound. But if you are at 59, and risk your luck with more insulin, and you dont rebound do you know what happens? You die. I would rather rebound.
You might want to read up on euglycemic DKA. Some of the oref0 algorithm settings are optimized partly to avoid that, and pump occlusions caused by extended lack of insulin delivery. I’m not aware of any FDA/EMA approved medical device that will suspend insulin delivery for more than 2 hours.
If you’d like to experiment with different algorithm settings and overrides, feel free. But please quit asserting that anyone who doesn’t care to implement your algorithm changes without testing them is somehow being irresponsible.
Thanks Scott, I'll give it a look. Tim/Adrian can you pls leave this feature req open till I've had a chance to experiment a bit? Mt
Scott, i did not say you were irresponsible. I am trying to be factual in pointing mistakes in your thinking process as well as to try to have you see the other side, i.e. by focusing on X you are risking Y which is way more severe than X. 1 - on DKA vs EDKA: these are 2 different conditions. You had mentioned DKA. 2 - EDKA is a condition whose etiology is not well known but it has NOT to do with absence of insulin. EDKA happens either due to a) decreased hepatic production of glucose during fasting state or b) enhanced urinary excretion of glucose. Both a) and b) can happen in the context of other conditions (consumption of cocain, pancreatites, heavy vomit/diarhea, etc), and actualy a) can happen when you intake insulin because the intake of insulin is what makes the liver NOT produce glucose. In short - EDKA is not caused by absence of insulin from the pump. And even if one day it will be found on a small group of people it will not be due to a few hours of zero basal to treat a hipo 3 - if we can agree on a zero-basal for 2h it is already a progress. 4 - pump occlusions? Are you really arguing that a pump occlusion is a fair balance to give someone insulin when on a BG of 59? 5 - where is your research published on the results and effects of your algorithm when delivering insulin on BGs below 60? I would love to read that. 6 - this is NOT "my" algorithm. Stop the delivery of insulin in the context of severe hypoglycemia is everyone's algorithm (except yours, apparently)
Feel free to go use another system if you don’t like the dosing algorithm as it currently exists, and don’t want to do the work to help improve oref0 by actually testing out your proposed dosing changes. Given how many people are using oref0 successfully at this point, achieving better time in range than with any other system (including more conservative ones), I don’t think it’s prudent to make any further changes to the dosing algorithm without backtesting them.
Scott, every time i point factual mistakes on your argument you come up with other arguments. Now you are making it personal "if you dont like this just go away". This is not personal. I use AAPS because it is the best. it does not mean the best can't be improved. There are tons of safety features in AAPS that are imposed on OREF0. This would be another one. By the way, you should know that AAPS already allows for this with an automation that moves you to another profile which would have 0-basal accross 24h. This is just to make it more "direct" and easier.
I have yet to see your evidence on how great OREF0 is in dosing insulin in BGs below 60. On the other hand if there is one safety feature the medical community agrees to is to NOT dose insulin on those ranges. I dont even get how you can be so attached to your algorithm to disregard such an obvious safety recommendation.
By the way - i would be happy to test current AAPS with the safety feature i am proposing. I simply don't have the technical skills. Again: false arguments and making things personal...
I didn’t have the technical skills to write oref0 either. I learned them as I went along. If you’d like to become a contributor instead of just complaining about how no one is recognizing the obvious superiority of your suggested dosing algorithm, let’s move over to one of the oref0 channels and discuss how to code up and test your suggested algorithm change. Otherwise, you’re leaving it to others to eventually test something along the lines of what you’re suggesting, and your arguments here are not going to influence their test results.
@GrapesAfonsoGithub - if you believe this is the correct approach, and you are willing to test it directly on your daughter, you can configure an automate script that will profile switch to a 0 TBR and suspend the loop for 30 mins. That way you would achieve what you are setting out to do here as a personalisation.
To make this a change to the way oref0 works requires someone to branch the algorithm then run the backtest, as @dexdan has offered.
It's worth noting that in exercise, euglycaemic DKA is now considered a factor in determining how dosing insulin and carbs should be undertaken, and when someone is doing "long-term" exercise (which is considered 2-4 hours or longer) the approach considered safest is not to simply suspend insulin for the duration but to continue with low level insulin and also carbs, as euglycaemic DKA occurs as a result of lack of insulin, and not only high glucose levels.
@scott, i am not claiming superiority not complaining. I am 1) providing facts and pointing mistakes to your claims to which you have no counter argument and 2) helping in the way i can which is not a small thing.
@tim i agree with your point on EDKA. but your solution (which is correct) is not to simply continue pouring insulin in someone that is on hipo. You add carbs and insulin which will reduce ketones while not moving you to severe hipo. This is not what the algorithm is doing. If someone is with hipoglicaemia and high ketones due to exercise and you simply give him insulin you will kill that person from severe hipo.
@Scott and @Tim i would have no problem in testing this algorithm on my daughter. Actually i do it already manually (i open loop and i cut the basal, or i give fake bolus to move IOB from negative to zero, until i get to safe BGs). Me doing code would make this enhancement ready in 2039. Me doing this code or you performing brain surgery although not impossible is probably not the most efficient way of doing things.
I respect you dont want to do it. Just that having me do it is the same as nothing.
@scottleibrand Thanks for your help with this. I did consider the easy option of guinea-pigging myself (!) by using an AAPS automate to a zero basal profile, but that seems dangerous as loss of pump comms could well leave soneone in a dka situation overnight. So I do think I need to have a fiddle with the code as you suggested and simulate the impact.
So to be clear - code to fiddle with is https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js - from a quick glance this seems to be somewhere around lines 150-170ish.
Then I need to simulate the impact of a change on some old NS data - I seem to remember there was a way of doing that, but can't find it? Might you please be able to give some pointers?
Finally that would need fitting into AAPS, which I think, but could be wrong (@tim2000s or @AdrianLxM please shout if so) is into \app\src\main\java\info\nightscout\androidaps\plugins\aps\openAPSSMB\DetermineBasalResultSMB.java although there seem to be various determine basal variants, including \app\src\main\assets\OpenAPSSMB\determine-basal.js which I didn't quite understand which AAPS will actually be using. I'm asssuming the former but pls shout if wrong.
Many thanks
@GrapesAfonsoGithub - given the limited data we have for your situation, what I've seen so far is someone that is low with basal suspended for the previous 3 or 4 hours. That's not "continuing to pour insulin into someone". Neither is a negative netIOB that's less than 50% of current basal rate. As has been mentioned before, these suggest other stuff going on, that may be settings and may be a recently diagnosed person still producing insulin in fits and starts.
It's worth pointing out that none of the algorithms are a panacea and do require a level of human oversight, hence the term "hybrid closed loop" rather than simply "closed loop". They are not magic.
I suggest you work with @dexdan who has offered up an approach and see where it gets to. @dexdan - lines starting at 880-893 should give you an indication of what happens in the current set up.
@MilosKozak @AdrianLxM my contribution is clear. I identified the issue, proposed a solution, and refuted all arguments from scott in his defense of "there is a good side to release insulin when a child moves from BG 54 to 59". I can't have the technical skills to do this on my own. I can test and RC if i can be of help. But doing it on my own is just impossible.
Please let me know if there is anything within my expertise as a user and caregiver where i can be of help in this enhancement. But i have to leave the decision and execution in your expert hands.
THANK YOU
I've experienced the described problem of "staggered lows" a few times about 1.5 years ago, and have the documentation to demonstrate what went wrong. (In all occurrences it was a matter of increased insulin sensitivity due to seemingly harmless physical action, such as commuting by public transport and catching trains). Autosens by definition is too slow to catch on with that. (It is not made to detect activity, it excells at determining flus's and other infections though...). For those who do not track their Insulin receptor up/down regulations, it also takes care of that, along with infusion sets that are overdue for a change). EDKA has everything to do with withholding insulin, (first hand report from a T1D professional running into that trap on AAPS). oref0 now is incorporating a number of safety precautions, and some of them are explicitly designed to dampening possible oscillations. A (too long, as measured in insulin action) reduction below a basal threshold that would be appropriate for aerob activity would cause (at first) insulin resistance. Subsequently we'd be talking rollercoaster. [The withholding of insulin] extended even longer, we'd be seeing ketones.
I have found that oref0 is pretty good without fiddling with the underlying algorithm, (and I have subjected it to a number of nasty experiments, including unannounced basal insulin (up to 25% of my BR administered as Lantus injection) and on other occasions EOL sensor noise. It never failed to surprise me how benign oref0 would handle these situations.
My solution to the problem at hand was to inform oref0 of the parameter change it couldn't detect and temporarily raise my ISF (aerob activity), take carbs, and observe oref0 dosing excess carbs appropriately due to the ISF applied.
The other cases described are not a problem of oref0 - it can only "take back" 2-3 hours worth of basal insulin if a meal got overdosed (and it does so, as long as it is considered safe to do, taking IOB into account). If you dose for food calculating no activity and get active during the consecutive insulin action, be prepared to "eat your weight"° in glucose. oref0 does not change the basics of life as T1D, but it does a tremendous job assisting.
-- °to be precise: up to the amount of carbs you were dosing for, minus the insulin action that has already passed before your activities started.
Edit: reformatting for line breaks and typos
Tatiana, thanks for this. A few comments: 1 - you say "EDKA has everything to do with withholding insulin". This is incorrect. Just so we avoid the propagation of wrong ideas let me clarify a) when you are exercising and therefore withold insulin (because you are more sensitive) and may even get some level of ketones (which non T1D will also get) that is not EDKA. b) When you withold insulin for a very prolonged amount of time you will run into hiperglicemia and DKA c) If you look into the more recent medical literature you will get this "Some of the common causes of EDKA that have been reported in literature so far are low caloric intake, fasting or starvation (5), pregnancy (6), pancreatitis (7), cocaine intoxication, prolonged vomiting or diarrhea (8), insulin pump use (9) and of late use of SGLT2 inhibitors like empagliflozin, canagliflozin and so forth (10)" https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5592704/ d) If you read publication of reference #9 what it actualy means is that you recently DOSED INSULIN and that made your glicemia come down to below 250 but your acidosis was kept high. 2) Hope the above does the job to differenciate having some ketones VS DKA, and DKA from EDKA. 3) Even if we forget all the above, lets imagine you are on hipoglicemia and EDKA: is the solution simply to dose insulin? No. If you do that you kill the pacient. You need to give him carbs and insulin at the same time.
If you read in detail the biological fundamentals of T1D you will see that the body of a T1Diabetic keeps the functionality, as the normal body does, to raise BG in the absense of insulin. That is why absense of insulin per se does not cause EDKA. It may cause DKA but that does not happen in hipoglicemia.
GOing through the literature would help you finetune your already greatly detailed knowledge.
Sorry to transform a github thread into a medical review... I sense this enhancement will never be accepted by you but lets at least reject it for the correct reasons... a)
I am still going to have an experiment with the code on this. But I was interested in how commercial systems guard against the possible EDKA risk.
The Medtronic 670g says "The Suspend on low feature causes the pump to temporarily suspend insulin delivery for a maximum of two hours. Under some conditions of use, the pump can suspend again, resulting in limited insulin delivery. Prolonged suspension can increase the risk of serious hyperglycemia, ketosis, and ketoacidosis" [https://www.medtronicdiabetes.com/customer-support/minimed-670g-system-support/cgm-low-settings]
The Tandem Basal-IQ (predictive low glucose suspend) says "Insulin may be suspended for a minimum of 5 minutes and a maximum of 2 hours within a 2.5-hour rolling window." [http://webcache.googleusercontent.com/search?q=cache:3MzJayn_ZdoJ:https://www.tandemdiabetes.com/providers/products/basal-iq&hl=en&gl=uk&strip=1&vwsrc=0]
The latter is interesting as it says to me that they will happily suspend for say 2hrs, then deliver 30mins of some insulin, then suspend again. The medtronic 'under some conditions of use' hints at similar. Now, I suppose that begs a question - if we were worried about EDKA (and I accept we might or might not be), what would be the minimal amount of 'some' insulin that needed to be delivered in the 30min delivery window between the prelonged suspends?....
My constructive contribution
- note that in the Medtronic site they never mention EDKA. They do mention DKA and hiperglicemia many times in the context of the CGM being wrong Vs the blood glucose.
- The Tandem one is not detailed enough to infer.
- also what both don't say is what it means to stop suspending. Is it going back to 100% basal or is it like the bare minimum the pump can afford (like 0.01U/h)?
- As EDKA is not caused by absense of insulin (sorry, it is what it is i can't work under a different assumption) i guess medtronic and tandem's concern is "if the CGM is low for a long time and insulin is cut for a long time could it be that the CGM is wrong when it says 60 and we are really at 300?". I would defer to continue with insulin==0 & use alarms saying "your insulin is cut for a long time please confirm BG on blood and ketones". The consequence would be a) if the person is awake the alarm would be seen and acted uppon propoerly b) if the person is asleep or for some reason misses the alarms i would still continue cut because it is the difference between "the CGM was right, the person is really low, and with more insulin he dies" Versus "the CGM was wrong and the person is in DKA". Between 2 evils i would rather pick DKA.
As a user i would not want the algorithm to pretend to know better than the CGM.