Request for fingerstick data entry

[t1derful]

FEATURE REQUEST FOR FINGERSTICK DATA ENTRY:

Background: Xdrip has fingerstick data entry in the treatment input. This is useful for calibrating CGMs, but it has a more important use. Occasionally xdrip users cannot use a CGM due to warm-up, dead batteries, etc. Entering fingerstick data can maintain diabetic control (old school) until a CGM is brought back online. Bg prediction, IOB, and carb recommendations are available for 24 hours. However, subsequently all telemetry ceases to display.

My feature request proposes that xdrip developers use fingerstick data for additional applications.

1. Continue xdrip telemetry past 24 hours for fingerstick data input to: A. Allow insulin treatment input and display, both as telemetry data and the green insulin dosage curve. B. Allow carb treatment and IOB to continue forecasting trends based on the fingerstick data point and predictive settings (purple curve).

2. Curvefit fingerstick connected data points versus time: A. Curve fit a polynomial to the fingerstick data up to 6th order, but let the user decide how many orders to fit. B. Use this curve fitted fingerstick data to estimate trends and other telemetry, such as statistics and HgbA1c.

Successful implementation of this feature would probably be the single most important advancement for Xdrip users who find themselves occasionally offline from a CGM or cannot afford a CGM. The data would not be as smooth as that of a CGM, but implementing available fingerstick data would be extremely beneficial to users.

[Navid200]

Sample Rate

This all falls under the category of xDrip+ Predictive Simulation. The accuracy of a simulator depends on the sample rate. We need to first come up with a minimum acceptable sample rate. If we have a value and have agreement, amongst the developers, that that rate or higher provides adequate accuracy, we can allow the user to enter blood glucose readings and have the simulator active as long as the sample rate is higher than that limit. But, as soon as the sample rate drops below that limit, the simulator will be disabled.

If the request is to enable the simulator, with no requirements, and leave it to the user to worry about accuracy, I assure you the request will never pass. We have to worry about how someone may incorrectly use xDrip and hurt themselves.

I doubt we can have adequate accuracy with only two readings (blood glucose measurements) a day. Do you think anyone would be willing to perform one blood glucose reading every half hour in order to have the simulator kept active? Please don't get me wrong. I am not suggesting that one reading every half hour is enough.

The devil is in the detail. If we figure out what an acceptable limit is, and go ahead and implement the required changes, and convince the developers to merge it, which is going to take a while, and then, no one uses it because the required number of blood glucose readings a day is not convenient or practical (too high), what's the point?

xDrip is not a medical app. Officially, it's not supposed to be used for making dosage decisions. The user has to agree to that before they can use xDrip. But, we still feel responsible for how xDrip may be used incorrectly and resulting in someone harming themselves or someone they love.

[Navid200]

Delay

There is another possible complication. A CGM shows interstitial fluid glucose, not blood glucose. The vertical axis is calibrated to convert the values to correspond to the blood glucose domain. However, there is nothing that can be done to the horizontal axis. That's why when you calibrate, xDrip shows the calibration with a 15-minute delay. But, that's just an approximation.

The problem is that the delay varies from person to person. But, the delay even varies, for the same person, depending on if the glucose is rising or falling.

Now, if the simulation was supposed to accept samples from both domains, the unknown delay, and its impact on the simulation accuracy, is another complication the developers should keep in mind.

[wjdthree]

I am ask for the same thing, enhanced fingerstick data prediction when offline from a CGM. I believe many others would greatly benefit; basically every single person who uses xdrip would benefit. I knew someone would worry about minimum resolution and someone "hurting themselves", as I saw in the developer comments. Anyone can hurt themselves at anytime, and xdrip already has a disclaimer that it is a research tool. Uneducated diabetics hurt themselves everyday without xdrip. Hence, minimum resolution should not be an issue and there should be no drop out limits. I will fingerstick myself as many times as necessary; but it does not necessarily have to mimic a CGM during level periods. Let the smart diabetics benefit from this enhanced feature. We are out here, and we do not want to wait.

