[Top][All Lists]

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

Re: [Gnumed-devel] encryption of documents in archive

From: Busser, Jim
Subject: Re: [Gnumed-devel] encryption of documents in archive
Date: Wed, 8 Jan 2014 23:14:07 +0000

On 2014-01-08, at 2:01 PM, Karsten Hilbert <address@hidden> wrote:

> On Wed, Jan 08, 2014 at 09:40:56PM +0000, Jim Busser wrote:
>> So is the question as narrow as
>>      whether some documents
> ...
>>      are to be stored within in their respective GNUmed db row
>>      as encypted content
>>      where each affected document in question would be individually encrypted
>>      using a key that is to be
>>      - other?
> Yes. In particular, the question was whether anyone saw
> any worthwhile value in the above.

I think so … the value in encryption would be mainly in the area of keeping 
information private, and so the question is in the value of keeping information 
more private inside GNUmed than what GNUmed already allows without such 

The ability to make things "more private" *could* be achieved by the adjustment 
of existing GNUmed permissions and so the question becomes wether encryption 
would offer anything that is simpler (easier) or less work than what would be 
needed to revamp the GNUmed permission system.

Some praxes may, for example, desire their medical office assistants (MOAs) to 
be able to open documents, in order to have the flexibility to be able to print 
and fax them. These praxes would view a wholesale denial of MOAs to open/print 
documents to be "too restrictive".

OTOH there may exist some documents so confidential (sexual or psychiatric 
related) as to want to restrict anyone but clinicians to be able to open them.

One way to do it would be row-level access, where only clinicians could open 
document rows which had been categorized "confidential" and where the opening 
of such a row by a clinician who was not the patient's usual primary provider 
could be logged.

Might it be be less work, code-wise, to encrypt such documents with a key 
stored on a per-primary-provider basis?

The same approach (and key) could be used at the point where a *clinician* 
would be exporting any of this kind of document to a /tmp area in the local 

-- Jim

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

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