Restarting the dexcom sensor - what you should know

Diabetes Technology Glucose Monitoring
1

First off to start with, we restart our Dexcom sensors at the end of 7 days. We all do. Some people even budget to get at least 2 weeks out of a sensor or more, and this is the only way they can afford to run it, some people if the sensor dies before 2 weeks will go without until the next 2 weeks starts. So a lot of people really depend on being able to restart the sensor.

Dexcom says you shouldn't do it, and they are only FDA approved for 7 days. But nobody tells you why. Until now.

As part of my work with the nightscout / CGM in the cloud guys and others, I've spent a lot of time analysing internal data in the dexcom receiver. We're working on a project that will allow us to bypass the dexcom receiver completely. In order to do this, we need to know firstly how the radio packets work (we figured that out), and how the calibration works (which we also mostly figured out).

When you insert a new sensor, and hit start sensor on the receiver, it starts a new sequence of calibration. This happens in stages. It moves past the old calibration data. After the 2 hours you enter 2 BGL readings and then it's working.

When you look in the calibration data, and check that against the raw data and calibrated readings, you can see that in the early stages of a sensor's life, the sensitivity of the sensor is changing. The sensor is actually getting more sensitive over time for the first 2 - 3 days. Dexcom has to account for this, so models it with a time-variant adjustment in their calibration. After a few days, this time-variant adjustment gets turned off as the system has levelled out. Ok, so what does this mean?

When you restart sensor with an existing sensor, the sensor has already reached peak sensitivity. But the receiver thinks it's a new sensor that will change sensitivity greatly over the initial couple of days. So it starts to apply the time-based compensation again. However since this sensor is already bedded in, this time-based compensation is out of place.

What this means, is the readings you will get, will drift downwards (compared with a finger-stick) over time.

For example, we restarted our sensor yesterday. We went about 16hrs before this morning's calibration, and the dexcom was showing 9.1 (164 mg/dl). I did a check with our Accu-chek performa, and was surprised to see a 18.2 (328!!!). He also wears an Animas Vibe pump, which has a dexcom receiver built in. This one was on a different calibration cycle. It wasn't restarted yesterday but a few days earlier. This means the pump wasn't applying the time-compensation factor. It was reading 14.9 - much closer to the fingerstick value.

So what can we take away from this? I think we still want to restart the sensor. It's clear from the raw sensor values that the sensor is often fine, especially if it's well-adhered to the skin and doesn't move. So I believe the answer is that when you restart the sensor, you should increase the number of calibration entries for the first day or two to maybe 4 per day. This will prevent the dexcom from drifting as far off.

7 Likes
2

This is very interesting and informative. I have also noticed the Dex drift lower on week 2. This is a logical explanation.

Thanks for the explanation!

3

That explains why I get more 2nd week accuracy than many do. Because I always enter a calibration any time that I test and Dexcom’s arrow is level.

4

Very interesting, indeed. Thanks for the clarifications.

5

Adrien, you are so amazingly smart I can't stand it. (This is Christine Deltrap.) My husband and I luuuuv you for continuing to figure this out.

6

A wristwatch would be the perfect receiver IMO. Even better than an iPhone receiver. Years ago I actually used the GlucoWatch. That’s what we need right now. Just like in that movie Panic Room where Jodi Fosters daughter had type 1 and wore a watch with her bg on it. I think we’re all ready for a DexWatch.

7

We use a Dexcom G4 and 4 different blood glucose testers. I was extremely cautious when we started with the G4. My son's previous HbA1c were 5.7 and 5.3 so we really were not aiming for an improvement on that side and I feared trusting the CGM would worsen the situation. That's why I decided to write my own programs to compare the CGM and BGTs data and I analyzed his first 8400 dexcom data points with around 700 data points from the BGTs Yes, that's a lot of testing, but he was used to that since he is extremely active and often had to test himself 10 times over 2 hours during tennis games. The result reassured me: in short BG tests were 108 mg/dl average, stdev 33 CGM was 107 mg/dl stdev 30. In the second phase we tested less and ended up with 107 mg/dl 34 on the CGM and 112 42 on the BG test, which was understandable because we while we made only 232 BG tests, we did more in situations of potential highs and lows. Other things we noticed was that there was some variability in the performance of sensors, possibly because or different sensors/locations/insertion trauma level but on the whole, it averaged. Blood testers give complete outliers now and then. One of our accucheck compact plus once gave 300 mg/dl, while our Glucomen was giving 140 mg/dl and an accucheck nano was giving 169 md/dl. Excluding those outliers, the biggest error we observed and double checked were around 20 mg/dl below 100 and around 40 mg/dl in the 150 mg/dl plus range. And this is unusual, maybe 1/10 checks. Not very different in fact than some of the initial double calibrations which we do on two different BG testers and that gave 105 and 140. We did get a 70 mg/dl CGM-BGT difference once, last week, but that was because the kid decided to calibrate when his BG was rising fast. He got roughly the same error in the other direction at the next calibration (also a non optimal calibration anyway) and the situation corrected itself in the evening. We restart sensors as well (third week on the current one) and haven't noticed any real difference (the sensor might be consistently a bit below BG or a bit higher than BG, but not drastically). This may be due to the fact that, we only calibrate when we are 100% sure we have been and will be stable for a while and when we are in physiological ranges. And, as you said, if we can push 4-6 calibrations quickly, we do it. Lastly, I am a typical number crunching guy (MD by training, but worked in IT all my life) and, while number crunching is very comforting because it helps understand, makes you feel useful, etc... I wouldn't trust single events - my certainty threshold is around 30 events, probably because I never quite understood the profound nature of Poisson's law - especially with BG testers: there are so many possible causes of extreme results. The Dexcom, as you know, simply masks or smoothes its outliers... And lastly, in addition to potential errors, never forget the physiological time delayed correlation: a few weeks ago, during a side change in a tennis match, after a hard game, BGT was giving 95, CGM was giving 100, the kid got up and served four double faults. 10 mins _later_, the CGM was beeping like hell at 50 but my son had already recovered from the dextro he had taken.