[MowgliChild]

Hi,

Can we get a large improvement here with no risk and little work???

We NEED more support when finger sticking. Please. Finger sticking is our back up when the CGM goes down. Diabetics always need a back up. This would benefit ALL users. I think a basic improvement can be made with

At the moment when I have CGM issues I have to change both SW and HW and lose a lot of functionality.

My alternative, Mysugar, no longer tracks IOB. I dont know of another app that tracks IOB other than XDrip (and propitiatory pump SW)? If Mysugr can do this (but now has a different model) withouth CGM, and XDrip doesnt need CGM for this, why does it not work?

I fully appreciate it maybe dangerous to do full predictive BG modelling from a stick single data point only (rather than a constantly updating CGM). You cant fit a complicated mathematical curve from one data point. I understand. I also agree (as above) that we already signed away the rights on the install.

However, IOB and COB are only entered at an instant in time and any update in this part of the model is only influenced by time. Since they are only time dependent, XDrip can still model these even without CGM and without giving predictive BG.

IOB stacking is encouraged to achieve good diabetic control, impossible to calculate in your head and very difficult to do with a pen and paper. It is however purely mathematical time function defined by the DIA (which the user already inputs). A calculation of total IOB (and COB) is invaluable and can be presented even without the CGM and still be accurate.

The tracking of IOB by Xdrip is excellent. It even shows the peak of stacked insulins graphically, not just the numerical IOB which is slightly different but more widely used / understood. The question is better phrased "WHY IS THERE NO IOB / COB WITH STICKING?"

This already is written into the code. What we are discussing here is changing the switch which enables it to happen with stick testing.

Suggestion: Implement COB and IOB model with stick data.

[tolot27]

The simplest answer why we'll likely not implement this, is confidence of the prediction, hence reliability. With a CGM you get a new data point every five minutes and the prediction is updated accordingly. Hence, you will have a constant confidence score of the prediction over time. It is only influenced by other factors like not are lately entered carbs, treatment, unknown activities (typically not taking into account) but at constant unknown factor. If there are only very few data points from fingerstick measurements at random time and with different/large time span in between, the confidence of the prediction is getting worse over time until it reaches zero or a new fingerstick measurement is done. And as Navid mentioned already, blood glucose can be and is often different from interstitial fluid glucose and hence can be used the same way in the prediction formula.

The curve fitting @t1derful mentioned does not work for very few or single fingerstick data points, especially with higher orders. The higher the polynomial order, the more data points you need.

[MowgliChild]

Hi, I agree with why no predictive modelling.

But why does Xdrip stop tracking IOB when there is no CGM? This IS possible and safe.

This would give a great help to ALL users

[simonpickering]

Would it be possible in this case to either have a banner saying loud and proud that the accuracy is undetermined and don't trust it (and/or a setting to enable this once suitable warnings are accepted each time it's needed).

And/or add error bound lines to the prediction curve, which would be a useful thing in any case imo.

[tolot27]

Would it be possible in this case to either have a banner saying loud and proud that the accuracy is undetermined and don't trust it (and/or a setting to enable this once suitable warnings are accepted each time it's needed).

Possible less, but not valuable. You should never trust a prediction. It is just and indication. I see no value of showing predictions with a heavy decrease in confidence and in an addition to warn about it. For simplicity, it should simply not shown - as is. And personally, I'm against another setting.

And/or add error bound lines to the prediction curve, which would be a useful thing in any case imo.

IMHO, "error bounds" or specifically "confidence intervals" would be useful for scientists but for most of the users, the would distract the graph and are likely not understandable. And obviously, the would diverge heavily for every data point in the future. This is expected intrinsically and hence useless to show, IMHO. ;-)

[tolot27]

But why does Xdrip stop tracking IOB when there is no CGM? This IS possible and safe.

