Artificial-Pancreas / iAPS

MIT License
175 stars 714 forks source link

Add support for different insulin strengths, such as U-200 #178

Open LiroyvH opened 1 year ago

LiroyvH commented 1 year ago

Added for tracking as discussed on Discord and as Jon already had been thinking about doing this as well:

Working with U-200 I started wondering if it'd be worthwile to implement different insulin strengths. You keep the same settings/profiles in iAPS and you bolus and log the same amounts of insulin and carbs, but the system will: a.) when set to U-200 mode reduce the insulin output on the pump by 50% relative to U-100 and b.) for U-400 it will reduce it by 75% relative to U-100, and c.) it will also have to multiply the remaining amount of units available in the reservoir. (Eg: Omnipod Dash that starts counting down from 50U would show 100U instead when on U-200 mode)

So what you see as the user is when you want X amount of units: you always get that exact same amount of units regardless of the insulin strength; also in reports and Nightscout. 1U is always 1U - we're using the unit as the standard for measurement rather than how many units per ml were in the pen and are now in your pump. As such, we just ensure the amount of millilitres required to deliver that amount of units are reduced in the background to account for the pump only 'speaking' U-100. On the pump itself, if it has a display, this will confusingly looks like reducing "units", but we're just compensating for its dumbness. (Eg; if we want 2U on U-200 mode: we tell the U-200 filled pump, which always thinks it has U-100 in it, to inject "1U" to compensate for the higher insulin strength. And 2U/hr of basal will be set to 1U/hr on the pump.)

The reasoning behind it is that this leads to:

Possible negative effects I honestly couldn't directly find any, especially as Eli Lily chose the exact same strategy with their pens. (Reduce output in millilitres, rather than making the user reduce their number of units - they chose to use the unit as the standard rather than the units per ml as well.) The current negatives are you have to maually change profile and manually remember it and the nightscout, AT and AS data get's "tainted" when you switch insulins. If it's as easy as switching in-app from U-100 to U-200 when you switch insulin type: that's easier and probably safer.

There are some caveats, however, such as:

Thank you for your consideration and thanks in advance to everyone providing input/suggestions/feedback on this.

dnzxy commented 1 year ago

Hi @LiroyvH

Love the idea of supporting U200 insulin from within iAPS. Just to add a point to your issue here and maybe move the discussion forward:

As a person that regularly struggles with pod leaks and has to „guesstimate“ how much insulin was administered, how much to delete from dosing history and possibly how much to give by manual dose, „hiding“ the actual dose would make this troubleshooting harder. Generally speaking, it would just make it harder to troubleshoot dosing in „what happened here when X was dosed or Y happened“ type scenarios.

I like the idea, generally, but I think it comes with big caveats when you are trying to analyze dosing history and I don’t think that you can 1:1 translate how Eli Lilly does its pen dosing mechanism to pump therapy.

How about you can switch or toggle a U200 or U400 switch / option and it automatically adjusts your settings for you (while considering technical limitations such as 0.05u minimum dose)? When you decide to switch back to U100, you just deactivate the switch. That way it doesn’t „hide“ things and the app will still clearly guide you through all dosing, but it stays transparent and you don’t have to go in and fiddle with settings.

LiroyvH commented 1 year ago

Ola @dnzxy :)

Thanks so much for the feedback and thanks for bringing it here. :)

I gave this some thought in the interim and I don't think I really understand how in this situation the problem is different when compared to the existing situation (even with U-100)? The system doses what you put in, so that’s still what you guesstimate on and is exactly the same situation when on U-200 or U-400. 🙂 The unit is the measurement, regardless of U100 or U200 - so deleting the treatments also stays exactly the same. That the pump, as it’s dumb and only understands U-100, says it delivered fewer units (to compensate for different insulin type) doesn’t change the fact how many standardised units were actually truly delivered. 1U is 1U, that the pump thinks it’s 0.5U or 0.25U is irrelevant; that’s because it thinks U-100 no matter what you throw in. iAPS would solve that by showing how many standardised units are truly delivered.

So you still just count units just like you did on U-100 and guesstimate how many will have been lost, there’s nothing you have to change or do extra maths on backwards; if you instruct to get 2U: you get 2U. The ml delivered doesn’t change anything there. If you can follow my train of thought there? 🙂 The situation isn’t any different? History stays the same. Etc.

