Pathology numeric values not supported in DV_Quantity

[Sam Heard]

An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/bd767cfc/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Vincent McCauley]

Hi Sam,
This case is I believe actually a measure of accuracy of a result.

In my pathology system, I deal with it by having a separate attribute on 
quantity
It takes values such as >, <, >=, <=, ~   
(~ => approximately, I => Inaccurate)

the value "I" may be used for instance when an analyser returns a potassium 
value
which on subsequent examination of the blood is shown to be erroneously 
high due to haemolysis. This is usually accompanied by some text which
is displayed instead of the numeric value e.g. HAEM but the underlying
numeric value needs to be stored anyway as well.

This of course makes the logic for deciding whether a result is within a normal 
range
more interesting and graphing routines etc need to take this flag into account.

I don't feel strongly whether you deal with this as part of the quantity 
datatype or have a new
datatype inheriting from quantity.

Regards
Vince

Dr Vincent McCauley MB BS, Ph.D
McCauley Software Pty Ltd


- Original Message - 
  From: Sam Heard 
  To: Heath Frankel 
  Cc: Tom Beale ; Openehr-Technical 
  Sent: Wednesday, March 01, 2006 12:41 PM
  Subject: Re: Pathology numeric values not supported in DV_Quantity


  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 http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/f137d66f/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Tom Tuddenham]

I may be missing the mark, as I come orginally from a process control
background, so apologies if this sounds like an engineering solution.
 
There is a mechanism in OPC (common protocol for getting information out of
machines) to where each data point can be identified according to the
quality of the data - e.g. OPC_QUALITY_GOOD, OPC_QUALITY_BAD,
OPC_QUALITY_UNCERTAIN. There is a further qualification for why the data is
bad (connection problems, config error, etc) but the record still contains a
actual value, so it can still be plotted, but if it can also be filtered
out. I guess this is essentially what you were saying Vince. 

Unless I've misunderstood what Sam has proposed, the problem with a
substituted value is that it's not going to reflect the recorded value - ie.
a chart won't show the "true" erroneous data.

-Tom



From: Vincent McCauley [mailto:vin...@mccauleysoftware.com] 
Sent: Wednesday, 1 March 2006 2:12 PM
To: openehr-technical at openehr.org
Cc: Tom Beale; Heath Frankel
Subject: Re: Pathology numeric values not supported in DV_Quantity


Hi Sam,
This case is I believe actually a measure of accuracy of a result.
 
In my pathology system, I deal with it by having a separate attribute on
quantity
It takes values such as >, <, >=, <=, ~   
(~ => approximately, I => Inaccurate)
 
the value "I" may be used for instance when an analyser returns a potassium
value
which on subsequent examination of the blood is shown to be erroneously 
high due to haemolysis. This is usually accompanied by some text which
is displayed instead of the numeric value e.g. HAEM but the underlying
numeric value needs to be stored anyway as well.
 
This of course makes the logic for deciding whether a result is within a
normal range
more interesting and graphing routines etc need to take this flag into
account.
 
I don't feel strongly whether you deal with this as part of the quantity
datatype or have a new
datatype inheriting from quantity.
 
Regards
Vince
 
Dr Vincent McCauley MB BS, Ph.D
McCauley Software Pty Ltd
 
 
- Original Message - 

From: Sam Heard   
To: Heath Frankel   
Cc: Tom Beale   ;
Openehr-Technical   
Sent: Wednesday, March 01, 2006 12:41 PM
Subject: Re: Pathology numeric values not supported in DV_Quantity

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

Pathology numeric values not supported in DV_Quantity

[Sam Heard]

An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/14f81e20/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Karsten Hilbert]

On Wed, Mar 01, 2006 at 08:31:23PM +0930, Sam Heard wrote:

> I like the flags - I wonder if we should have a ? or ! for the value affected
> by a quality issue - what do others think?

Probably "?" for dubitable results. "!" is commonly used
here for marking up (perhaps unexpectedly) clinically
important results (such as an *unusually* high titer of
something where I expected either normal or somewhat
elevated).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Pathology numeric values not supported in DV_Quantity

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/d9463cb7/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Gerard Freriks]

Thomas,

I agree it is very common.
But when <5 is reported in essence it means that it is an exception.
It is not a precise result. It does not mean that it is less than 5  
only. It means that something of an exceptional state in in order.
It could be zero, it could be 4.999.. And anything in between but not  
an exact figure like x=5.1 units of a kind.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 1-mrt-2006, at 14:10, Thomas Beale wrote:

> Gerard's point about <5 etc being an exception is not quite right -  
> it's very common;

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/afb34099/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Gerard Freriks]

Hi,

yy
What does it mean?

To my mind it semantically means a state of exception. Meaning not  
only that the measurement is yy but that it is unmeasurable.

If this reasoning is true than each archetype with a measurement  
needs an exception attribute.
In general this will be true in many more circumstances.

Each possible statement (data item and/or archetype) can have a few  
states:
requested/expected- unrequested/not expected  (eg expected is TSH  
measurement but unrequested and unexpected the response is TSH>2000  
as an indication of exception)
As exception there are at least two possibilities:
known-unknown.  (eg RR 120/unknown mmHg. TSH was measured and  
presented but it must not be considered a real result it is in doubt)
true-untrue (eg I measured RR 60/80  this measurement I consider  
untrue, but it was that was was measured. TSH >2000 but is untrue  
because it was unmeasurable)


Gerard




--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 1-mrt-2006, at 2:41, 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  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.
> 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
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060301/7385b9e6/attachment.html>