New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of FIAsp insulin curve #388

Closed
CrushingT1D opened this Issue Mar 1, 2017 · 81 comments

Comments

Projects
None yet
@CrushingT1D

CrushingT1D commented Mar 1, 2017

Add setting to select type of insulin
A) Novo/Humalog
B) FIAsp

If A selected use current curve calculation
If B selected use maths to match curve as described on page 12 of
http://www.ema.europa.eu/docs/en_GB/document_library/EPAR_-_Product_Information/human/004046/WC500220890.pdf

@peterlynton

This comment has been minimized.

peterlynton commented Mar 27, 2017

I'm happy to attempt to add this (new to all of it actually) but cannot find the curve calculation in Xcode .

@bashem

This comment has been minimized.

bashem commented Mar 27, 2017

There is a suggestion on Gitter to just shorten the DIA instead of touching the code.

@bashem

This comment has been minimized.

bashem commented Mar 27, 2017

Class that computes is evidently called InsulinMath

@peterlynton

This comment has been minimized.

peterlynton commented Mar 27, 2017

@bashem It's early days so happy to shorten the DIA for the moment, but it may be better to generate new code for the curve as FIAsp has a very quick initial absorption rate and is currently a bit of an unknown on high doses.

You're correct regarding InsulinMath, which is based upon Glucodyn code written by Ken Stack https://github.com/kenstack/GlucoDyn. I've messaged him on Gitter to see if he can help but otherwise we need someone who can convert 4th-order polynomials to algebra.

If we're able to generate new algebra more suited to FIAsp I foresee it initially being used / tested by end users editing the code, with the potential of adding it as a secondary option to Master as FIAsp becomes more available worldwide as @CrushingT1D suggested.

@jeremybarnum

This comment has been minimized.

jeremybarnum commented Apr 3, 2017