The only thing different is that maybe the puddle of insulin you see is smaller (though that’s an issue when halving as well hehe). Think of it as an Omnipod carrying 400U rather than 200U whilst 1U is 1U. Rather than having to half all your doses and technically “lie” by delivering “half the amount” you’re used to, you would now still deliver the same units - just with less millilitres of insulin solution being CSII-administered. But whether you’re on U-100 or U-200: the same problem is at play, no? I mean, if you half everything in your settings and your pod starts leaking you have to guesstimate it differently as well if the size of the spot is the indicator.

Long story, haha! But wanted to cover all bases of how I think we should approach it/what the mentality behind it is. :)

I like the idea, generally, but I think it comes with big caveats when you are trying to analyze dosing history

That I don’t think I understand, sorry! Can you please elaborate why would it be a problem when looking at the dosing history? Maybe if you look on a Medtronic pump (hence warning and explanation in app!), but for an Omnipod it shouldn’t matter at all as iAPS will tell you exactly what was dosed?

When you think of it, at least in my opinion: compensating by doing /2 or /4 on all doses is more of a cheat than when using the unit as the standard as how it should be. :) And U-100, 200 or 400: 1 unit is always 1 unit, the amount of ml isn’t in the equation, we just always had to do that because the pumps were too dumb to speak U-200 or U-400 and we had to do the maths ourselves. But that math is "wrong" in relation to what a unit is supposed to be.

How about you can switch or toggle a U200 or U400 switch / option and it automatically adjusts your settings for you (while considering technical limitations such as 0.05u minimum dose)?

