Adverse Event: incorrect insulin delivery due to falsely high and flat Libre/LimiTTer/xDrip+ readings

[scottleibrand]

We received an Adverse Event report today (via private message to @AdrianLxM) of a user running OpenAPS oref0 version 0.6.2, with CGM data from Libre/LimiTTer/xDrip+, who received excess insulin due to failure to detect a failing sensor. The event in question did not result in hypoglycemia or any other negative health outcome, but could have done so if they had not noticed the problem and removed the failing sensor.

As shown at https://slack-files.com/TAWP5KA0L-FJV9J8U5U-478bd8cf56, the failing Libre sensor gradually drifted low over the course of the morning. At approximately 10am local time, they recalibrated it to approximately 16 mmol/L. However, because the Libre raw readings were so low and barely changing, the resulted calibrated readings remained high and nearly flat, independent of actual BG. The user, a teenager, uses oref0's enabledSMB_always feature, to keep BG in range despite frequently forgetting to bolus for meals. As a result, oref0 delivered an incorrect quantity of insulin, as the CGM data indicated BG was still high and not coming down much. Once the user noticed the incorrect CGM readings, they removed the sensor, thereby stopping automated insulin delivery around 7pm, and resumed manual diabetes care until a new sensor session was started early the next morning. The reporter did not recall any particular interventions that were required due to the insulin delivered by OpenAPS.

After Adrian put me in contact with the reporter, I requested access to the user's Nightscout instance, which was provided, and downloaded the CGM entries for the time period in question. I also requested access to the pump-loop.log output for that time, which was provided via papertrail. I performed a full characterization of the issue, contacted the developer of xDrip+, and began evaluating a workaround for oref0 that would have mitigated the issue, on which I'll open a PR shortly.

A relevant subset of the information provided by the reporter is available at https://gist.github.com/scottleibrand/4c8c84d9989afc98bc92214a08e849f0 and the full logs can be made available upon request.

[efbest]

It might be even more complicated: these data I pulled from a patient‘s Libre Monitor into a commercial software (‚Diabass 5 pro‘). The graphs show oscillating cgm values 10 minutes apart over a couple of dass. https://share.icloud.com/photos/0Z0JAXZMjgampKmjuDMqJflAQ

[scottleibrand]

@efbest That looks like two simultaneous uploads from two different devices, being graphed by software that incorrectly assumes they're from a single source. oref0 avoids issues from that by looking at the device field in entries.json and ignoring data from devices other than the one reporting the most recent data point.

[efbest]

Nope. Only one patient and. one device at each time.

[scottleibrand]

@efbest ok, can you please open a new issue with as many details as you can provide?

[danamlewis]

This was resolved with the addition of #1259 which is now in the latest release (master), so closing. Please open new issues with any details of additional situations where this might still need to be improved, but we encourage all users to update to master branch now.

[Dune-jr]

@efbest could you reupload the image on github (right click on image, copy image, right click on github, paste)?