Lyumjev U200

[misterizzz]

An option with adjusted dosing for the omnipod dash for Lyumjev U200 would be very helpful

[JeremyStorring]

Hello @misterizzz, can you please use the following template?

## Is your feature request related to a problem? Please describe.
*Provide a clear and concise description of the problem. Explain how this issue affects your experience with the Trio app and any specific scenarios where it occurs.*

## Describe the solution you'd like
*Detail the desired change or feature you'd like to see implemented in the Trio app. Be specific about how this solution would improve your experience and address the problem described above.*

## Describe alternatives you've considered
*List and describe any alternative solutions or features you've considered that could also address the problem. Explain why you believe the proposed solution is the best option.*

## Additional context
*Include any other context, screenshots, or relevant information that might help in understanding the issue or the proposed solution. If applicable, describe any previous discussions or decisions that relate to this feature request.*

## Technical Details
*If applicable, provide any technical details or considerations that might impact the implementation of this feature. This could include dependencies, potential risks, or required changes to existing functionalities.*

## User Impact
*(Optional) Describe the impact of this issue on your use of the Trio app. Include any specific examples or data that demonstrate how widespread or severe the problem is.*

Thank you!

[LiroyvH]

I wrote a lengthy feature request for that for iAPS:

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:

• a.) Consistency. It is similar to using Humalog/Lyumjev pens with increased potency. With the pens Eli Lily provides, 1U on the dial is still 1U injected - this doesn't change. The mechanism reduces the insulin (in ml) administered, not the user. So with U-200 when you inject 100 units, it injects only 0.5ml instead of the 1.0ml it would've been on U-100. This ensures the user doesn't have to change anything, the only thing that changes for the user is that the pen lasts twice as long.
• b.) Prevents confusion when you have to do the maths yourself whilst coming from U-100 and are used to doing bolus calculations in your head or correcting quickly
• c.) Keeps nightscout output consistent so for analysis you don't have to multiply it by 2 or 4 for the interpreter (eg: endo) to understand it. Plus some added bonuses if the care team hates U-200/U-400.
• d.) Keeps settings cross-compatible with any insulin type and strength, nothing changes; you just have more units available to work with (a 200U Omnipod becomes 400U or 800U)
• e.) Makes tuning work better and cross-compatible between different insulin types as it has the same data to work with, only minor tweaks may be necessary after switching to a different concentration.
• f.) It's actually more correct imho. Artificially "reducing" the units you're delivering in the profile and for bolus and basal is technically lying to the system. You're not suddenly actually using 50%-75% fewer units of insulin, no: you're still using the same amount of units. You just have to "lie" about that because the pump isn't capable of speaking U-200/U-400, but this lie finds its way to all your settings, reports, the algorithm, etc. It becomes more confusing to analyse those reports as well when every delivery you see must be multiplied by 2 or 4 to get to the true amount of units delivered.

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:

• a.) The stored settings on the pump will be different than what the app shows, such as the basal rates. Whilst the app in this setup will show the same basal rates + ISF + I:C as on U-100, we do instruct the pump in the background to deliver 50% less on U-200 and 75% less on U-400. So 1U/hr basal will be 0.5U/hr shown on the pump with U-200 and 0.25U/hr shown with U-400. An in-app warning above/next to the basal rates (and other factors) plus a clear explanation in the docs is a good idea for starters. People must also be made aware that if for whatever reason they manually bolus directly from their pump (eg: Medtronic), they need to remember to do the maths.
• b.) The minimum bolus delivery (and minimum basal per hour) is different and is a hardware limitation. Eg: if 0.05 is the minimum, on U-200 that'd be equivalent to 0.1U and on U-400 that'd be equivalent to 0.2U minimum.
• c.) People using other software to generate reports from data stored on their pump, such as Glukoo or Tidepool, may see their insulin administration is reduced by 50% or 75% compared to what is shown in-app and in Nightscout. With the current supported pumps, that's likely not an issue (as they cannot be read with such tools to my knowledge); but it may be a problem in the future. It's important to point that out and/or get in touch with the developers of such tools to allow setting insulin strength.

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

(Copied from: https://github.com/Artificial-Pancreas/iAPS/issues/178)

[Sjoerd-Bo3]

@LiroyvH Is it okay that I paste this in the original message? Or a new issue? So it is clearer in the opening comment?

[LiroyvH]

@Sjoerd-Bo3 I'd be happy to open a new one, but it won't directly conform to the template. (I mean... it pretty much adresses everything that's asked, just not in that exact order :P)

[Sjoerd-Bo3]

@LiroyvH Making a new one is fine by me. You don't have to align with the template. But if you would:

Is your feature request related to a problem? Please describe.

Currently, Trio does not support different insulin strengths (U-200, U-400), which means users need to manually adjust their profiles and settings when switching from U-100 insulin. This can lead to confusion, inaccuracies in insulin delivery, and inconsistent data in Nightscout and other reports.

Describe the solution you'd like

Implement support for different insulin strengths (U-200, U-400) in the Trio app. The system should automatically adjust insulin delivery based on the selected insulin strength while keeping user settings and profiles consistent. Specifically:

• a) When set to U-200 mode, reduce insulin output on the pump by 50% relative to U-100.*
• b) When set to U-400 mode, reduce insulin output on the pump by 75% relative to U-100.*
• c) Multiply the remaining units available in the reservoir to reflect the correct amount (e.g., an Omnipod Dash starting from 50U would show 100U in 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 look 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.)

Describe alternatives you've considered

1. Manually changing profiles and settings when switching insulin strengths, which is prone to error and increases user burden. 2. Continuing to use U-100 insulin, which may not be feasible for all users due to availability or specific medical needs.

Additional context

This feature ensures consistency and accuracy in insulin delivery and reporting across different insulin strengths. It aligns with how Eli Lilly pens manage higher potency insulin, ensuring user settings remain the same while adjusting the insulin delivery in the background. Key benefits include:

• a) Consistency in insulin units delivered, regardless of strength.*
• b) Simplified bolus calculations and profile management.*
• c) Consistent data in Nightscout and other reporting tools.*
• d) Cross-compatibility of settings with different insulin types and strengths.*

The reasoning behind it is that this leads to:

• a) Consistency. It is similar to using Humalog/Lyumjev pens with increased potency. With the pens Eli Lily provides, 1U on the dial is still 1U injected - this doesn't change. The mechanism reduces the insulin (in ml) administered, not the user. So with U-200 when you inject 100 units, it injects only 0.5ml instead of the 1.0ml it would've been on U-100. This ensures the user doesn't have to change anything, the only thing that changes for the user is that the pen lasts twice as long.*
• b) Prevents confusion when you have to do the maths yourself whilst coming from U-100 and are used to doing bolus calculations in your head or correcting quickly.*
• c) Keeps Nightscout output consistent so for analysis you don't have to multiply it by 2 or 4 for the interpreter (e.g., endo) to understand it. Plus some added bonuses if the care team hates U-200/U-400.*
• d) Keeps settings cross-compatible with any insulin type and strength, nothing changes; you just have more units available to work with (a 200U Omnipod becomes 400U or 800U).*
• e) Makes tuning work better and cross-compatible between different insulin types as it has the same data to work with, only minor tweaks may be necessary after switching to a different concentration.*
• f) It's actually more correct. Artificially "reducing" the units you're delivering in the profile and for bolus and basal is technically lying to the system. You're not suddenly actually using 50%-75% fewer units of insulin; you're still using the same amount of units. You just have to "lie" about that because the pump isn't capable of speaking U-200/U-400, but this lie finds its way to all your settings, reports, the algorithm, etc. It becomes more confusing to analyze those reports as well when every delivery you see must be multiplied by 2 or 4 to get to the true amount of units delivered.*

Possible negative effects:

• a) The stored settings on the pump will be different than what the app shows, such as the basal rates. Whilst the app in this setup will show the same basal rates + ISF + I:C as on U-100, we do instruct the pump in the background to deliver 50% less on U-200 and 75% less on U-400. So 1U/hr basal will be 0.5U/hr shown on the pump with U-200 and 0.25U/hr shown with U-400. An in-app warning above/next to the basal rates (and other factors) plus a clear explanation in the docs is a good idea for starters. People must also be made aware that if for whatever reason they manually bolus directly from their pump (e.g., Medtronic), they need to remember to do the maths.*
• b) The minimum bolus delivery (and minimum basal per hour) is different and is a hardware limitation. Eg: if 0.05 is the minimum, on U-200 that'd be equivalent to 0.1U and on U-400 that'd be equivalent to 0.2U minimum.*
• c) People using other software to generate reports from data stored on their pump, such as Glukoo or Tidepool, may see their insulin administration is reduced by 50% or 75% compared to what is shown in-app and in Nightscout. With the current supported pumps, that's likely not an issue (as they cannot be read with such tools to my knowledge); but it may be a problem in the future. It's important to point that out and/or get in touch with the developers of such tools to allow setting insulin strength.*

Technical Details

This feature involves adjusting the Trio app’s insulin delivery calculations and display settings based on the selected insulin strength. It also requires clear documentation and in-app warnings to inform users about the adjusted delivery rates on the pump.

User Impact

Medium – This feature will improve the ease of use and accuracy of insulin delivery for users switching between different insulin strengths.

[LiroyvH]

@Sjoerd-Bo3 So it doesn't have to align with the template, as long as it does actually align with the template. Right. :P Alright, I used your example and made a couple of modifications. I very much preferred the order in which I wrote things in my original submission, but alas: it is what it is. :) Created as issue #264! :)

[Sjoerd-Bo3]

Ooh no it doesn't have too! But your request had, wishes challenges and why tangled into each other. That reads not so nice if you want to implement. It's nice as a story but not point wise for a solution. If you know what I mean. For sure my piece wasn't 100% complete I agree on that.