gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] clinicians: coding use case survey - please respond !


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] clinicians: coding use case survey - please respond !
Date: Fri, 6 May 2011 22:07:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 06, 2011 at 12:11:44PM -0700, Jim Busser wrote:

> No matter what is the EMR, even when the vendor says "no, the ICD10 cannot be 
> modified" the truth is that the vendor can ALWAYS modify the record.

Correct.

> Normally, the vendor can make it impossible for the
> *doctor* to modify the record because the doctor does not
> have special software or the doctor does not have the
> password to the database. With gm-dbo it is always possible
> to modify a record selectively,

Right.

> so there are only two ways
> that data integrity (non-falsification) can be argued:
>
> 1. the table design in GNUmed takes advantage that you
> cannot remove a clinical record unless you would be able to
> alter the master postgres program itself. This is because
> the gnumed tables have been defined to always keep a copy of
> clinical records in the audit table. So when you make a
> correction to the original, the original gets copied into
> the audit copy of the table, and the modified record can
> always be checked of some actual earlier version existed.

Well, no, as gm-dbo one could deactivate the auditing
triggers and modify the data. That would not be audited
then. As gm-dbo, one could also clean the audit tables of
undesired data.

> 2. you can therefore tell the Brazilian police that this
> software GNUmed does not allow the original to be gotten rid
> of.

... by a "normal" user, yes.

> (It is true, the same way with the vendor, that someone
> with the master password could go through the back with the
> password, however Karsten can maybe tell us whether, even
> with the password, the table structure does not allow the
> record to be deleted.

Given proper credentials it can sure be altered any way.

But we make that fairly hard and fairly cumbersome.

> (and the only real way to show that the record was not
> later changed, would be to have backups burned to some
> date-stamped media (CD) from a time shortly after the
> original event,

Correct. That's the only way.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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