Enforce validity of Datricsae (and indeed all) calibration plugin fit line(s)

[simonpickering]

Almost all of my sensors end up with a fit line that has a different steeper gradient to that fixed by the standard calibration (i.e. above the standard calibration line), therefore I always tend to use datricsae which allows for different gradients.

However, if I've not happened to run really low and do a fingerprick which I can use for calibration, the fit line is often invalid as the intercept is too high. This also happens if I calibrate using an intermediate value which happens to pull the gradient up enough that it fails the intercept test.

It would be wonderful, in the absence of an actual data point, and indeed even if there are data points but which generate an invalid fit, to force the fit to intercept the Y-axis at a value such that it's not invalid.

I realise this will generate a fit that is not exactly that indicated by the data, however, firstly I don't imagine most people care very much/it's very dependent on the data that happens to be selected as calibration points/a fit which is slightly "wrong" is far better than the plugin deciding that it is invalid and then needing to go back to the standard fit line with fixed gradient (which is always much worse for me at least)

[Navid200]

I'm not sure exactly what you are suggesting.

Currently, we have a limit on how high the intercept can go. The reason for that is that if it does go too high and the real glucose is low, the high intercept could result in a high value to be shown. That could lead to a disaster.

I could be wrong. But, devices that are in the market today are factory calibrated. They provide a behavior that does not degrade with time. In the old days, the relationship between glucose and what the CGM showed drifted with time. That was when calibration was required twice a day or at least once a day.
But, since factory calibration has appeared, that drift has been addressed.

What is not addressed is the wrong perception that the blood glucose meter is more accurate than the CGM. That used to be true when the immune system affected the accuracy of the CGM and that behavior had not been taken care of by factory calibration. With factory calibration, a CGM and a blood glucose meter provide comparable accuracy. None of them is perfect. Calibrating only brings the CGM closer to the glucometer, which is not any more accurate.

I don't believe we should spend any more time on calibration in xDrip. In fact, I believe we should encourage users to consult with the physician about the necessity of calibration with a factory calibrated CGM.

I'm not stopping any other developer adding more to calibration. But, I myself don't believe that is the right approach.

[simonpickering]

I understand that both CGM and fingerprick data have a range of accuracies. I understand about when to calibrate.

With my current sensor, and this is by no means unusual (probably needed on ~50% of sensors), the libre2 raw value says I have (and have had all afternoon - no eating, no insulin, perfect flat-ish BG territory) a BG of 2.9mmol/l, while (repeated) fingerprick blood tests put my BG at 5.3 mmol/l. The difference increases as blood glucose increases. Calibration is essential here as otherwise it's a case of running higher than desired to stop alarms or just using a calibration which allows a non-fixed gradient which makes it actually read correctly.

You talk about neither being perfect, which of course is true, though the error/MARD on fingerprick tests is certainly lower than that on CGMs, I don't think there's any debate there is there, though you say you think they are equally accurate? I suppose the most important thing is that despite being told I'm hypo by the libre2+ data I know it's not true from how I feel.

So while I understand what you're saying, unfortunately it doesn't work for everyone. It would be wonderful if Abbott could fix their sensors so they (also) work for my particular innards, but they don't seem to have done this so far despite my returning many many sensors to them with complaints about calibration issues (which I normally only do when the steady-state offset is ~>5mmol/l).

I could swap the sensor and hope the next one works better, and end up with a sore arm and Abbott wondering why I keep complaining (but apparently not doing anything about it). But it's much easier to make the one that's fitted work adequately as long as it doesn't require too much calibration, and this is the point - if one does need to calibrate to make a sensor work (better at least), it would be good if the calibration tried as hard as possible to avoid falling over/giving invalid data, simply to make life easier for uses such as myself who require these apparently unusual calibrations to be applied.

I understand this may not be a major requirement for most people and that therefore it won't be top of the pile, I'm happy to have a look and submit a patch myself, I also understand that forcing the fit line to have a constraint on the y-axis intercept changes the fit, so presume a tick box to enable this would be enough to keep everyone happy that the previous functionality is still available (but would improve matters for weirdos like me who consistently need calibration ;)).

[Navid200]

The Libre calibration limit that imposes a max intercept of 40 is an extreme measure and can be adjusted. But, it has to be done by a Libre developer. They have never put the time to do any additional fine tuning.

I would worry if we add a single switch to disable that safety measure. There are some safety measures in xDrip that are there for the safety of the majority and we cannot add a switch to allow disabling it. It would defeat the purpose it was added for in the first place.
I prefer if you work with the developers and fine tune the safety mechanism rather than to add a switch to let you disable it.

[simonpickering]

I'm more than happy to work with the devs to improve it, but I wasn't suggesting removing this intercept limit, rather performing a different type of fit to the calibration data points whereby a standard least squares fit is performed first (as usual), and if the intercept limit is failed, a constrained least squares fit is performed (which constrains the Y intercept to the minimum value to ensure the calibration can still safely signal a hypo, but also allows other data points to still influence the gradient of the fit line.)