I've spent a couple of days playing with this. While I agree with the comments that shortening the DIA is a good initial approach, the seemingly much higher insulin availability of Fiasp in the first 30 minutes does mean that a new algorithm would probably be a good idea. I'll try to synthesize what I've done and upload it - it's just the math part (not that fancy - just using LINEST() in excel to match the data in the graphs of the PK from the studies), not the code. It is clear that the current approach in Loop is a bit ugly - 3 different fourth order polynomials for DIA = 3,4,5 and then the InsulinMath does a linear interpolation of the IOB depending on the DIA input by the user. It's relatively simple to take the output IOB from those functions, manually generate a new IOB curve by taking the "treatment ratios" (AUC(t) for fiasp/AUC(t) for novolog) from the Fiasp studies, and do a new fit, which I've done. But if we're going to do this I wonder if while we're at it we should look at [https://github.com/LoopKit/LoopKit/issues/90] at the same time. @scottleibrand explains here [https://groups.google.com/forum/#!msg/openaps-dev/w_YNAmaguoc/0R00sksCU4wJ] how the oref0 approach works - I want to try that for Fiasp, using the earlier peak and generating an IOB curve using with that approach and see what treatment ratios that produces. Useful references: [http://onlinelibrary.wiley.com/doi/10.1111/dom.12803/full] [https://www.hindawi.com/journals/cmmm/2015/281589/#B18]

@scottleibrand

This comment has been minimized.

scottleibrand commented Apr 3, 2017

Heh, that is an old thread. But as surprised as I would have been at the time to learn it, we're still using that approach in OpenAPS, and rather successfully. The curves we use have peak activity at 75m for a 3h DIA, and all other DIAs are simply stretched from that. So 4h peaks at 100m, and 2h peaks at 50m. Because of that peak time, @tim2000s has been using the OpenAPS 2h-DIA curve with Fiasp, and rather successfully thus far as I understand it.

@bashem

This comment has been minimized.

bashem commented Apr 19, 2017

Looking at the code in LoopKit/InsulinMath, there is no DIA for 2hrs, so the 3h model would be used

switch nearestModeledDuration {
            case TimeInterval(hours: 3):
                return -3.2030e-9 * pow(minutes, 4) + 1.354e-6 * pow(minutes, 3) - 1.759e-4 * pow(minutes, 2) + 9.255e-4 * minutes + 0.99951
            case TimeInterval(hours: 4):
                return -3.310e-10 * pow(minutes, 4) + 2.530e-7 * pow(minutes, 3) - 5.510e-5 * pow(minutes, 2) - 9.086e-4 * minutes + 0.99950
            case TimeInterval(hours: 5):
                return -2.950e-10 * pow(minutes, 4) + 2.320e-7 * pow(minutes, 3) - 5.550e-5 * pow(minutes, 2) + 4.490e-4 * minutes + 0.99300
            case TimeInterval(hours: 6):
                return -1.493e-10 * pow(minutes, 4) + 1.413e-7 * pow(minutes, 3) - 4.095e-5 * pow(minutes, 2) + 6.365e-4 * minutes + 0.99700
            default:
                assertionFailure()
                return 0
            }
@jeremybarnum

This comment has been minimized.

jeremybarnum commented Apr 21, 2017

Well here goes nothing. I tried to create new curves for both Loop and OpenAPS. The work is in enclosed spreadsheet. I tried to document everything clearly. Eager for any feedback anyone has. My conclusion is that assuming we believe that Fiasp starts hitting a lot faster, as Novo Nordisk claims and as people have reported, shortening the DIA as a way to approximate the curve shape is better than nothing (and as mentioned seems to be working fine for some). But that approach would appear to involve compromises between matching activity in the first 45 minutes versus matching the tail. And since the whole point of Fiasp is to avoid post-prandial excursions, it seems worthwhile to consider adjusted curve shapes.
Example for loop DIA = 4, all the other DIAs are in the spreadsheet.

a^4 2.58154E-10
b^3 -5.56237E-08
c^2 -8.06366E-07
d -0.004278433
intercept 0.987630373

I am doing some more work on the OpenAPS curve to see if we can get a "purer" curve that is produced from user inputs that are intuitive and testable empirically, and does a good job of matching - in line with what @scottleibrand said about the original thinking behind the OpenAPS curves. I'll post that shortly.

FiaspCurve_part1.xlsx

@tim2000s

This comment has been minimized.

tim2000s commented Apr 21, 2017

I'd be careful on this one at the moment. I started off with DIA of two hours being very effective, and effectively almost no tail, but I've since seen some changes to my body's absorption characteristics with fiasp and until I'm sure what's going on, I'd be loathe to say that the Novo curves are 100% effective every time. By all means do the work but be wary of this factor, as I'm not sure I'm seeing the same level of front loading on the absorption.

@jeremybarnum

This comment has been minimized.

jeremybarnum commented Apr 21, 2017

Thanks Tim - yeah for sure this is obviously to be treated with great caution. Mostly I wanted to establish the framework - but it needs to be validated with experience clearly. And as you point out, it's all based on the published "Treatment Ratios" showing ratio of AUC between fiasp and novolog at different points in time. If those are wrong, then my curves will be wrong. And if the starting curves are wrong before getting transformed, then the new curves will also be wrong.
I want to experiment with some parameterization to allow the user to create custom shapes based on DIA test that a person can do for themselves - essentially adding some other "dials" to drive curve shape beyond just the DIA.

@peterlynton

This comment has been minimized.

peterlynton commented May 9, 2017

@jeremybarnum Thanks so much for the FiaspCurve excel file - I am aiming to trial it. Am I correct in editing the 4hr line to the following:

return 2.58153954561464E-10 * pow(minutes, 4) -5.56237306749063E-08 * pow(minutes, 3) -8.06365857215448E-07 * pow(minutes, 2) 0.00427843253655648 * minutes + 0.98763037314288

@jeremybarnum

This comment has been minimized.

jeremybarnum commented May 9, 2017

@upsetter looks like you are missing a negative sign in the last term, so the linear term before the intercept? should be -.004278...etc.
Also a few additional things:
-please be careful as I haven't been able to test it. It's just math, trivial change, should be fine, but...
-I assume you were just asking about DIA=4 as an example. If you're going to go through the trouble, you might as well change all 3 DIAs, so that if you change your DIA to something other than 4, it produces reasonable answer.
-if you're willing to do the experiment and are changing the code anyway, I would argue for doing a personalized curve shape test. Recall that everything I did presumes that the existing Novolog curve shapes are right, and that the academic data is right. It's so easy to generate a new polynomial based on your actual experience with the insulin, and update the code accordingly, it's probably worth it...of course the experiment is a pain, and arguably you would want to do it under a few different conditions, and average the result, and you should definitely read @tim2000s blog if you haven't already, but anyway. I was working on a template to facilitate the generation of the polynomial coefficients based on an experiment, I'll try to finish that and upload it. I'm hoping we can do the experiment in my house too, I'm just waiting for the right conditions.

@peterlynton

This comment has been minimized.

peterlynton commented May 10, 2017

Thanks Jeremy, I see the missing negative sign in the last term. I will change the three DIAs at once as suggested.
This is a trial and I will be careful. I appreciate that the curves have not been tested in the wild but I'm a willing guinea pig! I will look into a personalised curve shape test, I'm not sure what's involved yet.

@jeremybarnum

This comment has been minimized.

jeremybarnum commented May 16, 2017

CustomDIA_v0.1.xlsx

Here is the custom DIA template I mentioned for the personalized curve shape test. Should be pretty self explanatory. Any views/feedback welcomed.

@dm61

This comment has been minimized.

dm61 commented Jul 6, 2017

Based on Novo data shown in Figure 2 of this document, I fitted exp curves suggested by @tepidjuice. A general form of the curve is: (scale)*(t^n)exp(-nt/tau), where tau = time of peak insulin activity, and n is a parameter that may be used to adjust DIA. Taking the underlying system dynamics into account, n is expected to be 1 or 2. For Novolog, tau = 75 minutes, while n=1.5 gives a better fit to the data than 1 or 2. For FIASP, tau = 55 minutes, and n = 1. The results shown below include 1. a comparison of the data and the curve fits, 2. a comparison of insulin activity curves normalized to AUC=1, and 3. a comparison of the corresponding IOB curves.
novolog_fiasp_fit
novolog_fiasp_ia
novolog_fiasp_iob

@jeremybarnum

This comment has been minimized.

jeremybarnum commented Jul 6, 2017

That is really cool @dm61 -- seems like it achieves all the goals at the same time: simple, intuitive functional form with limited number of variables; good fit to published data; and (presumably) ability to easily fit individualized empirical experience as well. Consider me persuaded! If this is the way forward it would also be worth comparing to the current loop Walsh curves so that people know what to expect. Notably, the published data suggests activity all the way out to 6 hours, whereas I believe most users are using DIA between 3 and 4. So perhaps the most appropriate comparison is to compare the output of the Walsh curve for DIA = 4 to a curve that tries to fit that output with appropriate values for n and tau. I'll have a try tonight if I get a second.

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 6, 2017

Yes, I need to see a comparison to the Walsh curves, like I generated for the simple exponential version of this, preferably normalized by AUC, as you've done in the two top graphs.

Another remaining issue is truncating the tail of the decay curve. It's a bit sharp to just lop it off, but maybe that's ok. Might make small kinks in the forecast graphs.

Finally, depending on how we truncate the tail, I'm thinking we'll want to have actual insulin activity out to 5-6 hours, which is probably a reasonable choice for those who had 4 hour DIA set before. The tail is smaller in effect intensity, and should go out a bit longer.

@trixing

This comment has been minimized.

trixing commented Jul 6, 2017

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 6, 2017

The charts actually show activity by 10 minutes, and I do observed effects at that point for us as well.

@trixing

This comment has been minimized.

trixing commented Jul 6, 2017

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 6, 2017

Yes, the novorapid graph in the cited paper shows activity by 10 minutes. That's what we use, and I do see activity at that point usually. It may need to be moved over 5 minutes from where it is now. But you can see that even though the activity seems to shoot up fast in the activity curve, it also looks like were still at > 99% IOB at 10 minutes in the COB decay curve.

@dm61

This comment has been minimized.

dm61 commented Jul 6, 2017

Here is a comparison of the exp curves to the Walsh DIA=4h curves.
novolog_fiasp_walsh4_ia
novolog_fiasp_walsh4_iob

@scottleibrand

This comment has been minimized.

scottleibrand commented Jul 6, 2017

One idea for dealing with the tail is to shift the entire activity curve downward by the amount of the remaining activity at DIA, and then normalize the resulting curve to AUC=1. That would also end up shifting the early activity slightly right (by subtracting a constant, you end up truncating to activity=0 the first few minutes when activity is lower than at DIA), which might make the early part of the curve more accurate.

@dm61

This comment has been minimized.

dm61 commented Jul 6, 2017

Here is a zoom-in plot of the above IOB curves, to see how much error in AUC results from just chopping off the curves at a certain point in time.
novolog_fiasp_iob_tail_zoom

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 6, 2017

So if we lop at 6 hours, we'll be chopping off a little more than 1%. Thanks.

@tepidjuice

This comment has been minimized.

tepidjuice commented Jul 7, 2017

Looks promising. I'm travelling at the moment and don't have access to my computer but I have some questions/comments about this. I'd like to try my own fit when I get time. Would someone be able to post the FIAsp and novorapid data?

@dm61

This comment has been minimized.

dm61 commented Jul 7, 2017

For reference, attached are excel files with insulin activity data for Novolog and fiasp (digitized by @elnjensen).
fiasp_novolog.zip

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 8, 2017

Ok, @dm61, can you give me the integral (IOB decay) of your curve? :) That is ultimately what Loop uses.

