Add Afrezza, Apidra, Levemir, Basaglar and Tresiba profiles, and correct Lantus, Toujeo and Novo Rapid profiles based on more recent data.

[kaelonR]

This pull request will add Afrezza, Apidra, Levemir, Basaglar and Tresiba insulin profiles to Xdrip, and corrects profile data for Lantus, Toujeo and Novo Rapid based on published activity graph data. (Most notably, Lantus was listed as a 36-hour insulin while even the manufacturer published an activity graph showing only 24 hours of activity)

Numerous sources were used to find the profiles for each of these insulins.
https://dlife.com/insulin-chart/
https://my.clevelandclinic.org/health/drugs/13902-injectable-insulin-medications
https://alliedhealth.ceconnection.com/ovidfiles/01741002-201807000-00005.pdf
Activity graph showing profiles for various insulins
https://www.ema.europa.eu/en/documents/variation-report/novorapid-h-c-258-p46-0044-epar-assessment-report_en.pdf
https://www.toujeopro.com/toujeo-vs-lantus-efficacy-safety
https://www.afrezza.com/pdf/Prescribinginfo.pdf

After adding these profiles, because the amount of insulin profiles was increased from 7 to 12, the list of profiles in the insulinprofile_editor activity overflowed, causing some profiles to be unselectable:

To fix this, i've wrapped the insulin profiles in a ScrollView for future proofing in case more profiles are added in the future, and i've moved the basal/bolus dropdowns and cancel, reset and save buttons down to create more room for selecting insulin profiles. The result is this:

These additions should hopefully make it much easier for users to create profiles that correlate better to their insulin needs, by both making MDI easier to configure and BG predictions more accurate.

[ANDREAPIPPI]

Wow J141, these are very good news.
I hope to see it reviewed and merged in a short time.
Very appreciated, well done!
Bye
Pippo :-)

[jamorham]

@gruoner @stephencmorton can you provide comments on this PR please, thanks

[gruoner]

i will merge the PR to my DEV train and have a test - coming back soon

[stephencmorton]

I looked at the diffs and they look reasonable. I didn't look in tremendous detail, but it all looks reasonable to me anyway.

To be honest, at a meta level, I'm less and less convinced that this feature of tracking longer-lasting insulin makes much sense. I was only interested because NPH can be used as either pure-basal, or a basal+"delayed bolus" (e.g. if you don't want your child to have to inject at school, you can delay their lunch bolus by using NPH at home at breakfast time). But a lot of that NPH is still basal, so how do you account for what part is basal and what is bolus? Including all the basal parts in your bolus calculations could throw everything off.

[gruoner]

i had a successful compile and deployment and everything is running as expected. BUT someone with smaller display sizes (like me who uses a galaxy star) might get problems with the double sliding screen (first slider because the whole page is larger than the screen and second slider because the insulin scrollview). So it might be better to use fixed size for the bottom part and "the rest" of the available screen size for the scrollview? How can i add this to the PR or is it better J141 would do this?

[gruoner]

@stephencmorton
i can't really understand your arguments against long acting insulin profiles..... From my point of view insulin activity is reduction of blood glucose - whenever insulin activity will occur it will reduce blood glucose; regardless of ultrafast-, fast-, short- or long-acting profiles. Insulin is insulin and it will reduce blood glucose.
When my point of view is correct, all types of "acting insulin" is just (and only) a matter of therapy, not a matter of prediction.....
So one can use it for predicting effects of FIASP, novorapid and even levemir and Tresiba. BUT the precision and "correctness" of the activity model is much more important for longer acting profiles than for shorter or faster acting ones - that's for sure. And here such effects like accumulation of constant and regularly tresiba injection will get really important to be represented by the insulin activity model. When your arguments are addressing this issue of precision i can agree with you and together we can work on other activity models to increase precision. I'm quite sure there are lots of research papers where we can find information how really long acting profiles effect blood glucose.....

[stephencmorton]

@gruoner Let my try to clarify.

Insulin needs are generally divided into two categories "bolus" insulin which compensates the carbs you eat, and "basal" insulin that serves your body's metabolic needs. These are both important, but different.

We have concepts such as "I:C" ratio and Insulin Sensitivity Factor (ISF, often also referred to as a "correction factor").

When a program like xDrip+ calculates your predicted BG based on injected insulin and their corresponding decay profiles, food ingested and its corresponding decay profile, and your I:C ratio it is usually just talking about "bolus" insulin.

