[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] on meaningfully signing off reviewed items
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] on meaningfully signing off reviewed items |
Date: |
Sun, 29 Jan 2006 19:10:15 +0100 |
User-agent: |
Mutt/1.5.11 |
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