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.
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
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
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
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.
- 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
- 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.
- Web Interface Session Timeout: The maximum web interface (for
WebMail) session timeout will be 4 hours or less.
- WebAide Auditing: Auditing of Blog, Document, and Password
WebAides is always enabled.
- 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
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
Enforced Security. All Secure Forms have the following minimum
- Form submissions are transported securely over HTTPS.
- SecureLine encryption is used to encrypt any email messages
containing form data emailed from the Secure Form service.
- Secure FTP is used for any "FTP" integration uploads of form data.
- Data sent to all external integrations are transported securely
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):
- Services run only on dedicated servers. LuxSci does not provide a shared web hosting environment.
- "root" server access is not provided to Customers.
- "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.
- 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.
- Direct configuration of "crontab" is restricted. Changes to crontab must be approved by and made by LuxSci.
- 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
The following sections provide high-level details about using the
features and encryption options available in LuxSci's HIPAA Eligible
services for HIPAA compliance.
- 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.
- 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.
- WebAides: HIPAA customers may wish to employ optional
entry-level PGP encryption and access control features for Blog and
- 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.
- 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:
- Use of automation
- Using SecureLine Escrow with pre-determined security questions that must be answered to access the message
- Using SecureLine Escrow with SecureSend accounts that already exist
- Using SecureLine PGP encryption
- Using SecureLine S/MIME encryption
- 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:
- 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).
- SecureLine TLS. When SecureLine TLS is used, all email data is encrypted during transport.
- 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.
- 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.
- 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.
- 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:
- Dynamic. TLS is used whenever possible, falling back to other mechanisms when not possible.
- Exclusive. TLS is used whenever possible. When TLS is not possible, the message is not sent.
- Specific. TLS is used only with specific recipients/domains and/or not with specific recipients/domains.
- On-Demand. TLS is used only when requested by the sender.
- Disabled. TLS is never used as the only email encryption mechanism.
- 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.
- 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
- SecureSend Recipient Authentication. (Enabled by default) For
outbound email messages being delivered to recipients via SecureLine
Escrow, you can configure SecureLineso 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.
- 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.
- 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
- 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.
- 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.
- 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:
- 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.
- Filtering of decrypted emails upon arrival to LuxSci's servers using custom filtering rules.
- 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.
- "Business as almost-usual" email usage for PGP- and S/MIME-encrypted inbound email.
- 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,
"email@example.com" for regular email and "firstname.lastname@example.org"
for PHI. The recommendation for separate user logins is based on the
- These two accounts can be set up in parallel in the user's email program (e.g., Outlook or Thunderbird).
- 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.
- The user can see inbound emails arriving to either account in real time in his/her email program.
- The user can reply to messages as normal in his/her email program.
- 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).
- The separate domains with LuxSci keep the delineation of what is PHI and what is not PHI very clear.
- The separate accounts in the user's email client keep the distinction of what is secure and not very clear.
- It is up to your end user to determine what should be sent securely and what does not contain PHI.
- The recipient also gains assurance via the different email address "secure.yourdoctor.com" that s/he sees when receiving a message containing PHI.
- 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.
Images and Files. When creating campaigns in Secure Marketing,
the images and files that may be attached to email messages may be hosted
on your dedicated Secure Marketing server 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. Should files that contain PHI 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 will be protected in the secured message
- 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:
- the third-party service is owned by Customer and Customer certifies HIPAA compliance with respect to this PHI, or
- 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
- HIPAA-compliant protections are not required by law for the PHI after it arrives at the third-party service, or
- the PHI will be protected by another organization that falls under the scope of HIPAA, or
- no PHI will flow to the third-party service, or
- 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:
- Customer must have a HIPAA-compliant account with Slack, or
- the Slack account must be HIPAA-compliant and owned by a Business Associate of Customer, or
- 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
- the Slack channel is owned by another organization that assumes the HIPAA responsibilities for protecting the PHI after delivery, or
- 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.
- 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:
- Using TLS and password protection to secure portions of the website.
- Performing additional file-level or row-level encryption of data stored on disk or in databases.
- Using LuxSci's Secure Form service for processing form submissions that may contain PHI.
- Ensuring that PHI is never accessible to the public and never accessible without proper authentication, authorization, and access logging.
- Ensuring that unique access credentials are used for persons accessing PHI.
- Maintaining proper access controls, audit trails, and data backups.
- Using industry-standard best practices for secure coding.
- Performing periodic code reviews, penetration tests, risk assessments, and remediations.
- Performing risk assessments of any third-party code used in the website.
- Monitoring for security patches of third-party code used in the website and applying such patches in a timely manner.