*** Please send response to openhealth mailing list. I am unable
to control the "Reply To" field through my webmail account. ***
On Sun, 22 Apr 2001 08:13:09 Tim Churches wrote:
...
>Yes, but my question was to what degree do any of the open source
>practice managemengt/EHR systems actually implement or provide support
>for encryption of data on disc (and on secondary media such as tape)?
Hi Tim,
As far as the OIO project is concerned, we don't have encrypted storage yet and I am
leaning towards implementing encrypted storage as part of the SDSS. The reasons are 1)
(as you correctly pointed out) encrypting only the "identifying information" is
inadequate to prevent re-identification and 2) fully encrypted database has
significant performance overhead during query processing.
>Such capability is a sine qua non for use of such systems anywhere
>physical security can't be assured to very high levels.
This sounds fine but it is not "reasonable" for most clinical settings. The
state-of-art is inadequately protected systems at locations where physical security is
rather low. Offering encrypted systems that perform sluggishly is not going to help us
get into most clinical settings. Sadly enough, adequate security is not a high
priority. Just look at how many systems rely on the Microsoft Access security
mechanism!!!
>That applies to
>most community clinics and health centres, I suspect. I am assuming that
>the server for such systems is on a LAN and thus housed in the clinic or
>health centre. The best solution of course is to co-locate the clinic
>server at a secure site, but that requires broadband network access.
No. I think the best solution is to use SDSS and scatter the information across
several servers. All servers will have to be stolen to compromise information
confidentiality. :-) Broadband network access to external sites is not necessary since
most of the data can be hosted locally.
>Such access has arrived in metro areas in many developed countries but
>is not even on the horizon in most rural areas.
Yes. Local storage is still the most reliable and highest performance.
>In developing countries
>broadband access either doesn't exist or is unaffordable even for
>medium-sized hospitals, let alone community clinics.
For remote backup, broadband is helpful. For OIO with/without SDSS, dial-up access
(50k shared by 5-10 users) is more than enough. :-)
>So local encryption
>of data (and good key manangement systems) are required. Have they been
>implemented in the open source context?
The easiest (and perhaps best) way is to set up loop-back crypto:
http://encryptionhowto.sourceforge.net/Encryption-HOWTO-4.html
A wide choice of crypto algorithms are available. :-)
Another promising system (in my opinion) is Cryptfs at:
http://www.cs.columbia.edu/~ezk/research/cryptfs/index.html
It uses Blowfish 128-bit at about 100% performance penalty.
...
>the data is
>unencrypted as soon as it is pulled off the disc.
That's why SDSS is uniquely useful. :-)
...
>By far the best solution
>is encryption of sensitive data by the application itself - this
>ensures the data remains encrypted no matter where it goes.
A single application is still risky. More than one application running on more than
one machine under separate administrative control is even better (e.g. SDSS).
...
>A few
>simple SQL queries later and I have uniquely located that person's
>medical record (after first stealing the clinic PC or server), without
>ever needing access to that person's name, address or DOB.
Right. One approach is to encrypt everything and the other is to use SDSS. Encryption
comes with key management problems and does not easily allow many types of queries.
SDSS allows security without centralized key management and has no restriction on
query.
Best regards,
Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org
Assistant Clinical Professor
Department of Psychiatry, Harbor-UCLA Medical Center
University of California, Los Angeles
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