When a program like xDrip+ calculates the correcting effect of taking a certain amount of insulin to treat a high, based on your ISF, again this ISF is generally purely based on "bolus" insulin.

If you simply have a long-acting insulin like Tresiba and you want to put it in xDrip+ and you choose to not have it be part of the insulin calculations, this is fine, it's business as usual.
If you choose to have your long acting insulin be part of the insulin calculations, it will throw everything off. You could give it new I:C ratios and ISF values. But those will be non-standard values that will a) not really make sense and b) will confuse your endo because "you're not doing it right".

But things get more confusing with something like NPH because often it's used as part-basal and part-bolus. (You can see how an NPH curve is kind of like a flat basal long-acting insulin curve added to a delayed Humalog curve.) Here, what do you do? Do you make it part of your calculations, or do you not? Neither is really satisfactory.

The only real solution would be to also add a "required basal profile" to xDrip+ as well. For pumpers, it's just what you put in your pump as your basal profile. For those injecting insulin, you'd need some UI to add it. (A very rough solution would be to simply say "I need x Units/hour basal" which is not terribly accurate, but is better than nothing.)

Full disclosure: I haven't used xDrip+ in ages, so my understanding of its operation may be flawed.

If this doesn't convince you, let's not make a long drawn-out discussion, let's just agree to not understand each other. I've had trouble convincing you of anything at all in the past.

[ANDREAPIPPI]

Hi Gruoner and stephencmorton.
I would also like to express my opinion, and here it is: instead of discussing the sex of the angels (because in the end this is the result), why don't you let us check what's the effect in the REAL use of this new approach?
Surely I can say that the current system, with Tresiba's values not given because actually it cannot be done, is NOT precise enough, and sometimes badly wrong, at least for me.
So why don't we check what is the real importance of using a basal insulin value in the IOB calculation?
Maybe Gruoner is right, or stephencmorton is right, or both or nobody is right, but we will never know it only with words.
So please approve and merge it, and let's see what happens!
In this way you will be able to discuss using "in the field" real data.
My little 2 cents.
Pippo :-)

[gruoner]

OK; now its getting clear - you are stuck in basal/bolus therapy, but there are lots of other insulin therapies.....
All concepts you are using (basal, bolus, I:C ratio and ISF) are concepts of basal/bolus therapy and this kind of therapy assumes that there is a difference between reducing BG from eating and reducing BG for "metabolic needs". That's OK, but in the end its reduction of BG regardless where it comes from or what it is used for....
I can agree your issues with NPH and any other "multi purpose insulin product" - it can't be calculated in a basal/bolus therapy schema. BUT this isn't a problem of xDrip, it is a problem of your therapy as it can't handle it.
Now lets think about how we might calculate such multi purpose products to get a correct I:C, ISF and even a correct basal rate and lets implement it in xdrip.......

[stephencmorton]

@ANDREAPIPPI I'm not an xDrip+ developer/maintainer. I'm just a guy who once commented on this feature, and found a few calculation errors in it. I have no authority to approve anything.

Personally, as a professional SW developer though, I would argue that you test and shake out all the bugs before approving any pull request. (Especially for medical SW which life and death decisions may be based on, but really just on principle for any sw.)

[gruoner]

