Pages

Sunday, 26 July 2015

Sensor Glucose on the 640g Part 2: Calibration

This post assumes you've read (or glanced at) my earlier post on how ISIG is calculated in the Guardian 2 Link transmitter.

Once we've captured some ISIG data (the raw signal from the Enlite) we need to calibrate. 

Enlite users will be painfully aware of the Enlite's calibration routine - after its warm up (pushing lots of current through the sensor to try to get it to a stable state), the first calibration is due at 2 hours. At two hours... Not before, not after (unless you want to be without Sensor Glucose (SG) data...) And then another within six hours. And then at least every twelve hours... A certain amount of forward thinking is therefore required - but you'll be used to that as a person with T1D (or a T1 mum or dad...).

There are plenty of posts already about how annoying the first 24 hours on an Enlite can be, both in terms of accuracy and the calibration regime and we won't go down that route in this post.

However, there are some pretty big clues as to what's going on in those last two paragraphs...

Usual rules apply - I could be wrong: this is inherently noisy data and a different combination of the techniques described below may be responsible for the calibration factors. Please get in touch below or via Facebook to let me know :-)

A quick summary if you don't want to scroll? To calibrate:
  • The 640g takes the ISIG data from the G2L transmitter
  • It modifies it (by subtracting an offset)
  • Be very careful with your first calibration point!
  • It uses at least the last four calibration points (when available) to calculate a weighted-average calibration factor, with calibrations within the last 12 or so hours seemingly most important
What's different with the 640g vs Veo?
  • A different average offset appears to be applied to the ISIG data
  • The Veo also uses multiple calibration points (probably just four) but extends its weighting of these points to include much older (probably up to 24 hours) data.

Black Box Number 2: the 640g pump




Edit: On the current generation of Enlites, I originally thought only the ISIG is calculated on-board the Guardian 2 Link transmitter. However, if you look through the 640g's SG errors, there are a handful of errors suggesting that the calibration BG has to make it to the transmitter i.e. the G2L calculates the calibration factor. These errors include "No Calibration Occurred" and "BG Not Received". The calculation assumptions remain the same,

Whether or not the G2L calculates the final SG I don't know. I believe the Enlite 3 will perform all the calculations to get SG).

To get to a SG value we need to supply a calibration (sensitivity) factor to get from our "raw" signal (ISIG, nA) to SG (mmol/L or mg/dl).

In its simplest form, you could take a Blood Glucose (BG) value at time t  and divide it by the ISIG value from time t+10 minutes (allowing for the approximate time-lag between SG and BG values). This is known as Single Point calibration, or Single Point Sensitivity Ratio (SPSR). At two hours post warm up of a new sensor, that's all you've got - so make sure it's a "good" one!

Even this isn't quite as simple as it seems. The system appears to make two modifications to the inputs:

- First, it uses the third valid ISIG value after your calibration BG point i.e. a 10-15 minute delay between the BG reading and the signal used for calibration. That'll suit most people from what I've read about the delay between interstitial and blood values, but perhaps not everyone...

- Second, it also modifies the ISIG value - one of the key patents from Medtronic on this (US 6895263) mention several strategies, but the most repeated is to use an offset of -3 (i.e. subtract 3 nA from the ISIG value) providing the SPSR is below 7 mg/dl/nA [well, as a big US company, we'll allow them to quote and calculate in mg/dl instead of the mmol/L I'm used to in the UK :-) ]. The threshold may increase further for SPSR values less than 4 mg/dl/nA according to the Patent. Again, according to the Patent, the offsets are applied in an effort to recover non-linear performance at high BG levels for high sensitivity (low SPSR) sensors compared to low sensitivity sensors (high SPSR).

I was surprised not to see a more continuous formula presented, giving a continuous range of offsets (high at low SPSR, low at high SPSR), as I'd be concerned in the patent's implementation about patients whose sensor was on the cusp of a threshold being applied - small changes in SPSR may lead to more significant changes in reported SG (ISIG values for Janki are usually between around 15 - 30 nA and so a -3 offset would represent a 10%+ change in SG value).

