Thursday, November 27, 2014

Looking at the Libre raw data.

Curiosity killed the cat. I hope it doesn't kill me. The Libre sensor data can be read by (almost) any NFC reader including, somewhat conveniently, the one that had been sitting completely useless in my Galaxy Note 2.

Reading the tag from time to time has led to some insight about its content. It's quite clear that the sensor running time in minutes is stored as a word at 013C and 013D. Some large zones don't change from sensor to sensor. And some data is definitely stored and updated in 6 bytes long records.

Here's a dump from tonight, with some correlation values as exported by the receiver. Blue circles on the right highlight the 15 minutes spaced values that the reader uses to build its curves. The green circles highlight spot checks values displayed by the reader (in some cases, on a T1D user varying quickly, the spot values do not even fit in the average values - maybe a topic for another post). Left hex panel is approximately 14 mins later than right hex panel. Lots of things have changed at the top, possibly the two minutes internal checks. One neat 5 bytes record has changed below. And the timer has moved as expected. Lots of nibble shifts as well it seems.


Any insight you want to share? Do not hesitate contacting me in private. I've made the raw data available on github. I have no doubt that if you know what a nibble is and are interested, you will find it.


Tuesday, November 25, 2014

Abbott Freestyle Libre - Dexcom G4 - sensor wire image

A few shots



Here's a quick shot of the sensor wires. The 9 days old Dexcom sensor is on the left, the Libre Freestyle is on the right. The Libre sensor is shorter, wider, flatter and more rigid. While the Libre insertion is painless, I am not surprised Max could feel it the next day. I am wearing one now (I am not a type 1 diabetic) and I can definitely feel it as well. (magnification 20x - Nikon field microscope)




The Libre sensor wound with the sensor seat impression. Extremely small and clean looking. Remains of adhesive on the right. Much better than the Dexcom's wound and no sign of the small conical tissue growth we often see if we leave a Dexcom sensor 14 days. No trace of allergy or irritation to the adhesive. The sensor was still sticking firmly after 14 days. (100 mm macro shot - Canon 5D MKII)


A 100 mm macro shot of both sensors. The indentation on the Libre sensor was caused by my slightly rough handling.









The sensor adhesion and scarring is definitely a big win for the Libre. The adhesion is certainly helped by the flatter form factor and, consequently, I believe the fact that the sensor doesn't move and doesn't seem to allow water in keeps the wound very neat. It may seem a very minor thing, but since we are going to inflict small wounds on our kids for the foreseeable future, they might as well be very clean.

 Electronics

The expected Texas Instrument chip. The board is powered by a standard Varta V377 watch battery. Tension after 300 reads was 1.57 volts and the battery was apparently still capable of delivering 33 mili-amps (not sure if that last measurement was representative of anything)
FRL 152 H - maybe not similar enough but looks quite close


Saturday, November 22, 2014

Abbott Libre vs Dexcom G4 (non AP) - Quick Update


Quick update

The Dexcom site fell out during today's tennis practice, despite a couple of "rescue" tegaderms. The Libre is still hanging on but did also get its additional tegaderm after seven days as the upper edge was beginning to peel a bit. No irritation whatsoever at the Libre site, our usual tolerable slight itch at the Dexcom site after a week (the Dexcom sits on a tegaderm since Max is a bit reactive to the Dexcom's adhesive).

It might be a few days before I have the time to analyze the data and summarize my thoughts. Meanwhile, here is what both sensors thought of the week.


At first sight, there seems to be way to many lows, but this isn't as bad as it seems. The Libre has a minimum low treshold of 70, the Dexcom G4 is set at 60. Some of our lows are sport induced, others are Lantus peak related. None of them were surprise or severe lows. Hanging for long periods around in the 68 to 72 range at the beginning of the night will automatically trigger long periods of lows in the Libre and none with the Dex. On the other hand, the Dexcom will take a long time to recover from a low values.

According to the Libre, the worst period is around midnight, according to the Dex it is around 13:00. It's not incorrect, except for the fact that we want to be around 70mg/dl at 00:00 since we almost always start climb after 2:00. The noon period is a bit more problematic, and not intended: the school schedules introduces hard constraints on our ability to pre-bolus and time the noon meals.

As expected after the first day, the Libre kept running a bit higher (+13 md/dl), on average, than the Dex. We had previously noticed that the Dexcom was also running below our BG meter by 6-7 mg/dl over long periods.

I'll get back with the full analysis some time next week. Meanwhile, have a nice week-end!

Friday, November 21, 2014

Clarke Revisited

Revisiting the display of the Clarke grid


The Clarke error grid was defined in 1987. Initially developed to evaluate the accuracy of the BG meters in use at that time compared to reference values, it has become one of  the "gold standards" (with MARD) used to evaluate the performance of glucose measurement methods. Because it was initially defined from a clinical point of view, it may seem a bit arbitrary today: in the neighborhood of a reference value of 240 mg/dl and a measured value of 180 mg/dl, zone A, B and D are extremely close. In my opinion, the attribution of a zone to any value pair in that area should be taken with a grain of salt.

It's full of stars (or numbers)!

