Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
scottleibrand opened this issue May 18, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@scottleibrand
Copy link
Contributor

commented May 18, 2019

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

This comment has been minimized.

Copy link

commented May 23, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2019

@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

This comment has been minimized.

Copy link

commented May 24, 2019

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

@scottleibrand

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.