[Top][All Lists]

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

Re: [Gnumed-devel] test results and therapeutic ranges

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] test results and therapeutic ranges
Date: Thu, 16 Sep 2004 03:28:24 +0200
User-agent: Mutt/

> But also keep in mind that if we respect Karsten's caution, then 
> clinically_relevant will never be decided nor have its value assigned 
> automatically.
Yes, but still results can be marked to be outside val_normal
and/or val_target visually in the frontend guiding the doctor
to those results likely needing a decision on
clinically_relevant now.

> - test_results whose values are flagged by the lab
>    as within (or outside of) the reference range
We already have that thanks to Sebastian.

>    and/or
>    within (or outside of) target [if the data permits]
That we don't yet have thanks to my just having added it to
the schema ;-)

> - test_results which lack reference flagging information
didn't think of that before, hm

> The above could assist the doctor to code more than one row at a time 
> to an appropriate boolean value of clinically_relevant (or not) - BTW 
> do boolean data types in PG support a default of "null"?
Yes. Three-valued logic provides for typed NULLs effectively
saying "I don't know the answer to that question but whatever
it may be it will be of <this> type."

> So if we can abide computer-assisted "filling-in" of the *target* 
> data, is it reasonable to design it to be limited to a *contiguous* 
> graphical selection of test_result rows or, nongraphically, a 
> SELECTion of FROM <DATE> TO <DATE> rows for target-filling, ALL OF 
> WHICH MUST BE LIMITED TO a single value for fk_type (e.g. the LOINC 
> or equivalent Au/German code) WHERE  the presence of any data in any 
> of the selected target rows should invalidate the fill (or, 
> optionally, offer to complete the fill up to -- but not including -- 
> the row that contains target data)?
Well, basically *any* combination of result rows that the user
has on-screen and decides to flag/reference either way. Even a
button "set target range for all INRs you find to
such-and-such" is fine since clicking that button is a
(perhaps unwise) user decision.

> And since it is possible that targets previously entered into a row 
> were wrong, the target info contained in one or more such rows -- 
> again where they are contiguous -- could sensibly be allowed to have 
> their target info overwritten, if that is what the doctor wishes done?
Sure. For good measure the old target range is fully audited.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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