@dm61

This comment has been minimized.

dm61 commented Jul 8, 2017

Thought you'd ask for these at some point :)

Novolog: 1-erf(0.1*sqrt(2*t))+0.00212769*sqrt(t)*(t+75)*(exp(-t/50))

FIASP: (t/55+1)*exp(-t/55)

These functions return fraction of IOB remaining after t minutes, just as the Walsh polynomials currently do in InsulinMath. Fortunately, looks like swift Foundation includes erf function.

@dm61

This comment has been minimized.

dm61 commented Jul 26, 2017

@jeremybarnum you are reading my thoughts! Assuming we adopt DIA < td approach, I think it would be better to let Loop look DIA ahead in dosing calculations, while internally having a longer td that better accounts for the tail end of insulin activity. Looking at the great new visualization offered by the dynamic carb Loop, I have no doubts that the insulin tail does extend beyond Walsh model DIA (well, at least in my case).

@jeremybarnum

This comment has been minimized.

jeremybarnum commented Jul 26, 2017

@dm61 if I could read your thoughts I would be MUCH better at math than I actually am 😄. But your comment about the dynamic carb screen reminds me of a related thought I've been having about dynamic carbs. The new screen creates a positive feedback loop for users that allows absorption time estimates, at least for known, recurring meal types, to get increasingly accurate. In that context the 50% buffer on absorption times in the prediction, especially for long absorption times outside the DIA, might start to seem a bit too conservative. @ps2 already supplied an easy way to override that in the code, but it could also be interesting to have that configurable at meal time - essentially a "high confidence" option that would remove the 50% buffer for a given meal. Of course the user can just put in an artificially shorter absorption time in those cases, so I guess this is a pretty low priority suggestion, but...

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 26, 2017

I don't like the idea of having two different insulin duration terms, but I think the points raised above are valid. I think they may bring to a head the fact that dosing purely off the forecast at DIA does have some limitations. Namely, that it's possible that dosing an amount of insulin to bring the forecast at dia into range may produce a forecasted low at some point before DIA. This updated curve will make those situations more common, both because the activity early on will be stronger, and when carbs are active, it will try to cover more carbs, making Loop more aggressive. Conversely, by expecting more insulin action out further in the future, Loop will at times be more conservative. I think those separate changes in behavior might each call for different adjustments to loop. For the first case, It might be that we require an iterative dosing algorithm that re-evaluates the forecast as if the dosing recommendation was implemented, and reduces the recommendation if a low is predicted. For the second case, I'm not sure how to deal with it, but am actively thinking about it.

@sulkaharo

This comment has been minimized.

sulkaharo commented Jul 26, 2017

Btw I just noticed I've accidentally been running the first model on our dude with 4 hour DIA and it's been working extremely well. Makes me wonder if kids absorb the insulin faster; the published Fiasp study was afaik strictly adults only.

@eszcloud

This comment has been minimized.

eszcloud commented Jul 26, 2017

As @ps2 just said, I don't like multiple insulin duration terms. Along those lines, I also think that it's important not to obscure the actual term that we're dealing with (e.g. having people input DIA but turning that into td behind the scenes) because that becomes very confusing.

