Monday, February 2, 2015

Some thoughts and experiments on using the Freestyle Libre as a CGM

I continue to be impressed by the Libre, even if we now have our first "bad" sensor that reports values that are 20 mg/dL too low. It is wrong - consistently so - which means that it is still useful with a bit of mental adjustment.

Running the Libre as a CGM?

A few months ago, when we started with the Libre, I was so impressed by its accuracy and reaction speed that I immediately decided I should try to turn it into a full CGM system that would replace our Dexcom. The basic idea was to put a small NFC reader in an armband for the night and collect data  every 5 minutes or so which would then be pushed to our Nightscout setup in place of the Dexcom data. As far as my personal use is concerned, I was never interested in pulling data to a phone replacing the Abbott reader. After all, having a dedicated reader has advantages for a teen. It will not, for example, run out of battery because of Clash of Clans... With that goal in mind, I started looking at the data that was stored and updated in the tag (here) and slowly plowed my way through its interpretation.

An unexpected journey

When I started, I expected to face a system roughly similar in its mechanisms to Dexcom's data collection and interpretation. While there is of course a fundamental similitude, there are also significant differences. In a typical usage scenario, the Libre beat our non-AP Dexcom algorithm by a large margin. That is what matters for T1Ds in their every day life.

But once you dig a bit deeper, you realize that this impressive practical result is not solely achieved by exploiting a sensor that would be much better than the Dexcom sensor. Abbott fully exploits the adjustment opportunities offered by the typical usage scenario, offering the best info it can summarize at any given moment (or just declining to offer it when it can't). Once I understood the broad lines, I was a bit disappointed to notice that the data marked as fully usable wasn't as frequent as the relatively smooth user experience seemed to indicate (this would probably have a negative impact on an Libre controlled AP). That also meant that even with a full understanding of the data, going CGM wasn't going to be a short or smooth ride.

The chart below (spot checks = orange circles, historical data = small red dots) clearly shows that the Libre massages/cherry picks its data quite intensively. The spot reported sustained spike isn't consistent with the historical data and the historical data at the end has not been updated even if more than 15/16 minutes have elapsed. Interestingly, in both cases, the spot checks that weren't actually taken into account in the historical data fit nicely a linear trend extrapolation. This could be a coincidence, it happens very often, but not 100% of the time.


Texas Instruments bio-sensors

At the core of the Libre NFC tag, we find a new Texas Instruments chip (the FAL...) that has been customized to Abbott's specifications. That chip, based on a MSP 430 core, includes a set of ADC, a  thermistor, a communication stack, a ROM, some SRAM and a FRAM. FRAM is an interesting type of RAM that offers a lot of the advantages of Flash memory (persistance) and of RAM (directly accessible, low power needs). If my Libre investigations had only led me to discovering the existence of that line of TI micro controllers, I would already have been happy. These small wonders will certainly lead to a lot of interesting applications in the near future.

FRL152 sample project - unrelated to the Libre


Libre Tag
Unfortunately, while the main members of the family are now well documented, Abbott uses a custom version of that controller. I am now almost 100% certain that the AL in the processor name stands for Abbott Laboratories. There are other indications that this was a custom design. For example, a program written for the FRL line typically contains a command table delimited by a start and an end marker (0xCECE in both cases) while the controller used in the Libre has a 0xABAB pattern that, once you have seen it, becomes glaringly obvious (and so do the En and An commands and their addresses). Obviously Abbott got TI to customize that for them...

FRL152 Sample project - unrelated to the Libre
The philosophy behind the micro-controller is simple and elegant. You decide what you want to sample, set up a sampling scheduler that does its job for a while at defined interval. Once the loop is complete, the values collected are posted to FRAM and wait for collection. (possible issue here for a custom scanner: check if the sampling has been completed or not. Reading a partially collected sample blindly will introduce very significant errors). The fact that FRAM doesn't require bank rewrites like flash and that it can sleep for a while is a big plus for the duration of the sampling process (TI has a sample power usage analysis here) (again, possible issue for a custom scanner, how long will a battery last if the device is constantly or very frequently active)



Temperature

The TI chip also contains a thermistor which Abbott uses to monitor the sensor temperature. A reasonable assumption here is that the glucose oxydase reaction slows as the temperature goes down and accelerates as it goes up (I am not a bio-chemist but this is what I remember in general from the mandatory courses I took in med school). In that situation, you either have to correct for the reaction speed or decide to discard the value received as not valid. We can be sure that Abbott uses the latter as many users have reported their meter refusing to display a value in either warm or cold conditions. ( a custom reader would have to detect those conditions). We can't exclude a temperature based correction either, which would eventually give up when outside its comfort zones. That could lead to interesting situations when the sensor is used in warm weather or exposed to the sun when sunbathing. Since the Libre isn't available in the Southern Hemisphere yet, we'll have to wait for the Summer to find out how big an impact it has.

Shutdowns

In addition to the temperature issue, the TI chip has the ability to shut itself down when a certain threshold has been exceeded. One of our sensors seems to have shut down itself a minute after an extremely intense physical exercise. Since extreme movement and muscular activity are known to produce triboelectric effects (see for example here for an example of skin energy scavenging) I assume that some threshold was exceeded in the TI sensing configuration and that either the sensor stopped itself or that the meter shut it down based on the report of the condition. At least, a sensor that shuts itself down stops being an issue for a custom scanner, but it would of course be nice to detect the condition as well.

Changes and rapid changes

I was surprised to see that almost all sudden increases or change of directions of the measured values are treated as suspect. In some of the experiments in data interpretations I have conducted, almost 50% of the measures were flagged as less trustworthy or requiring special attention. In extreme cases, the Abbot meter will even decline to show historical values. This behavior is almost invisible in normal use. There is the occasional "wait ten minutes and try again" message or the unexplainable gap in historical data later. In less extreme cases,  data still gets flagged as unreliable now and then. This would definitely impact a third party scanner or a CGM.

Putting it all together - the good.

When the sea is calm and clean data comes in on a regular basis, using the Libre as a real CGM is definitely possible for short periods of time. Here is such an example where data was collected every minute both on a phone and meter, interpreted through a small custom algorithm that yielded a +/- 1 mg/dL correspondence. So far so good.


The bad

Let's now consider a situation where IG is changing a bit differently. Here is a simple interpretation of the raw data compared to what Abbott  makes of it. IG is slowly rising and so are the reported TI values. It looks as if the official meter first ignores the increase and then, when some threshold is exceeded, kicks in predictive extrapolation to reach the plateau before the actual data. Then, something changes (at this point I am not sure what changes exactly) and the straightforward interpretation of the raw data starts to diverge (the BG meter reported a value exactly between the raw value and Abbott's interpreted value). This behavior could arise from, for example, the application of an approximated sigmoid calibration curve where a change in IG range would switch to a different part of the curve. It could also be the consequence of a change in a scaling factor at certain levels. After a while, the traces will re-correlate until the next "incident".


 The ugly

 But what happens to a naive interpretation when a severe error goes undetected? Well, bad things. And bad things that can happen at less than ideal moments. Here is a result of a non official interpretation when an error is induced and not detected. One can easily imagine the panic of a non technical user if he saw an worrying but stable 50ish situation crash abruptly in real time.  A technical user would think "hey, this can't be - this is either a bug or an undetected error". A mother at night might be racing to the fridge for the Glucagon. This is a BAD THINGTM


