Tuesday, October 27, 2015

Getting the most of your Dexcom (non AP algorithm)

Getting the most of your Dexcom (non AP algorithm)

Note: this is a relatively old post I had prepared in early July 2015. I planned a couple of them listing all our Dexcom G4 (non AP) issues and solutions but ultimately lacked the motivation to fully document the accuracy improvements process. While I did get good results, the whole process was a bit cumbersome, the eventual slight differences between algorithms added to the cognitive load (as running two CGM in parallel did when we compared the Dex to the Libre) and I came to realize that while going below a 10% MARD was cool and satisfying, it served no practical purpose. I've decided to publish this first part as is. 

The Freestyle Libre sensors we have used have generally outperformed our Dexcom in terms of accuracy and tracking speed. In terms of convenience, the Libre system wins hands down., But the Libre is not perfect.
  1. it does not work out of the box as a full CGM and consequently does not fit in the Nightscout/xDrip ecosystem. The lack of range is a practical killer for those applications.
  2. it is not widely available.
  3. it did generate, in special circumstances, a few values that weren't in the A+B zone of the Clarke grid. Yes, a poorly calibrated G4 could also deliver amazingly bad and dangerous results (see below), but thanks to the wisdom we've collected over time, we don't see them any more (unless we experiment - but in this case we use two trackers).
  4. the Libre community is mostly a community of users, the Dexcom community is a bunch of builders. Well, there are builders in the Libre community, but a lot of them are interested in a quick buck and that does not fit my thought model...
But... when you have experienced the Libre, the non AP Dexcom is definitely disappointing. Is there hope! In this long multi-part post, I'll report on our experience trying to elevate the non AP Dexcom to a Libre-like level of performance and usefulness. We'll start with basic things and ending on possibly somewhat esoteric developments.

Physical aspects

  • Insertion should be as smooth as possible, which isn't necessarily easy with a small kid and the Dexcom inserter. The less traumatic insertion is, the smoother the immediate post insertion values will be.  
  • The sensor should be firmly attached and remain firmly attached throughout the wear period. A slightly mobile sensor will cause microscopic traumas that will negatively impact its accuracy. A sensor that lets liquids sip around the sensor wire's wound may lead to infection and temporary membrane characteristic changes that will also lower the quality of the readings. Triboelectricity caused by sensor movements can disturb the readings.
  • The location of the insertion site should be selected so that sensor compression issues are minimized. Observe how your kid sleeps and try to avoid areas that he typically sleeps on.
For a more complete description of the issue, have a look at the following paper

The first day: pre-insert or use xDrip.

The few hours after insertion can be difficult. This is well documented in the scientific literature and the reason why some of the most meticulous comparison tests were done with sensors that had been pre-inserted 24 hours before the measures started. Dr Damiano used pre-insertion in his CGM evaluation.

Insertion is an "analog" process, not something that is perfectly reproducible. How and where it occurs is a soft parameter that can't be precisely quantified. How your body reacts to the insertion and how quickly it heals the wound is as variable as any other parameter across a population of humans, from 10 kg toddlers to overweight retirees... While pre-insertion remains, in my opinion, the optimal strategy it is not always convenient and, unfortunately, the Dexcom "flipper" must be secured if the receiver is not immediately locked into place.

Sealant (probably silicon based) on the sensor base.
The bottom-line is that, in the time frame following the insertion, the G4 can return erratic data for... a certain amount of hours... How many? It depends. We have seen sensors settling after a couple of hours while others took almost a day.

We've observed, using either xdrip or a wired solution, very noisy secondary raw data as shown in the screenshot below (more about primary and secondary noise a bit later).

or noisy but slightly more coherent oscillations as shown below

Sometimes, the behavior may border on the insane if you focus on one single value, as in "Oh my God! The kid is crashing!"

except of course that, ten minute later, the kid isn't crashing anymore.

A word about noise: as you can see, in the above case, the synthetic "raw" value that the Dexcom returned has been marked as "clean". What this means is that the low level collection sampling loop that provided the synthetic (secondary) raw data worked with a decent strong signal. That unfortunately does not necessarily means that the signal is stable or clean at a larger time scale.

The problem, in that bad first hours scenario, is that calibrations occurring at a time the Dexcom essentially sees semi random data, is likely to negatively impact the accuracy of the following day(s). Your Dexcom may or may not decide to display "???" but you will probably end up getting something as senseless as this

Careless first day calibrations leading to absurd results.
The initial low was wrong. The subsequent sharp rise was wrong. The second sharp rise was also wrong. In short, the whole night was a painful mess...

Since xDrip reports a direct translation of the secondary raw value it receives, it will more clearly show if a sensor is unreliable or misbehaving. If you have not pre-inserted your sensor, don't feel forced to enter the initial calibrations exactly after the 2 hours wait period: initial calibration should occur only when the sensor is fairly stable and consistent.

For example, This startup sequence does not suffer much from secondary noise (there is a compression event starting around 3h30) and is good enough for acceptable calibration.

[Older post delayed - see NOTE on top of page]

No comments:

Post a Comment