Re: [Gnumed-devel] on meaningfully signing off reviewed items

[Karsten Hilbert]

On Sun, Jan 29, 2006 at 09:42:51AM -0800, Jim Busser wrote:

> ... what I mean is, the "signed by" would no longer accurately convey 
> the clinical acknowledgement and acceptance of responsibility... it 
> would be misleading
Exactly. And could be misused by malevolant people.

> So is what we want, the following:
> 
> - do not *require* a row to be signed in the back end, for an 
> unsigned row is part of the workflow we are needing to capture
Yes, we already have that.

> - if a row *was* signed, and was *afterward* updated, the update 
> needs to contain a null signature in order to be able to flag it as 
> having again to be reviewed & signed off.
Yes, we can do that with a trigger on update. We can force
the signature to NULL if the data changes.

> The fact that it gotten 
> altered if by someone other than the original signer would show up in 
> the audit log, but that is not enough for safe practice because we 
> want to be able (in the workflow) to identify rows that *again* need 
> review & signoff.
Exactly.

> Any chance that the Postgres "on update" function can constrain based 
> on the most recent (pre-update) value of the row?
Yep. In an on-update trigger we have both version (new and
old) available and can just check the new against the old
value and only invalidate the sig if the data *actually changed*

> For example, "on 
> update" requires signed_by to be null if the updating user is 
> different than whoever signed it? Or do we allow a doctor other than 
> the individual who signed it originally, to sign the newer version? 
Well, we allow *any* number of people to sign off a
document, as usual. The view then provides three fields:

reviewed
        (at all)
reviewed_by_you
        (that is, me, who is looking right now)
reviewed_by_intended_reviewer
        (well, the name says it all)

Changing the data would then invalidate *all* signatures for
that row by way of a trigger. Addition would not need
special treatment as the new, added row isn't signed right
from the beginning anyways.

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