7 Steps to Make your Web Site HIPAA-Compliant

March 2nd, 2021

Telehealth is the new normal thanks to the Covid-19 pandemic. Many medical providers are finding that not only is telehealth a safer option during the pandemic, it can also help increase patient access to healthcare and improve outcomes. Along with video appointments, the virtual medicine push includes making protected health information available to patients via a web site and collecting similar private information from patients or would-be patients online.

However, where the health information of an identifiable individual is involved, the Health Insurance Portability and Accountability Act (HIPAA) is the official compliance document. The Omnibus rule requires all web sites, old and new, to be properly designed or their owners can face potential financial liability into the millions of dollars.

So, what do these requirements mean and how can HIPAA be followed in the context of a website?

What are the HIPAA compliance requirements for a web site?

HIPAA is an unusual law in that it makes a lot of recommendations (addressable items) and a few assertions (required items), but in the end it is up to each organization to determine for themselves what they need to do to be compliant. This creates a great deal of flexibility and also a great deal of uncertainty. In general, there are seven main areas dealing with protected health information (ePHI) that need to be examined to ensure HIPAA compliance:

  1. Transport Encryption: Data is always encrypted as it is transmitted over the Internet.
  2. Backup: Protected health information is never lost, i.e. should be backed up and can be recovered.
  3. Authorization: Data is only accessible by authorized personnel using unique, audited access controls.
  4. Integrity: ePHI is not tampered with or altered.
  5. Storage Encryption: Data should be encrypted when it is being stored or archived.
  6. Disposal: ePHI can be permanently disposed of when no longer needed.
  7. Omnibus/HITECH: Protected health information is located on the web servers of a company with whom you have a HIPAA Business Associate Agreement (or it is hosted in house and those servers are properly secured per the HIPAA security rule requirements).

How does a “basic” web site stack up to HIPAA requirements?

By a “basic” web site, we refer to one setup at any old web hosting provider (e.g. GoDaddy) and written using off the shelf software or by someone without training in web site security best practices:

  1. Transport Encryption – Fail. Data is not encrypted during transmission.
  2. Backups – Maybe. Most web hosts will backup and restore your data for you. However, this assumes that the data collected is in a location backed up by the host. If you have information emailed to you, you must be sure that your email record is complete and the backups are good.
  3. Authorization – Maybe. Depends on your implementation.
  4. Integrity – Fail. No way to be sure that data is not tampered with or to tell if it has been.
  5. Storage Encryption – Fail. Data is never encrypted.
  6. Disposal – Maybe. Depends on your implementation. However, some web hosts and IT departments keep data backups indefinitely — and that is not “disposal.”
  7. Omnibus – Fail. Most web hosting providers do not even know what a HIPAA BAA would require them to do. Many of the remaining web hosts know that they cannot both sign such an agreement and live up to its requirements without completely changing how their business works and their prices.

Overall grade — failing. If you have a basic web site that has never explicitly been updated for HIPAA and which has anything to do with protected patient data, you can be almost certain that it is not compliant and needs attention. If you plan on expanding your site to include protected patient data, be sure that whoever does it for you is familiar with the requirements that you need to meet.

So, how do I make sure my web site is HIPAA-compliant?