One idea for dealing with the valley-and-peak situation @ps2 describes above is to incorporate Loop's future actions into the algorithm determining insulin dosing for the present moment and also to incorporate additional terms that are optimized, such as figuring out the dose to maximize how much BG is in range and to minimize dBG/dt. In this scenario, it's important to emphasize the effects of nearer term values as that's when the prediction is the most accurate.

Since the accuracy of such predictions is paramount, before implementing either of those, however, I think that we would want to have a dynamic insulin sensitivity factor to make predictions more accurate.

@sulkaharo

This comment has been minimized.

sulkaharo commented Jul 26, 2017

Did some curve fitting and the curve we're on right now is the same as the latest @dm61 curve with td = 600 and peak = 44, except we're cutting the calculation at 240 minutes, where the activity is ~6% of the peak

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 26, 2017

@sulkaharo I have a ML based model that fits CA and Insulin terms over lagged variables for 5 minute intervals over 6 hours (144 terms: 72 each for insulin and carbs), and can run it on weeks of data, so I can get an objective sense of what actual observed insulin activity and (averaged) carb activity is. I've run it on 4 kids and 1 adult so far, all on Novolog. I see faster time to insulin activity peak for kids (50min) than the adult (75min), and I'm guessing that effect would also apply to Fiasp.

@jeremybarnum

This comment has been minimized.

jeremybarnum commented Jul 26, 2017

I agree two DIAs is not what we want. But in reality that's not what we're talking about. We're saying there is one DIA - the real one - that's probably longer than then one many people are using. And then another parameter, which is the prediction horizon. Today, that equals the DIA, for very good reasons. But the combination of faster acting insulin and more accurate IOB curves with longer tails puts pressure on that convenient simplification.

@ps2 I do sort of think that we already have tentative near-solutions for each of your cases? Isn't the predicted early low case already, to significant degree, captured by BG guard? The only enhancement needed is for the bolus and temp basals to adjust down slightly - which I guess is your iterative point. But initially at least for boluses the user can do it manually. And I think your second scenario is essentially also naturally captured - if shortening the prediction horizon inside the DIA will create a low in the tail, BG guard will catch it, so it's just a matter of feeding that back into the recommended dosing. The nuance is risk appetite for lows in the tail - that could be a configurable sort of thing that constrains the low temping needed as a % of the basal rate, as in my example. Devil in the details I know and I imagine coding the iterative stuff can be tricky but conceptually I think all the building blocks are in place already.

@dm61 dm61 referenced this issue Jul 27, 2017

Closed

Dosing algorithm #533

@sulkaharo

This comment has been minimized.

sulkaharo commented Jul 29, 2017

FWIW openaps/oref0#568 now implements @dm61 's generic curve model for OpenAPS. We're looping with the curve with td = 300, tp = 45, Fiasp, 6 yr old kid and the first 12 hours on the model have worked very well.

@dm61

This comment has been minimized.

dm61 commented Jul 29, 2017

@sulkaharo Thanks for the update. I suggest you look at the difference between deltaBG and modeled insulin impact on BG (which I think is reported by OpenAPS as BGI). The difference represents counteraction effects. among which carb impact is expected to be the strongest factor after a meal (but watch out for exercise effects). So, after a meal, in the absence of exercise, any systematic negative values of the counteraction=deltaBG-BGI may imply that the underlying insulin activity model is off. The new Loop gives us a real-time view of the counteraction effects. With Walsh curves currently used in Loop, I have observed strange dips about 1-2 hours after a meal (which led me to think that Walsh curve peak comes too late), as well as fairly consistently negative counteraction 4-5 hours after the meal, implying too short tail of the Walsh curve. The hope is that the new curves model insulin absorption better, which we should be able to assess by looking at counteraction data.

@tim2000s

This comment has been minimized.

tim2000s commented Jul 30, 2017

One of the things I'm struggling with with these curves compared to the published data is the Insulin clearance. The published data states 57 mins mean half life, while the IOB curves that are generated from these activity curves works out at about 90 mins, so our understanding of activity vs clearance is not quite right. It may require us to make some minor variations to our IOB calculations.

