*** Please send response to openhealth mailing list. I am unable to control the "Reply
To" field through my webmail account. ***
On Sat, 21 Apr 2001 19:11:42 Tim Churches wrote:
...
>it
>must be adequately encrypted (and that does not mean the piss-weak 40bit
>RC2 encryption offered by MS Access). Are open source medical systems
>better than commercial offerings in this respect, I wonder?
Hi Tim,
I think it is helpful to distinguish between
1) encrypting data on a stand-alone PC vs.
2) encrypting information in a client-server/networked system.
Calle mentions a SQL-server setup in New York that encrypts patient identifiers
during storage. In essence, that system splits the "patient identifiable" information
across the workstation and the server (or the server and the human brain if the
"decryption key" is not stored on the Workstation). This falls into the second
category of client-server/networked architecture.
I think your original risk scenario involves a stand-alone system where patient
identifiable information is stored on a single PC. You wanted to know how best to
encrypt the data such that access to information is hard even with physical possession
of the PC. I think for that risk scenario, the most one can do is to encrypt strongly
and with multiple keys (across the dataset such that each key would decrypt one
patient's record, for example). [This obviously needs to be no stronger than the user
authentication system since the user-login system is frequently the weakest link.]
Because humans are not capable of storing multiple "strong keys" in their head (i.e.
strong passwords), the idea is to store them in a removable medium like a floppy disk
or smartcard. The idea is to prevent the "key list" from being stolen together with
the PC by putting it in a safe or elsewhere after the clinic is closed. :-)
This approach splits the "secret data" between the removable medium and the PC
database. The major weakness is susceptibility to the copying of the key list to the
PC itself (in cache/buffer). Also, the removable medium has to be duplicated/redundant
in case it is lost or destroyed. Additional copies of the key list increases
vulnerability to unauthorized copying and distribution.
...
>PS How many minutes will elapse after this message is posted before
>Andrew Ho replies, mentioning his (literally) patented secret splitting
>method for maintaining confidentiality? Just teasing!
Right! I always try to respond to "baiting" inquiries rather quickly :-).
Regarding the SDSS (Sequentially Distributed Secret Splitting) and how it fits into
this risk scenario, :-) I believe SDSS falls more into the "networked" (#2) category.
However, if one uses a "smartcard" instead of a passive removable medium (e.g. floppy
disk) in the proposed design above, it is possible to implement SDSS even on a
non-networked system. The smartcard would essentially act as a pseudo-networked
"secure patient identifier server". :-) This is potentially an "elegant" solution if
it is deemed to confer enough additional security to justify the extra expense.
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
