[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] protecting against clinical failure to review, or to resp
From: |
Jim Busser |
Subject: |
[Gnumed-devel] protecting against clinical failure to review, or to respond |
Date: |
Thu, 22 Jul 2004 19:18:05 -0700 |
One of my concerns with my present (fragmented) record system and
workflow / task management is trying to look out for things falling
between the cracks.
Even when I know about something that needs to be looked after, I may
have to postpone doing so or I may have begun but run into a delay on
account of some dependency.
I am wondering about a few areas where his is already provided (in
part) in gnumed and other areas where it could yet be structured.
For labs, we have the table test_result and the fields
- fk_reviewer (who has reviewed the item) and
- reviewed_by_clinician boolean (whether a clinician has seen this
result yet. Depending on the use case, this be simply set by any read
access by a clinican, or may follow specific business rules such as
"set as SEEN when treating/ requesting doctor has reviewed the item"
- clinically_relevant
So far so good. If it is a bad day in the office, say with the treating
doctor away, the covering doctor can have their work reduced by having
to view only the results that have been flagged technically_abnormal
(or, if there is unreliability of the test provider to flag these,
extending the set of results to include any result that is above an
upper range, or is below a lower range (say hemoglobin) or even any
result that lacks both {val_normal_min, val_normal_max}
One thing missing is whether the results require action. There is a
field clinically_relevant, but it best determines whether to include or
suppress in reviews of test history. Special tests even when resulted
normal, may be useful to mark "clinically_relevant" so as to keep them
in view, to be able to later see that these tests have already been
done.
If we add one field, something like "for_action" or "hold" or "track",
it could help
- a covering doctor to flag it for action/attention by the treating
doctor e.g. in cases where the business logic would otherwise have
considered the result reviewed_by_clinician, and therefore dismissed
it, OR
- the treating doctor wants to keep it flagged, because they have not
yet had time to i) think enough on it, or ii) act on it, or iii) want
the flag to remain as a reminder to re-measure it at some later time.
Some of the above could be achieved by the "cheat" of keeping (or
re-setting to) FALSE reviewed_by_clinician, but the downside is that
the covering doc will have to keep looking at it not only until the
treating doctor's return but even beyond, at their next absence, and
the treating doctor, once they acknowledge the review, would be left
with no "action flag".
The GUI could provide the reviewer options to
- mark / unmark ... all / selected ... [as] reviewed [as]
flag_for_action
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] protecting against clinical failure to review, or to respond,
Jim Busser <=