@dm61

This comment has been minimized.

dm61 commented Jul 31, 2017

@tim2000s parameters in the exponential curves can be selected to match published activity curves very well. The published half-time value must be coming from different experiments done under different measurement conditions. We could try to tweak the parameters (peak time tp and duration td) to get a better balance with respect to various published data. Or, we could try to find entirely different curves. However, I'd strongly caution against ad-hoc tweaking just IOB(t) or just Ia(t) separately. These two are related (one is just an integral of the other), and IMO we should keep them strictly consistent in any algorithm implementation.

@tepidjuice

This comment has been minimized.

tepidjuice commented Jul 31, 2017

Sorry to have missed most of this discussion. I've been on holiday. It looks good. The pedant in me is pleased to see the non-integer n have gone :).

Given that what we're doing is finding different approximate solutions to:

x' = -ax + by (1)
y' = -cy + dz (2)
z' = -fz + gu (3)

where:

  • x is the insulin effectiveness,
  • y (and* z) the insulin concentration
  • u the insulin input, and
  • typically**, f, g***, c and d are time constants, like the \tau in t*exp(-t/\tau), and a and b correspond to the insulin clearance rates and sensitivity .

*whether you use equation (2) or just use equations (1) and (3), replacing y in equation (1) with z, is pretty arbitrary. A third order system i.e. using all three equations will give a t^2 exp(-t / \tau) like response whilst a second order system will give a t*exp(-t / \tau) like response. I'll use a third order system from here on.

** as this is a linear system the exact position and definition of the parameters a, b, c, d, f and g is flexible.

*** g can also be used to change units and model site specific absorption dynamics.

Would it not be better to implement this for the insulin model? The advantages of this would be:

  • IOB = z
  • insulin action = x
  • we would only have to store the vector (z,y,x) to be called at each loop.
  • it's mathematically simple
  • it's flexible i.e. you can control the peak time, rise rate and fall rate of each variable.\
  • there is no need to cut the curve off after a specified period of time. This will be done by the numerical precision of the floats z, y and x.

I'd set the parameters as follows:

  • We can set a = c = d= f = 1/ \tau. As we don't care about the insulin concentration, y.
  • a = h(DIA), where h is some function of DIA e.g. 2/DIA
  • b = a*S, where S is the insulin sensitivity (in appropriate units)
  • g as a unit conversion factor

In the plot I've done this for S = 3 and S = 4 and g = 0.001 with a peak time of 75 minutes. NB I also set a = 1/75.

download

The rest is a dodgy implementation idea.

To be consistent with current implementations, I'd set u = 0 for a person's normal basal rate i.e. u = I - ub, where I is the actual insulin delivered by the pump and ub is the current basal rate. A bolus would set u to be the magnitude of the bolus.

To work out the effect of temporary basals is a little more complicated. I don't know how this is currently modeled in loop. I would do something like:

  1. A temp. of N u/minute is set for m minutes
  2. Find n = N - ub and calculate r = n*m, so r is the total amount of insulin to be delivered by the temp basal (or as it could be negative undelivered?)
  3. Assume the pump delivers basal insulin continuously
  4. Each time k_now loop runs calculate (k_now - k_previous)*n i.e. the amount of insulin that should have been delivered since the last loop, and set u to this value.
  5. As an error check keep track of w = w - |u|, where w = |r| at the start of the temp basal. If this value is negative then something has gone wrong.
  6. As another error check have E = |r| - n*M, where M is the time elapsed since the basal was started. We should have E ~= w .
  7. If a temp basal is cancelled then this corresponds to changing m and should only affect steps 5 and 6.

We of course would need to descritise the system. In my opinion the Euler descritisation is good enough i.e.:

x(k+1) = (k_now - k_previous) * (-ax(k) + by(k)) + x(k)
y(k+1) = (k_now - k_previous) * (-cy(k) + dz(k)) + y(k)
z(k+1) = (k_now - k_previous) * (-fz(k) + gu(k)) + z(k)

@ps2

This comment has been minimized.

Collaborator

ps2 commented Jul 31, 2017

For manually testing the model described above in Loop, see #539

@tepidjuice

This comment has been minimized.

tepidjuice commented Jul 31, 2017

