The HIPAA Security Rule Simplified
If you are like me, legal compliance is one of those things that really make you cringe and sigh in discontent. However, as we all know, legal compliance is there for a reason. Generally speaking, many of them are easy to comply with as long as you have the right tools, and most of them are beneficial to you, your business, and your customers in the long run.
You are probably here because you already know something about HIPAA (and sighed when you figured it applies to you), or you don’t know much about it and you are here to learn. Either way, it is best to start with the basics and build upon them. Keep in mind: this post focuses mainly on the ‘web security’ sections of HIPAA.
What is HIPAA Compliance?
The Health Insurance Portability and Accountability Act (HIPAA) was enacted by the U.S. Congress in 1996. It was put in place to mandate healthcare information management in the US. Namely, it mandates the privacy and security of PHI (Private Health Information) in light of all the vulnerabilities that come with managing health information (especially electronically).
Who has to comply?
Anyone who creates, receives, transmits, or maintains PHI. So most healthcare companies that hold patient information, and business associates of healthcare companies that deal with PHI.
HIPAA and Web Security
HIPAA as a whole is a massive, complex act. So to make things simpler it was divided into five separate titles. The one that interests us for now is the one that deals with web security — Title II. Title two also deals with preventing Medical Fraud and Abuse, Medical Liability Reform, and Administrative Simplification. The Security rule, together with the Privacy rule and EDI (Electronic Data Interchange) is part of the Administrative Simplification section of Title II. We’ll be talking about this section, and mainly focus on the Security Rule.
So, what does the Security Rule actually include?
The Administrative Simplification section deals with the management of PHI in general (particularly, the Privacy Rule). The Security Rule seems more like a subset of the Privacy Rule since it only encompasses electronic Protected Health Information (ePHI). Some of the organizational and documentation requirements and processes are quite similar to the ones mentioned in the Privacy Rule. To make navigating across the complex Security Rule easier, the rule is divided into three different parts:
- Requirements for implementation of Safeguards:
- Administrative Safeguards
- Physical Safeguards
- Technical Safeguards - Organizational Requirements
- Policies and procedures and documentation requirements
Before we get into each of these parts, let’s look over the big picture — the General Rule. The general security rule is contained in §164.306, and the Security Rule spans from §164.302 to §164.318.
The General Rule (§164.306) starts off by listing the general requirements which you can read here. Even though the requirements don’t seem burdensome at first sight, they become more complex and demanding when we take detailed specifications into consideration. The frequent use of the word ‘reasonably’, in sections a) and b), also leaves us with quite a vague idea of what is actually required. Also section b) emphasizes the importance of flexibility when it comes to deciding which security measures to use. The good news here is that companies have some freedom in choosing the security measures appropriate for them. Factors like technical infrastructure, size, capabilities, cost, and probability of potential risk can be taken into account when deciding on proper measures. So the measures that need to be taken by Company A, don’t necessarily need to be taken by Company B, and vice versa. However, this does not let companies carelessly omit requirements, if a requirement or a specification is omitted appropriate documentation for justification must be provided.
Following the general rules, the Security Rule requires companies (covered entities) to implement and maintain appropriate safeguards for securing their ePHIs. The safeguards are divided into three categories: Administrative, Physical, and Technical.
The Administrative Safeguards § 164.308 sets 8 standards and a number of implementation specifications for each. Some specifications are ‘required’, however, some are ‘addressable’. Again, this does not mean ‘free lunch’ on the addressable specifications, you still need to provide the necessary documentation to prove why isn’t your service compliant with those specifications, or what alternatives you have taken. The HHS (Health & Human Services) summarizes the Administrative safeguards as policies and procedures that are meant “ to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of the covered entity’s workforce in relation to the protection of that information,”. This means that you have to implement policies and procedures that will help you and your employees with the proper use of ePHI. Such policies and procedures include Risk Analysis and Management, proper delegation of security responsibilities, security training, etc. (Check this document for the full list of standards and specifications)
Next up are the Physical Safeguards § 164.310. As the title already suggests, the Physical Safeguards are the measures, policies, and procedures that are designed to protect your ePHI from physical threats such as a natural disaster, environmental hazard, or an unauthorized intrusion. Such policies and measures include making sure that physical access to ePHI is restricted to authorized persons only, proper storage of data as well as backups.
The Technical Safeguards § 164.312, according to HHS are “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.”. The safeguards also include certain technologies that are implemented for ensuring the security of your ePHI. Anti-virus software, multi-factor authentication, data encryption, firewalls, vulnerability scanners, and managers are all examples of technical safeguards.
After all the safeguards, there are some organizational requirements you will have to take care of. Shortly, The Organizational Requirements § 164.314, mostly relate to standards for contracts with business associates, group health plans, and other agreements.
And lastly, the Policies and procedures and documentation requirements § 164.316 section deals with the documentation of implemented policies and procedures. It deals with how documentation should be recorded, stored, made available, and updated.
So… There you have it! Even though this article is long it still doesn’t include all details. In fact, to fully understand the Security Rule, I’d suggest educating yourself from as many sources as possible. Further, there are countless tools and services that can help you get HIPAA compliant. One such tool is a Vulnerability Scanner. They scan your website for security issues and provide a report of all the findings. This can help you assess the security of your website, and fix the security vulnerabilities on it. Using a Vulnerability scanner will have some of the boxes ticked off, regarding the Technical and Administrative Safeguards.
If you want to get started with a Vulnerability Scanner you can get started with Probely for free! We also provide you with reports that you can show to your auditors, clients, or if it comes to it (hopefully not) an administrative law judge.
Healthcare organizations can use the Probely web application vulnerability scanner to execute HIPAA vulnerability scanning. By doing this, you will increase your efforts toward HIPAA compliance.
Using Probely, organizations can automate their security vulnerability scanning (a HIPAA security rule) and fix the vulnerabilities using the guidelines given by Probely, providing their clients with a more secure web app.
In short, Probely can help you, as a technical safeguard (Technical Safeguards § 164.312), with the requirements stated in the Security Rule of Title II.
