Monday, December 12, 2016

Fraud in the diabetes research world...

Just a very quick post. If you wonder, as I do, why many ground breaking diabetes discoveries never turn into anything concrete, here is a possible reason why...

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

Freestyle Libre external thermistor data dump

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.
Usual caveats
  • 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.
As usual, take your own measures.
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_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")

Blog issues, sorry...

Editing the last post in Open Live Writer seems to throw an exception currently. Blog may go up/down during the next few days. Sorry.

Thursday, November 24, 2016

Hard limits on Freestyle Libre third party applications (part 1–does temperature matter?)

Before I begin addressing one of the issues that intrinsically impacts all the third party Freestyle Libre applications I am aware of, let me restate a few things
  • Back in early 2015, I had a decent (for my purpose) solution that I felt would not extend well to others. That is mostly why I did not release it.
  • I supported and still support the BlueReader project. I am not against open source solutions. When the BlueReaders I ordered arrive, I will certainly enjoy experimenting with them. I will, however, not rely on them for my son, even if the Libre becomes our main monitoring solution.
  • I stopped my Libre investigations in early 2015, both because obtaining sensors from France was a drag and because what I learned in the process of investigating the Libre had helped me improve the results I got from the G4. I am just resuming them in preparation of the BlueReader.
  • piggy backing on the Libre sensor doesn’t sound like an attractive solution as far as I am concerned as it is only likely to increase micro traumas issues.
  • There is a fundamental difference between what the community calls “raw” from the Dexcom and the “raw” one gets from the Libre. In a nutshell, the Dexcom “raw” is not raw. The Libre “raw” is raw.


Temperature again

One of the things that differentiates the Dexcom “raw” from the Libre raw glucose data is that the Libre data is not compensated for temperature: that is the job of the reader or the phone application, working on the thermistor data.
Does it matter? Let’s start with a small explanation intended for software engineers who don’t have a biochemistry or medical background. Sensors rely on an enzymatic reaction. The enzyme used is often glucose oxydase (but it is not the only enzyme that would work, some BGMeters use hexokinase for example). The Senseonics sensors will use a different method based on fluorescence.
The activity of enzymes vary greatly depending on the local concentrations (Michaelis Menten kinetics), the pH and on the temperature. The local concentration issues are usually solved by the sensor membranes: they control the concentration of glucose and oxygen to match, as best as they can, the linear response zone of the Michelis Menten equation with their sensors. This video on amperometric glucose sensing is a must watch if you are interested
The pH is usually stable, except in DKA, of course, but at that point you have other things to worry about than your sensor’s accuracy (the acidosis can be so bad that standard laboratory tests may become unreliable). That is one aspect third parties don’t have to worry about much.

Temperature: does it matter in theory?

But what about the temperature? Intuitively, one may think “well, I guess it doesn’t matter much…”. Or, if you care, try to address it in a generic way. One of my first ideas, back in 2014-2015, was to get a some “glucose oxydase activity curve as a function of the temperature” and compensate for that.

Unfortunately, both the “I don’t care” and the “I will fix” ideas are wrong, as it can be seen in the image below (from this paper)
The relative activity of glucose oxydase varies immensely according to the pH but, as I said, we don’t care much as the pH variations shown here are well outside the physiological range. The temperature: we must care a lot about because the variation of activity can be is drastic within a few degrees and, finally, the way it is attached (difference between blue and red line). While it may be possible to find the exact temperature dependent response curve of Abbott’s wired enzyme, I suspect it is not publicly available and it would have to be experimentally derived. That realization killed my somewhat naïve hope to auto-magically correct the reported activity as a function of temperature. As far as some open source projects are concerned, not worrying about temperature compensation is a classical example of not knowing enough to even know there could be a problem. It is only when you know a bit more that you realize, to a better extent, that you don’t know.

Does it matter in practice?

Armed with a bit of side knowledge in the dirty details (more about this later) and a basic understanding of what Abbott is doing, I ran more specific experiments to investigate the response to temperature changes, the correction and the delay applied to the correction. Here is such an example.
I spent some time in a warm bath, enough to significantly increase my subcutaneous temperature and the enzyme activity.  My real BG  before the bath (as measured twice with the Abbott BG Meter) was 106 mg/dL, my BG after the bath was 109 mg/dL (shown as the star below). In normal, uncorrected, conditions, my calculated ISIG with the parameters I derived for my son would have been around 130 (not ideal, but there are temperature differences between my son’s skin and mine, we’ll get to that later). In relative terms, the response to my stable ISIG almost doubled. One word of caution, listing all the situations, bath temperature, submersion or non submersion of the sensor, etc… would be way too long for this blog and way to tedious for me to detail: let’s just say you don’t want a video of my person wiggling in a bath.
t2, shown here, is the temperature reported by the board thermistor. The Libre “official” check (round dot) sat between the direct conversion value and the SMBG value. Clearly, there is some compensation going on.
Let’s talk a minute about the thermistors, which I have arbitrarily named t1 and t2, the “close to skin” and “TI board thermistor” respectively and summarize what I know about them.

t1 – I have measured several thermistors and derived values from my observations, from which I have build a response curve. Limitations are: 1. I am not sure Abbott always uses the same thermistor as I have measured different values. This could be a variation in the thermistors delivered to Abbott, a simple factory/software configuration option, a defect. 2. I don’t have a direct way to measure the exact temperature the thermistor is reporting when applied as I can’t sneak another thermistor under the patch. 3. I can obtain reasonable values by tweaking and twisting the data, but I am not sure Abbott tweaks it the way I do.

