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?
Unless better ideas surface, I will create a CR on the basis of the above.
- thomas
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
