*Attendees*
Bob Brentrup, Dartmouth (co-chair)
Michelle Gildea, CREN
Neal McBurnett, Internet2
Steve Olshansky, Internet2
Eric Norman, Wisconsin
Tammy O'Brien, Wisconsin
Michelle Wood, Wisconsin
Kelly Kwiatkowski, Wisconsin
Jeanette Fielden, Internet2

*Discussion of Wisconsin S/MIME Project*
Michelle Wood was present to answer questions and discuss the project so far.

The study was started with respect to HIPAA issues regarding a need for policies and technical solutions around e-mail involving patient data. From the policy perspective they want to balance the usability for clinicians with the need for security.

There were a small number of encrypted messages being sent because there were only 10-12 people in the study and they could only send signed messages to other people in the study. This was complicated by the fact the other people in the study weren't part of the normal e-mail correspondence of participants. In the survey responses people exhibited an interesting dichotomy. They received email that they think should have been encrypted (not necessarily from other participants) but when they send mail they don't encrypt it. I.e. what comes to me should be encrypted but what I send doesn't necessarily merit/need it.

The Netscape messenger client was setup to encrypt and sign by default. If the users attempted to send a message to someone not in the study they received a warning that the e-mail would not be encrypted but the message could still be sent, it was not automatically discarded. A user gets a notice in their regular mailbox that they have encrypted mail waiting; they then switch over to Netscape messenger to retrieve it. The messenger set-up is that every time you touch a message you're prompted for your private key password phrase when you open Netscape, when you touch a message, when you compose. Currently it's set at the most secure, so it will prompt very often. There has been feedback that it's cumbersome and users want all mail in one place and not have to enter additional passwords to access it. On shared machines individual logins and Netscape profiles are used and there is a time out factor since an open unsupervised terminal is of great concern.

Some clinicians work in multiple environments and had to be set up in more than one place. The key is created, copied to a disk, which is used to setup additional machines or reinstall information if someone loses their pass phrase. The disk is stored in a locked location for future use if needed. Mail is left on the server so it remains accessible. The difficulty is this is not a scalable solution.

One surprise was that there were not more support issues. However, if it were to deploy on a scale much larger than 12 people there would be considerable concern about technical, training, and support issues. For instance, the original goal was to do it all in Eudora. This didn't happen because the user would have to encrypt e-mail manually and know when/how to do that and the training and support would have been unmanageable.

If a passkey is lost or forgotten it needs to be recovered since that information is patient linked and may need to be added to patient records at some point. When this has happened the certificate is removed and reinstalled from the stored disk so they're able to read past messages as well create new ones. Because of the need to retrieve past messages the ability to reinstall is critical, some form of disaster recovery needs to be planned for.

There was user training on what the purpose of study was, what the messenger client does, what a certificate does, why you have public and private keys, and a little bit about security and the idea that they will need everyone's certificate.

Any major transition will create support issues for users and require considerable handholding of users. For example the Root cert is about to expire and it hasn't been possible to create 100% overlap between the old and renewal cert to create a seamless transition for the user. So it will have to be handled individually.

While there appear to be areas of application for this approach, it doesn't appear to be universally feasible due to scalability, support and training requirements.

Websites with additional information on HIPPA requirements: http://aspe.hhs.gov/admnsimp/

HIPPA Security Matrix:
Notice of Proposed Rule Making for the Security and Electronic Signature Standards
http://aspe.hhs.gov/admnsimp/nprm/seclist.htm

Addendum 1: HIPAA SECURITY MATRIX
http://aspe.hhs.gov/admnsimp/nprm/sec14.htm
http://aspe.hhs.gov/admnsimp/nprm/sec06.htm

There are a number of other links on the pages that may be of interest as well.

The next call is scheduled for September 12, 2002.