t2 – I am quite sure of that one. With a bit of bit tweaking, it does match neatly with board/package temperatures that I can more easily measure. Limitations here are: 1. I do not know if Abbott interprets it the way I do. They could be seeing 32.5C when I see 33C or the opposite. This matters for additional adjustments for further processing, especially any eventual derivative based prediction methods. 2. temperature variations may be smoothed (per my observations and the Abbott patent).
Their respective responses are roughly (disregard the y-axis units, there is some post processing involved, the internal thermistor response isn’t linear, even if the line may make it appear so)
In the graph below, you can see what happens when I cool the sensor with ice for a few minutes after the bath. The board temperature falls precipitously, while the speed of the actual reaction continues to decrease (I did not cool my skin/core in this case, but the warming of the bath is beginning to wear out). My BG (the star) is still stable, the official Libre value is now 147 but the Libre is clearly (flags, not shown here) losing his marbles and will go error 373 for a while after that torture.

In order to make the difference in behavior visible, here are a couple of snapshots in stable conditions
I did run a few tests in stable conditions in order to address any doubts I had on my thermistor interpretation. Here is another external sensor warming
and another, less aggressive, external sensor cooling
As I said above, there is a delta between my direct interpretation and the direct interpretation of the parameters I derived used quite successfully for my son two years ago – here is an example from back then that matched exactly, in stable temperature conditions.
and another example
and a new view of the meal and bath incident (changing temperature conditions on that same sensor I correlated perfectly with)
and the original report (early to 2015) of that meal and bath incident and my interpretation of it.

At this stage, key points to remember
  • temperature variations can’t be ignored and may have a major impact on the signal.
  • my son’s parameters are different from mine and can be explained in great part by different skin temperatures (but I haven’t validated that by actually measuring it under the sensor).
  • temperature compensation effects may/often are delayed until some threshold has passed and the Libre considers it as real.
This is all for now. At this stage, before we get into the hows and whys, I simply hope to have convinced you of the effect of temperature on the Libre raw signal: minor changes such as wearing a jacket or a t-shirt are less visible but are present. I could have posted several more illustrations and will possibly do so if some points need clarification.
In the next posts (when time allows), we’ll talk a bit more on how Abbott tackles the problem of finding the temperature of the sensing site and how it differs from Dexcom’s temperature compensation. The exploitation of the double thermistor design is really fun and interesting (well, at least to me) even if I feel that it does not work too well in some cases. It seems there is a simpler (but much more expensive for Abbott?) way to address that issue. We’ll get there… (some time…)
That’s all for today.

Friday, November 18, 2016

FreeStyle Libre Patterns - non T1D (part1)

Just a quick dump of some FreeStyle Libre Sensor running on a non T1D, non T2D person. I will post interesting situations as soon as they arise. Please note that, even in normal individuals, the glycemic response to different aliments may vary. See this ground-breaking article in Cell for an in depth look at the issue:

Personalized Nutrition by Prediction of Glycemic Responses

That being said, testing foods and meals on a non T1D person offers useful insights for my son's management as the 'net' effect they have is more or less isolated from perturbations. Something that is harder to control for a non T1D person is likely to have amplified effects in T1Ds

Libre startup sequence and some fun

Post insertion, we start tickling the temperature compensation a bit (that part was done in the context of another, more tech oriented, experiment). The sensor is cooled with ice around midnight and warmed against a radiator around 2 AM. It is then left alone so it can proceed with its usual slightly noisy lowish start.

Stable sensor, some food and a bath

Sensor has stabilized: 2 eggs at 13:30, no effect, as expected. Warm bath - not hot - at 14:30. Now this gets interesting! Spot check at 146 mg/dL while there is absolutely no real reason to climb. History rewritten post-facto (through a well known... map simplification algorithm). This is again a clear example of the Libre's temperature compensation issues. As soon as the sensor cools, it resumes cruising around 100 mg/dL and some chicken breast at 16:00 have, as expected, zero effect.

Let's think about that for a minute: a warm bath (sensor fully immersed for 5-6 minutes) leads, in this case, to an almost 50% error on spot checks in a stable non T1D person. It does, however, corrects itself quickly.

Meals and exercise

Pre-made Greek salad consisting of lettuce, feta, olives, oil and some breadcrumbs at 18h20. Slow rise (as expected, way more fat than carbs) and the return to baseline has already begun at 20:45 when subject climbs on ergometric bike for a relatively intense 30 minutes spin. Hitting near hypoglycemia level at 21h20. A bit surprising as as test subject expects better counter regulation (but maybe not enough time for it to kick in). Double checked by strip tests - seems correct.  Time for two slices of gluten free bread with cheese. Response as expected.

The banana

A medium sized banana at 12:30. That single fruit does indeed have a major impact! While - according to its own strip tester - the Libre may have overestimated the impact, that single banana was much worse than the Greek salad three times the weight...

Greek salad again and an apple

Going from the Greek Salad again - based on specs (pre-made fresh food bowl), identical to the first one but let's add a medium sized apple as dessert. Impact remains lower than the banana effect.

Steak and chocolate

Steak at 18h45 has no impact as expected. Mild bump from around 30 grams of 90% cocoa chocolate.

More soon.

Wednesday, October 19, 2016

Type 1 vs Type 2: the dumbest fight ever!

There are many memes in the T1D online communities, but one of the most irritating is the one that resurfaces whenever Type 1 Diabetics feel offended to be compared to Type 2 Diabetics. It basically goes a bit like this
"Don't confuse me with those ugly, fat and lazy Type 2 diabetics - I am really sick and, in my case it is not self inflicted."
That type of comments infuriates me in a major way. For four reasons
    1. that is profoundly simplistic, dumb, uninformed and plainly stupid.
    2. it often ends up in mob style behavior from the T1D community, versus other patients, versus corporations, small businesses, versus politicians, etc...
    3. T1Ds constantly whine about the fact that the non T1D community doesn't understand their problems, are always the first in line whenever they can claim some advantages - "play the diabetes card" as they say. While this is understandable in the context of a very heavy chronic disease, why can't they at least show a bit empathy for other chronic sufferers? 
    4. the fact that Type 2 Diabetes is much more frequent than Type 1 diabetes drives research and funding. While it is true that you often can't directly transpose research, results and therapies from T2D to T1D, the most dim witted Type 1 Diabetic could at least try to understand that research in, for example, Insulin signaling could be beneficial in those two different diseases. Or that having huge budgets devoted to diabetology creates an eco-system that is favorable to progress in general. For all we know, a young post-doc who finds a reasearch job today in a metabolic lab focusing on TD2 diabetes could be the one who makes a major discovery applicable to T1D tomorrow. At least, he is definitely more likely to contribute than an orthopedic surgeon or a psychiatrist.
