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

[Karsten Hilbert]

> >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?
Mainly, this is a frontend issue. And it would surely depend
on the purpose one is trying to serve.

> 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
I would offer a button "apply to all rows of this test for
this patient back until XXX".

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

> 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
Well, in that case just put the target range on the next
incoming INR which would be the first in question.

>, so maybe it is in lab requests that the target (or at least a comment) 
> can be pre-entered.
The way the German importer works is that it won't
overwrite/update existing lab results. However, nothing
prevents one from updating pre-existing test result rows given
very specific criteria are met. On those the target range
could be applied.

> Lab requests that were coded as once-only would
In Germany we don't generally encode a connection between
subsequent tests. All of them are one-shot even if related.

> 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.
Also, lab requests don't support tests in the sense that they
specify which tests were actually ordered by that request
(which *could* be done, perhaps even without changing the
backend). They just state "do with the following samples as
stated on the accompanying reader card".

> 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.
Yes, however, copied forward information must never be used to
auto-compute clinically_relevant. It can be used, however, to
flag out-of-range in a list of *unreviewed* results.

> 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
Likely the practical solution.

> or gnumed 
> would have to check some other place (like lab requests?) for the 
> presence of information to help it fill in the values.
Again, GnuMed lab handling currently doesn't track the tests
requested. It could, however, if pre-entering test_result rows
was done and updating of such would be done by the importer.
However, that would fall foul at the mercy of the "standard
vocabulary dilemma" as you said.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346