WordPress & HIPAA – can these coexist?

As we discussed in an earlier post, WordPress, despite its vulnerabilities, is the world’s most popular content management system for both blogging and creating web sites.  It is popular because it is quick to set up, easy to administer, with a very large choice of plugins for add-on functionality, and themes for making the sites look good.  As a result, many LuxSci customers use WordPress in one fashion or another for their web sites hosted at LuxSci.

As LuxSci caters to a large segment of customers who have specific compliance needs, specifically HIPAA compliance, we are frequently asked about using WordPress in a medical provider setting. Given the information about WordPress vulnerabilities, the question usually asked is whether a site created using WordPress can secure access to electronic protected health information (ePHI) in a way that meets the requirements of the HIPAA-HITECH regulations.

Such questions are reasonable because although WordPress has many great features that make it quick and easy to get a web site running, it is still a third-party tool which is not specifically designed to conform to HIPAA standards. When using any third-party software, you should be aware of the associated risks that are out of your control. Vulnerabilities in WordPress can disrupt your site’s availability, perhaps even lead to a breach of protected and private information. Even if it is the WordPress software that’s at fault, the responsibility for any security lapses still falls on the site owner.

However, it is not all doom and gloom. The short answer to the question posed in the title of this post is “yes”. It is possible with care to build a site with WordPress (including plugins and themes) that is secured in a way that meets the requirements of the HIPAA security rules. The remainder of this post will discuss how this might be achieved.

Requirements of the HIPAA Security Rules

It is important to understand that the HIPAA security rules are actually a set of overall guidelines that covered entities and their business associates must follow to maintain the security of ePHI. In the unfortunate event of a breach, the covered entity must show that all reasonable measures were taken to protect ePHI. Thus, in a sense, it doesn’t make sense to discuss software such as WordPress as HIPAA-compliant or not. The HIPAA security rules aren’t a simple technical checklist, but rather a series of technical, operational, physical and administrative measures that have to be put into place and monitored and adjusted, as needed. (We have described such measures that could be taken by a small medical practice in a previous post.)

To summarize the HIPAA security rules, a covered entity and its business associates must:

• Ensure that ePHI they create/receive/maintain/transmit maintain the following protections:
  • Confidentiality: Ensure that ePHI is not disclosed to unauthorized persons.
  • Integrity: Ensure that ePHI cannot be altered in an unauthorized manner.
  • Access Control: Ensure that ePHI is only made available to authorized users.
  • Availability: Ensure that ePHI is accessible and usable on demand by an authorized user.
  • Transmission security: Ensure that ePHI in transit is protected against unauthorized access or alteration.
  • Logging: Ensure that information on access to ePHI (who? when? where? how?) is recorded and records maintained.
• Identify and protect against reasonably anticipated threats to the above items;
• Protect against reasonably anticipated, impermissible uses or disclosures;
• Ensure compliance to the above by their workforce

The operative words in the above are “reasonably anticipated”. Absolute watertight security is not achievable in practice, and HIPAA does not demand it. It only asks that a covered entity carry out a risk analysis commensurate with its own capabilities and constraints (such as size, technical capabilities, etc.) and determine the best solution that can meet the above aspects. A documented analysis and a reasonable justification for your choices can greatly help you, as a covered entity, in the event of a ePHI breach and a possible compliance audit.

To this end, the US Department of Health and Human Services recommends several steps that a covered entity should take to flesh out what might be reasonable and appropriate. These include:

1. Performing a risk analysis to determine what aspects of its online services might be vulnerable to breaches of ePHI;
2. Documenting the steps to mitigate against such vulnerabilities;
3. Maintaining all appropriate and reasonable security measures continuously;
4. Identifying a security officer within the organization whose task it is to develop, implement and ensure that its documented security policies are addressed, enforced and updated as circumstances and technology changes;
5. Maintaining all appropriate physical protections of ePHI data; and
6. Ensuring contractually that its business associates are also subject to HIPAA privacy and security rules and that it is informed of any violations of ePHI on the part of such associates.

In the remainder of this post, we’ll outline how a WordPress installation or its environment can be tuned to meet the above guidelines.

 

Using WordPress in a HIPAA-compliant manner

Let us examine the various items in the HIPAA security guidelines against WordPress features and see how each might be handled in a “reasonable” and appropriate way, leaning, as always, on the side of greater security.

Keep in mind that when referring to WordPress, we are also including the use of any plugins and themes. These are add-on enhancements to the base WordPress software, almost always provided by third parties, and it is a rare site that does not have some instances of these. Assuming these are from reliable vendors with a wide following, one can reasonably assume that such a plugin or theme has been extensively vetted in an operational environment; that security issues have been addressed as these emerge; and that there are active development resources for its enhancements and maintenance. Absent such a reassurance, it is unwise to rely on any additional 3^rd party software. Remember that you use these at your own risk, and that such parties are not your business associates in the HIPAA sense – you do not have any business associate agreement with them to protect ePHI.

