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
Thomas Beale wrote:
> Just going through the replies we have had on this one.....
>
> * Gerard's point about <5 etc being an exception is not quite right - it's
> very common; it's usually to do with sensitivity of instruments (i.e.
> accuracy), but there are also analytes which are reported as just being
> over a threshold since any number larger than X is fine (e.g.
> glomerulin,
> Sam tells me).
> * this is not an indication that the data type is really a DV_INTERVAL or
> DV_QUANTITY_RANGE - it is clearly not. When we see "HCO3: <5 mmol/L" we
> are not reporting an interval of 0 - 5 mmol/L, we are reporting a point
> value somewhere in 0-5, but we don't quite know where.
> * Tom Tuddenham's point is also correct. In openEHR, we actually do have a
> data quality marker (I used to work in SCADA as well, and lived with
> this
> kind of stuff for years!). It is called null_flavour and is defined on
> the
> ELEMENT class, next to the value attribute, which is the one that holds
> the Quantity that we are talking about (or some other kind of data value
> in other circumstances). Here we have a more fine-grained occurrence of
> the same problem, for slightly different reasons: the instrument or
> measuring method and data communicatoins are working as they should,
> it's
> just that either the value is too low or high for quantification by the
> instrument, or else the instrument doesn't bother reporting it above or
> below a certain threshold, since it is known that any value above/below
> is
> healthy. Nevertheless, we have to treat it in a similar way - probably
> with a flag that indicates 'status' of the value.
> * in practical terms we have to deal with the fact that quantities in the
> form of single-sided intervals with <, >, <=, >= can be mixed in with
> normal point value quantities, or replace them, on a per test-result
> basis.
> * we also have to have a solution that is easily comprehensible in the
> model
> and for software developers. Allowing INTERVALs to magically replace
> QUANTITY as is done in HL7 is not the way to do it, since there is no
> clean basis in the modelling to do this (i.e. it's not normally possible
> in OO languages - you have to do something quirky to make it happen.);
> in
> any case, as pointed out above, DV_INTERVAL is not semantically correct
> in
> these cases anyway.
>
> My analysis is that we need to slightly extend DV_QUANTIFIED (supertype of
> DV_COUNT and DV_QUANTITY, as well as all the date/time types), in the way
> that
> Vince has said (probably Vince worked this solution out years ago;-)...so
> that
> the semantics are:
>
> * a magnitude
> * NEW ATTRIBUTE: a status flag - with the following possible values:
> o > : greater than
> o < : less than
> o >= : greater than or equal to (Vince, do we really need this and
> the next one - do you get real values where it is reported like
> this?)
> o <= : less than or equal to
> o = : exact point value (i.e. the default situation)
> o ~ : approximately equal to, i.e. like '=' but with some unknown
> error
> o ? : innaccurate...what does this mean? If it is due to haemolysed
> blood then is it "inaccurate" or is it really just plain "wrong"
> ("incorrect")?
> * accuracy
> * ..other attributes, depending on subtype
>
> Adding a flag will be easy in modelling and software terms. What we have to
> do
> is carefully design the values; Vince has provided what is probably just
> about
> right, but I would like to be sure - see notes above on the list. Also,
> remember
> openEHR QUANTIFIED class already has accuracy as a Real - it can be a % or
> absolute value, so that any DV_QUANTIFIED can be created with a +/- 5% or
> whatever. Given this, do we need the '~' flag (maybe we do: maybe there is no
> accuracy data available, and all we can get from a legacy feed is '~')? And
> isn't the "inaccurate" flag (as Vince named it) about something else? As
> Vince
> said, doing this means more careful data analysis to determine whether a
> value
> is normal or not, and how it should be graphed. Do we need to take this into
> account in the model in some way - there is already another CR to adjust how
> normal_range is modelled, and we have an is_normal function defined on
> DV_ORDERED (the ancestor of all the Quantity types in openEHR).
>
> If we can get a bit more discussion on these details, I think we can fairly
> quickly state what changes are needed and write a CR for them.
>
> - thomas
>
>
>
>
>
>
> Sam Heard wrote:
>> Hi everyone,
>>
>> We want to report an issue that has arisen in data processing in Australia.
>>
>> The issue is the somewhat random ability of systems to report a >xx or <yy
>> range where a quantity is expected - there are still units and still a
>> normal
>> range. This is common with TSH and GFR - but can turn up in unexpected
>> instances - e.g. we had a baby with a HCO3 of <5 mmol/L. This can be dealt
>> with at present by substituting an interval - but it is a bit wierd as there
>> is still a normal range - it kind of works as there is only a lower or upper
>> value of the interval and so this single quantity can carry the normal range.
>>
>> The point is that it is really a point measurement that is outside the range
>> of the measuring device. Also, it means that we will have to have archetypes
>> that allow multiple datatypes for all quantities that could conceivably be
>> measured in this way.
>>
>> The alternative is to consider a DV_QUANTITY_RANGE that inherits from
>> DV_QUANTITY - it still has only one value - but now it has the ability to
>> set
>> this as the upper or lower value - and also whether this number is included
>> or
>> not.
>>
>> The advantage is that there would still be a number to graph and this data
>> type could always be substituted for a DV_QUANTITY (ie without archetyping).
>>
>> I wonder what others think.
>>
>> Cheers, Sam
>> --
>>
>>
>> Dr. Sam Heard
>> MBBS, FRACGP, MRCGP, DRCOG, FACHI
>>
>> CEO and Clinical Director
>> Ocean Informatics Pty. Ltd.
>> <http://www.oceaninformatics.biz/>Adjunct Professor, Health Informatics,
>> Central Queensland University
>> Senior Visiting Research Fellow, CHIME, University College London
>> Chair, Standards Australia, EHR Working Group (IT14-9-2)
>> /Ph: +61 (0)4 1783 8808/
>> /Fx: +61 (0)8 8948 0215/
>>
>>
>
>
> --
> ___________________________________________________________________________________
> CTO Ocean Informatics (http://www.OceanInformatics.biz)
> Research Fellow, University College London (http://www.chime.ucl.ac.uk)
> Chair Architectural Review Board, openEHR (http://www.openEHR.org)
>
--
Grahame Grieve
CTO, Jiva Medical Software Integration Tools
CTO, Kestral Computing Healthcare Applications
