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

[J Busser]

At 4:14 PM -0700 9/13/04, J Busser wrote:
> But what would be good methods to populate the val_target fields?
> > Karsten replied Mainly, this is a frontend issue...

Agree

> For any rows that exist prior to first entering a patient's targets:
>
> 1. User could manually edit each row to which a value is applicable (a pain!)
> > At 3:54 PM +0200 9/14/04, Karsten Hilbert wrote:
> > I would offer a button "apply to all rows of this test for
> > this patient back until XXX".
> 2. User could work backward from the most RECENT target range, 
> manually edits the OLDEST row to which a target range is applicable, 
> and the targets are written forward into the newer values. (If in 
> working backwards, the patient were most recently deliberately taken 
> OFF warfarin or coumalone, the user would presumably  need to fill 
> *something* into these fields (val_target_max = 1.1?), to prevent 
> these rows from being overwritten by an earlier "on-treatment" 
> target range. Or the widget would have to offer to constrain the 
> rows on which the operation is being applied.
> > At 8:09 AM +1000 9/15/04, sjtan wrote:
> > too fuzzy. leaving it blank and making the user decide sounds 
> > easiest and safer, even if it is a pain to enter each time.
>
> The user may find it sufficient to stop there, or could choose to go 
> back further in time and code in one (or more) previous ranges.

So there is agreement that filling in each row by hand is a pain
(and therefore is not likely to be done?!).

Also agreement it needs to be safe (no unintended consequences).

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. So I would foresee, for clinically_relevant, the front 
end assisting/guiding the doctor by providing views among:

- test_results whose values are flagged by the lab
   as within (or outside of) the reference range
   and/or
   within (or outside of) target [if the data permits]
- test_results which lack reference flagging information

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

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

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?