In any case, the site administrator MUST remain vigilant to any software updates to the core WordPress and any plugins or themes used. It is essential to update these to the latest releases in a timely fashion. We have discussed the perils of not doing so in earlier posts.

Access Control

WordPress allows defining roles for various users, with each role (of which there are six) allowed a certain set of actions. It is sensible to minimize the number of roles and individuals assigned to such roles. Certainly, the roles of Super Admin (if managing multiple sites) and Administrator (for a single site) should be confined to a single responsible individual. Unless there is continuously varying content, the individuals assigned as editors should also be kept to a minimum.

It is also important to turn off open subscriber registration and individually vet subscribers who wish to gain access.

Some WordPress plugins also allow for easy management of the portions of a WordPress site that a specific role can manage. With such a plugin installed, the administrator can limit the areas of the site which different users (roles) can access. For example, a certain role that is allowed to check doctors’ calendars and set up appointments for patients might not be allowed access to patient records – unless an individual (a nurse, say) is allowed to play both roles.

Certainly, the backend database with patient information should be limited to only those roles which absolutely need such access.

Another aspect of access control is password management. The very first steps you should take with any new WordPress installation are:

1. Change the administrative username from “admin” to something else.  As “admin” is the default administrative login, botnets and other attackers will try to guess the password to that login name to attempt to gain access to your WordPress site.  If there is no “admin” login, they can’t guess its password.
2. Use strong passwords.  Botnets and other attackers that try to guess your password by brute force will be unable to guess it with reasonable effort if you pick a good one.  See Revised Password Strength Criteria and Security Simplified: The Base+Suffix Method for Memorable Strong Passwords for ideas.

Two factor authentication adds another step in an attempt to thwart attackers, by requiring an additional piece of information beyond something you remember. The most common method is to send a code to the user’s phone (bringing in the second factor – something you possess), which must be entered on the login screen. This makes it significantly more difficult for a hacker to gain access.  See Duo Two-Factor for a two-factor authentication app for a smartphone.

Confidentiality

One aspect of confidentiality is protection of data at rest against unauthorized access. Unless a WordPress expert is structuring your site, it is best to avoid keeping this sensitive data in the WordPress database. Implementation errors can make the data vulnerable; therefore, it is often best to store it elsewhere. If you decide to use the WordPress database, it is important to have backups, encrypt the databases, and to have clear access controls and audit logs for access to this data. A thorough audit will also be necessary to ensure that you have taken all reasonable and appropriate measures to be HIPAA compliant.

Transmission Security

A key element in protecting ePHI during access or transit is to ensure that access to the site is over HTTPS. The use of HTTPS will ensure that the data exchanged with a site visitor cannot be eavesdropped or altered in transit.

We have described in past posts how to choose an appropriate certificate to present to visitors which provides them the necessary reassurance from browser visual clues that they are indeed at your site and not that of an imposter.

Logging

Logging every activity on a WordPress site that aims at HIPAA compliance is essential. Such a log is particularly useful when analyzing any potential breach or even looking for any untoward activities. A proper log should record every change to the site – who made what changes, where and when. Additional details should include the IP address of the user who made the changes.

Such logs should be reviewed frequently as these can provide an early warning of potential hacking activities. For instance, are there multiple failed login attempts; or have there been login requests for certain IP domains where you would not expect your visitors to be; etc. Many audit logs send automatic email alerts to the administrator when triggered by suspicious or unusual activities.

Logs should be maintained (or at least a backup copy in near real-time) at a separate location than the site itself.

There are many fancy plugins that provide logs with many visually appealing ways to present the data, but, as always, the concern should be the quality and longevity of the vendor that provides it. Will it continue to provide updates to account for the latest version of WordPress? If such a log plugin is abandoned by its developers, it may be possible to find another to take its place, but you are left with two (likely incompatible) log formats.

Other considerations

Thus, it really comes down to the “use at your own risk” factor, which is the case with any web site content management software that you are using from a third party.   You will also need to place your WordPress site on a dedicated server with a hosting provider that understands HIPAA compliance and who will be willing to sign your HIPAA Business Associate Agreement.  This means that HIPAA-compliant WordPress hosting at platforms such as wordpress.com and GoDaddy are not possible.

Due to the consequences of a potential HIPAA breach, it is generally recommended that you use a professional WordPress developer who has experience or is made aware of the various aspects of HIPAA compliance. There are also companies that offer to do a thorough security audit of a WordPress installation for a very reasonable sum of money. That is money well spent.

However, it may be advantageous to have a custom site developed for you meeting your specific requirements rather than rely on WordPress. In such a case you will have full control over what is implemented and you can choose a developer who knows web site security, is aware of HIPAA compliance, and with whom you can have a strong contract.  The price of that is much less than the price of a possible HIPAA violation. Web hosting providers such as LuxSci are dedicated to HIPAA compliance. This might make them a better hosting option for websites that need to meet HIPAA requirements.

Read Next: For a deep dive, see our white paper: Securing WordPress