832-calerror.PNG (10.5 KB) 833-restart.PNG (34.6 KB)
8

Hi Pierre. Thanks for that - it would be really interesting to get the internal information off the receiver for that. I wrote a util to dump records from the internal dexcom tables (table 3 - raw sensor data, table 4 - calibrated EGV data, and table 5 - calibration information). If you match radio data with EGV data, you can see the use of the calibration information, and the time-based compensation is also evident.

http://www.wingate.com/downloads/utils/dexcom_reader.zip

As for meter accuracy. Yes, it's a real problem. The first thing I did after the 18.2 reading was double check, and that was slightly higher. Different drop of blood etc, so I believed the 18.2. It had been a lot longer since entering a calibration value than we'd normally leave it, and in fact it had been asking for a calibration value for a few hours.

On the topic of meter accuracy, one of my other main projects over the last year has been analysis and testing of a range of SMBG devices. New Zealand went to a sole-supply agreement with i-Sens, so now all state funded meters are the same brand. There are issues a lot of people are seeing. I even hired out the university thermodynamics lab environment chamber to do finger stick testing between 10deg and 35 deg C. Something the manufacturers don't do, and none of the clinical trials on meter accuracy are performed outside of clinical environment (about 23 deg). In fact the ISO standard (15197) stipulates that all testing should be undertaken at 23 deg +/- 5 deg C. This I believe is a mistake.

9

Could resist recrunching some numbers on the post restart days and your analysis is definitely correct. Low impact in my case (apparently -5 mg/dl on average) but could indeed have a much bigger impact if BG values are higher and sensor response isn't linear in that range. (sorry for replying to myself, but couldn't recrunch fast enough to edit original post)

10

also - my avatar photo if you look at it is the result of another range of testing I did. When we were on MDI, and trying to dose down to 0.1U increments, we came into frequent issues with the accuracy of the printed scale on the BD 0.3ml syringes. Often got about 0.4U more than true amount if you went based on the scale, which for a dose of 2.1U and ISF of over 30mmol/l/U (540 mg/dl/U), is not acceptable. I got this escalated through BD once I sent them that photo, and things improved. Now on pump so it's no longer an issue for us.

11

Great evaluation. I, as you stated, use mine for an average of 3-4 weeks since I could not afford them on a weekly basis. I have noticed difference on the start of a new "session" and just watch closely. But now I have a better way, thanks! Also, flexifix tape is one of my best friends.

12

Except due to carpal tunnel issues aggravated by my diabetes, I can't wear watches. :(

13

Adrien:

How do I get involved with this project. Would like to add my idea into this mix:

Propose using the data from the sensor, pump and meter to aide patients/health care teams to improve glucose control and understanding of basal, bolus of a patient.

Please tell me where I can send a short specification of what I'm interested in

14

That is super interesting to know Adrien, thanks!

I guess it doesn't hurt that I calibrate 8-10 times a day, then!

(I basically calibrate every time I test)

I tried calibrating 2-3 times/day for the first couple months, and after that I just calibrated every time I tested... and saw no difference :-)

15

Hi, I'd suggest going to tidepool.org and contact them. Or to the CGM in the cloud facebook group that I linked to.

There are people working on those aspects you listed. Those are the same goals we pretty much all have.

16

This is great information and explains a lot. Thank you.

17

Thanks for the link to the exe Adrien. Seems to work fin on my systems. Also had a look at your python code as well. Will have a more in-depth look when the kid's exams are over (T1D being an additional stress here, results are random when he is in hypo). BTW, speaking of school exams, this is one of the reasons that makes communication with a smartphone a so-so idea for me. Kids aren't allowed smartphones during exams, but the "dumb" dexcom receiver will be ok. The other reason is that the smartphone will frequently be drained by clash of clans (or whatever is trendy at any given moment) abuse. Lastly, if you need additional data sets, let me know. Just received a few wixels in the post and will also be looking at that a bit.

18

Hi Pierre.

Programming that wixel can be challenging to get all the myriad of RF parameters working. I spent a lot of time on it, and currently it receives as well as the dexcom receiver. Let me know if you get stuck or need settings / wixel code.

19

Thanks for the offer. I am almost sure I will ultimately end up using your code as it will be, without any doubt, better than mine ;-). But at this point, I will experiment a bit. The fun is also in the process. I am not going for the in-the-cloud option for several reasons: the kid is able to handle himself quite well, having worked all my life in IT security I am quite worried about putting tons of stuff in the cloud in a hurry (I can see the moment when google will start pushing endocrinologist ads when it catches your BG control is sub-optimal, when insurance companies tell you that your BG control may be OK now but was poor five years ago or when someone somehow corrupts your data on purpose...). I think I'll go for something a dumb local UDP broadcaster and UDP clients displaying latest values and curves on my home network. But that's mostly because of the house topology, the number of devices hooked on my home network and my work sleep habits.

20

Always an option to host your own server (in your house). UDP isn't too bad on local wired network but I'm not sure about over Wifi. Something TCP-based would be more reliable and the sender can know if the data got sent as well. Unless you build some of TCP over UDP (like retry/ack mechanism).