The DV_AMOUNT and DV_ABSOLUTE_QUANTITY classes contain (optional)
accuracy attributes. However the specifications for the outcome of
mathematical operations (especially the add/subtract operators) seem
to be silent on the accuracy of the results of these operations. Is
this intentional or an omission in the specs?
that is indeed an omission. I think that both addition and subtraction
of two quantities with accuracies of +/- x and +/- y respectively must
give a result with an accuracy of +/- (x+y). Can someone confirm this?
If so, I will raise the CR.
The DV_AMOUNT and DV_ABSOLUTE_QUANTITY classes contain (optional)
accuracy attributes. However the specifications for the outcome of
mathematical operations (especially the add/subtract operators) seem
to be silent on the accuracy of the results of these operations. Is
this intentional or an omission in the specs?
that is indeed an omission. I think that both addition and subtraction
of two quantities with accuracies of +/- x and +/- y respectively must
give a result with an accuracy of +/- (x+y). Can someone confirm this?
If so, I will raise the CR.
While we are on this, maybe we should consider how two precisions (optional attribute of DV_QUANTITY) can be combined as well.
What intrigues me is the definition of accuracy from the NIST guide (terminology):
– Because “accuracy” is a qualitative concept, one should not use it quantitatively, that is, associate numbers with it; numbers should be associated with measures of uncertainty instead. Thus one may write “the standard uncertainty is 2 µΩ” but not “the accuracy is 2 µΩ.”
Does this mean that we perhaps should have some other term than “accuracy” for the attribute?
What intrigues me is the definition of accuracy from the NIST guide
(terminology):
-- Because "accuracy" is a qualitative concept, one should not use it
quantitatively, that is, associate numbers with it; numbers should be
associated with measures of uncertainty instead. Thus one may write
"the standard uncertainty is 2 µΩ" but not "the accuracy is 2 µΩ."
Does this mean that we perhaps should have some other term than
"accuracy" for the attribute?
In openEHR we chose the normal engineering definition (being an
engineer;-), which is what you find at wikipedia - http://en.wikipedia.org/wiki/Accuracy
For openEHR's purposes, accuracy is a side-effect of an instrument's
(including any human sense used to measure) inherent error in measuring
quantities (due e.g. to the kind of construction and/or calibration) and
is usually quoted using +/- x% or +/- x.
Precision is how finely the result is quoted, e.g. on a dial or digital
readout, and in openEHR it tells the numnber of decimal points, i.e.
significant places.
The accuracy of an addition or subtraction is indeed the sum of the accuracies of the operands. This is common practice to ensure that the measurement fault in source measurements is propagated into derived values.
A further question that then arises, is what to do with values for which the accuracy is +/-0. The OpenEhr spec reserves this values as indicating that the accuracy has not been specified. I take it that the outcome of any mathematical operation on a value with unrecorded/unknown accuracy must have an unrecorded/unknown accuracy itself. However, if that is the case, the calculation of formulas that have constants (which have a true accuracy 0) becomes an issue, because the OpenEhr spec currently does not seem to allow for the representation of values with a +/-0 accuracy.
> While we are on this, maybe we should consider how two precisions
> (optional attribute of DV_QUANTITY) can be combined as well.
> I didn't manage to find any guideline on how to combine accuracies
> from two quantities. But there are guidelines on expressing
> uncertainty from different national/international bodies, e.g. this
> one from NIST, http://physics.nist.gov/Pubs/guidelines/contents.html
> and /Guide to the Expression of Uncertainty in Measurement/, GUM from
> ISO:
> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45315
>
> What intrigues me is the definition of accuracy from the NIST guide
> (terminology):
> -- Because "accuracy" is a qualitative concept, one should not use it
> quantitatively, that is, associate numbers with it; numbers should be
> associated with measures of uncertainty instead. Thus one may write
> "the standard uncertainty is 2 μΩ" but not "the accuracy is 2 μΩ."
>
> Does this mean that we perhaps should have some other term than
> "accuracy" for the attribute?
In openEHR we chose the normal engineering definition (being an
engineer;-), which is what you find at wikipedia - http://en.wikipedia.org/wiki/Accuracy
For interoperability, clinical value should be standardised and
calibrated in same criteria. While physiolosical data is usually available
in the other hospitals, biochemistry data is not usable. Because one
meter or one kirogram means same value all over the world, but LDH
138IU/l sometimes means different value in each laboratory. JCTLM (Joint
Committee for Traceability in Laboratory Medicine) / ILAC (International
Laboratory Accredition) are establishing a worldwide platform to promote
and give guidance on internationally recognized and accepted equivalence
of measurements in laboratory medicine and traceability to appropriate
measurement standards. However, it will take long time to standardise
whole data measurement all over the world, data acuracy should be
disscussed on two aspects; method and criteria.
As the definition of the Wikipedia, I think 'precise' means the
reproducibility of data in the laboratory and 'accuracy' means the
coordination with such a criteria in laboratory medicine.
For openEHR's purposes, accuracy is a side-effect of an instrument's
(including any human sense used to measure) inherent error in measuring
quantities (due e.g. to the kind of construction and/or calibration) and
is usually quoted using +/- x% or +/- x.
Precision is how finely the result is quoted, e.g. on a dial or digital
readout, and in openEHR it tells the numnber of decimal points, i.e.
significant places.
Is it adequate that DV_AMOUNT and DV_ABSOLUTE_QUANTITY have 'method' and
'criteria' attribute?
This is one of the reasons I’ve started the discussion about quality some time ago and I think this accuracy discussion is in the same ‘corner’. For any given measured value in an EHR one needs to be able to establish whether a) the value given represents the actual value (i.e. the data quality) and b) the accuracy: i.e. what is the bandwith for this value: is it 134 +/- 100 or 134+/-1.
So in order to be able to interpret data measured by others, one need to have access to a lot of additional data: In which laboratorium was it measured, by who, which machine was used, was this machine properly calibrated and maintained, who operated the machine, was the operator properly trained etc. etc.
For this reason I proposed a different ‘device archetype’ similar to a demographic AT in which device/ machine related data can be stored and independently updated and re-used as time a measurement is done. I don’t know if that’s the (only) way to solve this but unfortunately this discussion stopped. I still feel this should be finished.
Furthermore one needs to know what the internal protocol/standard is and what the reference standards are. If a the measurement is performed according to the internal standard, by a trained person of a properly maintained machine it’s quality is ‘good’ according to the standard used. If the value 138 is within the internal reference standard it’s ‘normal’.
If in my place we use the same or a similar rotocol/standard I can use the measured value in an evaluation
Still it’s well possible that in my place we use a different rotocol/standard and that I’ve to reject the measurement. In that case I have to measure the value again.
Hello
This is a useful thread. I just want to add a couple of issues:
If two numbers of different precision are added then the result cannot have more precision than the lesser of the two - is that right?
The Microsoft CUI has a tick box for ‘approximate’ on dates. OpenEHR and the CUI have partial date times. I wonder how people feel about the tick box in terms of the ‘accuracy’ of the time. The issue that ‘approximate’ allows that is not possible with partial is for loose idea of time within the scope of that unit - so 11:30 approximately does have more meaning than 11 without minutes.
Interested in other’s views.