@ANDREAPIPPI i totally agree with you, but @stephencmorton reflected another issue and (as i'm also using a NPH) i think we should discuss how to address it.
i advice an authorization of this PR and some days after merge and release we can discuss your experience with the new tresiba prediction; i'm really excited.....

[gruoner]

@DiabeticTurtle & @cominixo i saw your emoji but a simple thumps down is pretty less for such an important discussion like "how do we want to use multiple insulin profiles in xdrip?"
Can you describe your issues u have with my comment - maybe its a matter of my lousy english?

[stephencmorton]

@gruoner I do not know the reasons behind others' emojis. I admit that I am a newb when it comes to T1D and insulin, so I could be completely wrong. But AFAIK, most treatments are based around basal/bolus therapy. Perhaps they were indicating that anybody implying otherwise, is making pretty outrageous statements. As I said I'm new to this, can you point me to some insulin therapies backed by large diabetic/medical organizations that are not based on basal/bolus concepts?

[cominixo]

The thing is, just because "there are other insulin therapies" doesn't mean they're accessible to everyone, and even then not everyone wants to use a pump and just prefer to stay on MDI. There's no reason to not have as many options as we can.

[kaelonR]

I'm going to add my two cents here, but isn't xdrip designed to offer as many options to as much people as possible? If so, I say we shouldn't be having a discussion on how we want to do multiple insulins in xdrip but rather allow the user to adjust xdrip's behaviour to their specific therapy and needs. people might be stuck on basal/bolus therapy, but i think that should only be more reason to support that therapy, not exclude it.

I also don't agree with your point that long term insulin is going to reduce BG regardless @gruoner. The point being that in order to correctly predict how a basal insulin affects one's BG, xdrip would somehow have to model the rise in BG levels when someone uses no basal insulin, which xdrip currently doesn't do and which i think is hardly doable because bodies' insulin needs vary troughout the day.

Currently i need 48 units of tresiba a day just to keep a roughly baseline BG level during the daytime. If i'd inject 30 units, my BG level would definitely shoot up as my body's basic insulin needs wouldn't be met. However right now if i'd enter 30 units of Tresiba into xdrip, xdrip is going to predict a rather steep drop in BG where in reality i'm not going to drop at all but rather climb up.

Rather than discuss how the basal predictions should work, i was planning on opening another PR soon to include an option not to use basal insulin in iob calculations, as this would solve a big part of the insulin predictions being unreliable for people on basal/bolus therapy that also want to keep track of their basal insulin, while keeping the current way of prediction open to people who prefer this mode of operation.

[gruoner]

thats the point - "large diabetic/medical organizations" always use/prefer therapy schema like basal/bolus as they are "very easy" to calculate WITHOUT any usage of IT - quite everyone can calculate his/her needs for basal insulin and their needs for bolus before/after eating and he/she doesn't even need a calculator. That's a very very (very)*..... big advantage of FIT and any other basal/bolus schema.
BUT (with xdrip and nightscout) we are in another situation - we use (and need) IT to support our T1D therapy; thus we can break with such limiting concepts like "basal for metabolic and bolus for eating needs" and we can harvest the fruits of this outbreak (e.g. limitless usage of multi purpose profiles like NPH and a "better" or "more precise" prediction of BG resulting in "better" therapy treatments)......

And now it comes to the really important question: is (the mainstream) xdrip a good container to evaluate such experiments or should we even establish a new train (of course with light-weighted connections to the mainstream) xdrip because even if we implement "experimental feature switches" and let the user completely switching off this experimental code / experimental ideas, it is even in the package and can effect users (e.g. with pump therapy) which NEVER will be addressed by these experimental ideas.

I ask (and i'm really interested in your thoughts): can we protect other users from the negative effects of this experimental code (and any other belonging to such experimental ideas) enough, to save us from a second xdrip train and let all the other user harvest the fruits of these ideas (as they want to!!) OR do we really need a second (experimental) xdrip train to evaluate such concepts/ideas?

[gruoner]

@j141
AFAIK there is a switch to exclude basal injection from BG prediction

[gruoner]

i've got a question belonging to the need of basal insulin (esp. but not exclusively to @stephencmorton and @j141)
what are the main (in meaning of the most influencing) factors for the need of basal insulin for "metabolic needs"? Of couse it is weight of the person but what else?

[kaelonR]

@gruoner

... That's a very very (very)*..... big advantage of FIT and any other basal/bolus schema.
BUT (with xdrip and nightscout) we are in another situation - we use (and need) IT to support our T1D therapy; thus we can break with such limiting concepts like "basal for metabolic and bolus for eating needs" and we can harvest the fruits of this outbreak ...

I agree with you that xDrip's situation gives a good foundation to break with these traditional concepts, and i'm definitely happy to see various kinds of experimentation being added. however, i disagree with your opinion that we should completely break away from the traditional concepts of basal/bolus therapy just because we can experiment with other approaches.

A lot of people i know use xDrip, and all but one of them aren't using xDrip to experiment with approaches at all. They rather use xDrip simply because they want to integrate their FGM/CGM/FGM bluetooth bridge with an app that can continually receive these values, alert them of high/low BG and perhaps even predict where their BG levels are going in advance or upload their data to other systems that xDrip can upload into.

All of these users use basal/bolus therapy, and none of them would be served well if xDrip was to break away from basal/bolus completely and use different approaches instead. And besides that, a lot of these users wouldn't be savvy enough to understand how certain experimental features work and/or how that's going to affect their predictions. Even with the current options i frequently enough see people asking for help because they have no idea what they're configuring in xDrip's settings.

And now it comes to the really important question: is (the mainstream) xdrip a good container to evaluate such experiments or should we even establish a new train (of course with light-weighted connections to the mainstream) xdrip because even if we implement "experimental feature switches" and let the user completely switching off this experimental code / experimental ideas, it is even in the package and can effect users (e.g. with pump therapy) which NEVER will be addressed by these experimental ideas.

Because of my opinion above that many people just aren't savvy enough to understand how certain experimental features affect them or what works for them and what doesn't, my opinion is that for the really experimental stuff, where we'd try out new and unconventional approaches, xDrip needs an experimental version of the app and these features need to stay out of the mainstream app until they're well tested, to protect users from themselves. We're working with medical-background software after all, and if users start trusting and relying on badly working experimental features it could lead to very dangerous consequences, which i think is in all of our interest to avoid.

[kaelonR]

However, i also feel that this discussion about whether experimental features should be included in the mainstreap app or a separate app, and how xDrip should handle basal insulin is going off-track and is missing the original goal of this PR.

xDrip already has insulin types, and already has onset, peak and duration predictions for insulin types. However currently there are only 7 insulin types included while a lot of people use other insulins. The goal of this PR is to expand the list of insulins from 7 to 12 to better support the various insulins people may be using while maintaining the current set of features in xDrip.

How the basal dosage is then used in calculations in xDrip and whether xDrip should continue supporting basal/bolus dosages or not is outside the scope that this PR targets and is definitely not a feature this PR changes or touches at all.

For discussing on whether xDrip should keep basal/bolus or not and/or how basal should be used in iob calculations, i would like to suggest opening a new PR dedicated to that discussion.

[gruoner]

@j141 understood and agreed to both of your statements/comments!!

[munster-shug]

As a brand new CGM user and a newbie to xdrip+ firstly let me express my huge thanks to all the developers and active contributers on here. Honestly folks, you perhaps cannot understand the sense of control and power that I feel over my body for the first time in over 20 years as t1d. Thank youThank youThank you.
But on this topic I am confused as the xdrip+ android app that I cannot find any options to adjust insulin profiles in the android app version that I have. Should I be seeing a treatment profile or multipleiinsulin page as per @j140 screenshot above

[kaelonR]

Hey @munster-shug,

the multiple insulin feature is currently only available on the nightly builds, and not the latest "official release" apk. The nightlies (which really is a bad name that should've been 'previews') are pretty stable and safe to install though.

You can grab the latest nightly from this page: https://github.com/NightscoutFoundation/xDrip/releases

However please note that currently only the following 7 insulin types are supported: Fiasp, Novorapid, Humalog, Actrapid, Insulatard (NPH), Toujeo and Lantus.

the insulin types Afrezza, Apidra, Levemir, Basaglar and Tresiba aren't available in the official xdrip app yet and pending inclusion per this pull request. A PR is essentially a request to include some changes to the code in the official app, and the maintainer of xdrip+ @jamorham hasn't made a decision on whether to include this change yet. (for jamorham, yes, this was a little poke to ask you what your intentions are for this PR. :) )

If you can't wait and really want to use the app with the additional insulin types i've added, feel free to send me an email at j[dot]dekoning141(at)gmail{dot}com and i'll send you a signed apk that includes this change that you can install on your phone. Note that that would mean using an unofficial version of the app that would not be supported by the maintainers of xdrip+ though.

[munster-shug]

Thanks @j141. I'll await @jamorham s call on whether or not to include this PR in official version

[jamorham]

I'm happy to include this if we think that the numbers describing the insulin action profiles are likely to be as accurate as they can be.

When this feature was first introduced I added the ability to exclude basal insulin from the calculations because I don't think it makes sense when there is no modelling at all for metabolic glucose rise that is unrelated at all to food intake. I do think it is important for users to be able to record basal insulin doses though.

I haven't studied this PR in great detail but as long as it preserves that behavior then I think that should be good. I'm not sure how to handle insulins like NPR which may or may not be considered basal. From memory I think the decision on whether an insulin is basal is based on its action time being more than a specified amount.

[kaelonR]

Hey @jamorham,
this PR only alters the profiles in insulin_profiles.txt, and alters the insulin editor settings view to provide room for displaying the new profiles.

I've taken special care not to alter any business logic, so xdrip's current behaviour regarding basal insulin is maintained.

[suside]

So I re-opened this PR on my fork, it builds APK on each commit, you can download ready to install xDrip app from Artifacts sections of GH Action run.
If you have any questions or comments please post them there.

[tolot27]

@suside Please let us work together on #1388 (comment) instead of just creating an apk elsewhere.

[tolot27]

@j141 Can't you unsubscribe from this PR, can you? If yes, I like to reopen it.

[suside]

@suside Please let us work together on #1388 (comment) instead of just creating an apk elsewhere.

I'm really into working together @tolot27 😉 but:

• I am unable to create peer-reviewed publications etc. regarding insulin profiles myself.
• What could be found on the internet was already provided.

Therefore (and I said this last year) I see no other option than just use it as it is. However, if you have something specific in mind just let me know!

[aurixtech]

Any update on merging this PR? It would be useful to have, even if only from a logging standpoint. When sharing xDrip via Nightscout the "caregiver" can then verify that both bolus and basal treatments have been administered. Plus, it would be nice to have Apidra as an option for selection. Making a treatment note and having no option to select the correct insulin type is problematic when the treatment needs to be reviewed by a caregiver/medical professional.

Much thanks for the works so far!

[kaelonR]

@aurixtech Sadly, the PR has reached a dead end for now.

@tolot27 wants proof that the insulin profiles are correct, but the available info for each type of insulin and their activity profiles has already been provided in the original description of the PR. Besides the research done and papers available on that which have already been linked, We can't exactly do peer-reviewed research ourselves.

If you have anything in mind on how to proceed @tolot27 I'd love to hear it. As suside has said, what info is available has already been linked, and we don't exactly have accesss to the required equipment to do peer-reviewed research ourselves. I'd love to hear if you have a path forward in mind or if the PR cannot or will not be merged and should remain closed.

[jamorham]

I would like to split this PR to get at least some goodness out of it and provide utility to users. In my opinion there is no accurate information about insulin profiles, none of the manufacturer curves I have seen really seem to match with personal reality and there may also be significant variations even between individuals.

The data in the insulin profiles is intended as a reference guide, its good if its as close as we can get to good data but its not absolutely essential.

I would like to split this in to 3 parts and am happy to take guidance on the best way to achieve this:

1. Add insulins that are not currently supported. Even if these profiles are not 1000% accurate it is better than not having them as is the current situation.
2. If the UI elements are problematic due to too many items then that can be improved. If point 1 requires point 2 then I guess this needs to happen at the same time.
3. Change/correct existing profiles if a consensus can be achieved as to a better set of numbers for those curves.

[Navid200]

@jamorham An alternative approach, which would address 1 and 3:

Add 3 new custom profiles. I don't think there is anyone who uses more than 3 types of insulin at the same time.
Each custom profile should allow editing the parameters onset, peak, duration etc. such that any existing profile can be set up.
This will allow a user to tweak the profile to exactly match how the insulin works for their body.

In the documentation, we can include some guides including popular profiles as well as the required xDrip parameters to create an equivalent profile.
So, for example, a user can see what they need to set for onset and peak etc. to create a profile that would be equivalent to the existing FIASP profile.

[AlFontal]

So... What's the status on this? Is there any way to have a Novopen 6 assigned to Tresiba?

[yevhenlisovenko]

Also looking the changes in master as well. It will be very helpfull to see my insulin profile in xDrip.

[TheConen]

Can we please finally merge this? This PR has been open for over 3 years, I am still using a version of xDrip+ that I built myself out of this PR about 2 years ago because I am using Apidra and Toujeo. I would like to be able to update my xDrip+.

From a user standpoint I can say: I don't care about any activity curves. I know that Apidra lasts about 2hrs for me - I don't need xDrip+ to tell me that. What I do need is to be able to choose the Insulin type I actually use when entering treatments so I have a proper documentation.

[mateusglucas]

I was just searching how to choose Tresiba on xDrip+ and ended finding the Pandora's box. I think no one cares too much about the activity curves. It is only a mean activity, which doesn't exactly apply to anyone. It helps, but in practice no one takes the activity curves for granted to the degree of precision being discussed here.

Why not only merge the new profiles, without modifying the already defined activity curves?

[AlanRobertClark]

Fully agree with @mateusglucas: Please add Apidra profiles to the existing activity curves!

[TheConen]

Since this PR seems to be dead, I resolved the merge conflicts and created #3157 .
Also, for those that cannot wait, I created an APK up-to-date with the current master.
Keep in mind that this uses different signatures than the official xDrip+ app, so you will have to uninstall xDrip+ to install this one.

xdrip-pr1388-20231026.zip

[TheConen]

Since #3157 has been merged, I think this PR can be closed now.

[kaelonR]

Since #3157 has been merged, I think this PR can be closed now.

I agree. This PR is now closed.