Sunday, February 19, 2017
I felt a bit dizzy around 15:00. My urinary ketones were positive at 16:00
I will stubbornly avoid discussing my opinions on that type of diet, short term or long term, in adults or kids. A comprehensive review of its issues and merits can be found here (pdf) on the paleomom blog
Tuesday, February 7, 2017
The blog has slowed to a crawl, I apologize. The reasons behind my relative silence are
- Max has reached the tender age of 16. That means that teen issues and behaviors have become more common, impacting his control and our mood. I believe every T1D or T1D caregiver can relate to that situation which means I will leave it at that. Our latest HbA1c, a week ago, was still 5.5% but I believe this will be one of the last time we’ll see values below 6%. I will try not to despair, as there definitely are trade-offs one must accept if a kid is to have a semi-normal adolescence.
- We are going through an extensive remodeling of our environment and that takes time.
- rant alertFinally, as much as I hate to write this, I have lost interest in most open-source, community driven projects. I think I need to qualify that statement a bit before I get a lot of flak. As far as making data accessible everywhere and anywhere, I am still extremely grateful to the community as a whole, and especially the core members of the Nightscout project who made that data conveniently and cheaply available. The open source, or semi-open source community is great at developing features that actual T1D and T1D caregivers need or want. What really deeply annoys me, however, is how little attention is paid the the delivery of accurate results. Adding a new display device, check. Adding new minor features or screens, check. Accuracy, not so much. Assuming one want to deliver accurate results from raw data, there is a bit more to it than jumping from a single point calibration to another, or calculating an arbitrarily constrained slope. Occasionally, two open or semi-open source solutions are compared: they show a 50 mg/dL difference, eventually absurdly amplified by the lever effect of a bad slope, devices are rebooted, restarted and the community moves on. That is not to say that I would or that I privately do better, at least in a way that is applicable to a general population but that is precisely because I am aware of the potential issues that I decided not to inflict my experiments on innocent bystanders. On top of that, in the Libre world, the “semi-open source” approach, consisting of an incomplete github source dump that often misses all the computation parts, irritates me. Don’t think for a minute that those effectively closed source solutions are hiding some miraculous sauce: they aren’t. The reason for the omission is often that they simply want to hide how they turn a very nice sensor like the Libre into something that behaves and performs like a second generation Medtronic sensor…end rant alert
Some personal comments
as you can see, the sensor is – on average, note this is MRD not MARD – essentially perfect in stable or near stable conditions. The most significant relative differences occur in dynamic conditions and in the same direction.
In other words, when you are falling quickly, the Libre trails the fall and reads higher (probably missing some hypos), almost as a non delay compensated CGM would do. When you are rising quickly, the Libre leads and overshoots the rise (overestimating some hypers). This is a behavior we noticed immediately (see here, here and here for some of our 2014 reports) and have consistently observed since.
I am of course quite happy and a bit proud to have identified the issue in 2014 , while remaining aware our test population was n=2.
Monday, January 9, 2017
Here’s the situation on a relatively standard scale: can you spot anything? Don't cheat and look below.
21:00 Max starts climbing slowly. Because he had a small hypo earlier, the light evening meal, mostly protein (salmon) he took starts showing up.
21:30 recalibration, the Dexcom was a tad too high, the Libre (on the other arm) was spot on at 108 mg/dL. The decision is made to take no action because we know that the 20:30 will start pushing BG back down a bit roughly 3-4 hours after injection (20:15 in this case).
Sure enough, we seem to be on a small downtrend starting around 23:15, for a 155 mg/dL high. Yes, that is not ideal, but at some point we have to consider the trade-off between undisturbed sleep and perfect BG. Today, undisturbed sleep was the intent.
At first sight, this slope still looks like a mild downtrend, with a bit of noise.
However, this is what I get in another view: my compression detection algorithm has triggered!
Interesting… Time to look at the decision parameters
Parenthesis: my compression algorithm isn’t wildly different from what has been published in the literature. I developed it independently in 2015, as a toy project. In a nutshell, the algorithms examines the last few hours available (at least an hour although I can fine tune the parameters conveniently), assesses noise, overall trend and builds “confidence” on those values. It’s a bit of a cookbook of hacks and rules. For example, the SD a detrended trend gives a good indicator of the current “meta” noise level in the signal: a drop caused by a compression should, obviously, by more important than the SD of that detrended signal by some factor (one that I tuned based on experience and visual assessment). It also goes without saying that the delta must be negative. On top of that, a few rules have been added here and there for experimentally observed special cases.
At that 00:53, the new value enters the “hour buffer” which happens to have an extremely high level of confidence. Note that the algorithm did not have that level of confidence at 23:23, post peak, where the hourly trend was less clear and a bit of noise (maybe a transient compression) pushed the detrended SD a bit higher.
That being said, the case isn’t settled at this point and I decide to zoom on the chart and go up and check. Max is indeed leaning on his Dexcom, and not leaning on his Libre. The Dexcom, which had been tracking the Libre after recalibration is actually 10 points below.
The acid test is of course to move Max a bit from leaning on its Dexcom to not leaning on either devices. Here is a zoom on what happened: the very mild compression recovered almost immediately.
- Instead of being slightly down, the trend is actually either stable of very slightly trending up. Knowing this allows me to push a 1 U correction (being extremely conservative here in order to avoid any hypo risk.
- the scale at which we are looking at our CGM signal impacts our perception and our assessment of a situation. (which is one of the reason I developed my own “in-the-cloud” visualization, which I can tweak and zoom to my liking)
Good question: let’s answer this methodically
- the custom “artificially intelligent” algorithm says so
- the Libre says there was no drop.
- I have confirmed visually that Max was sleeping on its Dexcom side.
- I have confirmed that, by relieving the compression, the sensor recovers as expected and resumes cruising.
- yes, I have no idea that the “real” level is actually 137, 127 or 147 mg/dL but it does not matter: the relative change does matter.
- yes, there are situations where the Dexcom is too noisy, the trend is unclear and the decision is ambiguous, if possible at all.
Anyway, this blog post is almost live because this must be the first time an algorithm tells me something I may have not noticed. 3 years ago I had a quick look at Neural Networks and AI but, while I got them to tell me interesting things and issue decent predictions, they never told me anything I wouldn’t have noticed or predicted by myself. That one is a first!
Ah, and one more thing – let me reassure all the hydrophiles out there, no glass of water was harmed in this experiment.
Wednesday, January 4, 2017
I am always surprised at the number of patients or caregivers who are either unfamiliar with or afraid of the “pre-bolus” technique. “Pre-bolusing” means injecting insulin 25, 20, 15, 10 minutes before a meal rich in carbohydrates. While I am sure this post will be very basic for most of the readers of this blog, I feel it could be useful for occasional readers.
What is the reason behind pre-bolusing?
It is very simple. Ideally, you want your insulin injection to match as closely as it is possible the insulin secretion of a non T1D person. Unfortunately, this is not possible with insulin that is injected subcutaneously. When you are not diabetic, a meal will trigger an immediate insulin secretion in the bloodstream (in some studies, the mere thought of a meal was enough to trigger an insulin secretion). As a T1D, the insulin you inject (or push through your pump) lands in the peripheral subcutaneous tissue and needs to be picked up. That takes a while. This is not speculation, not something “one needs to consider” – it is a fact and it has been extensively studied.
In the graph below, you can see the three essential differences between a physiological response and an injection. (source: recovered data from https://www.ncbi.nlm.nih.gov/pubmed/26041603) Note: these activity curves are always a bit approximate in terms of absolute activity as, even in healthy volunteers, clamp studies area bit imprecise. Model curves don’t take some practical parameters into accounts. What matters is the notion of delay (due to absorption and transport) of the injected insulin peak and, later, the residual tail which is often ignored.
After an injection, even if you have matched your insulin dose and meal perfectly
- you start by having a relative lack of insulin
- after an hour or so and for the next two hours, you have a relative excess of insulin
- your short acting insulin typically has a longer “tail” than a physiological response
And here is a video showing what happens when the timing of the insulin injection is adjusted
Here are a few real life examples, all of them are high carbs breakfasts.
Injection at the start of the meal: the relative lack of insulin at the start of the digestion process leads to an excessive peak at 200 mg/dL. The relative excess of insulin after the meal has been digested slowly but surely leads to an hypo that will require a correction.
Late bolus: in this situation, the injection came during the meal (as in “f***, I forgot my insulin”). The relative lack of insulin leads to a higher peak, that is to be expected. But the late relative excess is also more pronounced. It leads even more quickly to a potentially severe hypo that requires a couple of corrections.
Pre bolus: here, the insulin was taken some 10 minutes before the meal. The difference is drastic. The initial peak is greatly reduced and the relative excess of insulin has a minor impact. Yes, the timing possibly could have been a bit better, maybe 15 minutes. And, yes, there is still what could be considered a mild hypo. But in this case, a couple of dextrose tablets was all we needed to get back on track.
20 mins prebolus: In this case, Max woke up a bit late (holidays…) with a dawn phenomenon already significant. This gave us the opportunity for a longer wait. It ended up so well that the insulin action tail (and another small prebolus) took care of the light 2PM lunch.
Important note: we typically don’t prebolus if we are trending down or already below 80 mg/dL. We obviously don’t want any additional insulin activity pre-meal in those cases. Common sense, as usual, applies.
Monday, December 12, 2016
Dr Kathrin Maedler, a prolific and widely cited author in the field of diabetes research, JDRF and multiple award recipient has just been stripped of her professorship because of scientific misconduct. She had been under the fire of retraction watch for a while (and retracted or corrected around 15 papers dated back from more than one decade).
Have a look at this very good blog if you want the juicy details
Kathrin Maedler loses Heisenberg Professorship
Kathrin Maedler: persecuted genius or zombie scientist?
PS: Will be back later with some Libre posts: at this point a difficult T1D teen and his term exams interfere...
Wednesday, November 30, 2016
I’ve received a couple of questions about the Libre thermistor temperature curves in my previous blog post. One of the reason I did not post actual data is that I wasn’t 100% sure of their absolute validity (in relative terms, they were enough for my purpose). The data I used last year was derived through a polynomial fit, not the ideal option, when there is a better approximation formula that is commonly used for NTC thermistors.
That is why, today, I decided to double check the data and provide it.
- thermistor have tolerances, 5%, 10%, generating errors.
- my multimeter probably suffers for a certain error.
- my contraption may introduce additional resistance.
- my heating bed’s thermistor also has its own error.
- the thermistor is extremely reactive: breathing on it changes its resistance, testing it in an open environment or under some insulation changes the values.
- I have seen thermistors not behaving as expected.
Here is the test environment. The glass bowl serves as a temperature stabilizer. I am patching on an old Libre sensor.
I ran a few measures at 55°C, 35°C, 0°C (separately), averaged them and solved the 3 equation system
1/T1 = a +b(log(R1))+c(log(R1))^3
1/T2 = a +b(log(R2))+c(log(R2))^3
1/T3 = a +b(log(R3))+c(log(R3))^3
to derive the Steinhart-Hart coefficients (working in kOhms rather than Ohms.
The Wolfram Alpha query for that system is
1/328=x+y*(ln(31.5))+z*(ln(31.5))^3, 1/308 = x +y*(ln(83))+z*(ln(83))^3, 1/273= x +y*(ln(330))+z*(ln(330))^3
It matches closely the solution I got in numpy. Here’s the plotted “theoretical“ curve versus the separately observed data. Please note that this can’t be directly converted in the Libre bits and bytes and is not necessarily exactly what the Libre sees.
The thermistor seems to be a 120k NTC thermistor and not a 100k thermistor. That was either a quick wrong assumption back in 2015, or a thermistor variation (I don’t remember and don’t have that thermistor for a retest anyway).
Edit 30/11 – after additional measures with a third thermistor, taking the gradient over my bed in consideration and testing older thermistors, the old assumption of a 100k thermistor could very well be the correct one, in that case, the curve below simply shifts to the left. It is correct in relative, but not absolute terms
And here is is the python code containing the experimental data. Again, if you are interested, by all means, take your own measures (and eventually let me know). I have observed slightly different values, possibly a 100k NTC and, at least in one case, drastically different values. It is hard for me to know if the thermistor was damaged of if Abbott uses two different types. And yes, I am aware that the decimals in the data dump are probably pointless, but I just noted the values as the rig stabilized.
import matplotlib.pyplot as plt import numpy as np import math as m # 0C K = 273 # takes the coefficients, measured resistance, returns temp in celsius (note kOhms) def SteinhartHart(a, b, c, r): invT = a + b * m.log(r) + c * (m.pow(m.log(r), 3)) TK = 1 / invT T = TK - K return T # thermistor measures Observed = [(40, 69), (40, 66), (39, 72), (39, 69), (38, 74), (38, 72), (37, 76), (37, 76.5), (36, 79), (36, 78.34), (35, 83), (34, 86), (33, 89), (32, 93), (32, 93), (31, 96.8), (31.3, 95), (30.5, 98), (30.5, 99), (29.9, 101), (27.6, 111), (27, 114), (25.8, 116.6), (25.2, 122.2), (25.9, 117.4), (30, 100), (29, 104), (28, 108), (27, 112), (26.7, 114), (26.2, 116.8), (25.7, 118.4), (24.8, 123.3), (55, 32.9), (62.2, 20), (0.1, 340), ] fig = plt.figure() ax = fig.add_subplot(111) ax.set_title('Ext. Therm (Steinhart-Hart)') ax.set_xlabel('kOhm') ax.set_ylabel('Temp. Celsius') # plot observed data v, t = zip(*Observed) line2 = ax.scatter(t, v, c='r', marker='.', label="Measures") # steinhart - hart, linalg code omitted, double checked with wolfram alpha kOhms a = 0.00270712 b = 0.0000629848 c = 0.00000302854 # generates Steinhart-Hart Curve x = np.linspace(1, 350, 350) s =  for i in x: s.append((SteinhartHart(a, b, c, i))) line = ax.plot(x, s, c='g', label="Steinhart-Hart") plt.legend() plt.show()