Additional examples

I have dozens of extremely good CGM runs.

This one is meter 137 - home CGM 138.75


This one is meter 124 - home CGM 121 (the measure as -5 was "flagged" in the tag data)











This one is meter 156 - home CGM 159
This one is real time tracking of my son going a bit low












And this one is real time tracking of the effect of two Dextro tablets. It was, by the way, a fascinating experience to observe and measure in real time, minute by minute, what we usually learn to approximate by experience.


And a copy of the "lab notes" - not sure anymore this is an exact match, the notes usually end up in a spreadsheet and I ran multiple experiments.



Wrapping up

Wearing my techie's hat, I could decide that this is wonderful, start to party thinking the problem is solved and unleash code onto the world. That would be irresponsible.

Wearing my MD's hat, I say - wait a minute, this is not good at all. There are too many unknowns, too many poorly understood situations or possible error conditions that could lead, if displayed to real patients, to absolutely disastrous situations.

This is why I limit myself to providing hints and tips. I do hope, however, that other people who may have easier sensor access than I do and are better and more motivated than I am may eventually find useful information here that would ultimately lead to much better implementations and a better understanding of the system.

Possible future investigations

  • Not feeding intrinsically tainted data to any algorithm, in other words, detect 100% of the data that should be ignored on technical/physical grounds (sampling issues, TI error conditions, temperature...)
  • Deal with borderline data with the same caution as Abbott.
  • eventually implement a custom system + algorithm, possibly similar to what Dexdrip does on the Dexcom raw data.
Note: I may post the listing of a typical FRL152H based application (non Abbott) as an addition to this post. Posting it in the midst of this post would have made it extremely hard to read.

Regardless of where my investigations lead, I enjoyed tremendously the time I spent looking at this system. The journey is the destination!

Addition: 

I have been asked about what happens in higher ranges - we don't often see them, but here is such a case which we monitored today. Please be aware that the data below is presented in a slightly misleading way in terms of alignment because I have not yet modified the display code.

 

2 comments:

  1. très jolie article.
    Can you say something about how you extracted the data from the chip?
    I'm trying to give my used sensors a second life as a NFC-Tag or ADC for my Raspi...

    Mülly

    ReplyDelete
  2. thx
    great review
    i have two Q. :
    1-algorithm is it done inside sensor or reader ?
    2-is there a simolification of alogarithm used in fs libre ?

    thx and regards

    1-

    ReplyDelete