For the next 20 years, from 1987 to 2007, diabetics were doing a few checks every day and only rarely had reference values at their disposal - maybe a few laboratory checks now and then. Researchers in clinical studies had more but for shorter periods of time. A quick black and white Clarke grid was all that was needed for a visual analysis of their test. With the arrival of CGMs, we are now literally drowning in data. And too much data usually means visualization trouble. Take a look at a conventional black and white Clarke error grid when it is used to compare CGM data vs meter calibration points. Somewhat useful, but a bit crowded. We can see that the CGM performs relatively well compared to the blood glucose meter, and that's it.


 Adding a bit of color and transparency makes the grid much easier to interpret and provides interesting additional information. We can now see the frequency of calibrations in certain zones. And, assuming one calibrates at fairly representative moments of the day, on can almost visualize the average glucose values for the range of dates considered (the actual calculated average is 108 mg/dl). As an added bonus, the use of colors has allowed me to identify minor bugs in a couple of "standard" Clarke grid implementations. Since the grid background code is independent from the individual data pair plotting and zone attribution routine, any mis-attributed data point will appear with the wrong color for the zone.

Here's an example of such a slightly buggy plot using a "reference algorithm"


As you can see, some of the data pairs classified as being in zone A should actually be counted as in zone B at the top end, and some of the data pairs classified as in zone B should actually be in zone A. The error comes from a single variable comparison done in the wrong order. [programmer's rant - it seems that the more competent developer are - or think they are - the more they use extremely short variable names so their code looks neat and tight. Longish more explicit names don't look as cool, but they are easier to keep track of]

And here is the visual representation I am now using.


Does it even matter?

For the typical user, keeping track of his calibration accuracy is probably overkill. However, visualizing his calibrations as a whole can help develop an optimal calibration strategy and assess the progress made as the strategy is implemented. CGM accuracy will be an essential parameter to track, in my opinion, when an artificial pancreas becomes available and if it still relies on a user calibrated CGM input.

Biases, biases


And I would be remiss not to add the usual caveat: all these results are likely to be biased. Some bias coming into play here are:
  • BG meter accuracy: I have a good understanding of our BG meter accuracy, but some of them are somewhat unreliable and/or used improperly.
  • by using calibration points vs pre-calibration value I am, in theory, biasing the result against the CGM since it could be expected that it is when it needs a calibration that it is not performing optimaly.
  • conversely, by using a calibration strategy that avoids tricky situations (fast changes, very low values, etc...) I am biasing the results in favor of the CGM.
Well, those biases are part of our lives, and there isn't much we can do to avoid them. We just need to remember that they exist.

Wednesday, November 19, 2014

Some general thoughts on data analysis, bugs and CGM based decision taking.

Looking at CGM data


When both the CGM and the BG meter show 100 mg/dl, it's hard not to think this is a wonderful event that demonstrates how good the CGM is. This perfect match will remain in our memory and color our perception while we'll tend to forget the mismatches or, worse, underestimate some of them and overestimate others. Our brains haven't evolved an always on percentage calculator and trend extrapolator.

MARD


That's why computers are useful when it comes to put some objectivity in accuracy assessments. But computers also have issues. We write the code and have a tendency to insert nasty bugs in that code.

This is also why I tend to be extremely verbose and slow when I examine data. (in this case calibration values vs CGM reported data - I also use a similar analysis for BG meter data not used as calibration points)

Here is, for example, how I keep track of the current performance of our CGM - some of the output of my programs is given below, slightly edited for brevity (comments are in bold)

Period Length: 13 days, starting 2014-10-31 00:02:41 and ending 2014-11-13 07:06:59

Time and date issues are extremely important: meter and CGM clocks drift, use different date formats and generally ignore things such as winter/summer time. I keep track of the time deltas between the different devices and adjust the data accordingly before processing it.

Calibration values [72, 86, .., 128, 130]
Measured values [49, 87, .., 148, 148]

It's always good to have some visual confirmation of the data you are working with.

Number of Calibrations: 33 excluding double start-up calibs and calibs after loss of signal or error

Obviously, if you are using a CGM that requires calibrations, the start-up calibrations should be ignored and so should double calibrations entered very close to one another. Entering five calibrations in one hour and then none for twelve hours is likely to introduce a significant bias in the data.

Number of Calibrations per day : 2.54 on average
Average Absolute Delta         : -4.48 mg/dL - objective
General Trend at calib time    : 1.26 mg/dL - speculative
Average Delta debiased 5 min   : -3.22 mg/dL - speculative
Average Delta debiased 10 mins : -1.96 mg/dL - speculative

In the calculation part, we see that the CGM is reporting, on average, values that are 4.48 mg/dL BELOW the meter values. That's interesting, but this is not the whole story. As we all know, CGMs are delayed therefore I calculate a trend at the moment of calibration and project what the results could have been if no delay was taken into account. You see that the CGM would have been "more correct" if the trend had continued. Note: the maniacal observer will notice that the average projected value and the rate of change don't strictly match. There are two reasons for this, the first one is that we don't really bother checking if the calibration occurred 4 mins 59 sec or 1 sec before the next value; the second one is that we can't rely on the corrected post calibration value to estimate an error.

Average % Error vs BG          : 15.35 % - objective

That would be the MARD vs meter we are currently running at. Decent, but not great for that sensor.

Average Rate of Change         : 0.12 mg/dL min (linear)

That's a check to make sure we aren't calibrating when rising or falling too fast.

No calibration in low range

0% of calibrations in the < 60 range. This is intentional, calibrating in that range is playing the lottery.

