With a 40% increase in healthcare data breaches from 2015 to 2016, securing PHI is more important than ever. Let’s look at what HIPAA means for WordPress, the ways you can make WordPress compliant, and the tradeoffs for each one.
HIPAA requirements and WordPress
The Department of Health and Human Services list four very vague technical guidelines for making a website HIPAA-compliant. WordPress has some method for meeting all of these, either through standard functionality, off-the-shelf plugins, or custom development.
- Access Control. A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI).
WordPress can do this with a mix of built-in security and plugins. An out-of-the-box WordPress install lets you add and modify user roles, and to lock down admin- and public-side content by those roles.
Get a demo of Formulate and get your WordPress site HIPAA-compliant.
However, the standard roles are pretty basic. You may need plugins to completely disable a module or content type for non-authorized users. For example, you’ll need a plugin to give certain users permission to edit service-line content, but disable their access to PHI stored in calendar registrations.
If you have only a few people who work on your site, you can probably get by without a plugin. You’ll definitely need a plugin if you have multiple users across departments, or if you have multiple categories of PHI (such as calendar registrations and appointment request forms).
This HIPAA guideline also deals with data encryption. HIPAA doesn’t explicitly require data to be encrypted at rest, but it’s considered best-practice and should be followed wherever possible. MySQL has built-in functions to handle this. Plugins for this exist as well, but they may not be compatible with other things on the site.
- Audit Controls. A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.
This piece requires a plugin to fully implement. There is at least one good, well-reviewed and complete option for implementing this.
- Integrity Controls. A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed.
This is partially covered under audit logging, and also under database security. Most everything covered here would be handled by good hosting practices coupled with a good audit logging plugin. Anybody planning to build a HIPAA-compliant site needs to host in a HIPAA-compliant environment.
- Transmission Security. A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.
Use Transport Layer Security (TLS), a protocol for securing communications over a computer network. And make sure your database-to-application communication isn’t happening over the internet. These are pretty standard practices.
Balancing the tradeoffs
On the surface, HIPAA-compliance may not seem that hard. WordPress has a plugin for everything. The real challenges come in when you consider the interaction between all of the moving pieces: core WordPress software, off-the-shelf plugins, and custom functionality.
To start, it’s critical that WordPress is kept up-to-date, because of its wide adoption and status as open-source software. WordPress vulnerabilities are frequently discovered and exploited. Every day that a site stays on an outdated version can compromise your data, and in turn, your HIPAA-compliance.
Having to keep a site on the bleeding edge version while relying on third-party plugins introduces some competing concerns. Any time you update core software, it can cause problems with any third-party component that interacts with it. In many cases it’s advisable to avoid this sort of conflict by waiting for a software platform to mature before jumping on board. However, this is not an option with WordPress because it’s constantly evolving.
There is also a concern around the plugins themselves. You’ll likely use other plugins to enhance the site, and each one of those introduces new vulnerabilities. You must monitor these plugins and keep them up-to-date, regardless of changes in functionality or compatibility with other plugins, or any customizations you may have made to the plugins.
As for the HIPAA-compliance plugins (such as audit logging), you have to take some leap of faith that those will be kept up to date with the latest versions of WordPress. What do you do if upgrading to the latest version of WordPress breaks your audit logs? That creates a no-win situation in which you may not be compliant either way.
And what if your audit logging plugin is abandoned by the developer? There will probably be other options to take its place, but you’ll have to decide what to do with all of the logs that you already have.
Those are the real challenges of maintaining a fully secure WordPress site that deals with such sensitive data. Balancing correct site functionality with security is not a good choice to have to make.
How to approach HIPAA-compliance
There are three ways to approach HIPAA-compliance for WordPress.
First, many experts would recommend you keep all PHI in a separate application, completely segregated from WordPress, and pass through any sensitive information from the website. This alleviates the WordPress site from any responsibilities relating to handling PHI.
If you want to view the PHI data in WordPress’ administrative interface, you can develop a custom plugin to display the data to an authorized WordPress user without much consequence, as long as the plugin logs who viewed what.
Second, you can develop custom plugins to deal with all PHI and manage it all within its own context, rather than relying on WordPress and its extensions to help. This option is effective, but also costly and time consuming. How costly and time consuming depends on what you are trying to do, but this solution is probably not efficient unless your site already requires a lot of custom development.
Third, you can go the third-party security plugin route. This is a viable option, but it’s less reliable and predictable in the long run.
We would highly recommend one of the first two solutions, though it’s hard to say which one is best without details about a particular site.
More questions? We’re happy to help
Sign up for a demo of Formulate, a form builder that will help you make your WordPress site HIPAA-compliant.