gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] test results and therapeutic ranges (was Possible dev


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] test results and therapeutic ranges (was Possible development opportunity)
Date: Mon, 13 Sep 2004 23:04:41 +0200
User-agent: Mutt/1.3.22.1i

> Before considering the target range for Patient X with an INR of 
> 2.0-3.0, can we also consider the handling of a drug whose levels can 
> be measured, and which has a therapeutic range which
> - may depend on the indication and/or
> - may be changed by the doctor who wants it narrower/higher/lower than "usual"
Agree.

> 1) have we a suitable place to keep this patient-specific 
> information, perhaps linkable to the test, so that when the test 
> result is reviewed we can easily discern if we are satisfied?
We have val_normal_min/val_normal_max/val_normal_range which
are *per test result* - eg. two INR results for the same
patient may very well have different *normal* values. We also
have technically_abnormal to flag results outside the *normal*
range as well as clinically_relevant to flag our decision on
whether the result is relevant as is (regardless of *normal*
and/or technically_abnormal). What we *don't* have is a way to
say val_target_min/val_target_max/val_target_range which I
agree sounds like a useful addition. Often the lab does not
and cannot know about these ranges.

> 2) table test_results has fields
> - val_normal_min
> - val_normal_max
> - text field val_normal_range
> all of the above are meant to hold values provided by the lab
Correct. They *could*, however, be used to store locally
determined values for normality, too, if one takes care that
the lab data importer does not enter data into those fields.
The German importer does. An AU one doesn't have to.

> when a lab supplies for example phenytoin/dilantin result of 56 and 
> provides a numeric or text range of 40-80 do we place that in the 
> _normal_ field(s) in which case they are no longer _normal_ but 
> _reference_  ?
Why are they "reference" instead of "normal" ? IMO "normal"
means "as expected given the known circumstances". Of course,
when circumstances are not known to the lab the ranges they
send as normal may very well be different from what we want
the value to be.

> maybe it is better to have a separate set of fields in addition to 
> _normal_ considering that when a biologic test like INR comes back at 
> 1.5, this is abnormally elevated in some people, but it is 
> subtherapeutic in someone on warfarin
Which would IMO be served by *_target_* quite adequately ?
"Therapeutic" is too restricting as the target range may be
different from "normal" for reasons other than therapy.

In fact, your idea seems to make so much sense that I already
added the fields in the schema and value object. They don't
hurt in any case.

> could it be a good idea to write a patient's corresponding target 
> values into the test-result row, either overwriting the lab's 
> reference range or (if these must be preserved as original 
> communication) into value_target_min and value_target_max?
That's another way of doing it.

> I am wondering if this would make querying and reporting faster, 
> separating patients who will need a change of dosage (needing quicker 
> contact) from the others?
Not necessarily faster (unless one uses fancy functional
indexes that operate on value and normal ranges) but surely
more selective.

> Also, once having written the target info 
> into the test_result row, the row would remain meaningful even after 
> a doctor later raises or lowers Patient X's range.
Surely.

> I realize that a 
> within-patient history of changes to target ranges should be 
> accessible via the audits,
They are. Changes to the test_result table are fully audited.
Also, they would be stored along with *each* individual
result.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]