gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] encryption of documents in archive
Date: Thu, 9 Jan 2014 21:14:48 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jan 09, 2014 at 07:53:56PM +0000, Jim Busser wrote:

> >> 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.
> > 
> > Those could be encrypted before import.
> 
> My first reaction was "well, you would be unable to combine this encrypted 
> document, perhaps a PDF, together with unencrypted files, into a single PDF 
> however it may not be necessary for an export to achieve such combining, they 
> could just be zipped. I suppose the keys that would be needed to decrypt the 
> one-or-more encrypted contents could be supplied to the receiver in a 
> separate transaction.
> 
> A big problem would however arise if GNUmed was to store enrypted documents, 
> the keys to which were inaccessible to anyone but an importing clinician who 
> had stored the key somewhere else, or nowhere.
> 
> It seems to me the risk of losing the key would make the above approach a 
> non-starter. I cannot get my head around importing, into GNUmed, a document 
> which could never be opened except by the solitary holder of a secret key 
> inaccessible to GNUmed.

All in all I haven't seen a compelling argument in
this thread. HOW such things would get implemented
is another matter entirely not worth thinking about
if value of the feature isn't entirely clear.

Karsten

> That is why any such encryption should, I think, be overseen by GNUmed as 
> part of importing a document.
> 
> A mini-project could be as follows:
> 
> 1) call to some reputable open source software (like GPG)
> 2) point GPG to the document that is to be encrypted
> 3) auto-archive the now-encrypted document, and
> 4) ask for, and store, the randomly-generated key
> 
> except #4 would need a suitable place to have been identified (if not 
> developed) in the schema
> 
> Borrowing a row in the patient's comm channels could work, and that row could 
> be marked confidential, but could risk having to create a series of channel 
> "types" (key1, key2, key3 …) each pointing, in the Comment field, to the 
> document to which it relates. This would make it a very limited solution. 
> Maybe it could, in the course of time, be migrated to security or permissions 
> tables if GNUmed were to later develop these.
> 
> -- Jim



> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel


-- 
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]