Let's quickly look at the genetic inheritance aspect of T1D and T2D as it is often seen as the ultimate "responsibility" test... this will be quick.
Type 2 diabetes concordance in dizygotic twins 40%
Type 2 diabetes concordance in monozygotic twins 70%
Source:Genetic Screening for Type 2 Diabetes

Type 1 diabetes concordance in dizygotic twins 3.1%
Type 1 diabetes concordance in monozygotic twins 27.3%

Just in case you don't know = dizygotic twins are standard brothers and sisters, with different genomes. monozygotic twins have mostly the same genome.
You can present the data both ways:

T2Ds are the ones who should complain because...
... the genetic factors play a much bigger role in Type 2 diabetes than in Type 1 - if you have a monozygotic twin with Type 2, there is a 70% chance you will be type 2 as well. In the case of Type 1, only 27.3%. (please do note that the lifestyle choice issues are mostly excluded by the comparison with dizygotic)

or, you could say

T1Ds are the ones who should complain because...
... the genetic factors play a much bigger role in Type 1 diabetes, having a T1D monozygotic twin multiplies your risk by 9, in T2D your risk is only multiplied by 1.7.
And that is only scratching the surface. Going back to the above points
  1. if you don't have the time to educate yourself, just shut up. Or, at the very least, learn to shut up when you are going to say mean stupid things. A statement such as "these are two different diseases" is enough, no need to badmouth others.
  2. don't join mobs, mobs are never a good idea.
  3. other people have diseases too. There is no "good" or "bad" patient. Show empathy, just as you would like others to have empathy for you.
  4. be thankful that a larger part of the population creates an environment that is favorable for research in general. No one knows where or when the eventual breakthrough will occur.

