# Support of FIAsp insulin curve #388

Closed
opened this Issue Mar 1, 2017 · 81 comments

Projects
None yet

### 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 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 commented Mar 27, 2017

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

### bashem commented Mar 27, 2017

 Class that computes is evidently called InsulinMath

### 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 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 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 commented Apr 19, 2017 • edited

 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 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 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 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 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

### 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 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 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.

### 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.
Collaborator

### ps2 commented Jul 6, 2017 • edited

 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 commented Jul 6, 2017

 Do you have the data to play with somewhere? The curve in the Novolog curve doesn't very well cover the first 10 - 15 minutes of non-activity. You might want to play with shifting the zero point by this time. … On Thu, Jul 6, 2017 at 8:30 PM, Pete Schwamb ***@***.***> wrote: 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. The other remaining thing is truncating the tail of the decay curve. It's a bit sharp to just lop it off, but maybe that's not an issue. Might make small kinks in the forecast graphs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#388 (comment)>, or mute the thread . -- Jan Dittmer , http://l4x.org
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 commented Jul 6, 2017

 I meant for Novorapid. Talking about this corner of the graph. … On Thu, Jul 6, 2017 at 10:10 PM, Pete Schwamb ***@***.***> wrote: The charts actually show activity by 10 minutes, and I do observed effects at that point for us as well. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#388 (comment)>, or mute the thread . -- Jan Dittmer , http://l4x.org
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 commented Jul 6, 2017

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

### 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 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.
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 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 commented Jul 7, 2017

 For reference, attached are excel files with insulin activity data for Novolog and fiasp (digitized by @elnjensen). fiasp_novolog.zip
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 commented Jul 8, 2017 • edited

 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.

Closed

### 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 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...
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 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 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 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
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 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.

Closed

### sulkaharo commented Jul 29, 2017 • edited

 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 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 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 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 commented Jul 31, 2017 • edited

 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. 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: A temp. of N u/minute is set for m minutes 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?) Assume the pump delivers basal insulin continuously 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. 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. 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 . 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)

Closed

Collaborator

### ps2 commented Jul 31, 2017

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

### 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.

### francesc0-cgm commented Jul 31, 2017

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

### tepidjuice commented Jul 31, 2017 • edited

 @francesc0-cgm I have no idea. I'm just a mathematician. Have you tried searching for paediatric clamp data to fit? 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 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.
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.
Contributor

### elnjensen commented Aug 3, 2017

 @dm61 Nice experiment!

### 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 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.

Merged

Merged

### 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 commented Mar 18, 2018

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

Merged