IOB tracking is a good point. Maybe, we should open a separate issue for it after the discussion is finished.

[simonpickering]

Possible less, but not valuable. You should never trust a prediction. It is just and indication. I see no value of showing predictions with a heavy decrease in confidence and in an addition to warn about it. For simplicity, it should simply not shown - as is. And personally, I'm against another setting.

Tricky one because the prediction curves are all predictions, sometimes they work, sometimes they don't. Quite how one would calculate and display the confidence interval is indeed an issue though.

It would be nice to have a choice of prediction algorithms (if people want to offer others) with some able to adapt themselves, and therefore some sort of tracking of how well they have predicted would be useful (a skill rating if you will - https://en.wikipedia.org/wiki/Forecast_skill).

This should probably be broken out into a different issue though re multiple algorithms, though a skill rating for the current one wouldn't go astray as I know mine is terrible shortly after consuming carbs - I could doubtless tune the parameters , but it changes depending on what I've been doing/eating, and I imagine that knowing what to adapt is not immediately clear to most users.

[Navid200]

This should probably be broken out into a different issue though re multiple algorithms, ...

Please don't open too many issues. When a user experiences a problem and comes to the issues platform and sees 170 open issues, they may not feel like searching through them all to make sure. They may just go ahead and open an issue to inform the developers that there is a bug or there is a need for something new. Then, we have to spend time closing the duplicate issues. The time that can be spent on fixing issues.

The problem with having too many open issues is that the developers are human beings too. They also stop looking at all the issues when there are too many of them.

There are bugs that need to be fixed. If the developers stop looking at the issues, those bugs will never be fixed. A fancy feature doesn't have priority over a bug that stops people from effectively using the app.

Please open a thread in the discussions or post in the Gitter room and give us a chance to have a look before opening an issue.

[simonpickering]

Noted and my apologies

[wjdthree]

Matthias, you are being extremely close minded about this issue. Give diabetics every option available to fill on their own holes. Do not assume we are incapable of discerning what is accurate or not. Polynomials can be fit to any number of data points as well as straight lines. Nobody cares if it is not a perfect fit. We just want more from fingerstick data points and what we are asking for is easy to implement and mostly already there. CGMs fail constantly for many reasons. Fingersticks do not fail and are far more accurate. I fingerstick at every treatment even if I am on a cgm.

On Fri, Oct 29, 2021, 18:29 Mathias Walter @.***> wrote:

Would it be possible in this case to either have a banner saying loud and proud that the accuracy is undetermined and don't trust it (and/or a setting to enable this once suitable warnings are accepted each time it's needed).

Possible less, but not valuable. You should never trust a prediction. It is just and indication. I see no value of showing predictions with a heavy decrease in confidence and in an addition to warn about it. For simplicity, it should simply not shown - as is. And personally, I'm against another setting.

And/or add error bound lines to the prediction curve, which would be a useful thing in any case imo.

IMHO, "error bounds" or specifically "confidence intervals" would be useful for scientists but for most of the users, the would distract the graph and are likely not understandable. And obviously, the would diverge heavily for every data point in the future. This is expected intrinsically and hence useless to show, IMHO. ;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/1795#issuecomment-955099743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKB4V54AGGO23NCUFPNAOXTUJM363ANCNFSM5BL2P73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Navid200]

... you are being extremely close minded ...

@wjdthree If you become one of the volunteers and contribute as much as he has, you should still not make a personal attack.
We are all here to talk about xDrip. We should be able to do that, and state our opinion, without having to worry about who may attack us because they don't like our opinion.
Even if you are right, allowing your words to focus on the person instead of the subject reduces the impact of your words.

Please edit your post and remove that line.
The last thing we need is the users driving developers away. We don't have enough volunteers. We need more not less. Please thank developers for contributing their time instead of criticizing them.

[t1derful]

-->I will volunteer. Send me the code, and I will program it myself. I  owe noone any apologies. He is being closed minded and that is not a personal attack. Xdrip needs a refocus onto important advancements. It has been stale for too long.

