[Top][All Lists]

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

Re: access to review audits (was Re: [Gnumed-devel] encounter edit befor

From: Karsten Hilbert
Subject: Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save)
Date: Sat, 16 Aug 2008 12:43:23 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Aug 16, 2008 at 01:28:35AM -0700, James Busser wrote:

>> GNUmed currently also supports
>> a) unsetting the review status when a document part is changed
>> b) thereby re-notifying the responsible clinician via the inbox
>> c) notify the responsible clinician of a test results review change  
>> via the inbox
>> Jim, do you think we should invalidate a test results review
>> when said result is modified ? (this would, in turn, notify
>> the responsible clinician courtesy of the then-lacking review)
> I am not sure of the difference between
>       c)
> and
>       if we would "invalidate a test results review"

Well, a change in review of a test result can happen
directly (a user changing the review) or indirectly (a user
changing the result which would trigger database-side
invalidation of a pre-existing review -- which would *then*
notify the reviewer by the aforementioned mechanism). The
former currently works while the latter is not implemented.

> Do both test against whether the last reviewer was
>       test-result.fk_intended_reviewer

Lemme check...

No, it notifies the previous reviewer, no matter who it was.

> Also, should there be a configuration setting which determines whether or 
> not, in any given praxis (*) whether the ordering doctor / intended 
> reviewer must sign all incoming results?
I should think the intended_reviewer is intended to review ;-)

Hence, yes, she should be signing all relevant results.
Seems like a general design decision to me.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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