This document briefly outlines how customers can use LuxSci's services for scenarios regulated under the Health Insurance Portability and Accountability Act (HIPAA). It focuses on the HIPAA Privacy and Security Rules for protecting Protected Health Information (PHI), how to use LuxSci to encrypt data in transit and at-rest, and how LuxSci's features can be used in scenarios that include PHI.

Contents

  1. Introduction
  2. HIPAA Eligible Services
  3. HIPAA Customer Account Restrictions
    1. All Services
    2. Secure Email Sending
    3. Secure Email Hosting
    4. Secure Form
    5. Secure Web Hosting
  4. Encryption and Protection of PHI in LuxSci
    1. All Services
    2. Secure Email Sending
    3. Secure Email Hosting
    4. Secure Marketing
    5. Secure Form
    6. Secure Web Hosting

Introduction

HIPAA, the Health Insurance Portability and Accountability Act of 1996, applies to "covered entities" and their "business associates." HIPAA was expanded in 2009 by the Health Information Technology for Economic and Clinical Health (HITECH) Act and in 2013 by the Omnibus Rule. Together, these create federal standards which are designed to protect the security and privacy of Protected Health Information (PHI). These standards include requirements around the use and disclosure of PHI, administrative responsibilities, individual rights, and safeguards for the protection of PHI.

Covered entities and their business associates can use many of LuxSci's services in alignment with HIPAA compliance requirements. LuxSci's services and data centers utilize multiple layers of operational and physical security to help ensure the integrity and safety of customer data. LuxSci's services are HITRUST CSF certified, and LuxSci's data center provider(s) have SOC2 and HITRUST CSF certifications, among many others.

LuxSci offers a Business Associate Agreement (BAA) for covered entities and their business associates. Customers who execute a BAA with LuxSci (called "HIPAA Customers") may use any LuxSci service; however, they may only process, store, and transmit PHI using HIPAA Eligible services.

LuxSci's BAA requires customers to encrypt PHI when stored or transmitted using HIPAA Eligible services in accordance with guidance from the Secretary of Health and Human Services (HHS). LuxSci offers a comprehensive set of features and services to make encryption of PHI easy to manage. HIPAA Customers have a great deal of flexibility in how they meet encryption requirements for PHI. They should evaluate and take advantage of the encryption features native to the HIPAA Eligible services when determining how best to implement encryption for their use case(s). Alternately, HIPAA Customers can satisfy their HIPAA encryption requirements through other means consistent with guidance from HHS.

There are two types of HIPAA Customer Accounts at LuxSci:

  • Account-wide HIPAA: (The default). All users in the account are locked down for HIPAA compliance. All users can use HIPAA Eligible services with PHI and all users must have SecureLine licenses.
  • Selective HIPAA: Only "non-excluded users" can use LuxSci HIPAA Eligible services with PHI. I.e., account administrators can select which users are compliant and which are not. This option is available upon request and is generally most useful for customers using Secure Email Hosting or Secure Connector that require only some users to be locked down for compliance. Selective HIPAA accounts must have SecureLine licenses for all non-excluded users.

HIPAA Eligible Services

See: HIPAA Eligible Services

HIPAA Customer Account Restrictions

LuxSci is known for providing a combination of high security together with high flexibility. This allows our customers to configure our services to optimally meet their unique business workflows. For HIPAA Customers, LuxSci restricts some of the features and options available, locking down the HIPAA Customer's settings with a minimum level of security settings higher than those available to non-HIPAA Customers. We describe the default restrictions generally below.

All Services

  1. Enforced use of Secure Logins: All logins to LuxSci services by any user in a HIPAA Customer account are secured via TLS, SSH, and/or VPN.
  2. Password Strength: All passwords used by all HIPAA Customer users to access LuxSci services must, at a minimum, be 12 or more characters long, contain both letters and numbers, and pass a minimum password entropy checking system to ensure that they are hard to guess.
  3. Web Interface Session Timeout: The maximum web interface (for WebMail) session timeout will be 4 hours or less.
  4. WebAide Auditing: Auditing of Blog, Document, and Password WebAides is always enabled.
  5. WebAides Feeds: All published WebAide feeds are password-protected, and transport-encrypted.

