gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] CCHIT - access restrictions per SOAP note


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] CCHIT - access restrictions per SOAP note
Date: Sat, 7 Nov 2009 21:59:14 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Nov 07, 2009 at 09:28:46PM +0100, Hilbert, Sebastian wrote:

... GPG encryption of SOAP content ...

> While that would work I am not sure that is what they had in mind. I guess 
> they accept it being clear text in the database and delegating the 
> confidentiality stuff to the application level.

Tell you what - I don't care what they have in mind :-))  
What I do care about is whether the feature makes any real
sense or not. If so we'll think of a way to implement it
reasonable and not just as a certification fake.

However, if Verbus and his Band Of Brothers implement a
"sufficient quick fix" into their version of GNUmed and then
acquire certification for that -- no problem.

> I wonder if on the fly encryption is possible.

It is but we don't want that. It is too slow as well.
Imagine a free-text search across the medical record ;-)

> Supposedly there is a pg_crypto module.

Yep, and it's great.

> However, the data becomes inaccessible when the key / password changes 
> unless all data is reencrypted during a planned key / password change. 

Another reason not to want that.

What IS desirable is encryption *below* PostgreSQL at the
disk level, however. For that, dedicated encryption hardware
can be used if speed is an issue.

> I guess they would accept using different sql queries / views for that. When 
> flagged _is_confidential the returned value would be 'confidential' 
> On selecting 'show confidential record' one would be asked for the password 
> again which would trigger the other view or sql query.

Yep, that could work.

> Still not encrypted but I doubt the other vendors do it any different. 

You could well be correct there !


> Eventually we should surpass the requirements :-)

We will. In fact, implementing the approach I outlined isn't
at all technically challenging. It's just a matter of time
and priority.

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




reply via email to

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