[snip]

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]

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

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.

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.

[snip]

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

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

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.

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".

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.

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.

You think so?

I suppose so.

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.

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.

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?

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

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

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

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.

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.

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.

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

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.

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

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.

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