Thomas Beale wrote: > > Concerning my last reply on this subject, > > I feel the appropriate solution is: > * add an attribute value_qualifier of type STRING with allowable values >>, <, >=, <=, = (since this is a closed list, using coded terms doesn't > seem to be useful) > * allow ELEMENT.null_flavour and DV_QUANTIFIED.accuracy to be used to > cover Vince's Inaccurate (probably wrong) and '~' (slightly inaccurate, > but usable value) cases respectively. In the latter case, it seems to me > that if accuracy is going to be reported, it should be quantified, the > way we do it in openEHR, i.e. +/- 5%, +/-2 and so on. Vince - am I being > unreasonable? Did you have '~' because labs devices output this?
If you are going to capture error limits around a scalar quantity, then you need to also capture the nature of those limits. Sometimes they are simply co-efficients of variation, sometimes one or two (or 1.96) standard deviations (as frequentist confidence intervals for normally distributed data, or asymptotically normal confidence limits for non-normally distributed data), sometimes they are non-normal confidence limits, and occasionally (but often with clinical trials etc) they are Bayesian credible intervals. Then there is the confidence level - often 95% but sometimes 99%, sometimes less. Will the proposed solution cover these and other scenarios? Tim C > Grahame Grieve wrote: >> hi >> >> I don't think that the concept of <,> etc should >> be conflated with the concept of approximately >> and doubtful in the model. the approximate and doubtful always raise >> the issue of why and how and so I think that should be a matter for >> the archetype to resolve. However < and > etc, should be a data type >> thing. >> >> Grahame >> >> > Grahame, you are right - to express ">5 (inaccurate)" we need two flags... > > I can't think of great names of the top of my head, but how about: > > * value_qualifier - the attribute that carries the <, >, = etc > * value_status - an attribute that carries some other possible > flags, e.g. ?, ~, others? > > I am suggesting that Vince's '~' is more like a data quality marker than > an indicator of how to read the value...'?' means inaccurate....possibly > wildly? Are '~' and '?' really different? If the second flag was just to > say accurate / inaccurate then we could just use a Boolean. That would > probably cover 95% of needs and be simple at the same time....Vince - > any comments on that? > > I think we are close to a solution here. > > - thomas >