Obviously, there are a large number of steps that can and should be taken to turn your basic web site into a HIPAA-compliant one. What works for you will depend upon exactly what you are trying to accomplish with your site and how protected health information is present and transmitted. Below, we discuss the seven most common cases that we encounter.

  1. Transmission Encryption: PHI is always encrypted as it is transmitted over the Internet. The first step is to ensure that you have a secure web site (i.e. one protected by SSL and which is accessed via https://…). Any page that collects or displays protected health information, or which is used for logging users in, which transmits authorization cookies, etc., must be protected by SSL and must not be accessible insecurely (i.e. there should not be an alternate insecure version of the same page that people can access). Use of SSL can meet HIPAA’s data transmission security requirement in terms of communications between the end user and your web site. However, your SSL configuration must be strong enough to prevent methods of encryption that are “too weak;” it is up to your web host to be sure that this is the case. (See: What level or SSL or TLS is Required by HIPAA?) Next, what if the end user submits PHI that is collected on your web site and then your web site transmits that data elsewhere, or stores it? This process must also be HIPAA-compliant. We will discuss this below, as it is one of the hardest things to do and still be compliant.
  2. Backup: Data is not lost, i.e. is backed up and can be recovered. You must be sure that all PHI stored with your web site or collected from your web site is backed up and can be recovered in case of an emergency or accidental deletion. Most web hosts provide this service for information stored on their servers. If your site sends information elsewhere (for example, to you via email), then those messages must also be backed up or archived and you must take care that those backups are robust, available, and accessible only by authorized people. Note that the PHI stored in backups must also be protected in a HIPAA-compliant way — with security, authorization controls, etc.
  3. Authorization: Data is only accessible by authorized personnel using unique, audited access controls. Who can access the protected health information that resides on your web site or which is collected there? Your web hosting provider probably can. Are they a trusted HIPAA Business Associate with a privacy agreement? If the site collects health information and sends it to you or others, it is important to know who can access those messages. Anyone with access to your email or the messaging system? Are they all trusted and “in the loop”? If your web site stores or provides access to PHI, does your web site enforce unique, secure logins which ensure that only authorized / appropriate people can access that data? Are these logins and the data accesses audited? This will be up to your web site designers to setup properly for you.
  4. Integrity: PHI is not tampered with or altered. Unless the information that you collect and store is encrypted and/or digitally signed, there is no way to prevent it from being tampered with or to verify if tampering has happened. It is up to your organization to determine if tamper-proofing your data is needed and how to best accomplish that. Generally, using PGP, SSL, or AES encryption of stored data can accomplish this and also address the next point.
  5. Storage Encryption: Data is encrypted if it is being stored or archived. It is up to your organization to determine if this is needed; though it is highly recommended. If storage encryption is necessary then you need to ensure that all collected and stored protected health information is encrypted and that it can only be accessed/decrypted by people with the appropriate keys. This makes backups secure, protects data from access by unauthorized people, and generally protects the data no matter what happens (unless your special keys are stolen). Storage encryption is especially important in any scenario where the data may be backed up or placed in locations out of your control, or where you may be sharing a web server with other customers of the same web host. Should something unfortunate happen and a server become compromised, your liability is significantly limited by having the data encrypted.
  6. Disposal. Information can be permanently disposed of when needed. This sounds easy, but you have to consider all of the places where the data could be backed up and archived. You need to ensure that all of those backups will expire and disappear. Consider that every location that the information touches could be making backups and be saving copies of your data … indefinitely. It certainly helps if the data is encrypted in the backup, but if the backup is there and the keys to open the data exist, then it is not really “disposed of.” It is up to you to determine how far you need to go to ensure data disposal in order to be HIPAA compliant. It is up to the folks managing your servers to also ensure that the media (e.g. the hard drives) containing PHI are properly disposed of when you are no longer using them.
  7. Business Associates: You must have a HIPAA Business Associate Agreement with every vendor that touches your PHI. If your web site or data is located on the servers of a vendor, then HIPAA (first HITECH and then in Omnibus) requires that you have a signed Business Associate Agreement with them. This agreement ensures that the vendor will follow the HIPAA security rule requirements with respect to your data and its servers. Note that web sites are complex beasts and no web hosting provider will be policing your web site functionality and content — they can’t. Instead, they will be providing an “infrastructure” that meets HIPAA compliance requirements and they will require you to design and manage your web site so that its functionality is HIPAA-compliant. Choosing a provider will not make your web site HIPAA-compliant unless you and your designers ALSO take all of the steps to ensure that its design and functionality is compliant. This is universal unless you buy a web site that is pre-designed and fully under the control of the host.

So, there are many things to do and a lot is all “up to you.” Of course, just because you are on the “honor system” doesn’t mean that you can make whatever choice you feel like. If you make a poor choice and something bad happens or if you are audited, you will be found willfully negligent (ignorance is not an excuse here). You really have to carefully consider what is necessary and appropriate to suitably protect health information and the privacy of your users, based on your web site application and how the patient data is used and transmitted.

Collecting health information from people

Many doctors and medical practices like to use online tools to collect patient information on their web site so that they can:

  • Sign up new patients
  • Schedule appointments
  • Make diagnoses and recommendations about medical situations
  • Get into digital prescriptions

Securing the transmission of the information from the patient to the web site is pretty easy (it’s #1 — use a web site secured with SSL). However, what do you do with that information? Common solutions include:

  1. Store it in files on the web server to download later
  2. Store it in a database for download or remote access
  3. Email it to someone

The third option, is the most popular choice because it is the easiest and requires the least additional software or infrastructure… everyone is already checking their email. It also opens a whole can of worms in terms of “how do you make the email component HIPAA-compliant?”

1. Storing the data in files requires that:

  • The web site encrypt the files
  • Someone downloads the files over a secure channel (i.e. Secure FTP)
  • The web site owner gets notified via an email that a new file is waiting
  • Backup and disposal are taken care of

2. Storing the data in a database allows you to write software for remote access and management of that information, however:

  • Transmission to and from the database needs to be secure.
  • The software that provides management access must be secure and meet all sorts of HIPAA requirements in terms of access control and auditing.
  • Issues regarding encryption keys and database secure storage must be addressed.

So, Option 1 is easy, but requires a bit more technical knowledge on the part of the users and puts the onus of backup and disposal on them. Option 2 is better and allows more flexibility, usability, and control and a centralization of the data into one place. However, Option 2 is more technically complex requires more cost and effort to implement properly. Option 3 is easy, but how do you make the email HIPAA-compliant?

Securing data emailed from your web site forms

The ideal procedure for securing your emailed data is basically as follows:

  • Your secure web site encrypts the submitted data (using PGP or S/MIME, TLS, or a secure web-based email pickup solution) such that only one or a few of your employees can open it.
  • This data is emailed to those recipients and “forgotten” by the web site (or an encrypted copy is stored on the site if you prefer).
  • The recipients receive the data and stored it on their email server (still encrypted unless TLS was used for delivery).
  • The recipients can access these messages securely (over SSL) and decrypt the data either in their email program or on a Web-based interface that supports decryption.
  • The email provider takes care of backups.
  • Deleted messages will expire from backups after a while (get a signed statement saying this from them, if you like).
  • Keep copies of all of the encrypted messages on the server instead of downloading them all, so that you are responsible for backups and so that they are all stored in a central location.

Make your Web Forms HIPAA-compliant Quickly

LuxSci’s SecureForm service allows you to collect data from your web (and PDF) forms and deliver it to you via email, secure FTP, or database in a way that is both automatically HIPAA-compliant and does not require any programming on your part.

Further Reading: