Vincent McCauley wrote:
> Hi Thomas,
> Specific points:
> 1. My pathology software supports <= and >= in this context but I have
> not come across an automated blood analyser
> interface that supports or requires this and in the couple of databases
> I looked at (approx. 15X10^6 numeric values over 8 years) no user has
> used these values.
hopefully your software did that for you, else I shudder to think of
what your bedside reading looks like!
> So probably good for completeness but no apparent use in the real world!
>
yes, my suspicion exactly...
> 2. The "Inaccurate flag" generally means that for some reason this
> value should be treated with caution
> or is unreliable.
> It may in fact be perfectly accurate (as in the haemolysed blood K+
> example) but not actually a
> measure of the defined analyte - i.e. rather than a serum K+ value
> what was measured was
> serum K+ contaminated with Intracellular K+.
probably if the analyte name is already chosen by the archetype, we have
to assume inaccurate - it is only by an expert visually reading the
result, and knowing the the sample was haemolysed, that the inference
you made above can be made. Certainly from the point of most normal
software, it will be an error.
> Similar issues occur with cold agglutinins (inaccurate values if
> performed on specimen
> not kept at body temp) and Serum glucose measured on a specimen which
> does not
> contain a metabolic inhibitor ("fluoride tube") which has been kept at
> room temp for too long.
> At other times it may actually be inaccurate e.g due to failure to
> calibrate an
> analyser correctly.
>
> The fact that the value is unreliable often only becomes apparent
> after the event
> e.g. the doctor rings up to query a high normal K+ on a patient whose
> K+ value
> was expected to be low and a visual/microscopic examination of the
> specimen
> reveals haemolysis
so we can assume that the initial import of the data (e.g. form an HL7v2
message) into openEHR, it won't be marked as unreliable/inaccurate; but
due to phone calls etc, discovers the problem. Two things could happen then:
a) the lab re-issues the same result with a "haemolysed" marker on it;
this will be imported into openEHR as a new version of the existing
result, and it will now correctly be marked inaccurate...although - how
will this happen exactly? Will the lab mark which analyte values are now
inaccurate, or only the fact that the sample was haemolysed, leaving the
receiving doc to eyeball the result and make the appropriate conclusions?
or
b) the doc modifies the EHR in situ, making a new version of the result
in whihc the inaccurate flag is set on the appropriate analyte value of
the test result.
and...the test is possibly re-ordered and we start again...
> In the case of a badly calibrated analyser, statistical analysis of
> values performed routinely may demonstrate
> that there has been an unacceptable variability in results or the
> average result
> was significantly higher than expected or
> (as happened very memorably in my practice in the Emergency department)
> the values over a period of time fail to correlate with the clinical
> condition of the patients.
>
> So it is absolutely necessary to be able to record (and keep) the
> value but be able to flag it either at the time or sometime later as
> unreliable/inaccurate.
> It is probably not worth (or even in some cases possible) to decide
> whether an erroneous result is inaccurate or unreliable.
Hmmm - I am starting to think we should just use the ELEMENT.null_flavor
for this - that's what it's there for. openEHR's versioning takes care
of the retrospective changing of the data.
>
> 3. Rules need to be provided as to how such values should be treated
> when comparing
> with normal ranges. For example if the normal range is 0-6 and the
> value given is <5 then
> this is normal. However if the normal range is 0-3 is this a normal
> value or not?
> This can be dealt with by "flavours of null" on a "normality flag".
you mean we need a "normality" flag and flavours of null on that?
>
> 4. Applications such as graphing, statistics packages etc. need to be
> aware of
> such values and treat them appropriately. Some general guidance/rules
> around this for
> developers/users may be appropriate.
I can see there being an "openEHR pathology manual" some time soon;-)
- thomas