And, to some extent, I agree with there are, in many cases, a "self inflicted" part in T2D, but that doesn't change the above points: educate yourself, don't join mobs, show empathy, be thankful.
That "self inflicted" part - which again doesn't concern the whole T2D "class" of patients, by far - is not easy to solve. Are you going to remove kids from their families on "lifestyle" choices? Sterilize parts of the population? Invest in education so people know what a good diet or exercise regimen is? (even experts can't agree on many things). Shake up the food industry so the eventual trigger factors (we don't really know precisely which ones) are excluded? Yeah, that could be a good idea, but, get real, it won't be implemented any time soon.

educate yourself, don't join mobs, show empathy, be thankful

Monday, October 17, 2016

Make the Dexcom transmitter great again!

Let me apologize for being a bit too silent these days. To be honest, this boils down to the load and stress diabetes puts on our family. On paper, last week appears to be quite nice, with a 105mg/dl average, a 34 mg/dl SD and very few hypos. That being said, we still had a few symptomatic hypos, surprisingly not in the situation that is flagged as an hypo.
Anyway, to say that we are tired is an understatement. About the only diabetes project I managed to proceed with is the replacement of the batteries of our old dexcom transmitter. In this post, I am going to dump the pictures I took and some info on the practical choices I made. Nothing ground breaking, but maybe some useful info for others.

Is this a good idea?

This is something I want to get off my conscience immediately: I am not sure the battery swap is a very good idea. Just like everyone, I do feel ripped off when the time to buy a new transmitter comes. But I wouldn’t want to compromise the accuracy of the results we get in order to save 320 EUR (the price we pay our transmitters). I do, however fully realize how lucky I am not to have to worry too much about the cost of our diabetes supplies and understand that paying 160 EUR per coin battery can be very, very hard to swallow. Why isn’t it a good idea? Well, I have talked to a few battery swappers and, when you go beyond the “cool hack” enthusiasm of the initial success post, you often realize that replacing batteries is a bit of a hit or miss project: there is a high failure rate at the first stage of the operation. That basically means that, if you really rely on your Dexcom data, you are probably going to need ordering a new transmitter anyway, just in case you fail the battery replacement. Then, even when the initial replacement went well , several swappers have told me that the transmitter quickly stopped working. In some cases after a few days, in other cases after a few weeks. Other concerns include proper waterproofing (removing and replacing the transmitter for showers is not an option if you really care because it causes micro traumas and greatly increases the chance of local sub acute infection and wire encapsulation), the stability of the power delivery and the quality of the results you get. You do not want to lose your Dexcom right after a sports session because movements impacted the contact in your sensor.

Battery removal

I used a Dremel with the small Dremel drill press to dig for the original batteries. I used a Dremel carving bit  (probably the 26150561JA) to dig for the batteries. The main advantage of that bit is that its end is flat: unless you are extremely heavy handed, you will get to the batteries and the top tab without even scratching them.
2016-09-07 00.12.13
I then lifted the tabs with a very small screwdriver. The dexcom Grey GooTM is really everywhere, be patient. There are a couple of spots where the tab seems to have been hammered/soldered? into the battery to make contact. These are the point where you want to work patiently with the screwdriver.
2016-09-07 00.39.56
I then drilled the separation between the batteries in order to insert the cutter around the batteries. I would have loved to find another solution, but I did not.
2016-09-07 00.37.59
We then get to the battery lifting part, where you have to make sure you take the correct approach angle. Again, the lower tab seems to be attached battery by two contact points. I worked around those points with a cutter until they let go. Make sure you hold the battery when you play with the cutter as you don’t want to apply torsion to the bottom part of the tab, the one that attaches to the board.
2016-09-30 21.17.15-1
I started “blind”, without looking at the details of the previous tutorials (yes, I am the type of guy who hates to ask for directions) and ended up wrongly guesstimating the back battery position. So you can avoid that mistake, here is the geometry I measured, starting from the narrow end is as follows (+/- 0.1mm except for batteries)

1.4mm+11.6mm (bat1)+1.1mm(spacer)+11.6mm (bat2)+5.7mm = 31.4 mm total length
With the batteries removed, I did a few quick tests. The tabs marked in blue act as a contact that puts the batteries in series. If you break them, this is probably recoverable with a simple wire. Applying 3.1V with a power supply leads to the expected behavior (193mV in my case) on the transmitter external contacts.
I decided to use greater capacity batteries, rated 90mAh instead of the original 50/55mAh Maxell SR1120W. Time will tell if that makes a huge difference in life expectancy.
2016-10-02 02.25.49
The bottom contact isn’t really a problem because it can be easily folded and act a bit as a spring. I applied a liberal quantity of mono component superglue and let it cure under pressure, for more than the recommended time.
The increase in height of the 390 batteries isn’t too bad, although it may have caused a few problems at a later stage: we’ll get to that.
Now the hard part: gluing the top tabs to the battery. Most of the people I talked with have used the scratch, glue and pray approach to attaching the top tabs. This is where I felt the source of instability lied and decided to tackle the issue with conductive epoxy glue. That thing is most often used to fix broken boards or windshield heaters and most of the brands I looked at had bad reviews except the 8331 family from MG Chemicals. There are four versions of the silver glue, one “extreme” version which is, well, extremely expensive (8330, 8330S)  - around 80 EUR for the smallest pack and the 8331 8331S version, still expensive (35 to 50 EUR) but a bit more reasonable. It would be ideal to use it for several battery replacements to diminish the per unit cost.

This is when I started to run into some issues: the 8331 version is supposed to be faster, but wasn’t readily available. I settled for the 8331S which has a working time of 4 hours and a full cure time of… 96 hours at room temperature. My first attempt at gluing the tags when I released the spring loaded clamps after 4 hours and… the tabs slowly rose.
2016-10-06 17.16.09
After reading the data-sheet that gave a 2 hours cure time at 65°C, I went for a 4 hours session on a pre-heat bed I happened to have around.
2016-10-07 19.30.00
Here’s the result of that attempt.
2016-10-09 14.37.22-1
It tested correctly
2016-10-02 02.24.32-1
And I encased the thing in standard dual component epoxy and let it rest for a couple of days. Alas, after 48 hours, I could see that the epoxy had retracted a bit (I guess this is something you want when you glue things together) and that the tabs were beginning to lift (possibly in part because of the added height of the batteries). So I went back to square one…
By the way, if you are worried about a second battery change after an epoxy layer has been applied, don’t sweat it. The glue, even when it has cured, does not really stick that much to the Dexcom transmitter’s material…
2016-10-13 20.28.23-1
For the third and final try, I went “all-in”. I first glued the underside of the tab to the battery, keeping it in place with my spring loaded clamps. Then, still under clamp, I applied a top layer on one half of the tab, let it cure, switched side and repeated the operation. And I finally added a bit of glue on top of the tab bridge. The rationale is that even if it lifts a bit, it should still have contact.

Note: if you want to test the voltage of the transmitter pads, you need to wait for the silver glue to cure. I kept them under monitoring and saw the voltage appear and increase progressively to the nominal 193 mV as the glue cured. (no picture, so many clamps and wires nothing was visible)
WP_20161012_19_24_48_Rich (2)
The final version has now been encased in standard epoxy (I will possibly put an additional layer of sanitary silicon)
2016-10-15 17.47.51-1
and has been under test for a few days (with a slightly modified version of the excellent python script for the rapsberry pi that jamorham has kindly made available in his “Diabetes Smart Home”. (212 is the battery level that you want if you aren’t familiar with raw dexcom packets)
The next phase will be a live test, which I plan to do on myself since my son has a new transmitter anyway and I would hate to have him deal with eventually bad or intermittent data.
That’s all folks. I do hope I will be in the mood for more stuff in the near future.

Edit: you really want the new cover to be waterproof. There is a direct opening between the battery compartment and the board.

Thursday, September 15, 2016

Calibration Basics - or why I stopped worrying about others and ran my calibration algorithm.

While I love the various diabetes open-source projects, the way they moved the industry forward and how they made what was either non-existent or wildly expensive, I have mostly stopped using them as such. I either run my own stuff, use modified freeware versions or, am generally happy with what the G4 505 AP offers in terms of accuracy (speed not so much).

I remember vividly one incident, almost a couple of years ago, where an open source solution displayed negative or impossibly low glucose values when the sensor was pulled out. The root cause of that issue was an intercept set to zero in what was supposed to be a slope + intercept calibration model. At the time, I tried to argue that this was a bad idea and I was kindly mobbed as people who dare to criticize aspects of open source projects often are.

I confess that I was partly to blame for my conciliatory surrender as I did not want to get into endless discussions on the issue. But, now and then, I relaunch one of those solutions and use them for a while. For some reasons, I was hit by even fancier errors caused by forced bad slopes and intercepts.

In this post, I will explain why I think of you need to use a slope intercept model, with a positive intercept. OK, I admit I use "think you should use" as a polite version "you definitely must use"...

Driving a fitted straight line to zero assumes the observed signal is directly proportional to the glucose concentration. That is totally inaccurate, at least until manufacturers decide otherwise.

Sensors are driven (I will get back to this in a bigger 'sensor' post) by a potential difference between the electrodes. That is why sensors become unreliable when their batteries go low and why people who replace batteries in old transmitters check the voltage. The consequence of that voltage is that current always flows between the electrodes of the sensor. That flow is not perfect and is subject to noise. The next figure shows what it looks like.
If the current generated by the sensing process was directly proportional to the glucose concentrations (we assume here that all the linearity issues have been solved by the different membranes around the electrodes), we would get something like this, again with some noise.
On that type of measurement, a slope intercept model with a nil intercept would be roughly valid (you would still have to add a bias so you don't get negative values now and then or if you want to have some room to characterize the noise, but anyway...)

From the above, you should see that the actual physical signal, reflected in the raw count, looks like this (with both the noise of the driving current and the noise of the glucose measurement playing a role)

From the above, it is obvious that no linear estimator forced through a zero intercept or allowed to go through a negative intercept will ever be satisfactory.

The "divide by 10" approach that I observed in some Libre freeware a few months ago was, by definition, heading to a zero intercept: it was doomed to be inaccurate, even if it had somehow used the correct slope. But that basic mistake (sorry) is also present, or potentially present in some situations, in other solutions.

Here is such an idealized (no noise) slope, from a Dexcom patent but, if you still need to convince yourself, there are dozens of similar examples on the net, thousands if one include other sensors, electrods and methods.

Last not least: this is of course valid for as long as manufacturers deliver a raw signal that is actually connected to the real RAW. The Libre signal can currently be considered as raw, coming directly from the TI FAL152. The Dexcom signal of the G4 is partly processed and denoised on transmitter (a noise estimation is provided along with the counts).

But nothing will prevent manufacturers from doing full on transmitter or on sensor processing in the future and deliver some value that has already been fully denoised and from which driving current will already have been subtracted. When that time comes, some will certainly complain that "raw" isn't available anymore, but the truth is that there would be very little to with raw values at that point, unless you can do a better low-level denoising job than the manufacturer.

Note: picoAmps are realistic values, noise is present but idealized for easy visualization. Real noise can be proportionally lower or higher, depending on situations (muscle triboelectric activity for example)

Wednesday, September 7, 2016

Back to the Libre, well... kind of...

Libre now fully covered by social security in Belgium

That's the big news. Since this Summer (2016), the Abbott Freestyle Libre is now fully covered for Type 1 diabetics in Belgium. To be honest, given the complete lack of CGM/FGM awareness that I encountered a couple of years ago and after reading the opinion (in 2015) that CGMs weren't working well in the magazine of the Belgian diabetic association, I was a bit surprised to see the rapid evolution.

There is a catch though - totally understandable - but still a catch. When you declare your interest in the Libre, you sign an new paper that modifies your "Convention of Diabetes Co-Management" and switch from free finger testing strips to free Libre sensors. Instead of the truckload of strips you would have received for the 3-4 months until your next endocrinologist visit, you get sensors to cover that period and a box of Abbott test strips to test your sensor now and then and, eventually, contact Abbott for a replacement. Essentially, if you choose the Libre, it is intended to fully replace your blood testing routine, which is of course in line with Abbott's marketing.

Note: we did try to use the Abbott strips a couple of time and that proved to be a challenge! Those things are blood vampires compared to the Menarini Glucomen LX plus we have been using for the last 3 years, to our complete satisfaction (well within the latest ISO requirements). The Freestyle Libre BGMeter could be slightly more accurate than our current one, but I don't believe we will find out any time soon.

Back to the Libre in Belgium. I managed to talk myself out of the "training session" - I think I can fairly say that our family knows enough about the Libre already. I confess that I had the somewhat perverse idea to take advantage of that training session to ask a few questions about that annoying dual thermistor approach to temperature compensation but I doubt I would have received meaningful answers from the Abbott representative.

More interesting was the reaction I got when I told our team that we intended to enter the "Libre" part of our care convention: "are you really sure?" From what I understood, the average patient is not too enthusiastic yet. The usual issues (running low post insertion, adhesion problem, skin irritations, inaccurate results or confusion about accurate results, teens or kids not wanting to put something in their body...) are apparently slowing adoption.

Back on the Libre but...

The long term readers of this blog are well aware that I liked the Libre a lot when it was released, to the point that we went through the hoops, with the help of the French part of our family, to obtain sensors. The Libre sensors we had back then proved to be more accurate than the Dexcom G4 non AP (14 days comparison). They were also much faster, which was essential for sports (speed matters, tennis and the Libre). We were a bit lucky back then (an informal poll in the Libre user groups reported roughly a 20% failure rate at the time) and enjoyed several complete runs with minimal BGMeter testing. In fact, we enjoyed the Libre so much that we forgave it for stealing our data covertly (the license terms have been updated, your data is now lifted officially) . I dug a bit into its mode of operation and used some of what I discovered/read about in the process to improve our G4's behavior. At that point, the tedium of ordering in France, the lack of convenient remote monitoring (more about this later) and the improvements I made to the processing of the G4 non AP raw data led us to abandon the Libre.

On top of that, several generous readers of this blog offered to send us a G4 AP from the US and, I finally accepted one in November 2015. You can see my G4 non AP vs G4  AP comparison here. In short, the Dexcom G4 AP (and G5) remains slower at picking up trends than the Libre, is a bit faster than the old G4 and, more importantly is now much better at dealing with sub optimal situations, noisy startup sequences and erroneous / non optimal calibrations. While I have taken a long hard look at the G4 AP algorithm, I haven't found anything (given the frequency of the signal) that I really wanted to improve upon or that I felt I could improve.

Finally, and that is subjective, based on a single patient and a year of sensor use, we do feel that the Dexcom sensors have improved a lot: we have not had a single sensor failure in our last 30 Dexcom sensors and, more importantly, they mostly all seem to run acceptably with the same calibration parameters for longer time (this implies that Dexcom has improved both the consistency of what they deliver and the stability of their sensors) 

That means that the Libre is now facing, as far as we are concerned, much stronger competition.

And of course... 

Nonetheless, we decided to give the Libre another shot and inserted a sensor as soon as we came back from our endo's office. As it was to be expected, that sensor was a dud. An interesting dud, but a dud.

Here is an (approximate) snapshot of its behaviour.
In practice, such a dud behaves in a way that may be surprising to an average user
  • around 100 mg/dl, it will appear to display the correct value. 
  • below that value, it will under estimate the correct value.
  • above that value, it will over estimate the correct value.
  • that "bad" slope will increase the apparent variability of your interstitial glucose tremendously.
In fairness, that is probably a sensor that I should have exchanged but we decided to keep it in order to investigate it a bit more. That I could understand quickly the sensor behavior and that Max understood the above representation and its impact on his displayed BG values made the situation tolerable. But, after 2-3 days, when it became clear that the sensor would stay stuck on that bad slope, we inserted a Dexcom...

There is that old saying in French that roughly: "you never get the second chance to make a first impression". In our case, the first Libre impression was extremely positive. We have been running CGMs for several years and understand bad sensors can happen. But what about a first time user, who has just gone through basic training and has never tried a CGM/FGM? I really don't know...

Now, putting my tinkerer's hat back on, the interesting thing about that bad behavior is that it is exactly the kind of situation you can calibrate your way out. Should you? That possibility is already available through third party software. It is a valid question, but the answer is not easy: there are other potentially confusing situations and other Libre malfunctions (temporary or permanent) that can not be handled or should not be handled through calibration.

I'll try to explore the issue in more details in a follow up post.

Last thing before closing this post: Sandra Kessler has launched a crowd funded project for a Libre add-on that would bridge periodic NFC reads to BT and possibly transform the Libre in a full fledged CGM. There are many potential issues and risks involved in supporting such a project but I have decided to support it. I am well aware of other hacks (in the positive sense of the term) to achieve the same goal and have, in the past, expressed my disappointment about the algorithms those projects used. As far as I can tell, that profound algorithm issue has now been mostly solved. That does not mean these projects, Sandra's and the others, don't face additional hurdles. Time will tell.

I will also try to devote a blog post to the blueReader project in the future and, if we are still on the Libre, possibly contribute a bit more.

Tuesday, August 30, 2016

Sometimes, you get thumped on the head with a scientific paper...

Now and then, a member of some "low carbing" communities tries to "educate" me. In fact, I am not fundamentally opposed to a lower carb diet, or even no carb periods, but I probably not "faithful" enough to avoid a virtual Sunday morning "Jehova Witness style" call. Here's a paragraph from a scientific paper I have already been sent three times.

A claim so dramatic and peremptory that I should either see the light or crawl back into my hole. This is the type of statement that closes all debates and can easily be summarized for the choir. (it comes from

Let's dig a bit into it, in details.
"Contrary to popular belief supported by the leading physiology and biochemistry textbooks, there is sufficient population of glucose transporters in all cell membranes at all times to ensure enough glucose uptake to satisfy the cell's respiration, even in the absence of insulin"

Popular belief, maybe... But textbooks are fully aware of the existence of the different transporters (some of them insulin dependent, some of them gradient dependent, etc...), their respective distribution and roles in different tissues and of the absence of barrier. So, this is basically creating a giant out of a windmill. The "giant" is extraordinary and as such deserves an extraordinary proof. The proof comes from (21), the only article cited multiple times in the paragraph, which you can find here This is, by the way, an article devoted to doping in sports which summarizes, sometimes without references, some information about insulin. The article hasn't been cited too often as a fundamental work on Insulin metabolism... but I digress..
"Insulin can and does increase the number of these transporters in some cells but glucose uptake is never truly insulin dependent."

What does "truly" actually mean? Is it dependent or not, partially, mostly, not at all, falsely dependent, somewhat falsely dependent? I don't know... "not only dependent" would have been acceptable though.

"Even under conditions of extreme ketoacidosis there is no significant membrane barrier to glucose uptake – the block occurs "lower down" in the metabolic pathway where the excess of ketones competitively blocks the metabolites of glucose entering the citric acid cycle."

This is an almost verbatim quote from (21) - even in ketoacidosis, glucose can enter the cell. But it is blocked "lower down" (which means at the Krebs Cycle level).

So, let's rephrase that: nothing prevents glucose from entering the cell, but it will be under utilized. Fair enough. It is a bit like saying "Falls are never dangerous to humans. The danger occurs "lower down" when the human hits some hard surface.

"Thus, insulin is not needed for glucose uptake and utilization in man"

Aha... Did he just prove that in a flash? Yes, some uptake does occur without insulin. That is the windmill the author had changed into a giant. But utilization? The author just stated that there is some kind of block "lower down" (which happen to be ketones that, in short, insulin would prevent)... I am somewhat confused here.

Anyway, let's go for another verbatim quote of 21, blah blah blah...

In fact, the process appears to be general for all polar (water-soluble) substrates, as transporters are the mechanism by which they are transported across the highly non-polar (lipid) cell membranes. 

and follow that by another interesting statement.

When insulin is administered to people with diabetes who are fasting, blood glucose concentrations falls. It is generally assumed that this is because insulin increases glucose uptake into tissues. However, this is not the case and is just another metabolic legend arising from in vitro rat data.

The claim that insulin lowers BG in diabetics because it increases uptake into tissues is now a "legend". Not bad. We'll get to that...

It has been shown that insulin at concentrations that are within the normal physiological range lowers blood glucose through inhibiting hepatic glucose production [].

Ah, finally, some truth. Yes, insulin does suppress endogenous glucose production. Among many other things. And, indeed, in some ranges, fasting and at rest, uptake does not increase and may even decrease. No demand from the cells. Except when you move your muscles a bit...

Now, let's go back to article 21. An article that deals mostly with doping and ends up on the usual customary note... If it was quoted three times, it must contain additional supporting evidence...

"Both methods need further validation before implementation. Research work carried out as part of the fight against doping in sport has opened up a new and exciting area of endocrinology."

That article also states, the very conventional... (the language is a bit dated, see below)

"The truth is that insulin acts exactly as Schafer had predicted – it acts as both an autacoid and a chalone. Through stimulating the translocation of ‘Glut 4’ glucose transporters from the cytoplasm of muscle and adipose tissue to the cell membrane it increases the rate of glucose uptake to values greater than the uptake that takes place in the basal state without insulin."

Ah, OK, then uptake does increase after all... Why skip that?

Finally, it completes the "lower down" paragraph quoted verbatim in the first paper

"... the block occurs ‘lower down’ in the metabolic pathway where the excess of ketones competitively blocks the metabolites of glucose entering the Krebs cycle. Under these conditions, glucose is freely transported into the cell but the pathway of metabolism is effectively blocked at the entry point to the Krebs cycle by the excess of metabolites arising from fat and protein breakdown. As a result of this competitive block at the entry point to the Krebs cycle, intracellular glucose metabolites increase ‘damming back’ throughout the glycolytic pathway, leading to accumulation of free intracellular glucose and inhibiting initial glucose phosphorylation. As a result, Figure 1 Insulin exhibits both inhibitory (chalonic) and excitatory (autacoid) actions via the same receptor. In these experiments carried out on rat adipose tissue, in vitro insulin simultaneously inhibits lipolysis (the release of glycerol from stored triglyceride) and stimulates lipogenesis (formation of stored triglyceride from glucose). Thus its anabolic action is due to two mechanisms working synergistically. much of the ‘free’ intracellular glucose transported into the cell is transported back out of the cell into the extracellular fluid. Thus under conditions of ketoacidosis, glucose metabolism (but not glucose uptake) is impaired as a direct consequence of the metabolism of fat – the ‘glucose–fatty acid’ cycle (Randle et al. 1965)"

which is a bit old, is widely understood to be generally correct and has been fine tuned since but not drastically. On the whole, when the paragraph is quoted completely, the meaning changes a bit though...

This is followed by a quite longish discussion about other things we also now know to be mostly true and are, in many ways, in complete opposition with the revelations of the original paper...

1. Through facilitating glucose entry into cells in amounts greater than needed for cellular respiration it will stimulate glycogen formation. Thus hyperinsulinaemic clamps will both increase muscle glycogen concentrations prior to events and in the recovery phase after events. Since performance in many events is known to be a function of muscle glycogen stores, Figure 3 The data used in this illustration were obtained from healthy normal subjects using a series of euglycaemic and hyperglycaemic clamps at basal or increased insulin concentrations. Rd1: insulin independent glucose uptake. The data have been fitted to the generic model shown in Fig. 2 (see text for details). Insulin, GH and sport · P H SONKSEN 17 Journal of Endocrinology (2001) 170, 13–25 ‘bulking up’ these stores will most probably enhance performance. There is no documental proof that this technique is being used but informed ‘street talk’ indicates that it is not uncommon. 2. Through use of similar hyperinsulinaemic clamps post-event and during training, it is likely that recovery and stamina will be improved. 3. ‘Street talk’ indicates that insulin is also being used in a more haphazard way, particularly to increase muscle bulk in body builders, weight lifters and power lifters. This use is allegedly by regular injections of shortacting insulin together with high carbohydrate diets. Through this therapeutic regime it is almost certainly possible to increase muscle bulk and performance not only through increasing muscle glycogen stores on a ‘chronic’ basis but also by increasing muscle bulk through inhibition of muscle protein breakdown. Just as insulin has a chalonic action in inhibiting glucose breakdown in muscle glycogen, it also has an equally important chalonic action in inhibiting protein breakdown. Indeed, the evidence now indicates that insulin does NOT stimulate protein synthesis directly (this process is under the control of GH and insulin-like growth factor-I (IGF-I)). It has long been known that insulin-treated patients with diabetes have an increase in lean body mass when compared with matched controls (Sinha et al. 1996). 

in some specific insulin and BG ranges to end up with the conclusion that

Taken together, all these points support the concern shown by the Russian medical officer in Nagano and the immediate response of the IOC to ban the use of insulin in those without diabetes.

To summarize...

The paper I have been mailed several times so I could "educate" myself
  • makes an outstanding sounding claim.
  • that it falsely presents as a revelation that contradicts fundamental textbooks.
  • attempts to justify its claim by cherry picking partial paragraphs
  • out of a single paper that attempts to address a completely different issue
  • and comes from an era where we had concerns that insulin and GH could be used for doping.
  • finally, the original article manages to cram a couple of non sequitur and to contradict itself.
That's a bit light to convince me...

But, of course, the fact that the article is.... hmmmm.... what it is, does not invalidate its premise. In other words, it is not because people e-mail you crap on a semi-regular basis that the pillar of their faith is wrong. It could very well be correct. One could make a completely stupid argument that the Earth is approximately spherical and still be correct.

My goal here is not to attack the idea of low carb in itself, but it would be nice if the people who mail me papers could at least attempt a bit of homework...

Monday, August 8, 2016

PTPN22 gene and type 1 diabetes: a short post about why the genetics of diabetes are so complex.

Apparently, this post has been sleeping as a draft for a while. Wrote it at the beginning of the year, never posted it...

The case of PTPN22

Outside of the major histocompatibility complex (yes, that HLA-DR... stuff), the PTPN22 gene that encodes a protein call Lyp (lymphoid protein tyrosine phosphatase) is one of the genes most associated with auto-immune diseases such as Type 1 Diabetes, RA, JIA, Addison, Psoriasis, etc... A single mutation in the coding part of that gene leads to an amino acid (the building blocks of proteins) substitution. We will call that "bad" mutation R620W.

Here's a short description of PTPN22, we'll talk more about the roles of the phosphatase it encodes a bit later.

You will note the phosphatase is a member of a sub-family (an indication that there are lots of them). You will also note the use of "may". Not necessarily the word you want to read when you are looking at a strong suspect... We'll also get to the reasons behind the uncertainty.

How do we know it is associated with auto-immune diseases?
There are a few "simple" cases where one single mutation in a single gene creates a well defined disease. Phenylketoneuria is the archetypal single gene disease. Certain forms of Type 1 Diabetes have a direct genetic cause. When the Human Genome Project started, we lived for a while under the illusion that we would soon explain hundreds of "genetic diseases". We were totally wrong! In most cases, when a genetic predisposition is present, the causal links are weak and many. Most of today's gene-disease association research is done through Genome Wide Association Studies. How do those GWAS work? Here is a simple analogy. Let's say that 50% of the citizens of the USA are republicans. Therefore, we know that 20%  of the US citizens (40% of 50%) vote for Donald Trump. We also know that only very few Muslims, a small percentage of Blacks and possibly a slightly bigger percentage of Latinos vote for our dear Donald. Crunch the numbers, and you will obtain the odds for each population category. In that simple case, you can safely say if you are Caucasian your risk of contracting Trumpism is higher than the general population. The danger is even worse if you are a Caucasian Republicans! Of course, Caucasian Democrats are less likely to contract the disease but some of them could catch it at some point. Calculate all the odds and predict the results of the elections. Not that simple, right?

But in fact, biology is even more complex than politics and the odds aren't always that clear. Consider that recent Chinese study for example.

The tiny genetic code modification in PTPN22 is more frequent in the T1DM patients population. But, and that is extremely important, approximately 80% of the T1DM patients and 92.5% of the healthy control do not carry that variation! In a nutshell, while more T1DM patients than healthy subjects carry that variation, the vast majority of the population does not carry it...

The risk factor is clear, but the big picture is extremely fuzzy.

The huge weakness of GWAS studies is that while they find a lot of strong or weak correlations, in most cases they do not help us much in terms of causal link. They are pointers that can help directing further research.

Another interesting link between the bad mutation R620W and auto immune diseases is that its geographic distribution mirrors the distribution of diseases (Finland for example has the highest T1D frequency in Europe and also the highest R620W frequency). 

What do we know about PTPN22?

We know an awful lot about PTPN22. In fact, we know almost everything there is to know about it. Here is a simpler description of the gene

It has been extensively studied. 437 citations in Pubmed. 309 Gene RIFs (roughly established connections to functions)

Note: the green rsxxxxxx numbers are the SNPs (single nucleotide polymorphisms) tested by the 23andMe version 3 chip. Our SNPs are constantly loaded as a browser extension and automatically highlighted on pages that I visit.

In fact, you could probably devote your life to the study of PTPN22, its product, the role of its product, its interactions and associations.

Now, lets interest ourselves with the product of PTPN22, the phosphatase itself. You'll find a good summary of what we knew in 2011 in the excellent article Why is PTPN22 a good candidate susceptibility gene for autoimmune disease? I will just summarize a few salient points below.


Lyp, the product of PTPN22, is a protein tyrosin phosphatase (PTP). We know more than 110 variations of which at least 57 of them are present in Lymphocytes ("white" cells, in general cells involved in the immune system). Phosphatase (PTP) and Kinase (PTK) are enzymes that control the activity of signalling transmitters, the messengers that will inform the cell of external changes and change the cell behaviour (they are the control switches inside of cells). In general PTP control the amplification of the signal, PTK control its tempo and duration. Again, you could spend a full life studying kinases and phosphatases without running of material...

Reaction to outside signals is obviously extremely important for immune system cells. It is no surprise that several of those phosphatases are associated with auto-immune diseases (PTPN2, PTPRC, UBASH3A, PTPN11, PTPRT and our PTPN22). PTPN22 was linked to Type 1 diabetes in 2004 (N. Bottini, et al., A functional variant of lymphoid tyrosine phosphatase is associated with type I diabetes, Nat. Genet., 36 (4) (2004), pp. 337–338)

Lyp, the member of a family of 100+ enzymes, a sub family of 57+ enzymes has three forms, independently of its eventual mutation.

The expression of Lyp varies, depending on the type of lymphocyte and cells.

Lyp inactivates some of the kinases of the Src and Syk families.

Lyp interacts with many other molecules. Here's a rough overview


and a closer view of one of the process. 


At this point, I can't resist a few direct (unlinked) quotes.

 The precise stoichiometry of the interactions that promote Lyp phosphorylation by Lck is complex and remains to be determined, but Csk micro clusters may facilitate this interaction through SH2 binding sites that allows the docking of Lck and subsequent phosphorylation and inactivation of Csk associated Lyp. Clarification of the sequence of events that govern inhibition of Lck by Csk and Lyp is also required, since Csk preferentially targets activated Lck that is phosphorylated at Y394, as demonstrated by in vitro kinase assays and phosphopeptide mapping [72]. The regulation of Lck has also been brought into question in recent years since it is becoming evident that acute dephosphorylation of Y505 may not be necessary for Lck activation and TCR signalling

 Studies have yet to address the contribution of Lyp in regulating Vav function.

Because B cells share much of their signalling machinery with T cells it is likely that Lyp may regulate proximal B cell receptor signalling in a similar fashion, but substrate trapping experiments have not been undertaken in B cells. There is some evidence that there may be impairment of signalling in human individuals carrying the R620W variant  

Despite these two molecules having opposing kinase/phosphatase activity, they both serve to inhibit T cell function, possibly synergistically

Together these studies flag up two important questions. First, how does a mutation outside the catalytic domain lead to increased enzyme activity? Second, how could an apparent attenuation of TCR signalling lead to autoimmune disease?

There is still no clear consensus as to whether R620W is a gain- or loss-of-function variant and there is a possibility that in the future there may be newly discovered functions of the mutant phosphatase. It is not inconceivable that R620W may exert both gain- and loss-of-function activity in different pathways but within the same cell. Another possibility is that the mutant Lyp may have different (or opposing) effects in cells of different lineages, or that the mutant has opposing activities in different pathways in the same cell.

Note: I stopped my draft at this point - probably out of despair.

Addendum: interesting papers

Staging Presymptomatic Type 1 Diabetes: A Scientific Statement of JDRF, the Endocrine Society, and the American Diabetes Association (

A convenient list of T1D SNPs and their weighted risk score

Genetics of Type 1 Diabetes (