[Top][All Lists]

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

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

From: J Busser
Subject: Re: [Gnumed-devel] test results and therapeutic ranges
Date: Tue, 14 Sep 2004 19:38:32 -0700

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


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

reply via email to

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