Freestyle Glucose Meter: Approximate Error Correction?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Thelma Lubkin - 12 Oct 2005 00:25 GMT

My husband just noticed that he's gone through about 20 strips with his
Freestyle blood glucose monitor code set to 17 when it should
have been set to 12. He's not expecting to correct those readings with
any precision, but does anyone know at least what direction the
correction would go in, and better yet a back of the envelope
algorithm for a reasonable guess?

thanks, --thelma

Reply to this Message

Herman Rubin - 12 Oct 2005 16:07 GMT

> My husband just noticed that he's gone through about 20 strips with his
> Freestyle blood glucose monitor code set to 17 when it should
> have been set to 12. He's not expecting to correct those readings with
> any precision, but does anyone know at least what direction the
> correction would go in, and better yet a back of the envelope
> algorithm for a reasonable guess?

This should be done with all meters, and as far as I know, it
is not done for any.

Signature

This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558

Reply to this Message

Anja Länge - 12 Oct 2005 16:18 GMT

Thelma Lubkin <thelma@alpha2.csd.uwm.edu> schrieb:

> My husband just noticed that he's gone through about 20 strips with
> his Freestyle blood glucose monitor code set to 17 when it should
> have been set to 12. He's not expecting to correct those readings with
> any precision, but does anyone know at least what direction the
> correction would go in, and better yet a back of the envelope
> algorithm for a reasonable guess?

No, but why don't you find out yourself? Do threee tests at different times,
each test with two strips, one set to code 17 and one to code 12. Either
there is a pattern or there is not... and please tell us about your findings
;-)

Anja

Reply to this Message

Thelma Lubkin - 12 Oct 2005 16:41 GMT

Anja L?nge <anja.laenge@gmx.de> wrote:

: Thelma Lubkin <thelma@alpha2.csd.uwm.edu> schrieb:

:> My husband just noticed that he's gone through about 20 strips with
:> his Freestyle blood glucose monitor code set to 17 when it should
:> have been set to 12. He's not expecting to correct those readings with
:> any precision, but does anyone know at least what direction the
:> correction would go in, and better yet a back of the envelope
:> algorithm for a reasonable guess?

: No, but why don't you find out yourself? Do threee tests at
: different times,
: each test with two strips, one set to code 17 and one to code 12. Either
: there is a pattern or there is not... and please tell us about your
: findings
: ;-)

He did this for *one* test and the code 17 returned a value
that's about 11% lower than the code 12 reading. If I could
convince him to explore this any further I wouldn't have
posted.
--thelma

: Anja

Reply to this Message

Anja Länge - 12 Oct 2005 17:00 GMT

Thelma Lubkin <thelma@alpha2.csd.uwm.edu> schrieb:

> convince him to explore this any further I wouldn't have
> posted.