[Navid200]

xDrip is open source. That means the code is out there for everyone to see.

I suggested this proposal to be brought here, from the facebook group, because it sounded like a few individuals were interested in it. I didn't mean that the abusive behavior that is allowed in the facebook group should also be brought here. I now feel sorry for having suggested that.
What a shame!

[tolot27]

-->I will volunteer. Send me the code, and I will program it myself. I  owe noone any apologies.

The code is available to everyone. Please submit a PR of your modification along with a user documentation. I've assigned this issue to you. Thanks for volunteering!

He is being closed minded and that is not a personal attack.

If you think so, I can live with that. I'm strongly focused on improving xDrip and improve user experience while reducing the complexity.

Xdrip needs a refocus onto important advancements. It has been stale for too long.

You are welcome to contribute and if you feel this issue is an important advancement - more important than the other issues, please take the development lead for it.

[wjdthree]

Nobody is abusing anyone here, and it is just silly to assume that. Everyone appreciates the developers' work, but we cannot say congratulations forever. Otherwise, xdrip will keep getting complicated with little add ons like making every new watch work with it or something trivial. What we are asking for is a monumental improvement in xdrip for technology that is already inside of it. I am a PhD engineer and have been plotting my blood sugars and applying mathematics to prediction and extrapolation for 43 years. When I mastered the predictive feature of xdrip, I dropped my HgbA1c to below diabetic threshold (<5.6%) almost 4 years ago and have been below that threshold since. This halted my diabetic retinopathy and brought back 20/20 vision to me when I was legally blind. Nobody appreciates the developers' work more than me, so it pisses me off to read that someone does not think I appreciate it. Navid, sto it. I respect you highly for your dedication and patience. However, stop with the "don't hurt the developers feelings" crap. It's tiring and probably insulting to the developers.

If the developers do not want to tackle this concept of extending more functionality to fingerstick data, then I will attempt it. However, I am not trained in app development, so it would take a while for me to get up to speed. I would need some help from you guys (gals). It needs to happen. The holes and gaps are too big in the bg timeline. The most dangerous time for my vision is when my CGM goes down. My retina starts bleeding at 200 mg/dl. Assuming you are T1s, you all will be here someday if you think things are fine the way they are.

On Mon, Nov 1, 2021 at 5:30 AM W Donnelly @.***> wrote:

Matthias, you are being extremely close minded about this issue. Give diabetics every option available to fill on their own holes. Do not assume we are incapable of discerning what is accurate or not. Polynomials can be fit to any number of data points as well as straight lines. Nobody cares if it is not a perfect fit. We just want more from fingerstick data points and what we are asking for is easy to implement and mostly already there. CGMs fail constantly for many reasons. Fingersticks do not fail and are far more accurate. I fingerstick at every treatment even if I am on a cgm.

On Fri, Oct 29, 2021, 18:29 Mathias Walter @.***> wrote:

Would it be possible in this case to either have a banner saying loud and proud that the accuracy is undetermined and don't trust it (and/or a setting to enable this once suitable warnings are accepted each time it's needed).

Possible less, but not valuable. You should never trust a prediction. It is just and indication. I see no value of showing predictions with a heavy decrease in confidence and in an addition to warn about it. For simplicity, it should simply not shown - as is. And personally, I'm against another setting.

And/or add error bound lines to the prediction curve, which would be a useful thing in any case imo.

IMHO, "error bounds" or specifically "confidence intervals" would be useful for scientists but for most of the users, the would distract the graph and are likely not understandable. And obviously, the would diverge heavily for every data point in the future. This is expected intrinsically and hence useless to show, IMHO. ;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/1795#issuecomment-955099743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKB4V54AGGO23NCUFPNAOXTUJM363ANCNFSM5BL2P73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Navid200]