Secure Email Sending

This section involves email sending via authenticated SMTP, API, and WebMail. It applies to users of Secure Email Hosting, Secure Connector, Secure High Volume, and Secure Marketing services.

Enforced Email Encryption: Use of LuxSci SecureLine outbound email encryption is enabled for all non-excluded users of HIPAA Customer. This forces all email messages sent by these users to be encrypted by default.

Secure Email Hosting

Enforced Secure Email Forwarding: In addition to the secure email sending restriction (above), HIPAA Customers using the Secure Email Hosting service are subject to enforced secure email forwarding. This restriction ensures that all inbound email messages which are forwarded will be encrypted during transport to the recipient(s) using a sufficient level of SMTP TLS (else the forwarding will be disabled and/or not permitted).

Secure Form

Enforced Security. All Secure Forms have the following minimum requirements:

  1. Form submissions are transported securely over HTTPS.
  2. SecureLine encryption is used to encrypt any email messages containing form data emailed from the Secure Form service.
  3. Secure FTP is used for any "FTP" integration uploads of form data.
  4. Data sent to all external integrations are transported securely over HTTPS.

Secure Web Hosting

In addition to securing the web hosting server environment, applying timely patches, configuring, and updating firewalls, performing automated virus scans, performing automated server vulnerability scans, providing access controls and keeping audit logs, and watching for intrusions and other activities, LuxSci locks down its Secure Web Hosting service with the following security controls (note: these restrictions are applied to all Secure Web Hosting accounts, not just those of HIPAA Customers):

  1. Services run only on dedicated servers. LuxSci does not provide a shared web hosting environment.
  2. "root" server access is not provided to Customers.
  3. "sudo" access is restricted; sudo access to very specific commands is only granted after a LuxSci security review of the impact of said access and then only if there is a very strong need for said access.
  4. Direct access to "php.ini," Apache, database server, and other server and service configuration files is restricted. Changes to such configurations must be approved by and made by LuxSci.
  5. Direct configuration of "crontab" is restricted. Changes to crontab must be approved by and made by LuxSci.
  6. Only secure channels for server management are permitted (i.e., HTTPS, SFTP, and SSH).

Encryption and Protection of PHI in LuxSci

The HIPAA Security Rule includes addressable specifications for the implementation of encryption for PHI in transmission ("in transit") and in storage ("at rest"). Although this is an addressable HIPAA specification, LuxSci requires customers to encrypt PHI stored in or transmitted using HIPAA Eligible services in accordance with guidance from the Secretary of Health and Human Services (HHS).

All data storage locations used by all LuxSci services, including backup locations, utilize encrypted disks and/or encrypted objects. This ensures that all data stored at LuxSci is always encrypted at rest. LuxSci's services provide additional encryption options that can be used on top of storage-level encryption to enhance the level to which data is encrypted at rest.

The following sections provide high-level details about using the features and encryption options available in LuxSci's HIPAA Eligible services for HIPAA compliance.

All Services

  1. Sharing: Customers in Selective HIPAA accounts are permitted to share objects (e.g., email folders, address books, etc.) owned by non-HIPAA users (i.e., "excluded users") with HIPAA users. It is the Customer's responsibility to either (a) restrict sharing by end users so that this is not permitted, or (b) ensure that HIPAA users never copy PHI into the shared objects of non-HIPAA users.
  2. Access Control and Auditing: HIPAA Customers may want to implement LuxSci's security features such as (a) multi-factor authentication, (b) Service-level access restrictions, (c) IP-based access restrictions, (d) time-of-day access restrictions, and others to limit access to services and accounts. Additionally, it is HIPAA Customer's responsibility to review the access auditing reports for individual users if that is deemed by HIPAA Customer to be important for their HIPAA compliance. Only HIPAA Customer would have clear knowledge as to what access is legitimate and what is not.
  3. WebAides: HIPAA customers may wish to employ optional entry-level PGP encryption and access control features for Blog and Documents WebAides.
  4. Widgets: Customers should not implement custom or third-party Widgets in the LuxSci user interface which might transfer PHI to a third-party location in a manner that is not HIPAA-compliant. It is up to the Customer to determine the suitability of any custom or third-party widgets used by its users.

