Over on Twitter, a friend asked me a question related to the FreeStyle Libre, since he knew that I’m an user. I provided some “soundbite-shaped” answers on the thread but since I got a few more confused replies afterwards, I thought I would try to make the answer a bit more complete:
Ciarán Handley (@ciaranhandley) July 29, 2018
Let’s start with a long list of caveats here: I’m not a doctor, I’m not a paramedic, I do not work for or with Abbott, and I don’t speak for my employer. All the opinions that follow are substantiated only by my personal experiences and expertise, which is to say, I’m an user of the Libre system and I happen to be a former firmware engineer (in non-medical fields) and have a hobby of reverse engineering glucometer communication protocols. I will also point out that I have explicitly not looked deeply into the NFC part of the communication protocol, because (as I’ll explain in a minute), that crosses the line of what I feel comfortable releasing to the public.
Let me start with the immediate question that Ciarán asks in the tweet. No, the communication between the sensor and the reader device (or phone app) is not authenticated or protected by a challenge/response pair, as far as I know. From what I’ve been told (yes I’m talking through hearsay here, but give me a moment), the sensor will provide the response no matter who is asking. But the problem is what that response represent.
Unlike your average test strip based glucometer, the sensor does not record actual blood glucose numbers. Instead it reports a timeseries of raw values from different sensors. Pierre Vandevenne looked at the full response and shed some light onto the various other values provided by the sensor.
How that data is interpreted by the reader (or app) depends on its calibration, which happens in the first 60 minutes of operation of the sensor. Because of this, the official tools (reader and app) only allows you to scan a sensor with the tool that started it — special concessions are made for the app: a sensor started by a reader device can be also “tied” to the app, as long as you scan it with the app during the first hour of operation. It does not work the other way, so if you initialize with the app, you can’t use the reader.
While I cannot be certain that the reader/app doesn’t provide data to the sensor to allow you to do this kind of dual-initialization, my guess is that they don’t: the launch of the app was not tied with any change to the sensors, nor with warnings that only sensors coming from a certain lot and later models would work. Also, the app is “aware” of sensors primed by the reader, but not vice-versa, which suggests the reader’s firmware just wouldn’t allow you to scan an already primed sensor.
Here is one tidbit of information I’ll go back to later on. To use the app, you need to sign up for an account, and all the data from the sensor is uploaded to FreeStyle’s servers. The calibration data appears to be among the information shared on the account, which allows you to move the app you use to a new phone without waiting to replace the sensor. This is very important, because you don’t want to throw away your sensor if you break your phone.
The calibration data is then used together with non-disclosed algorithms (also called “curves” in various blogs) to produce the blood glucose equivalent value shown to the user. One important note here is that the reader and the app do not always agree on the value. While I cannot tell for sure what’s going on, my guess is that, as the reader’s firmware is not modifiable, the app contains newer version of the algorithms, and maybe a newer reader device would agree with the app. As I have decided not to focus on reversing the firmware of the reader, I have no answer there.
Can you get answers from the sensor without the calibration data? As I’m not sure what that data is, I can’t give a definite answer, but I will note that there are a number of unofficial apps out there that purport of doing exactly that. These are the same apps that I have, personally, a big problem with, as they provide zero guarantee that their results are at all precise or consistent, and scare the crap out of me, if you plan on making your life and health depend on them. Would the paramedics be able to use one of those apps to provide vague readings off a sensor? Possibly. But let me continue.
The original tweet by Eoghan asks Abbott if it would be possible for paramedics to have a special app to be able to read the sensor. And here is where things get complicated. Because yes, Abbott could provide such an app, as long as the sensor was initialized or calibration-scanned by the app within the calibration hour: their servers have the calibration data, which is needed to move the app between phones without losing data and without waiting for a new sensor.
But even admitting that there is no technical showstopper to such an app, there are many more ethical and legal concerns about it. There’s no way that the calibration data, and even the immediate value, wouldn’t be considered Sensitive Personal Data. This means for Abbott to be able to share it with paramedics, they would have to have a sharing agreement in place, with all the requirements that the GDPR impose them (for good reason).
Adding to this discussion, there’s the question of whether it would actually be valuable to paramedics to have this kind of information. Since I have zero training in the field, I can’t answer for sure, but I would be cautious about trusting the reading of the sensor, particularly if paramedics had to be involved.
The first warning comes from Abbott themselves, that recommend using blood-based test strips to confirm blood sugar readings during rapid glucose changes (in both directions). Since I’m neither trained in chemistry nor medicine, I don’t know why that is the case, but I have read tidbits that it has to do with the fact that the sensor reads values from interstitial fluid, rather than plasma, and the algorithms are meant to correlate the two values. Interstitial fluid measurements can lag behind the plasma ones and thus while the extrapolation can be correct for a smooth change, it might be off (very much so) when they change suddenly.
And as a personal tale, I have experienced the Libre not reporting any data, and then reporting very off values, after spending a couple of hours in very cold environment (in Pittsburgh, at -14°C). Again, see Vandevenne’s blog for what’s going on there with temperatures and thermal compensation.
All in all, I think that I would trust better a single fingerprick to get a normal test-strip result, both because it works universally, whether you do have a sensor or not, and because its limitations are much better understood both by their users and the professionals. And they don’t need to have so many ethical and legal implications to use.