HIPAA-Compliant Web Sites: Requirements and Best Practices

Published: February 27th, 2014

We are approached frequently by webmasters and site designers asking for clarification on or guidelines for using ePHI in web sites that must be HIPAA compliant.

While we have discussed previously what makes a web page secure in general and also what in particular makes a web site HIPAA compliant, it seems that a concise recommendation that spells out what you should and should not do with web sites in shared and dedicated environments would be particularly useful to many.

HIPAA-Compliant web sites on a shared server – really?

While use of a dedicated server for any web site that deals with ePHI is highly recommended for the clear security advantages, we do allow such web sites on LuxSci’s shared web servers as well, provided they are designed properly.

What is the danger on a shared web server?

Use of a shared web server is inherently less secure than a dedicated server because of the fact that the server is used by many different web sites and many different, independent site administrators.  If there is ePHI on the server, it must be protected against:

  1. Unauthorized access by another customer administrator
  2. Unauthorized access by someone hacking into an unrelated web site and gaining limited access to the web server file system
  3. Unauthorized access by someone hacking the web server itself
  4. Security issues with your web site, users, and administrators

With a dedicated server, there is no issue with #1 or #2 – you just have to secure you own web site and access properly and let LuxSci handle #3.  On a shared server, you can’t control other people’s stupidity or negligence.

On a shared web server, ePHI could  be stored in files and/or in a database.

Database-stored ePHI is pretty safe from access, unless the server itself is compromised, as long as the username and password to that database is not available on the shared server to anyone with unauthorized access to your files.

File-stored ePHI is more vulnerable.  If those files are unencrypted and the permissions are set improperly for any reason or the yare stored in a poor location, then there is the potential for unauthorized access in all 4 cases above.  Even if you are careful to use permissions and file ownership to isolate access to your files from other customers, it only takes one mistake or bug to break that system and any system-level compromise of the server would also leave all of these files exposed.

What are the requirements on a shared web server?

For these reasons,  LuxSci only permits ePHI on shared web hosting servers if (as documented in our HIPAA Account Restrictions Agreement for HIPAA customers):

  • The data is stored in encrypted files and the password+keys to decrypt those files is not also “right there”, or
  • The data is stored in a database and the credentials to access that database are protected against others on the same server from gaining access to it.

It is not enough to just

  • Use careful file permissions
  • Put the data in a web site password-protected directory
  • Use obfuscation in file and/or directory names

Furthermore, great care must be taken to ensure that should someone gain access to the raw files or scripts in your website, that they could not obtain the password to your ePHI-containing database or to decrypt the encrypted files.

What about in a dedicated server environment?

While use of a dedicated server does eliminate a lot of risk, and while we do permit storage of ePHI in unencrypted files (as only you the customer and LuxSci staff, your Business Associate, has access to those), there is no reason to be lax.  Care should be taken to secure ePHI to the maximum extent possible in every case.

So, what are our recommendations?

We highly recommend dedicated solutions.  The price tag is not high anymore, starting just over $100/mo.  The significantly increased security afforded by a dedicated solution is very important for HIPAA.

If you must use a web site on a shared server for ePHI (e.g. because you can’t afford a dedicated solution and are willing to sped the time and energy to properly secure your data), you have some work to do.  We recommend doing some or all of the following:

  1. Ensure that your web site is secured with an SSL certificate so all traffic to and from your site is encrypted.
  2. Use PGP or S/MIME to encrypt and decrypt any files containing ePHI that will be stored on disk. Do not store the password to the PGP or S/MIME key in your web site anywhere — force your web site visitor to enter the password and use cookies to preserve that password from page to page.  This separation of the password from your encrypted data and keys ensures security in the event that your data is compromised.
  3. Ensure that any ePHI-containing files are owned and accessible only by your user and are stored outside of your web site’s document root (e.g. so there can be no web link to access them directly).
    1. This ensures they are not accessible via a web link
    2. Proper ownership and restricted permissions further restrict access to the files so just your own account.
  4. If you store ePHI in a MySQL database, once again ensure that the password to that database is not stored in your site – required the web site visitor to enter it so that the password is separated from the data.  Better yet, encrypt the data using PGP or S/MIME before saving it in the database.
    1. What about CMS web sites, like WordPress, that require you to put the database credentials in a plain text file in the web site?  This is risky and we recommend that customers with these kinds of sites use dedicated servers or using the “Trick” discussed below.
  5. Use a MySQL database to log all accesses to any ePHI — an audit trail of access is important for HIPAA.
  6. Ensure that ePHI is only accessed by individuals who are “logged in” to your site somehow so that you know who they are, they have verified their identity with a password, and so you can track their activity.

A trick for maintaining separate user passwords all of which grant access to the same encrypted files, without leaving the password to decrypt those files in your site.

This method adds a little complexity to your site design, but increases security and adds a lot of usability.

  1. Define a single complex password [CP] that will be used for encrypting all content (or which will be used for accessing a database)
  2. For each user of your site, encrypt the CP and save it in a small file. Use that user’s own web site access password as the password to decrypt their own version of the encrypted CP.

Then, when a user logs in to your site successfully, you can use the user’s submitted password to decrypt the CP.  Then you will have the password that can be used to unlock any of the ePHI files or connect to the database that that user needs.

Clearly, this trick can be expanded to give selected access to specific files to specific users and can be extended via cookies, hashes, and other techniques to provide session-length persistence of the decryption information needed.

If this all sounds “greek” to you, it is very technical.  Running any web site with ePHI and HIPAA requirements will require significant technical skill to implement all of the security, privacy, and auditing features properly and to avoid simple, but very bad security blunders.

You should seek a developer well versed in these areas to implement your web site.  We recommend against using someone who is learning security as they go along or who has not developed similar sites before — that is a recipe for future trouble. We also recommend against being lazy and just setting up WordPress with some plugins with SSL and thinking that your site is thus secure and compliant.  If you “assume” then you are not performing your HIPAA risk analysis properly.

Will my web site be “HIPAA Certified”?

Neither LuxSci nor any other web hosting provider offering HIPAA compliant services will certify that your web site itself is HIPAA compliant.  At least, not unless either:

  1. They developed the site themselves and are in full control of all of its content and scripting going forward, or
  2. They spend hours reviewing your site scripts, design, and implementation.  This would be an expensive, paid audit and would be invalidated as soon as you change anything.

LuxSci does offer HIPAA compliance certification seals for email services and secure web form services … but not for web sites.  And there is good reason for this:

  • LuxSci is not in control of the content of your site or the workings of the scripts that run it
  • LuxSci is not auditing every change you make to your web site. E.g. a web designer could update the front page of the site one day and paste in some ePHI right there for everyone to see.  No one can stop that except for the web designer and your company procedures.

So, it is up to the customer to implement their web site in a compliant manner, as outlined and agreed to in our HIPAA Account Restrictions Agreement.  What LuxSci does do, which is all anyone can do who also gives you the freedom to install your own custom site, is to provide a HIPAA-compliant environment for you to operate in:

  • Providing a Business Associate Agreement
  • Ensuring the servers are secured
  • Ensuring that backups are made and restores can be had and that the backups are HIPAA compliant
  • Ensuring that the tools are available for your to implement security: E.g. SSL, PHP, Databases, Password protection, etc.

We bring the environment, you make the site and ensure it is done in a compliant way.  If you are unsure how to implement HIPAA-compliance in your web site yourself, please find someone who does – or find some other way to achieve your goals.  There is no magic switch that anyone can pull to make a web site always compliant; well, except for turning off the site…

 

Leave a Comment


You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.