When you make a comment at someone else's expense, you are the one who is wrong.
If someone comes to facebook and says I need help for restarting my sensor, and someone responds with "anyone who restarts a sensor is a fool", that's an inappropriate response.
They could say it's not a good idea to restart because .... But, when they say "you are a fool", it is unnecessary.

Imagine if a member of the parliament/congress proposes to raise taxes. Another member may disagree with that proposal. Saying "I disagree because ..." is an appropriate response.
Saying "you are closed-minded" is very inappropriate. The speaker of the house will warn the second member in this case.

No two people think exactly the same way. The concept of governance by committee requires hearing all the ideas openly without prejudice. Sometimes when you hear the opposing argument, you may change your opinion because they explain something that helps you see the matter from a different angle you hadn't considered before. But, if the opposing side uses personal comments, you may never even consider the opposing side's proposal openly, which defeats the whole concept of governance by committee.

The developers disagree all the time. There would be no xDrip if we called each other closed-minded every time we disagreed about something.

[wjdthree]

I should be receiving these messages because extending fingerstick functionality was my idea, not because I am being accused of hurting someone's feelings which is ridiculous. I have made zero personal attacks on anyone, not on facebook and not here. Honestly, the only one being personally attacked is me, and I am tiring of it but not crying about it. Stop going on about this nonsense and get back to focusing on the issue of increased fingerstick function!

On Tue, Nov 2, 2021 at 10:16 AM Navid @.***> wrote:

When you make a comment at someone else's expense, you are the one who is wrong. If someone comes to facebook and says I need help for restarting my sensor, and someone responds with "anyone who restarts a sensor is a fool", that's an inappropriate response. They could say it's not a good idea to restart because .... But, when they say "you are a fool", it is unnecessary.

Imagine if a member of the parliament/congress proposes to raise taxes. Another member may disagree with that proposal. Saying "I disagree because ..." is an appropriate response. Saying "you are closed-minded" is very inappropriate. The speaker of the house will warn the second member in the second case.

No two people think exactly the same way. The concept of governance by committee requires hearing all the ideas openly without prejudice. Sometimes when you hear the opposing argument, you may change your opinion because they explain something that helps you see the matter from a different angle you hadn't considered before. But, if the opposing side uses personal comments, you may never even consider the opposing side's proposal openly, which defeats the whole concept of governance by committee.

The developers disagree all the time. There would be no xDrip if we called each other closed-minded every time we disagreed about something.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/1795#issuecomment-957798340, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKB4V53L7XLWAQ2NK74ZRALUKAFGJANCNFSM5BL2P73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[simonpickering]

Leaving aside what has gone before, there is what seems to me to be a reasonable idea here, it's worth discussion even if it won't necessarily make it into the "mainline" of the code. I would hope there are options to try ideas out that suit subsets of people with certain requirements and to make that code available (assuming there are enough devs to implement it of course).

Could we move the discussion to, and summarise on, @Navid200's Discussions page which afaiu was setup to reduce long discussion threads on the Issues page (which I am guilty of!) To let people discuss how things could be made to work, and indeed to offer reasons why they wouldn't that aren't directly associated with the concern of affecting what people currently expect from XDrip+?

Discussion site is here: https://github.com/Navid200/xDrip/discussions/categories/ideas

[Navid200]

Stop going on about this nonsense and get back to focusing on the issue of increased fingerstick function

But, you are the one who called someone closed-minded. That sentence, not about the issue and instead about a participant/volunteer, was written by you, not me. If someone calls you closed-minded, I will warn them and ask them to stop also. I'm not picking on you.

I have not used a single negative adjective (like closed-minded) to describe you. Yet, you are saying that I have personally attacked you. What would you say if I called you closed-minded?

My request from you is to delete that sentence. And I will stop mentioning it and will delete all my comments about it.

I'm not going to be very active in this thread because you have stated I made you uncomfortable. So, I respect that and will keep my distance. But, if you quote me again, I'll have to reply.