Good point :-(

Anja

Reply to this Message

oldal4865 - 12 Oct 2005 17:46 GMT

Thelma Lubkin wrote in message ...

>: Thelma Lubkin <thelma@alpha2.csd.uwm.edu> schrieb:
>
[quoted text clipped - 4 lines]
>:> correction would go in, and better yet a back of the envelope
>:> algorithm for a reasonable guess?

There is a way to correct. The manufacturer figured it out when he
assigned the code. However, the code number is arbitrary and has nothing
to do with the correction.

Code 17 might read 20% higher at low blood sugar and 10% higher at high
sugar; or exactly the opposite; or exactly 17.5% lower at all sugars,
or just about any other combination you can think of.

You might call the strip manufacturer, and they might tell you. I suspect
they won't but they might.

Caution: I expect a question like that to totally baffle the bright-eyed,
cheerful but naive customer service rep. It's really a question for the
folks in the Quality Control Lab. They tested that batch of strips over
a wide range of blood sugars, then assigned a code which most nearly
matched the particular calibration equation needed for that strip.

Regards
Old Al

Reply to this Message

Alan Mackenzie - 17 Oct 2005 14:22 GMT

Thelma Lubkin <thelma@alpha2.csd.uwm.edu> wrote on 11 Oct 2005 23:25:08
GMT:

> My husband just noticed that he's gone through about 20 strips with
> his Freestyle blood glucose monitor code set to 17 when it should have
> been set to 12. He's not expecting to correct those readings with any
> precision, but does anyone know at least what direction the correction
> would go in, and better yet a back of the envelope algorithm for a
> reasonable guess?

If the manufacturer were to be cooperative (fat chance), they could be
corrected _exactly_.

This is an instance where technology could (and should) help. The code
number should be written onto each strip and read electronically by the
meter when the strip is inserted into it, thus obviating _another_ source
of human error.

> thanks, --thelma

Signature

Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Reply to this Message

Cindy Wells - 17 Oct 2005 17:14 GMT

<snip>

> This is an instance where technology could (and should) help. The code
> number should be written onto each strip and read electronically by the
> meter when the strip is inserted into it, thus obviating _another_ source
> of human error.

There is one meter/strip manufacturer that does that. IIRC, the brand is
even more expensive than the ~$0.80 per strip I grumble about at the
pharmacy.

Cindy Wells
(I'll stick to my cheaper tester and remember to change the codes
myself. Although I might consider getting the $30 cable if the
connection was two-way and I could correct the code number while
uploading the test results.)

Reply to this Message

Tere - 21 Oct 2005 19:42 GMT

> Thelma Lubkin <thelma@alpha2.csd.uwm.edu> wrote on 11 Oct 2005 23:25:08
> GMT:
[quoted text clipped - 8 lines]
> If the manufacturer were to be cooperative (fat chance), they could be
> corrected _exactly_.

Yes, it could be done exactly, but not trivially.

Each code might represent an entirely different response curve. One
might linear, and other might be a sinusoidal, and so on, with offsets,
scale factors and/or constraints. That's assuming the response curve is
even a function. The mappings from one to the other might be a little
complicated.

A complete set mappings, from every code to every other, would have
n*(n-1)/2 mappings, excluding inverse mappings (twice that with
inverses). My Freestyle Flash has 50 possible codes. 1225 mappings w/o
inverses.

The risk of liabiliy are too high for them to give out this
information.

Another idea would be to build a feature into their PC software to
facilitate code changes.

Reply to this Message

Alan Mackenzie - 24 Oct 2005 08:40 GMT

Tere <terence.griffin@nist.gov> wrote on 21 Oct 2005 11:42:43 -0700:

>> Thelma Lubkin <thelma@alpha2.csd.uwm.edu> wrote on 11 Oct 2005 23:25:08
>> GMT:

>> > My husband just noticed that he's gone through about 20 strips with
>> > his Freestyle blood glucose monitor code set to 17 when it should
>> > have been set to 12. He's not expecting to correct those readings
>> > with any precision, but does anyone know at least what direction
>> > the correction would go in, and better yet a back of the envelope
>> > algorithm for a reasonable guess?

>> If the manufacturer were to be cooperative (fat chance), they could be
>> corrected _exactly_.

> Yes, it could be done exactly, but not trivially.

> Each code might represent an entirely different response curve. One
> might linear, and other might be a sinusoidal, and so on, with offsets,
> scale factors and/or constraints. That's assuming the response curve is
> even a function. The mappings from one to the other might be a little
> complicated.

I suppose that's possible, but I think it's very unlikely. I don't know
for certain, of course, but the designers of the device will surely have
made it as simple (reliable) as possible, given the constraints of their
marketing department. I would think that the different code numbers are
to compensate for inaccuracies in the strip manufacture - they'll make a
batch, then calibrate it.

> A complete set mappings, from every code to every other, would have
> n*(n-1)/2 mappings, excluding inverse mappings (twice that with
> inverses). My Freestyle Flash has 50 possible codes. 1225 mappings w/o
> inverses.

Again, I don't think this would be true. From the given BS reading and the
code number which was used, you can go back to the
resistance/reflectivity/albedo/pH/whatever that the sensor measured in
the first place. Then you can go forward again, using the correct code
number.

> The risk of liability are too high for them to give out this
> information.

Ah yes, that old chestnut. Standard excuse used by pharma companies to
withhold essential information. Doesn't even involve having to think.

What is the concrete risk in this case? How could giving out the data to
correct historical BS levels lead to liability on their part? The info's
probably available from their patent anyway.

>> This is an instance where technology could (and should) help. The
>> code number should be written onto each strip and read electronically
>> by the meter when the strip is inserted into it, thus obviating
>> _another_ source of human error.

> Another idea would be to build a feature into their PC software to
> facilitate code changes.

Yes, but that's only any good to the people who use their PC software.

Signature

Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Reply to this Message

Tere - 25 Oct 2005 21:28 GMT

> Tere <terence.griffin@nist.gov> wrote on 21 Oct 2005 11:42:43 -0700:
>
[quoted text clipped - 25 lines]
> to compensate for inaccuracies in the strip manufacture - they'll make a
> batch, then calibrate it.

Actauly, I agree the examples I gave are a stretch. The point I was
trying to make is that code number are arbitrary wrt to the mapping. A
batch of reagent that gets code 17 may have a completely different set
of corrections that a batch with code 18. And the correction may depend
not only on the codes, but the value as well.

> > A complete set mappings, from every code to every other, would have
> > n*(n-1)/2 mappings, excluding inverse mappings (twice that with
[quoted text clipped - 6 lines]
> the first place. Then you can go forward again, using the correct code
> number.

Ok. So for 50 codes, you have 100 mappings, two for each code, one to
go back to the raw electronic values, an on to go forward to the
corrected value. The user than has to apply two conversions to change
from one code to the next. A lot fewer codes, but a lot more room for
error on the user's part.

> > The risk of liability are too high for them to give out this
> > information.
[quoted text clipped - 4 lines]
> What is the concrete risk in this case? How could giving out the data to
> correct historical BS levels lead to liability on their part?

Playing devil's advocate here, you starting with a user who has a
demonstrated capacity for error. He failed to coce his meter properly.
How easy would it be for him to a) pick the formula for the wrong code,
b) pick the wrong formula for the data vaule c) pick the wrong
direction (going from 13 to 17 or 17 to 13?), or d) misuse the formula?