Secure Email Sending

This section involves email sending via authenticated SMTP, API, and WebMail. It applies to users of Secure Email Hosting, Secure Connector, Secure High Volume, and Secure Marketing services.

  1. Images and Files. When creating email templates (and using LuxSci's Content Library, in general), the images and files that may be attached to email messages will be hosted by LuxSci as publicly accessible web links. I.e., these objects are not password protected and are accessible to anyone who can discover their web addresses. As such, these images and files should not contain PHI (or PII). Should files that contain PHI or PII need to be sent, it is recommended that they be sent as message attachments, which will be protected in the secured message bodies.
  2. Email Template Body Content and the Drag-and-drop Template Editor. "Email template body content" includes the text and/or HTML content of email templates. It does not include other content that may be present in an email message sent to a recipient. I.e., it does not include the subject, recipient name, or recipient email address. Customers using the drag-and-drop template editor should not include PHI or PII in the body content of templates managed with that tool. Instead, such templates should either (A) contain generic content or (B) contain placeholders that will be filled with recipient-specific details on send. Customers may use LuxSci's API or the WYSIWYG Template editor when templates containing PHI or PII need to be used".
  3. Secure Email Sending. LuxSci gives Customers the ability to send email to anyone on the internet and have that email content be transmitted to the recipient(s) in a secure manner. It is the Customer's responsibility to ensure that PHI is only transmitted to recipients whose access to that PHI would not violate the HIPAA Privacy Rule. HIPAA Customer is responsible for preventing any breach resulting from PHI being emailed to incorrect recipient email addresses. The risk involved with email messages being sent to an incorrect recipient email address can be mitigated by:
    1. Use of automation
    2. Using SecureLine Escrow with pre-determined security questions that must be answered to access the message
    3. Using SecureLine Escrow with SecureSend accounts that already exist
    4. Using SecureLine PGP encryption
    5. Using SecureLine S/MIME encryption
  4. SecureLine Email Transport Encryption. PHI should be encrypted during transport in email messages. To this end, LuxSci's SecureLine email encryption service ensures that email message content can always be encrypted when delivered to recipient email servers. However, based on the type of email encryption used, more or less of the overall email data will be encrypted:
    1. Opportunistic TLS. SMTP TLS is always used with recipient servers that support a sufficiently strong level of TLS. When Opportunistic TLS is used, all email data is encrypted during transport (i.e., the sending, the recipients, the subject, all other headers, and all body content and attachments).
    2. SecureLine TLS. When SecureLine TLS is used, all email data is encrypted during transport.
    3. SecureLine Escrow. SecureLine Escrow secures the message body and all attachments and, by default, also protects the actual email subject. If the Escrow notification message can be delivered via Opportunistic TLS, then all message data is protected. If it cannot, then the combination of the sender and recipient email addresses will not be secured.
    4. SecureLine PGP and S/MIME. PGP and S/MIME each secure the message body and all attachments. If the resulting encrypted message can be delivered via Opportunistic TLS, then all message data is protected. If not, then all message headers (i.e., the subject, sender, recipient, and any other custom headers) will not be secured.
    5. SecureLine SecureText. SecureLine SecureText secures the message body and all attachments and, by default, also protects the actual message subject. The combination of the sender's email address and the recipient's phone number will not be secured.

    It is the HIPAA Customer's responsibility to ensure that appropriate encryption mechanisms are selected to appropriately secure the PHI placed in emails by HIPAA Customer. Alternately, HIPAA Customers can satisfy their HIPAA encryption requirements through other means consistent with guidance from HHS.

  5. TLS Secure Delivery: (Enabled by default) SecureLine permits enabling TLS-only delivery as an option for outbound email encryption. Recipient domains whose email servers support a sufficiently secure version of SMTP over TLS, can be delivered to "normally" without the required use of more complex outbound encryption mechanisms (e.g., PGP, S/MIME, or Escrow). With TLS delivery, messages to such recipients would look like "regular email;" however, that regular is delivered over a secure transport channel. This kind of email delivery meets the HIPAA Security Rule's minimal requirements, while allowing a large class of email messages to be sent, received, and accessed in a way that appears "normal."

    LuxSci provides many TLS delivery options from which administrators may choose:

    1. Dynamic. TLS is used whenever possible, falling back to other mechanisms when not possible.
    2. Exclusive. TLS is used whenever possible. When TLS is not possible, the message is not sent.
    3. Specific. TLS is used only with specific recipients/domains and/or not with specific recipients/domains.
    4. On-Demand. TLS is used only when requested by the sender.
    5. Disabled. TLS is never used as the only email encryption mechanism.
  6. Global SecureLine Address Book. An account administrator can create an "Address Book" in the LuxSci web interface where common contacts to whom the organization corresponds can be defined. In this address book, administrators can upload PGP and S/MIME public keys and/or specify question and answer pairs that should be used to verify recipient identity when picking up secure emails via SecureLine Escrow. This address book can be shared with some or all users in the account so that it is automatically used when these users send email messages. Not only do these users get easy access to the shared contact list, but the security information being used can be centrally located and managed.
  7. Default SecureLine Escrow Question and Answer. For outbound email messages going to recipients that are using SecureLine Escrow for encryption, you can define a default question and answer that will be used to authenticate access to their messages. This default question and answer is used in cases where other recipient-specific authentication information is not available. The use of a default question and answer allows you to send to any email address without needing to pre-configure it or to require recipients to create SecureSend accounts. Questions and answers are needed for Escrow when SecureSend Recipient Authentication (6) is not enabled.
  8. SecureSend Recipient Authentication. (Enabled by default) For outbound email messages being delivered to recipients via SecureLine Escrow, you can configure SecureLine so that the recipients are required to register for a free SecureSend account and then use those login credentials to authenticate their access to all SecureLine Escrow messages received. This precludes the need to define "questions and answers" for your recipients and to communicate those to them.
  9. Encryption Opt-Out. HIPAA Customers who permit their end users to opt-out of outbound SecureLine email encryption on a per-message basis must ensure that their users are well trained in the identification of what constitutes PHI and take on the responsibility for ensuring that their end users never misclassify PHI-containing email as non-PHI-containing email when opting out of email encryption. Opt-out is not available by default; it must be intentionally enabled by an account administrator before it is available to users.
  10. Mutual Consent. HIPAA permits the sending of PHI insecurely under Mutual Consent (i.e., where the patients have approved insecure delivery in writing, secure alternatives are available, and where the patients have been educated on the risks). To send messages insecurely under Mutual Consent at LuxSci, a HIPAA Customer account administrator must contact LuxSci to request that always-on email encryption be relaxed. A signed contract addendum for use of Mutual Consent may be required.

Secure Email Hosting

  1. Email Forwarding. LuxSci gives Secure Email Hosting Customers the ability to configure rules that automatically forward inbound email messages from LuxSci to external email addresses that support a sufficient level TLS for secure email transmission. In this way, all messages are forwarded in a secure, encrypted manner. This feature is intended to make it easy to integrate LuxSci's email services with those of other HIPAA-compliant email service providers. It is the Customer's responsibility to ensure that email is not forwarded to locations that could result in violations of the HIPAA Security or Privacy Rules. Customer is responsible for preventing any HIPAA breach resulting from PHI being forwarded to improper recipients or insecure locations. For example, forwarding emails to Customer-controlled accounts which are NOT HIPAA-compliant could be a non-compliant use of email forwarding.
    • Even though email forwarding is restricted to be to TLS-enabled recipients only, Customers still have responsibilities regarding forwarding. Customer administrators can choose to restrict end users from managing their own email forwarding and filtering settings. By requiring only account administrators to configure these settings, Customers can ensure that only approved email-forwarding rules are in place. Additionally, instead of forwarding email messages to external accounts, custom email filters can be used to send non-PHI-containing notices of message arrivals to external email addresses. In this way, users can be informed in their insecure accounts of the arrival of messages to their secure accounts, without PHI being forwarded out of their secure accounts.
  2. Premium Email Filtering. Customers with access to the Premium Email Filtering control panel must ensure that any email delivery or email forwarding rules configured in this portal are configured to only deliver email messages to recipients in their filtered domains. Forwarding to other, external email addresses may result in the messages being delivered without transport encryption to the recipient(s). Furthermore, Customers should not send outbound email messages containing PHI from the filtering portal's "Emergency Inbox "feature, as these messages will not be encrypted using SecureLine.
  3. Automatic Inbound Email Decryption. This optional feature allows all inbound email messages which are encrypted via PGP or S/MIME to be automatically decrypted upon arrival to LuxSci. This enables:
    1. Users to access these email messages "as normal messages" via WebMail or their favorite email client without needing to explicitly decrypt these messages each time they are opened.
    2. Filtering of decrypted emails upon arrival to LuxSci's servers using custom filtering rules.
    3. Archival of inbound messages in an unencrypted format so that they are more easily searchable and so that they can be accessed even if the original certificates used are deleted or the passwords are forgotten.
    4. "Business as almost-usual" email usage for PGP- and S/MIME-encrypted inbound email.
  4. Multiple Sending Profiles. For users who must be able to send some messages securely and some insecurely, LuxSci recommends having two separate users- one regular and one HIPAA-compliant. For example, "john@yourdoctor.com" for regular email and "john@secure.yourdoctor.com" for PHI. The recommendation for separate user logins is based on the following:
    1. These two accounts can be set up in parallel in the user's email program (e.g., Outlook or Thunderbird).
    2. The user can select the appropriate email account by choosing the account in the email program before sending it. E.g., click on the "Secure" account to send PHI and the "insecure" account to send non-PHI.
    3. The user can see inbound emails arriving to either account in real time in his/her email program.
    4. The user can reply to messages as normal in his/her email program.
    5. The user can reply to an "insecure" message securely by dragging and dropping it from the insecure inbox to the secure inbox before sending it (among other ways).
    6. The separate domains with LuxSci keep the delineation of what is PHI and what is not PHI very clear.
    7. The separate accounts in the user's email client keep the distinction of what is secure and not very clear.
    8. It is up to your end user to determine what should be sent securely and what does not contain PHI.
    9. The recipient also gains assurance via the different email address "secure.yourdoctor.com" that s/he sees when receiving a message containing PHI.
    10. The non-HIPAA-compliant logins with LuxSci will not be forced to send emails in an encrypted manner.

    This approach is really the cleanest way to separate always secure from regular email in terms of clarity and ease of use for the end user and in terms of limiting liability for improper disclosure of PHI.

Secure Marketing

Images and Files. When creating email templates and campaigns in Secure Marketing (and when using LuxSci's Content Library, in general), the images and files that may be attached to email messages will be hosted by LuxSci as publicly accessible web links. I.e., these objects are not password protected and are accessible to anyone who can discover their web addresses. As such, these images and files should not contain PHI (or PII). Should files that contain PHI or PII need to be sent, it is recommended that LuxSci Secure Email Hosting, Secure High Volume, or Secure Connector services be used to send them as, with these services, the files and images can be sent as attachments, which will be protected in the secured message bodies.

Email Template Body Content and the Drag-and-drop Template Editor. "Email template body content" includes the text and/or HTML content of email templates. It does not include other content that may be present in an email message sent to a recipient. I.e., it does not include the subject, recipient name, or recipient email address. Customers using the drag-and-drop template editor should not include PHI or PII in the body content of templates managed with that tool. Instead, such templates should either (A) contain generic content or (B) contain placeholders that will be filled with recipient-specific details (which does create PHI or PII) on send. Customers may use LuxSci's API or the WYSIWYG Template editor when templates containing PHI or PII need to be used.

Secure Form

  1. Forms are Public. When creating Secure Forms, the forms, images, and files presented to the users who may fill out these forms will also be accessible to the general public. I.e., these objects are not password protected and are visible to anyone who can discover their web addresses. These objects should not contain PHI (or PII).
  2. External Integrations. Secure Form permits Customer administrators to set up integrations that can cause PHI in posted form data to flow from Secure Form to third-party services. It is HIPAA Customer's responsibility to determine and ensure that either:
    1. the third-party service is owned by Customer and Customer certifies HIPAA compliance with respect to this PHI, or
    2. Customer has a HIPAA Business Associate Agreement with the third-party service and that service will protect the PHI in a manner that is HIPAA-compliant, and which will maintain the HIPAA compliance of the Customer, or
    3. HIPAA-compliant protections are not required by law for the PHI after it arrives at the third-party service, or
    4. the PHI will be protected by another organization that falls under the scope of HIPAA, or
    5. no PHI will flow to the third-party service, or
    6. HIPAA Customer can satisfy its HIPAA encryption requirements through other means consistent with guidance from HHS

    For example, if Customer chooses to send data from Secure Form to Slack then either:

    1. Customer must have a HIPAA-compliant account with Slack, or
    2. the Slack account must be HIPAA-compliant and owned by a Business Associate of Customer, or
    3. the Slack account must be owned by a person who has a right to view the PHI and who can and has (for example) opted out of security through the Mutual Consent provisions of HIPAA, or
    4. the Slack channel is owned by another organization that assumes the HIPAA responsibilities for protecting the PHI after delivery, or
    5. Customer ensures that no PHI will be or can be in Slack by carefully choosing which data is sent there.

    Any breaches of PHI at the third-party service provider are the sole the responsibilities of Customer and/or the third-party service provider.

  3. Database Storage. It is common for Customers to have copies of the data from Secure Form posts stored in a LuxSci-hosted database. Customers may choose to use Secure Form's native row-level database encryption feature to raise the level of at-rest encryption used for their database-stored Secure Form data.

Secure Web Hosting

HIPAA Customers are in full control of the content and operation of any hosted websites. LuxSci does not perform audits of these sites to ensure that they are HIPAA-compliant; that is the Customer's responsibility. HIPAA Customer must ensure that any PHI stored on or accessible through or submitted to its website(s) is safeguarded to a degree that satisfies the HIPAA Security and Privacy rules. This may include, for example:

  1. Using TLS and password protection to secure portions of the website.
  2. Performing additional file-level or row-level encryption of data stored on disk or in databases.
  3. Using LuxSci's Secure Form service for processing form submissions that may contain PHI.
  4. Ensuring that PHI is never accessible to the public and never accessible without proper authentication, authorization, and access logging.
  5. Ensuring that unique access credentials are used for persons accessing PHI.
  6. Maintaining proper access controls, audit trails, and data backups.
  7. Using industry-standard best practices for secure coding.
  8. Performing periodic code reviews, penetration tests, risk assessments, and remediations.
  9. Performing risk assessments of any third-party code used in the website.
  10. Monitoring for security patches of third-party code used in the website and applying such patches in a timely manner.