High Range Calib Percentage    : 6.06 % - above 160 mg/dL
Average % error in high calib  : 6.11 % - above 160 mg/dL

Not very significant, we have very few calib in that range

Average Delta in high calib    : -11.50 mg/dL - above 160 mg/dL
Norm Range Calib Percentage    : 93.94 % - between 60 and 160 mg/dL
Average % error in norm calib  : 15.94 % - between 60 and 160 mg/dL
Average Delta in norm calib    : -4.03 mg/dL - between 60 and 160 mg/dL

So now that we have our MARD, what about a CLARKE error grid?

CLARKE


Errors aren't created equal. Some are really insignificant and don't matter from a clinical point of view. But other errors can kill you. The Clarke error grid is a somewhat arbitrary look at the data that takes that human risk factor into account, based on what the clinical consequences of the error could be. Roughly speaking, falling in zone A is excellent (this is ideally where you would want the CGM that controls an artificial pancreas to be at all times). Zone B is acceptable. Zone C and D could get you into trouble if you based a treatment decision on it and will certainly lead to sub-optimal adjustments. A decision taken in zone E has a very high probability to lead to an emergency room visit.

The Clarke grid analysis of CGM vs meter data is a bit tricky to implement, that is why before running it on my data, I always check that my program still works with a test validation run with a test data set. This is the result of such a test. The use of colors helps spotting an eventual bug.
CLARKE Validation
And here is the result on our actual two weeks data set.

CLARKE - actual data
As you can see, the data provided by the CGM falls squarely in that A and B zones of the grid. In other words, if I had relied exclusively on CGM data to adjust my son's treatment, I would have been alright.

But what about the recommendation not to take any decisions based only on CGM data? That's a tricky question, and while I certainly wouldn't recommend it in general, I have to confess that I do correct based on CGM data alone at times. But you can't do this blindly. You need
  • to be sure of the reliability of your BG meter (I run separate analysis on that part, maybe the topic of a later blog  post)
  • to understand the physiological climate you are in (stress, post-exercise, dawn phenomenon)
  • to be able to analyze and understand your CGM data extensively. (most of the user submitted data files I have analyzed do not fit nicely in the A and B zones)
  • to take clinical symptoms into account. You are treating a patient, not fixing numbers.
  • to be confident that you will be able to react in case something goes wrong.




Saturday, November 15, 2014

Libre vs Dexcom (non AP) - day 4


Quick update (Now 15, 2014)

 
Click to enlarge

Just a quick update, on a day with two sport sessions.

1:00 - night started a bit low, correction caught by the Libre about 15 mins before the Dex
4:00 - trending low, new correction caught by the Libre about 10-15 mins before the Dex
8:30 - calibration in perfectly stable conditions - Dex matches BG meter a bit better
9:30 - pre tennis carb loading - Libre catches rise 10 mins earlier than the Dex
10:00 to 11:00 tennis - Libre doesn't go as low as Dex and seems to be correct compared to symptoms/feelings. Catches up post-training rise 30 mins before Dex which seems to have trouble recovering from lows.
12:00 to 16:00 - lowish afternoon after intensely aerobic morning training.
17:00 - carb loading for evening tennis - caught by Libre about 20 mins before Dex. - 1U Novo to compensate for Lantus extinction.
18:00 to 19:30 - tennis, not as aerobic as first sessions, outside Lantus acting hours.
20:00 - Dex calib in stable conditions for both devices. Libre is spot on. Dex way off.

Just looking at the behavior in general at this point, no definite answer on accuracy (relative to BG meter) yet.

If you hit this post first, you might want to check the previous ones for the general context of the comparison.


Friday, November 14, 2014

Another day - another Dexcom G4 (non AP) vs FreeStyle Libre chart

We are now in the third day of the comparison test. In theory, both sensors have now had the time to settle and should be performing without hiccups. Let's have a look. This time, I used a pure scatter plot to make the different sampling frequencies visible.

The night

We increased our Lantus by 1U in an attempt to master our dawn phenomenon. For some reason, it worked exceptionally well. Too well compared to the correction doses we normally have to use. There was actually less physical activity than usual during the previous day. This is the reason why I am a bit concerned to use a pump with increased insulin delivery to counter the dawn phenomenon (see previous posts).

The Dexcom continued to oscillate a bit (mild compressions?), fortunately without hitting the 55 mg/dL that triggers alarms, regardless of the settings. The Libre happily stayed in an excellent range, between 100 mg/dL and 80 mg/dL. I am sure the higher actual sample frequency (every 2 mins in theory) smoothed in one measure every 15 minutes helps with the oscillations.

The morning

Which one was correct? According to the clinical symptoms during the night and the meter test at 7:00, the Libre was correct. The morning calibration was clearly above the Dexcom data. But, as you can see, we have lost the period from 4:00 to 9:00 because Max forgot to pick up his third device and scan himself. Since the Libre only stores 8 hours of retrospective data and we could only scan Max when he came back from school at 17:10, we lost everything between 4:00 and 9:10. Win for the Dexcom here.

10:00 to  12:00 was PE class. At that point, the Dexcom went out of range. But as the Libre receiver was quietly resting on a shelf at the house, the sensor was still recording and we can clearly see the effect of the two sports drink Max took on his own to maintain his blood glucose. Win for the Libre.

The afternoon

