[Top][All Lists]

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

Re: [Gnumed-devel] test results and therapeutic ranges (was Possible de

From: J Busser
Subject: Re: [Gnumed-devel] test results and therapeutic ranges (was Possible development opportunity)
Date: 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.

reply via email to

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