[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] test results and therapeutic ranges (was Possible de
Re: [Gnumed-devel] test results and therapeutic ranges (was Possible development opportunity)
Mon, 13 Sep 2004 16:14:47 -0700
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.
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.