We then have a small meal spike at 13:30 and a relatively stable, if low, afternoon. The Dexcom alarmed several times during that period, but Max did not take any drastic action as he wasn't feeling as low as the Dex suggested. I would again rate the afternoon as a win for the Libre.

Back at the house at 17:10, we scanned and decided to take a few grams of carbs (6-7grs) to raise the BG a bit. We know by experience that after 16:30 the Lantus has mostly run its course after 22 hours (note - this varies from person to person) and we correct very sparingly. The Libre picked up the additional carbs almost immediately and rose sooner and more sharply than the Dexcom. Another win for the Libre here.

A miracle

Then, at 19:10, a miracle happened: the Libre,  the Dexcom and the meter all agreed, within 2 mg/dL.
Max started eating and the Libre picked up almost immediately while, for some reason, the Dexcom continued to fall for a while.

Additional notes
  1. I have previously established that the Dexcom under-estimated our values relative to the BG meter, this seems to also be the opinion of the Libre.
  2. I am aware that this was a lowish day and that the dose of Lantus that keeps the dawn phenomenon under control is sub-optimal for the rest of the day. Compromises, compromises...

Stay tuned for the next episode, and have a good diabetes day, if there is such a thing.







Thursday, November 13, 2014

Dexcom G4 (non AP) vs Freestyle Libre vs Glucose Meter

The test has begun



Our small test has started. A couple of days ago, Maxime volunteered to have two sensors installed. His usual Dexcom G4 and our newly received Abbott Freestyle Libre. I would have liked to put both sensors at the back of the left arm since the back of the arm is the only recommended location for the Abbott Freestyle Libre. Unfortunately, as you can see in the picture below, the previous Dexcom sensor had left Max with a small irritation that I did not want to cover before it was fully healed. The Freestyle went where it was supposed to go. The Dex went in a location we had used in the past with great success (BG meter relative MARD of 12.9% for the two weeks the sensor ran there).


The Libre insertion was totally painless as other users have already reported. Abbott has definitely nailed (hmmm) the insertion process. Once once you have inserted the sensor in the applicator, a spring is primed. You simply place the applicator on the site and press. At some pressure point, the spring is freed and the sensor is both inserted and glued to the skin. I was a bit unsure about how hard I should push and did not want to hurt Max so I fiddled a bit. The trigger caught both of us by surprise, and that was it: sensor in and glued. This compares very favorably with the Dexcom insertion process where you have to manipulate a device that looks a bit like a torture instrument that proudly displays a very long visible needle that you should stick carefully in place before counter-intuitively holding and pushing at the same time before pulling and holding to withdraw the needle. The Dexcom insertion process was however smooth, very little pain and no bleeding. 

I should however mention that during next day's tennis session, Max complained that he was feeling the sensor in his arm. That had never happened with the Dexcom sensor. 

Start-up Sequence and day 1

Note: you may want to download the full chart below and keep it open if you want to look at the first day results in details. It's a big chart because there are a lot of things I wanted to track and also because I like big charts... ;-)


The Freestyle Libre becomes available an hour after it has been inserted. The reader displays a nice precise countdown and tell you how many minutes are left before you can take your first reading (another plus compared to the vague Dexcom green pie). That's with some trepidation that we did our first scan. It was instantaneous and reported a slightly worrying 60 md/dL. (orange dots are spot readings taken with the Freestyle Libre) We immediately double checked with a meter blood test (white stars) and the result was a very good, and clinically expected, high 80s mg/dL reading. There was a small downtrend to 50 mg/dL until 21:00, which we measured to be in the 70 mg/dL range. The Libre was reporting values about 20/25 mg/dL lower than the blood meter and did so consistently until 7:00.

We calibrated the Dex around 90 mg/dL, in a stable situation and it started humming along nicely. Then, something that we had never seen before happened: the Dex started climbing at full speed, reaching 150 mg/dL a bit before midnight. I had previously seen the Dex fall quickly because of a compression event. I had seen it drift slowly away from the real value. But I had never seen hit shoot for the sky after an insertion. Midnight triggered a recalibration (red dot + white star). We were still in the 90s and the Libre was still too low by about 25 mg/dL. Then, after less than an hour, the Dex's horn started to sound the alert for a severe LOW. That, of course, wasn't the case but triggered an additional blood check and calibration. 

During the next 5 hours, the Dex started to oscillate around a slowly rising line. The Libre was also rising and oscillating, not necessarily in sync with the Dex... I can't imagine how a new CGM user would have reacted...

I assumed this was reflecting the typical slow increase we have been fighting for a while and decided to ignore any fast rise or fast fall alerts the Dex could give. Knowing your current patterns and the clinical symptoms of lows is, in my opinion, essential. Don't fall into the "blind faith in technology" trap! 

5:00 led to our now traditional early morning correction dose (2U Novorapid), yet another calibration and finally, at 7:00, Alleluja! The Meter, the Dex and the Libre (sounds a bit like the title of a Sergio Leone movie) finally agreed. 

Max went off to school where, at 10:00, he preemptively over-corrected a possible low, went a bit high pre-meal at noon without adjusting his insulin dose. He came back home at 13:00 at which point we had the following surprise (the meter is still on summer time, that has been corrected for the chart).


Now, I have to confess something: whenever I see someone who posts a set of matching numbers and starts raving about how perfect everything is, I usually exhale deeply and starts thinking about the widespread innumeracy that plagues this world. But even rationally knowing that this does not meant much in itself, I was floored and thought "woaw!". The Dex was trailing, but it can be argued that it would have caught up within 15 minutes or so. Keeping in mind that delay, I would not have taken a wrong decision if I had relied on it and that is what matters.