We now have a Modified Single Point Sensitivity Ratio (MSPSR) = BG / (ISIG - Offset)

In the 640g data I have access to, I typically see an average offset value of around -3, although there is significant variation, which may indicate that there's an additional filtering step added to this ISIG data before SPSR is calculated and an offset is applied or that a more complex threshold algorithm has been applied.

In the samples of Veo data I have had access to, the offset appears to be much more consistent and set at -2 for the SPSR ranges I have access to.

In both cases, I don't have data with a sufficient range of SPSR values to verify if upper threshold boundaries may apply or not.

According to the Patent, there'a also an error check in here, one of the ways to generate a Calibration Error. I'll put up a separate post on Sensor Errors in a little while...

Is that it? No, unfortunately not...

So at the first calibration point, MSPSR is applied.

But using either the SPSR or MSPSR later in the sensor's life does not correlate with the Calibration Factors reported by the 640g (as found in the CSV report from CareLink). In the example data below, you can see examples of where the single point factor ratios from one calibration to another are incorrect and - crucially - events where the Medtronic calibration factor rises (or falls) and the single point value moves in the other direction - a sure sign that more than one calibration event is involved...

Therefore, after the first calibration event, previous calibration pairs (i.e. BG and ISIG values) are also used in a modified linear regression technique. This technique takes a weighted sum of BG x Modified ISIG values and divides them by the sum of (Modified ISIG)^2.

(By the way, there's another chance for a Calibration Error here...)

Example 640g Data
The patents mention a range of weighting regimes and regression periods (e.g. last 4 or eight samples or the last 24 hours) and focus on a Gaussian weighting with fixed time points applied to each previous calibration pair (actually based on a Gaussian width of 15 hours, sampling - calibrating - every 6 hours).

However, in the 640g data that I have, I've found a much shorter width (~3-5 hours) produces a reasonable fit. An exponential function is also marginally more successful than a Gaussian in the datasets I have access to. For a 5 hour width, this translates to a weighting factor of ~30% at 6 hours, 10% at 12 hours and just ~3% at 18 hours from the current calibration point. Therefore in most calibration situations - unless you get trigger happy... - it's only going to be take the last one or two calibration factors into account.

It would seem sensible for the pump to track the last 4 calibration points, although it may track more (the example above was calculating 8 points for example, but anything beyond ~12 hours is not making a significant contribution). See below for an example of how the weighting factor may drop away for previous calibration points:



I don't have enough data to categorically define these parameters. The above graph is a typical example of what I get - in the calculation zone (between the first blue diamond and the last), the match between the pump (Medtronic, red) and my home-brew calculation (Exponential 5hrs, green) is usually pretty good, but not perfect. As we'll see in the next post it yields an overall SG match (Medtronic to my calculation) typically within ~2-3% over the period I track with my code (up to five sensors).

There may also be factors applied to reduce sensitivity with sensor age (as would be expected) and, possibly, to build-up a 24-hour pattern of sensor sensitivity to account for daily variation in user biochemistry, but I haven't had a chance to look into these.


So how does this vary with the apparent Veo settings with an Enhanced Enlite?

I've already mentioned the average ISIG offset is reduced to -2. But, with this applied, we're still clearly a way from matching calibration factors (below). There's too much variation and the differentials are also poorly matched - i.e. the width needs to increase and the function itself might be wrong.


A better fit, is to use a Gaussian function and a longer width (8 hours are shown below)



But similar performance is also seen with a Gaussian using a 10 hour width and only the last four calibration points (below). Both of these scenarios result in an overall SG error of around 3-4%, compared to the Medtronic values.


I don't have enough Veo data to completely lock down the Veo calibration parameters, but I am reasonably sure that a significantly longer regression width is applied, which means more calibration time points will come into play in the current factor calculation on the Veo than the 640g.

Will this have an impact on the SG values between the two systems? Stay tuned...

Next up, home straight, calculating the SG value itself.

No comments:

Post a Comment