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)

1 comment:

  1. And now the 100$ Question: Are the parameters of the calibration curve (intercept, slope, curvature) for the currently used sensor somehow present in the header/footer of the sensor data?

    This is what I would call factory calibration.