> The info's
> probably available from their patent anyway.

It's probably proprietary. A full set of conversions that could reveal
specifics about the manufacturing process

> >> This is an instance where technology could (and should) help. The
> >> code number should be written onto each strip and read electronically
[quoted text clipped - 5 lines]
>
> Yes, but that's only any good to the people who use their PC software.

If one had it, they could use it *only* when they miscode their meter.
They wouln't have to use it all the time.

Reply to this Message

Alan Mackenzie - 26 Oct 2005 08:35 GMT

Tere <terence.griffin@nist.gov> wrote on 25 Oct 2005 13:28:55 -0700:

>> Tere <terence.griffin@nist.gov> wrote on 21 Oct 2005 11:42:43 -0700:

>> > Each code might represent an entirely different response curve. One
>> > might linear, and other might be a sinusoidal, and so on, with
>> > offsets, scale factors and/or constraints. That's assuming the
>> > response curve is even a function. The mappings from one to the
>> > other might be a little complicated.

>> I suppose that's possible, but I think it's very unlikely. I don't
>> know for certain, of course, but the designers of the device will
>> surely have made it as simple (reliable) as possible, given the
>> constraints of their marketing department. I would think that the
>> different code numbers are to compensate for inaccuracies in the strip
>> manufacture - they'll make a batch, then calibrate it.

> Actauly, I agree the examples I gave are a stretch. The point I was
> trying to make is that code number are arbitrary wrt to the mapping. A
> batch of reagent that gets code 17 may have a completely different set
> of corrections that a batch with code 18. And the correction may depend
> not only on the codes, but the value as well.

I think even that is unlikely. Code 17 will be "next to" code 18, for
some reasonable value of "next to". But as you say, the correction
probably won't be as simple as "subtract 3.2%". It will be likely vary
enormously over the range of BS values. Hmm. Maybe that computer
program you were suggesting isn't such a bad idea after all.

>> > A complete set mappings, from every code to every other, would have
>> > n*(n-1)/2 mappings, excluding inverse mappings (twice that with
>> > inverses). My Freestyle Flash has 50 possible codes. 1225 mappings
>> > w/o inverses.

>> Again, I don't think this would be true. From the given BS reading
>> and the code number which was used, you can go back to the
>> resistance/reflectivity/albedo/pH/whatever that the sensor measured in
>> the first place. Then you can go forward again, using the correct
>> code number.

> Ok. So for 50 codes, you have 100 mappings, two for each code, one to
> go back to the raw electronic values, an on to go forward to the
> corrected value. The user than has to apply two conversions to change
> from one code to the next. A lot fewer codes, but a lot more room for
> error on the user's part.

