#FreeStyleLibre2 – further thoughts

The big question that remains for many more technical users in relation to the FreeStyle Libre 2 is whether it is transmitting glucose data or something else to the reader for alarming purposes. There have been plenty of discussions, with a lot of opinions placed, however, nothing solid has so far been determined.

Abbott themselves have been stalwart in their vagueness and lack of detail, stating only that “information is sent between the sensor and the reader allowing the reader to determine if it needs to alert”.

People have approached Bigfoot with the same question and received a similarly vague reply:

And as a result, we are none the wiser. The question still remains. What is being transmitted between the Libre 2 sensor and the reader? 

Given the lack of information, let’s step back and look at what we know about Libre 1, about Abbott’s & Bigfoot’s plans, and where this leads. It might give us some indications as to what’s going on here and the opportunity to present a couple of hypotheses.

Libre 1

Libre 1 is Flash only. There is no transmission of data “real time”. The sensor captures data every minute, stores it and every fifteen minutes stores an aggregate value. 

When you flash the sensor with the reader, the algorithm in the reader collects the data and interprets it, presumably establishing the last known upload from time stamps and filtering from that point. We know the data in the flash upload contains a number of fields including timestamp, glucose value, thermistor values and a couple of noisier values that appear to be linked to the algorithm’s interpretation. 

The Libre 1 operates a countdown timer that is triggered from the first flash event with a reader/phone app, so we know there is a form of two way communication in evidence.

So then. What does that mean for Libre 2?

Libre 2

The key additional point we know is that there is constant communication from the sensor to the reader/phone app. That’s all we know. What else can we hypothesise about in relation to this? There seem to be a few things, related to the points we know, so let’s list those features:

• Variable, customizable alarms (that even a patient could use!!!)
• Real-time alarming, including for sensor loss
• Reader interpretation of data to determine alarms
• Bluetooth Low Energy communication between devices
• Flash communication between devices

Looking at each of these, it gives us some either/or situations:

Alarms

The reader determines whether it needs to alarm based on information received from the sensor and also whether it is receiving information.

Either the reader is seeing a variable value of some description, which it determines is within the ranges that the user has entered and therefore when to alarm;

Or, the reader receives a value that is states high, low or okay, which is sent to it from the sensor. For this to happen, the reader needs to communicate with the sensor and inform it of the high and low settings that the user has entered, which it could do real time via BLE or it could wait until the next flash event.

If the user adjusted an alert before bed, and didn’t flash, this could be considered a safety issue, so it seems likely that in the event of alert data being sent to the sensor, it would be done over the BLE connection.

The mentioned “loss alarm” triggers when messages are missed for a period of time. Given the system is communicating every minute according to the Abbott information, I’m speculating that would be around ten minutes.

Bluetooth Low Energy communications 

Regardless of the payload, BLE is in use every minute. From what I understand, the factors that drive BLE power use include, amongst others, connection interval, size of data transferred and number of packets of data transferred, amongst other things. Based on this smaller and fewer packets in that regular, 1 minute transmission seems to make sense, given the likely battery capacity of the Libre sensor.

Flash Communication

Abbott have stated that Flash is needed to get a glucose reading. This would also pull historic data off the device to provide the historic graphs. This is a low power mechanism for extracting larger amounts of data and seems to retain what is done already. 

Power consumption

We’ve heard from multiple, uncorroborated, sources that the model that Abbott have alighted on is the most power efficient in terms of sending data and sensor use. 

Abbott Future plans

Given the tie up with Bigfoot, it seems reasonable to assume that Abbott would be looking to register some form of Libre as an iCGM, in line with Dexcom’s G6 certification. In referencing that, an iCGM is defined by the FDA as:

An integrated continuous glucose monitoring system (iCGM) is intended to automatically measure glucose in bodily fluids continuously or frequently for a specified period of time. iCGM systems are designed to reliably and securely transmit glucose measurement data to digitally connected devices, including automated insulin dosing systems, and are intended to be used alone or in conjunction with these digitally connected medical devices for the purpose of managing a disease or condition related to glycemic control.

This doesn’t state that an iCGM requires that what is transmitted is a specific glucose measurement, simply glucose measurement data (which leaves room for interpretation).

Are there any conclusions or hypotheses that we can draw from this?

If we apply what we know to the two models that have been discussed, then it may provide some insight. So let’s look at the two hypotheses for  data delivery via BLE and see where we end up:

1. The data transmitted is a raw value containing multiple fields that the reader interprets
   • Positives 
     • Libre 1 only allowed raw data transmission so no change to output (potentially)
     • Sending the last minute’s raw data would be a relatively simple task
     • The proprietary interpretation algorithm would remain in the reading device also reducing power in the sensor
     • Back up data collection via NFC means that there would be no need for historic backfill
     • Fits the pattern of the Libre 1 and limits overall system changes
     • Doesn’t require two way BLE communication for user updates of alert limits
     • Lower power usage on the sensor in terms of algorithms running
   • Negatives 
     • If iCGM status is sought, with the current model it would require the device with which the sensor worked to run the Libre algorithm for interpretation
     • Packet size is larger than might be needed if a simpler message is sent, potentially affecting power consumption
2. An algorithm runs on the sensor and transmits a signal/simple value to the reader
   • Positives
     • Lower power requirement for data transmission
     • Algorithm on the sensor moves separates real time data interpretation from the reader/phone app
     • Back up data collection via NFC means that there would be no need for historic backfill
   • Negatives
     • Potentially more power is consumed on the sensor by running the algorithm
     • Change to the Libre model (but may be part of the plan)
     • Requires clear two way communication channel between sensor and reader, other than the simple start up, adding to the complexity of the system.

Based on these two hypotheses, it’s still very hard to determine what Abbott are really doing. 

We know that Bigfoot plans a pivotal trial early in 2019 with an aim to launch in 2020, and that this is planned with Libre thanks to the collaboration announcement in 2017 and corroboration from employees that they are using Libre.

If they are to do this, either the Libre 2 has to provide something usable as a glucose reading or they will be doing the trial with a pre-production “Libre 3” which in itself presents a risk. Or Abbott intend to release “Libre 3” much sooner than we anticipate and maybe in the US only. 

Both the offered hypotheses would support this, although in slightly different ways, with the second potentially being a public “proof of concept” for an on sensor algorithm and transmission mechanism that would allow Abbott to capture performance data in the wild. But if you’re going to do this anyway, why not transmit something that represents a glucose value? 

Abbott’s press office have made the following statement:

It’s not exactly a glucose value that’s transmitted, but information that allows the receiving device (reader) to calculate the glucose level (as we explained yesterday) – what is transmitted, is transmitted over Bluetooth.

That tends to lean towards the initial hypothesis. 

However you choose to look at it,  I don’t have the answers, but hopefully presenting some of my thinking about what might be going on with Libre 2 provides a useful insight into why there is such a debate raging, after what seemed like such a simple announcement. Whichever way you look at it, this is part of the Libre product development path, and both hypotheses make sense.