POLL: Would you try a DYI system, even with the recent FDA warning?

[Mila]

Would you try a DYI system, even with the recent FDA warning?

• YES
• NO

Why? or why not?

[Terry4]

I’d like to add a few details about what caused this incident. First of all, for those interested in more than the two-dimensional headline description of this situation, please read the FDA statement.

I’ve read from other sources that it was a Miao-Miao device added on to a Libre sensor that fed false low readings to an OpenAPS system which led to an insulin overdose. The patient did recover.

First, some background. In a typical automated insulin dosing system a continuous glucose monitor generates a glucose value and transmits that number to an algorithm contained in an app, often resident on a smart phone. The app decides whether it should add or withhold insulin to bring/keep the glucose in range.

The big concern here is any system’s inability to detect bad glucose data and disable insulin delivery based on that inaccuracy.

The Dexcom CGMs (G4, G5, G6) all produce a stream of live CGM data without any needed electronic request. The Freestyle Libre, a flash glucose monitor, only produces glucose data when an electronic manual inquiry (waving the receiver nearby the sensor) is made.

In order to automate (simulate the Dexcom CGM push notifications) the Libre and turn it into a functional CGM, add ons like Miao-Miao and Blucon will take the Libre signal and push it to an app to modulate insulin delivery.

In the case that led to the FDA warning, the combination Libre/Miao-Miao produced false low numbers. Unfortunately, this do it yourself arrangement has no way to detect whether the data stream it produces is valid or not.

The Decom systems have a built in way of dealing with this. When the Dex screen produces a ??? reading or data simply drops out, the system is saying that the glucose signal it is receiving makes no sense. Loop detects this condition and will set no further temporary basal rates until it regains confidence in the glucose numbers.

Any glucose data failure that exceeds 30 minutes will revert insulin delivery back to the programmed pump settings. In other words, Loop will fail safely. This did not happen with the Miao-Miao/Libre system in question.

I’ve used a DIY system for 30 months now and I can confidently say that my overall safety is better than the pump/CGM combination that I used before. Insulin treated diabetes is a risky and sometimes dangerous proposition.

[CJ114]

@Mila

Why? or why not?

I put more faith in individuals with a vested interest in making things work than the Government that messes up pretty much anything they touch. I am on MDI and my 0.1u delivery digital insulin pens are manufactured in Korea and I have been importing them from Germany for decades as they are not FDA approved but far superior and offer far better control to any pens historically available in the US. I buy my Humalog/Lantus outside of the US at a 90% discount from US list price and even though made by the same company, it is not US FDA approved.

I am prepared to accept full responsibility for using something that is not FDA approved but better for me either mechanically or financially.

Maybe my risk tolerance is much higher than others and maybe my rewards are a lot greater because I do my own research and accept responsibility rather than look for excuses and someone to blame when things don’t work out quite to plan.

[Tony24]

The FDA approved sof-sensors and enlight sensors -

Then they had the brilliant idea of limiting libre to ten days while it was working in Europe for 14 days - they did this just because they could - no sane reason

They are not the sharpest tools in the shed

IMHO they do not have the patients welfare in mind at all

If I was to become head of the world they would cease to exist

[mohe0001]

I think this is fine for adult, gold star, long term diabetics who do continuous monitoring. Its good for people to know that new devices have bugs and they need to have a heightened level of caution. They are ‘beta testing,’ and the goal is to find problems and ensure safety for the rest of the patient community who might have more vulnerabilities/less experience.

I would agree with Tony that many things are OK with FDA, that would not be OK with me, personally. So, we need to expand our options however we can.

[Paytone]

From what I understand about this incident, the root cause was incorrect readings from the CGM. The old phrase “garbage in, garbage out” applies to any way you use CGM data to make dosing decisions. It doesn’t matter if you’re using your brain or a DIY loop algorithm. If you blindly trust the CGM system when the numbers don’t make sense, you put yourself at risk.

[Terry4]

I like this take from Renza Scibillia on DIY tech and our community in light of the FDA warning.

Diabetogenic

The money line: All diabetes is DIY.

We make treatment decisions all day, every day, year after year after year. Due to the very nature of diabetes, we must improvise.

[Rphil2]

I did not have any desire to do it before or after the FDA warning. Look I think it is great if people want to use them, they are just not for me. Live and let live.

[athx9891]

The incident is explained here.

Basically, the transmitters in “true” CGMs not only transmit data, they also validate it. If it seems bogus (whatever that may mean), they don’t transmit anything until they gathered enough measurements to be able to properly analyze what’s going on.

The software in the Libre reader and the LibreLink app also does this. The NFC blocks that are scanned when you swipe the reader/smartphone over the sensor contain markers for measurement quality. The software looks at these, and if they seem suspicious, the software refuses to output BG data. That’s one reason for why sometimes the reader/app may show you errors like “cannot show BG right now”.

But, the person who landed in the hospital didn’t use official software. He/she used xDrip, combined with the Miaomiao third-party transmitter. This combination turns the Libre into a DIY CGM … but it has serious problems. xDrip can read the NFC blocks, but not all of its values are understood. Temperature compensation is one that is ignored, which is why you must regularly calibrate if you use these raw values with xDrip. Worse though, this setup also ignores the quality markers, because they too are not understood. So, this person combined xDrip and the Miaomiao with the DIY loop. This works, as long as the calibrations are done diligently.

But then, one sensor went bad. When Libre sensors go bad, they show false lows, all the time. So, it will return a super low value constantly. This is important. Assume that the sensor showed, say, 46 mg/dL (because it was dead, and that’s the lowest value it can return I think). The person measured with a finger stick, result is let’s say 180 mg/dL. Ohhh, looks like it needs some calibrating! After calibrating, xDrip output something around 180 mg/dL. Seems like all is well again. But … the sensor was actually dead! And xDrip didn’t know, because the quality markers are not understood, and therefore got ignored. So, xDrip kept sending some value around 180 mg/dL to the loop. Constantly. The loop got mislead, and thought that the person had persistently high BG. What happened? Constantly elevated insulin administration.

So, what went wrong? The Libre+xDrip+DIY-Loop combination has always been controversial, for multiple reasons. The loop itself was not the culprit. Neither were xDrip, or the Miaomiao. Improper use of the Libre was. This would not have happened with Dexcom sensors, because as said, with them, there is no BG data when bad sensor data is detected.

This is one reason why I stuck with libreOOPalgorithm while I was using the Libre+Miaomiao combo (I’m on the G6 now). LibreOOPAlgorithm is a great hack to be able to use Abbott’s code with xDrip. Basically, it goes like this: Miaomiao reads NFC block from sensor and transmits it over Bluetooth LE to xDrip → xDrip receives the NFC block and forwards it to LibreOOPAlgorithm → LibreOOPAlgorithm forwards it to a sandboxed internal copy of the core LibreLink code (yes, they extract the Java class binaries for this!) → that code figures out a BG value (or doesn’t return anything in case of bad sensor data) → LibreOOPAlgorithm extracts that BG value and forwards it to xDrip → xDrip shows BG value. Result: BG values in xDrip that almost exactly match that of the Libre reader. Said reader’s values were always very accurate for me, but I know that they weren’t for some people, so I understand the appeal of the xDrip+Miaomiao combo with calibrations instead of LibreOOPAlgorithm. But, as we now have learned, there are dangers.