I spent a few minutes fitting the ODE's to the novorapid data set. I've included the exponential for comparison. It wouldn't be too hard to get an even better fit if desired.

download 1

@francesc0-cgm

This comment has been minimized.

francesc0-cgm commented Jul 31, 2017

So @tepidjuice for novorapid is 75 of peak and td of 360? Also in a kid?

@tepidjuice

This comment has been minimized.

tepidjuice commented Jul 31, 2017

@francesc0-cgm I have no idea. I'm just a mathematician. Have you tried searching for paediatric clamp data to fit?

From this:
http://www.novonordisk.ca/content/dam/Canada/AFFILIATE/www-novonordisk-ca/OurProducts/PDF/novorapid-product-monograph.pdf

It seems the peak time, t_max is the same in most populations but the peak concentration C_max is higher in children. If this is true it would appear that novorapid is eliminated faster in children than adults. Giving a lower td.

I only know for myself novorapid peaks at 60-80 minutes and has a noticeable effect for 4.5-6 hours. I found this out by getting myself in steady-state, i.e. fasting and with a constant basal rate, then administering a small bolus. I did this overnight.

But if we use the differential/difference equations td would no longer be an important variable. We'd only have to consider ISF and tp.

@dm61

This comment has been minimized.

dm61 commented Aug 1, 2017

So I've been running the Loop insulin model testing branch #539, with exponential curves, td=360 and tp=75 (Novolog) for couple of days now. This morning I assumed the combined roles of a lab technician and a lab mouse, and performed a semi-controlled experiment: took couple of glucose tablets to bring bg to around 150, waited a bit to get to steady state, and then dialed a 1U correction bolus, while keeping Loop open, and with no food or exercise for the next 5 hours. Below are screenshots illustrating the results. BG started to drop noticeably at around 30min, which seems to be well predicted by the model. The most important graph to look at is Glucose Change (which shows insulin counteraction effect). Ideally, if the modeled insulin absorption curve were perfect, that graph would show zero at all times after the correction bolus. As shown below, not exactly zero, but the values are relatively small and bounce around zero (which is to be expected given bg sensor noise and quantization). A slight negative bias may imply that my ISF or basal rate are a bit off, but that's a different topic.
exp-curves-test-08-01-2017

@ps2

This comment has been minimized.

Collaborator

ps2 commented Aug 2, 2017

@dm61 That graph is beautiful! :) Our insulin counteraction effect chart seems to have cleared up a lot since running the new curves as well.

@elnjensen

This comment has been minimized.

Contributor

elnjensen commented Aug 3, 2017

@dm61 Nice experiment!

@tim2000s

This comment has been minimized.

tim2000s commented Aug 3, 2017

@tepidjuice, @francesc0-cgm insulin clearance in children under clamp conditions has been shown to be more or less the same as that in adults, and that is >5 hours in both cases.

That's why My concern comes about modelling the activity and iob and the relationship between them. There's an additional component that we need to determine given the data we have for half life and activity.

@tim2000s

This comment has been minimized.

tim2000s commented Aug 3, 2017

To add to my last comment, (sorry on phone with no edit function) - the physiological mechanism for insulin clearance is a combination of insulin activity within the tissues that have insulin receptors (so typically GLUT4 in T1 in peripheral muscle) and also kidney activity. There's a small amount of hepatic clearance but that pretty low in T1. I think our IOB based on activity looks solely at the effects based off insulin activity and ignores the renal clearance, hence why the IOB curve has a slower rate of decay than the published data.

@zqf7738

This comment has been minimized.

zqf7738 commented Mar 18, 2018

Hello, Thank you very much! But now I have a question about insulin time. I want to ask you. My insulin works faster in the morning, and it can be injected once a day, but the onset time at noon and evening is much slower. It can only be injected first, and the other can only wait an hour after it can be injected. This leads to a closed loop pump system. It predicts high blood sugar. And then press it on the basis of the foundation. The results are easy to cause hypoglycemia. How to solve such a problem. What is the best way to fill in the time of insulin action

@scottleibrand

This comment has been minimized.

scottleibrand commented Mar 18, 2018

Are you using Loop or OpenAPS or something else? Probably best to move this over to Gitter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment