HIPAA Compliant Email – You Decide Which Messages Need Encryption

November 16th, 2012

Customer feedback is extremely important to LuxSci and we have listened once again. Customers faced with the need for HIPAA-compliant email now have the option to decide on a per-message basis which messages need encryption (e.g. contain Protected Health Information – PHI) and which do not. Routine non-PHI-laden correspondence no longer needs to be encrypted and users no longer have to use separate users or profiles to send regular email messages.

The HIPAA Compliance vs Usability Conundrum

HIPAA requires that all electronic communications containing PHI (a.k.a ePHI) be secured during transmission. Among the myriad of HIPAA requirements and recommendations, this is one of the more fundamental ones that applies to any kind of use of computers or the Internet in conjunction with medical information.

As your email provider and HIPAA Business Associate, LuxSci is required to ensure that all ePHI is protected. Originally, we accomplished this by:

Ensuring that all email sent from any user in an account requiring compliance was encrypted, no matter what.

This protected LuxSci and our customers by making it impossible to accidentally send PHI without encryption. We call this “Account-Wide Compliance” and it is still the most widely used type of HIPAA-compliant account at LuxSci.

Clearly, most organizations also need to send a lot of email that does not contain PHI and sending that “regular” email over secured channels is undesirable for many reasons. To simplify the process, we introduced “Domain-Wide Compliance” in April of 2011. This worked by:

Ensuring that all email sent from any user in any domain that requires compliance in an account was encrypted. Email sent from users in other domains in the same account be sent as regular email.
Not requiring customers to obtain and manage separate accounts (one for HIPAA-compliant email on one domain like “info@secure.doctor.com” and one for regular email on another domain like “info@doctor.com”)

Domain-wide compliance permits customers to have one single account which is part compliant and part “regular”. The customer is required to use only compliant users for ePHI — and it is up to the customer to ensure that s/he is using the secure users when needed (obviously LuxSci cannot monitor that) to ensure that the customer is operating in a compliant way. This reflects the customer’s own responsibilities regarding the proper handling of PHI in all other circumstances.

Use of separate secure and insecure users does permit the customer to send PHI securely and to send regular email without PHI; however, it can be annoying and time consuming to require setup of 2 email accounts and switch between addresses (generally, with increased security comes decreased usability). There is also a cost associated with duplicate addresses for these differing purposes.

Customers have told us that they would ideally like to be able to choose on a per-message basis if encryption is needed — after all, who knows better than the customer which messages contain PHI and which do not?

Now – you can!

You Decide if an Email Contains PHI!

The new feature of LuxSci SecureLine email encryption enables end users to decide on a message-by-messages basis in WebMail if encryption is needed. If there is no PHI, the message can be sent without encryption.

How It Works

If you decide the message does not contain PHI and you want it to be sent without SecureLine encryption, simply uncheck the “Encryption” check box in WebMail.
When you press “Send”, you will get a confirmation dialog that will ask you to certify that the message does not contain any PHI and can be sent without encryption.

If you press the button to certify that the message contains no PHI, the message will be sent as regular email and this “opting out” of encryption will be logged.

It’s up to the Account Administrator

Allowing end users to decide for themselves if encryption is needed is a risk for account administrators, as they must ensure that their end users are well trained and will make appropriate choices.

Allowing these end-user decisions is disabled by default in LuxSci. It can be enabled on an account-wide or domain-wide basis; however, when an administrator in a HIPAA account enables this feature, the administrator must certify that s/he understands the implications and takes responsibility for the end users’ choices (and this is logged).

Administrators who do allow their users to be able to opt out of encryption do have some new tools on their side to help ensure and monitor compliance:

Reports: Records of all messages that users have chosen to send without SecureLine encryption are logged and those logs are kept for 10 years. Administrators can login and access these reports at any time. Note that only the user, message ID, date and time, recipients, and subject of the messages sent in this way are kept in the long term logs.
Auditor: Administrators can specify an “auditor” email address that will automatically be sent copies of all messages that users have chosen to send without SecureLine encryption. In this way, user choices can be monitored in close to real time if needed and records can be kept of these email messages. (We require that all messages going to the auditors be sent over TLS for security).

Any new or existing account can enable this user encryption “opt out” feature by going to their Account-wide SecureLine or Domain-Wide Outbound SecureLine configuration pages and choosing the new “On – User can ‘opt-out’ of SecureLine when not needed.” method for “WebMail Encryption“.

What about SMTP?

The changes described above apply only to sending email from the LuxSci WebMail interface. We plan to release a similar feature available to SMTP users — e.g. users of Outlook (though our SecureLine Outlook Plugin) and possibly other email programs as well, before the end of the year.

This entry was posted on Friday, November 16th, 2012 at 9:58 pm and is filed under Business Solutions, LuxSci Library: HIPAA, LuxSci Library: Security and Privacy.