Re: [Gnumed-devel] test results and therapeutic ranges (was Possible development opportunity)

[J Busser]

At 11:04 PM +0200 9/13/04, Karsten Hilbert wrote:
> val_target_min/val_target_max/val_target_range which I
> agree sounds like a useful addition. ...
> ... your idea seems to make so much sense that I already
> added the fields in the schema and value object.

Thanks!

But what would be good methods to populate the val_target fields?

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!) or

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.

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.

3. A script might instead do this automatically, based on information 
kept somewhere else in the schema. Scripting a connection from a 
clinical SOAP note "Plan" (e.g. INR 2.5-3.5) risks being too fuzzy. 
Ah! but as you start the patient on a warfarin or some other drug, it 
may make sense to plan immediately your next INR or drug level, so 
maybe it is in lab requests that the target (or at least a comment) 
can be pre-entered. Lab requests that were coded as once-only would 
in time disappear out of view, but if lab requests were to support a 
"standing" or recurring test, the target range info can be preserved.

When reviewing results, there is likely agreement that any 
originating lab requests be brought into view even if there had been 
no script to write the targets forward.

Future test_results rows:

Once a target has been entered for any patient / test combination, 
the information should be copied forward into newer rows until the 
target is removed. Therefore after importing gnumed would have to 
either re-analyse the test_results table studying the most recent 
unique patient-test combinations from BEFORE the import or gnumed 
would have to check some other place (like lab requests?) for the 
presence of information to help it fill in the values. If the latter 
has advantages, it could require the the lab requests row to carry a 
code that will match the test uniquely (in centres whose labs will 
carry a unique code through the entire trip) or at least by test type 
which may be better in case you are copied an INR ordered by someone 
outside the gnumed practice (but of course, if someone else ordered 
it, maybe they changed the target, too, so it may be smart to not 
fill in the target automatically for patients whose test was order by 
someone outside gnumed - if appropriate, the target could still be 
filled in using (2) above.