OK, I see what you're saying. Having a "17 to 20" mapping chart is much
less error prone than a "17 to raw sensor" and "raw sensor to 20".

>> > The risk of liability are too high for them to give out this
>> > information.

>> Ah yes, that old chestnut. Standard excuse used by pharma companies
>> to withhold essential information. Doesn't even involve having to
>> think.

>> What is the concrete risk in this case? How could giving out the data
>> to correct historical BS levels lead to liability on their part?

> Playing devil's advocate here, you starting with a user who has a
> demonstrated capacity for error.

Although that is not actually false, it is a massive misinterpretation of
the issue. ANY user could make such a simple mistake. It's normal human
failability. It's the gadget which is a at fault, providing no
safeguards against such error.

> He failed to code his meter properly. How easy would it be for him to
> a) pick the formula for the wrong code, b) pick the wrong formula for
> the data vaule c) pick the wrong direction (going from 13 to 17 or 17
> to 13?), or d) misuse the formula?

Just hang on a moment! We're not talking about introducing error where
there was none before. We're talking about correcting error which has
already happened. The correction will probably make the BS values
usable. The worst it can do is to convert unusable values to other
unusable values. I can't see how the most idiotic misuse could lead to
damage creating liability for the firm giving a conversion formula.

>> The info's probably available from their patent anyway.

> It's probably proprietary. A full set of conversions that could reveal
> specifics about the manufacturing process

You think so?

>> >> This is an instance where technology could (and should) help. The
>> >> code number should be written onto each strip and read
>> >> electronically by the meter when the strip is inserted into it,
>> >> thus obviating _another_ source of human error.

>> > Another idea would be to build a feature into their PC software to
>> > facilitate code changes.

>> Yes, but that's only any good to the people who use their PC software.

> If one had it, they could use it *only* when they miscode their meter.
> They wouln't have to use it all the time.

I suppose so.

Signature

Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

Reply to this Message

Tere - 26 Oct 2005 22:31 GMT

> Tere <terence.griffin@nist.gov> wrote on 25 Oct 2005 13:28:55 -0700:

[snip]

> > Actauly, I agree the examples I gave are a stretch. The point I was
> > trying to make is that code number are arbitrary wrt to the mapping. A
[quoted text clipped - 7 lines]
> enormously over the range of BS values. Hmm. Maybe that computer
> program you were suggesting isn't such a bad idea after all.

Could be. Without *knowing* what the response curves are, your
supposition is just as speculative as mine. All I'm say is they *could*
be quite diffferent. They might be a stack of similar curves offset in
slightly varying degees across the spectrum, numbered sequentially. But
we don't know that.

[snip]

> >> Again, I don't think this would be true. From the given BS reading
> >> and the code number which was used, you can go back to the
[quoted text clipped - 10 lines]
> OK, I see what you're saying. Having a "17 to 20" mapping chart is much
> less error prone than a "17 to raw sensor" and "raw sensor to 20".

If I were designing the software, I'd use your method and hide under
the user interface.

> > Playing devil's advocate here, you starting with a user who has a
> > demonstrated capacity for error.
[quoted text clipped - 3 lines]
> failability. It's the gadget which is a at fault, providing no
> safeguards against such error.

I agree. I'm speaking from a Comapny perspective. Their "safeguard" is
the explicit instruction to confirm the meter code *before each test*
(yeah, right).

I thnk there's an AccuChek meter that reads code from the strip. And
there's a company who puts a disposible meter on the cap of each bottle
of strips.

> > He failed to code his meter properly. How easy would it be for him to
> > a) pick the formula for the wrong code, b) pick the wrong formula for
[quoted text clipped - 7 lines]
> unusable values. I can't see how the most idiotic misuse could lead to
> damage creating liability for the firm giving a conversion formula.

But the the correctio process is even a little bit more complicated
than coding the meter in the first place, the Co lawyer will advise
them to keep the translation formuli secret.

The inital coding error might change a reading from 87 to 99. An error
in recoding might make it 220 or 53. That might be a liability issue.

> >> The info's probably available from their patent anyway.
>
> > It's probably proprietary. A full set of conversions that could reveal
> > specifics about the manufacturing process
>
> You think so?

[snip]

To the right person who knows these these (i.e. chemists at a
competitor's lab), yeah.

Reply to this Message