Switching the profile settings doesn’t really solve any of the other issues unfortunately :(. Then you still run in to “fake” delivering fewer units (you say you injected 0.5U but in reality it was 1 or 2U), calculations work completely differently, reports in Nightscout change, your profile and basals are “wrongly” adjusted, the algorithm may struggle with your new TDD-data, etc.

Thanks again for the feedback, ideas and input!

dnzxy commented 1 year ago

1U is 1U, that the pump thinks it’s 0.5U or 0.25U is irrelevant; that’s because it thinks U-100 no matter what you throw in. iAPS would solve that by showing how many standardised units are truly delivered.

I think I misunderstood this part. I thought you wanted to manipulate what is being shown as dosed and show just 50% or 25% of what was actually dosed.

The only thing different is that maybe the puddle of insulin you see is smaller (though that’s an issue when halving as well hehe).

This may actually be an issue in itself because this may make it harder to identify leaky pods / occlusion; but totally different scenario and issue.

Think of it as an Omnipod carrying 400U rather than 200U whilst 1U is 1U. Rather than having to half all your doses and technically “lie” by delivering “half the amount” you’re used to, you would now still deliver the same units - just with less millilitres of insulin solution being CSII-administered. But whether you’re on U-100 or U-200

Yep, totally making sense now. The guesstimating part stays the same. I don’t know by, but I initially thought we were setting out to manipulate what was being shown in iAPS, but your suggestion wouldn’t do this. It’s just that 1U is actually 2U or even 4U strength. I may have been guided down this thought pattern by that last paragraph talking about settings not being truly what’s being dosed. My fault, sorry.

Can you please elaborate why would it be a problem when looking at the dosing history?

Same issue, see above. Thought we were masking what’s being dosed.

Sorry for my initial comment. I seem to have completely misunderstood your suggested feature in a very weird way. So essentially, instead of masking anything in iAPS, the idea is to actually still show the true insulin dose, so units-based history and settings, just half (or quarter) the actual injected dose, e.g., app shows 1U dosed, but it actually just doses 0.5U=U200 or 0.25U=U400. Same for IC or ISF. IC of 1:10 is still 1:10, but the actual dose would be 0.5/0.25U; ISF of 50 still means 1U moved sugars by 50mg/dl, yet it requires only half or quarter of the „fluid“ (as in the clicks by the pod = insulin injected).

Do you know if Jon, Pierre or anyone else has started to work on this yet?

MikePlante1 commented 1 year ago

I love this idea. Two things I don't see mentioned above:

Currently when switching between U100 and U200 with iAPS, it's important to either reset the app or build a second iAPS app, because several equations use TDD history which would be very wrong after switching concentrations. Sounds like this wouldn't be an issue with your solution, though.

Also, Bolus Increment would have to be set to 0.1 instead of 0.05 for U200 (.2 for U400, which I didn't even know existed). The bigger problem that needs addressing is basal increments, though, since I currently don't see any settings to alter that minimum.

jlmgithub commented 1 year ago

Love any idea that makes life as a T1D easier. Per your comment and @MikePlante1's info and help, I set up a U200 iAPS version, which I will be using when I change my pod within the hour. I absolutely would love to NOT do calculations constantly.

LiroyvH commented 1 year ago

@dnzxy No problem! Re-worded it a little in the hopes its clearer to prevent confusion. :)

Sorry for my initial comment. I seem to have completely misunderstood your suggested feature in a very weird way. So essentially, instead of masking anything in iAPS, the idea is to actually still show the true insulin dose, so units-based history and settings, just half (or quarter) the actual injected dose, e.g., app shows 1U dosed, but it actually just doses 0.5U=U200 or 0.25U=U400. Same for IC or ISF. IC of 1:10 is still 1:10, but the actual dose would be 0.5/0.25U; ISF of 50 still means 1U moved sugars by 50mg/dl, yet it requires only half or quarter of the „fluid“ (as in the clicks by the pod = insulin injected).

Yes and no. In technical terms, that is what it does - but I'd like to ensure the "actual dose" part isn't worded that way. It actually doses an adjusted dose to compensate for the problem with the pump solely speaking U-100. Might sound a bit nitpicky, sorry for that :P, but I hope we can move away from taking what the pump says as "the true/actual dose" and instead consider how many units we truly inject. If we dose "0.5U U-100" whilst the pump is filled with U-200: that is simply 1U actual dose, not 0.5. That the pump displays it wrong/has to be told what to inject "in the wrong way/dose" doesn't alter the fact about the units actually being delivered. The unit is the standard, not what the pump claims the U-100 equivalent is and which we have to compensate for by "reducing" output in the background.

@MikePlante1

Currently when switching between U100 and U200 with iAPS, it's important to either reset the app or build a second iAPS app, because several equations use TDD history which would be very wrong after switching concentrations. Sounds like this wouldn't be an issue with your solution, though.

Correct, this shouldn't be an issue as the algorithm can keep using the exact same units and profile settings. (ISF, CR, basal, etc.)

The bigger problem that needs addressing is basal increments, though, since I currently don't see any settings to alter that minimum.

I think this is guarded by the same minimal delivery? If your hourly basal rate is 0.1 which so happens to also be the pump minimum, then it cannot account for that with U-200 as the minimum is then 0.2U actual dose. (0.1 * 2 = 0.2U minimum). But that'd be a problem when attempting to reduce it manually on the pump as well instead of iAPS or whatever else; you can't go beyond the technical limitations of the pump in any way at any time. So U-200/U-400 simply wouldn't be fit for those people.

At other moments I don't think it's an issue as it should simply reduce the basalrates in the background and send that, background modified, profile to the pump so the pump delivers U-100 equivalents (compensated for by us, iAPS keeps showing the actual units) of whatever insulin strength (U-100/U-200/U-400) it has. If someone uses extremely little basal, it's rather unlikely they'll use U-200 so I don't think we'll quickly find someone who would hit this limitation. But if they do: nothing can be done. 0.x is the technical minimum and even us accounting for it won't make a difference.

dnzxy commented 1 year ago

The unit is the standard, not what the pump claims the U-100 equivalent is and which we have to compensate for by "reducing" output in the background.

Very much agree, I was just trying to make sense to what the dosing (as in less fluid, less ticks from the pump perspective) would mean with non U100 insulin. I meant it the way you so rightfully described it.

Do you know of any development in this direction? I took a look at the APSManager the other day and some of the instances where enactBolus and enactTempBasal are called, but it seems very odd to just multiply that dose by a specific factor. I‘m also not sure if some changes would need to be made to dependencies (OmniKit?) and if it’s a good thing to be altering that; I‘m not sure it’s necessary though so would be interested if there are some rough outlines of how this would go implementation-wise.

LiroyvH commented 1 year ago

@dnzxy I believe @Jon-b-m was toying with the idea, but not sure if any development work or thought has gone in to that yet other than perhaps concepts or deep thoughts during a long walk in the forest (ok, projecting now. :P). Hence why I also dropped it here with an essay on what I think is needed, pros and cons/caveats. :)