We corrected immediately with 6U of Novorapid and a 30 minutes wait before the meal. A few interesting things happened, but they need further investigation.
  • the Libre spot measures continued to climb aggressively. Looking at the averaged data in details it is borderline strange but too long to discuss here.
  • the Libre went AWOL during the steep fall - it kept telling us "No glucose data available, check again in ten minutes" The Dex kept tracking the fall.
  • when the Libre recovered, the Dex went into "???" mood for about 25 minutes around 14:00
Around 15:00 we began our carb loading for the tennis practice that started at 16:00 and lasted to 17:00. The Libre tracked the rise before the Dex did. But the Dex tracked the fall during practice before the Libre. 

Between 17:00 and 18:00, we saw our usual post training increase (could be caused by either a disconnect between the adrenalin+cortisol release triggered by the exercise but irrelevant because the exercise had ceased, or excessive "re-carbing"(doubtful in this case) or also the lowest Lantus on board point of the day. 

The evening calibration ended up closer to the Libre than the Dex and, from that point, both the Dex and the Libre essentially agreed 100%

We had a mild symptomatic low between 21:00 and 22:00. We had added 1U to our usual evening meal dose because of the high pre-meal glucose level and we probably overshot because the post-exercise increase was a "fake" increase, caused by the mobilization of existing glucose stores rather than by an excessive input. Finally, we saw an early rise that we corrected around 3:00 AM when it reached 150 mg/dL.

That was indeed a busy first day! Stay tuned. 

PS: typos, non intelligible sentences, other errors, do not hesitate to shoot. 

Monday, November 10, 2014

Dexcom's conference call and some disturbing trends.



Dexcom is currently the clear leader in Continuous Glucose Monitoring. I believe that CGM, as it is commonly abbreviated, is an essential tool in diabetes management. Within a few years, I am willing to bet they will be seen as the cornerstone of correct diabetes management, possibly replacing blood testers, just as blood testers replaced home urine test sets.

Unless, of course, some breakthrough technology becomes widely available... While the artificial pancreas currently in development will rely on CGM, long term implantable sensors or non-invasive sensors that actually work could disrupt the landscape. And a fully functional encapsulated ß-cells implant would obliterate it, much to the delight of Type 1 diabetics.

That being said, assuming we don't see any of those drastic changes, Dexcom is likely to remain a significant player in the field for a few years. That's why it is interesting to pay attention to where they are going.

Dexcom talks

Dexcom is clearly trying to have its cake and eat it. On one hand, they would like to have as much control as it is possible on what is done with their products and its data output. Being a Class III medical device has its advantages: "Prior to doing so however we would want assure ourselves that any such third-party has a robust quality system and regulatory resources required by FDA to develop and maintain a Class 3 medical system." But they would also love to grow their market tremendously, using the opposite argument: "We have always considered CGM to be a consumer product, it has requirement of a medical device, but the utility of it and its power as a consumer tool." Yes indeed, wouldn't it be nice if everyone was constantly monitoring his glucose levels and sensors sold as razor blades?

That's the behavior of a fairly typical business in a capitalist society. Capitalism drives innovation. We need innovation therefore we need to live with the drawbacks...

How is your licensed data flux doing, Sir?

But we can also see the hints of a disturbing trend.

"When it comes to retrospective display of our CGM data we have announced open architecture policy whereby we will allow third-party software developers, companies such as Tidepool, Diasend and others, to display retrospective data from our G4 PLATINUM system within their data aggregation platforms."

While "open architecture policy" sounds very nice, there is quite a bit of discrete semantic drift here. Note that your blood sugar levels aren't really yours anymore: they have become "retrospective data from our G4 PLATINUM system". Dexcom is not even the worst company on the data access issue: they still allow you, to some extent, and for now, to choose where you'll look at and analyze your data. But the blood glucose levels that you used to consider yours, to be shared with your doctor, is slowly becoming a licensable data flux. 

Repeat it often enough and it will start sounding natural.

We know a ton of things about you, would you like to buy that, Sir?

This, almost casually, came up in the discussion about the "Share", their remote monitoring platform.

"And we have learned a whole bunch in a very short period of time about our patients behaviors and patterns and their glucose reading."

Again, this sounds very positive, very smooth and innocuous. But let's think about it for a minute, step by step.

Glucose reading: that is, I believe, the less controversial part of the statement. After all, Dexcom is in the glucose reading business. Sending your data to them (to look at) seems logical. But do HIV test manufacturers need to know if you are HIV positive? Does Dexcom need to know how you are doing in terms of diabetes control? From what they say, they apparently had a very extensive look at the data of their users. It would be interesting to know who has access to that data (server admins, contractors, etc) and how it is controlled.

Patient behaviors and patterns: this one is, in my opinion, a scorcher! Why would Dexcom analyze patients behaviors and patterns. Look at the graph below

Can you spot when my son took his bath? Yes, right before 7 PM, as shown by the loss of connection with the Dexcom receiver. Is Dexcom really the ideal partner with whom you'd like to share your behaviors and patterns? That's none of their business!

But of course, it is!

The issue, you see, is what we commonly call Big Data. Companies would love to know as much as they can about your life and behavior patterns. That's the Google and Facebook business model. They know a lot about us, we kind of know that they know a lot, even if few of us have a precise idea of what "a lot" means. Our profile is the product and, in exchange, we get to use nice free services. That deal is a bit controversial and often attracts a lot of attention.

In the diabetic patient case and in health care in general, companies are jumping on the trend and  would love to sell you analysis software or even better, simply the analysis itself. They would love you to subscribe to a service that gives you "meaningful advice based on large scale pattern analysis" and all that kind of stuff. That's where a part of Dexcom's future business lies. (but you'll still get to pay for your receiver, emitter, share and sensors... )

We still have a choice.

Today, that kind of service is still "opt-in". You can still look at your data in the privacy of your home, choose when and with whom you will share it. However, you can be sure that in the next few years, you'll have to defend the right to "opt-out". Security and confidentiality reasons will justify locking your own data out of your direct reach. Convenience will pressure you into hosting it with commercial providers. Incompatibilities and data sharing contracts with private insurers will prevent you from switching vendors and lock you into what may have become a sub-optimal solution...

But this remaining freedom hangs to a single fragile thread: the ability to have full access to our data. Once we have lost that, we will have stopped being patients and become licensable data flux.








Friday, November 7, 2014

Abbot Libre vs Dexcom G4 - pre comparison pictures.

The FreeStyle Libre has finally landed. 


The comparison should start this week-end. At this point, the plan is

  • to run the sensors side by side for (hopefully) 14 days on Max's arm and do a strict comparison of the results. I am of course interested in the general accuracy of the devices but also by their reactivity to rapidly changing conditions. Since Dexcom hasn't made its new AP G4 algorithm firmware upgrade available to us Europeans, the comparison will be vs the standard G4.
  • to run the sensor on myself to have a look at the communication side of things. Now, RFID is not exactly in my area of expertise, wonders should not be expected.

Menawhile, in the great "unboxing" Internet traditio, a couple of pictures.

Bottom: reader - on top two sensors


 
Sensor insertion kit.



The reader, charger (550ma) and cable. Pebble for scale.

First setup screen: a decent touchsreen, much better visually than in
this macro shot
Second setup screen
Range definition: bottom limit at 70 mg/dl - max limit not checked
Startup Screen
Overall, a very nice impression. The display and touchscreen feels quite modern compared to the Dexcom receiver. It's not possible to change units (France gets mg/dl - UK and Netherlands get mmol). It's not possible to change the language. The settings include a locked "professional" option.

And, of course, the receiver also acts as a blood strip tester. From a convenience and design point of view, this is very good indeed.



Thursday, November 6, 2014

Exercise in a LOW context

Warning: 


This is an exercise report. Not a recommendation!
Do not try to replicate anything described on this page!

Basic Data: boy 13y10m approx 164 cm 51 kgs - MDI - typically 5 N 6 N 5 N 16 L

General context: we have been fighting the dawn phenomenon lately. We can control it with higher Lantus doses, but then are hit by early nights lows and a general downtrend during the day. We have also noticed that days with a decent amount of physical exercise led to good nights without increasing the Lantus dose.

The day's context: (CGM trace below)

  • 4:30 AM climb to 130 mg/dl (CGM) in the night. 150 mg/dl at the BG tester. Corrective action based on previous nights patterns: 3U Novo. Recalibrate. 
  • 7:00 AM Wake up at 125 mg/dl (CGM) 101 mg/dl (BG). Usual morning calibration. In both cases, the Dex was probably running a bit late but was in line with the trend. 3U Novo at 7:15, reduced from the usual 5 because of the stacking with the 4:30AM dose. 
  • 9:90 AM Small spike meal followed by a low. Hindsight: could probably have reduced the 7:15 Novo to 2. 
  • 11:00 AM Correction spike, better safe than sorry. No overshoot: good.
  • 12:00 PM Standard Meal - Novo 5U 
  • 15:00 PM Again small low 3 hours later - there is a steep slope on the way home.
  • 15:45 PM Correction approximately 15 gr of carbs, low but very little insulin on board at that time.
  • 15:50 PM CGM at 69 mg/dl in a steep climb, BG confirms steep  rise at 95 mg/dl
  • 16:15 PM Exercise started.



Exercise: threadmill - 4 km total distance - interval training by 250m segments alternatively at 8 km/h and 16 km/h. Last segment of 500M at 16 km/h. Couple of minutes of pause after 15 mins to drink and check general feeling. Exercise duration excluding pause and warm up: about 20 minutes, cooldown 20 mins slow walk. Polar HRM recording below.

Post Exercise: trending low for about 5 hours, although not as badly as the CGM indicates (77 mg/dl BG vs 60 mg/dl CGM at 18:34 for example). Steady at 83 mg/dl CGM since 10 PM - no calibration entered in low as calibrating the Dexcom below 80 mg/dl has proven to be a lottery.

Summary: obviously not something to try at home if one is uncomfortable with lows and unable to monitor constantly for the rest of the day and possibly night. The carb loading for the exercise seemed to have been insufficient and a glucose debt + increased insulin sensitivity follows. Note: we have previously seen highs of 180 mg/dl with low carb doses (5 grs) when IOB was insufficient. Critical hour to watch 3:00 AM during the following night as purely aerobic exercises delayed lows usually appear after 11 hours (in our case, may vary greatly from individual to individual).

Post Mortem: (added 11/7/2014)  well, the plan failed on two accounts. Despite the exercise, we had our typical increase. But to make it worse, this is a night the Dexcom did not want to cooperate, possibly because of a mild compression. Or just because it did not want to. BG started to raise at the usual time, but not as steeply. In fact, they were rising as a 3:30 AM BG blood test showed. 3U novo were injected, and life resumed.

Feedback: thanks to the two readers that contacted me directly with the suggestion that a pump would probably solve the issue. I do agree that this would probably be the best course of action but there are two factors that we have to take into account.
  • while Max is doing a great job at controlling is blood sugars, he isn't very careful with some of the hardware around him and is definitely not the most scrupulous adolescent.
  • that pattern isn't always present and its intensity varies a lot (corrections range is 1U to 5U). I wouldn't sleep more without a pump with a suspend function and a reliable CGM.
Thanks a lot for your feedback MGO and LT!

Tuesday, November 4, 2014

Local Installation of NightScout on Windows 7 and 8.1

I really like the NightScout CGM remote monitoring project. It has the potential to change, and has already changed, the lives of families with T1D kids. It's free, open source and actively developed. But when the gods of the Internet refuse to cooperate, it can be frustrating. Nightscout is a chain and every link has the potential to break. The uploader phone and cable, Internet connectivity to the database, access to the monitoring web site. We had such an incident this morning. Google browsing protection falsely flagged the sites hosted on Azure as malware. Bang, access denied, and a very alarming message to boot. For many families, the monitoring just stopped working.

 It doesn't have to be that way. Wouldn't it be nice to have a backup site? Well, nothing prevents you from adding a site to Heroku, Digital Ocean and other cloud providers. More instructions, more sign-ups, more passwords. Wouldn't it be even nicer to have a local backup site, on your own computer, that you can fire up instantly when you need it? Well, you can - and it is not difficult. Let's get started.

 1. Install node.js on your own computer 


Go to www.nodejs.org and download node.js - the web site will automatically offer a download link for your operating system. Install it, as you would install any other program.

2. open the node.js command prompt 


Go to the application menu. Right click on the item named "Node.js command prompt" and choose the "run as administrator option" (it is not absolutely mandatory to run as administrator, but it makes things easier at the last stage).


Keep that prompt open, we will soon need it.

3. install and download the cgm-remote monitor source code 


Create a folder for your local monitor by typing (for example)

mkdir c:\monitor-local 

 The folder can be anywhere, just keep its name and location in mind and adapt accordingly. Jump into the new folder by typing

cd \monitor-local

Now, we need the code for the server. Download the zip archive from Github - once it has been downloaded, open it and extract its content to the folder you have just created. You should see something like this in the folder, not the cgm-remote-monitor folder.

05-11-14  00:48    <DIR>          .
05-11-14  00:48    <DIR>          ..
05-11-14  00:48    <DIR>          'this
04-10-14  04:51                49 .bowerrc
04-10-14  04:51                33 .deployment
04-10-14  04:51               132 .gitignore
04-10-14  04:51               151 .travis.yml
05-11-14  00:48    <DIR>          a
04-10-14  04:51               273 app.json

4. prepare the node environment


 This is probably the only slightly difficult part. In order to run the server, we need a correct set of libraries. NPM - the node package manager will install them for us. In the console, type

npm 

You are likely to get the following error message

 Error: ENOENT. stat 'C:\Users\yourusername\AppData\Roaming\npm' 

Don't worry, it simply means a folder where NPM wants to work is missing. Let's create it. Type (you can simply copy and paste the path from the above error message)

mkdir 'C:\Users\yourusername\AppData\Roaming\npm' 

We are now ready to install all the libraries needed by the remote monitor. Make sure you are connected to the Internet and type

npm install 

You'll see cryptic lines go by and possibly a question about "Bower" to which you may respond either yes or no. At the end of the install, you should see something like this.

├── update-notifier@0.2.0 (semver-diff@0.1.0, string-length@0.1.2, latest-versio
n@0.2.0, configstore@0.3.1)
├── handlebars@2.0.0 (optimist@0.3.7, uglify-js@2.3.6)
├── inquirer@0.7.1 (figures@1.3.3, mute-stream@0.0.4, through@2.3.6, readline2@0
.1.0, lodash@2.4.1, rx@2.3.14, cli-color@0.3.2)
└── insight@0.4.3 (object-assign@1.0.0, async@0.9.0, chalk@0.5.1, os-name@1.0.1,
lodash.debounce@2.4.1, tough-cookie@0.12.1, configstore@0.3.1, inquirer@0.6.0)

c:>

5. configure the database 



Your server is now ready to run. It is only missing the mongo database configuration. Here you have two options, either use system variables or modify the database_configuration.json file. Type

notepad database_configuration.json 

You'll see this


 Edit the file so it contains your mongo connection strings - it should look like this


 Save the file.

6. run the server


Type

node server.js 

If you typed your connection strings correctly, your server should start and you will probably be prompted by the Windows Firewall - allow your application to access the Internet. Your should then see something like the text on the left part of the image below. Your server is connecting to mongo and serving the data. In order to test it, fire up a browser and type, as a url, either localhost:1337 or 127.0.01:1337 (these are equivalent ways to have the browser connect to the local computer) - your portal will show up. You are done, or almost...



7. making it easy


Stop the server with CTRL-C (in general, you can only run one single server on a single port). As it stands, you'll need to open a command shell, move to the correct folder and type node server.js every time you want to start it. Not very convenient... Lets improve that a bit.

If you look at the properties of the node.js command shell, you'll see this

node.js comes with a batch file that sets its environment. We'll modify this batch file a bit to better suit our needs. Type

cd "\Program Files\nodejs\" 
notepad nodevars.bat 

Notepad will open and show this

Edit the last line and add one line as shown below.

The first yellow line makes sure you start your server in the correct directory. The second line starts the server from that directory. Save the file. Now, right click on the node.js command prompt link and create a shortcut to it on your desktop.


Whenever you click on that shortcut, your local server will run. You could still improve this a bit in terms of convenience, for example by launching a browser automatically or adding the server as a service so it runs all the time. Good Luck

Update January 19, 2015: local installation tested with the 0.6 Dreamsicle release. Still works.

Saturday, November 1, 2014

October 2014 results.

If you had asked me, a few years ago, about the voluntary public sharing of health related data, I would have responded that complete secrecy was essential. This is, in fact, still how I feel about most conditions: no one should know that you have high blood pressure, a bad lipid profile or a sexually transmitted disease.

Type 1 Diabetes changed my perception. For two reasons:
  1. every friend or person you interact with will ultimately know that you have T1D anyway. This is sometimes a good thing: friends can keep an eye on you and remind you to treat a low you might not be aware of. Partners or opponents in sport will be aware that you might need a few minutes to check and/or correct your blood sugars. This is also a bad thing: your bank will overcharge your mortgage. Uneducated people will think you have an unhealthy life style. Uber-idiots might think you are contagious. Trying to hide your diabetes will lead to sub-optimal treatment: skipping injections, trying to drive through a severe low. Information will leak whether you want it or not.
  2. when Max was diagnosed, the only resources that I could think of were books. There are some very good ones - Ragnar Hanas Type 1 Diabetes in children, adolescent and young adults is a must have. I learned a lot from them but I learned a lot more by looking at what experienced diabetics were sharing on the internet: movies of their sensor or pump insertions, sharing of their data pre or post exercise, how they handle potentially dangerous situations in the most practical way, how they tackle the myriad of daily issues a T1D faces. Information helps.
This is why I now believe that sharing T1D data is useful and will share more of it in the coming months, including full training and exercise data.

So, putting my money where my mouth is, here's our October summary as seen by our Dexcom CGM and a small discussion of it. Max is almost 14 and on MDI therapy (Novorapid and Lantus)


Mean glucose was reported to be 98: that's quite good, but not totally accurate. A statistical analysis of our Dexcom and Glucometer data has shown that our CGM is systematically running a bit low, underestimating results by 6 or 7 mg/dl. In addition to that, we still have too many lows, mostly during and post exercise. Since the CGM bottoms at 40 mg/dl and the Dexcom tends to recover slowly from lows, we are biasing the average lower. My guesstimate would be that we are running at a still decent 110 mg/dl average.

Standard Deviation remains one of the best indicators of blood glucose variability despite the near monthly appearance of new estimation methods (publish or perish), stands at 33 md/dl. That is very good given the mean glucose value. It shows that we aren't frantically over-treating lows and aren't driving our G levels all over the place. But let's not forget that the rule of thumb endocrinologists often quote "SD must be below 50% of MG" should be taken in the context of good control. A mean glucose of 250 and a SD or 120 is not good. 110 and 33 is.

Hypos: I still feel we have too many of them, but they are extremely hard to eliminate when one continues to be very active. This is a work in progress. Our rule for treating lows is to aim for 110 mg/dl based on a gram of carb per kg of weight calculation. After each correction, we wait 30 minutes before adding additional carbs as sugars need about that time to be absorbed. This is of course more tiring and work intensive than taking "a juice", but this also the only way to avoid over correcting highs.

In target: around 80%, and even around 90% if we consider lows to be on target. Well controlled lows don't hurt long term, highs do. On certain days, we can hit 100%, but then there is always an issue that disrupts that dream landscape.

Hypers: at 8% are a bit too high for my taste (who knows a diabetic who is happy with any highs anyway?) but could be worse. However, and that is a big issue, keeping the number of hypers below 10% is a lot of work, including a frequent corrective dose of insulin given at 4 or 5 AM. On the positive side, the total absence of hypers above 240 mg/dl is, in my book, the best part of this report. I am a bit anxious by nature and, whenever sugars are high, I can't prevent myself from picturing evil glucose molecules cooking themselves in my son's proteins and cells. The less that image is present in my mind, the better it is.

Profile: the average profile clearly shows the pattern we are battling. As discussed in a previous post, the current Lantus injection has been causing early night lows and is unable to control our current dawn phenomenon. It is not a huge issue medically speaking, but is becoming very tiring in practice. In some cases, the dawn phenomenon starts around 3 AM and the rise can be as big as 30 mg/dl per hour. At that point, an additional dose of 5U of Novorapid may be barely sufficient to keep the BG below 160 mg/dl at wake up time (the typical dose is 2-3U of Novorapid). If Max was using a pump, a solution would be to program a higher rate during that period, except that in about 1 night out of 4, we see no increase. Higher insulin deliveries could then create lows. The current strategy is to try to address those morning increases through a bit of standardized exercises.

That's all for today folks!