Addressable vs. Required Implementation Standards
Within the HIPAA Security Rule, there are a series of safeguards and standards that all organizations under HIPAA, both business associates and covered entities alike, must follow in order to keep ePHI entirely safe. These are categorized as physical, technical, and administrative safeguards. Throughout the verbiage of the law itself, there is an ambiguity built into each standard when it comes to the way that organizations can implement that.
The HHS intentionally wrote flexible implementation into the text when they created, wrote & passed HIPAA. At times, they built clear and specific guidelines to follow for implementation, but with other standards, they left the details of executing that piece in the hands of the Privacy Officer at each organization. In this blog, we will look at why the HHS decided to have two types of implementation standards, what those mean, and what standards fall underneath each.
The two types of standards underneath the Security Rule are “Addressable Standards” and “Required Standards.” All requirements within the HIPAA Security Rule are clearly designated as one of these two types, and cannot change between the two. We’ll define them both, give you some examples, and talk about practical implementation guidance for you.
What are “Required” Rules under HIPAA?
Of these two kinds of standards, the “required” standards are fairly cut and dry as to what we expect for HIPAA. A required standard is something that all covered entities and business associates must implement just as is stated by the law. There is a much smaller degree of flexibility with a required specification and typically comes with a clear sense of direction and instruction in terms of implementing it into your business operations.
What are “Addressable” Requirements under HIPAA?
On the other hand, an addressable requirement provides flexibility for organizations as they can implement the standard as it appears, implement an alternate form of reaching the intended compliance standard, or not implement the standard at all which comes with a huge caveat. It is important for us to make it extremely clear that if a company chooses not to implement an addressable standard, then they must have a clear and strong argument for why that standard is not necessary for their particular situation and then have written documentation of that reasoning.
This flexibility in implementation is designed so covered entities and business associates will assess each safeguard laid out in the Security Rule and then decided how that is reasonable and appropriate to implement in their organization in order to increase ePHI security. That is why the HHS has allowed HIPAA organizations to take some ownership over their compliance so that they can guarantee the most appropriate ways to handle the Security Rule safeguards in their workplace.
Here is another way to understand this tricky concept - let’s say that your mom put you in charge of feeding you & your sibling’s dinner one night when you were a teen. As long as everyone got fed and no one ended up sick, she’d be happy. Well, that still left you with a few options - you can make something at home, take everyone out to a restaurant, or go through a quick drive-thru. Each of these methods accomplishes the goal but each of these may be a better fit depending on the situation. As long as everyone is well-fed, the goal is accomplished, but you likely will have to explain your reasoning to your mom so you should be prepared for that!
Are Addressable Requirements Optional?
When people hear that certain HIPAA Security Rule requirements can be “addressable” instead of “required” - they often assume that it makes those standards optional. That is not true! These standards are just as important as the required standards and cannot simply be ignored. However, there is some leniency in terms of implementation. If your organization decides to follow the third option, it should not be done so casually.
Documentation for Alternate Solutions:
The documentation that you are expected to have in the event of choosing an alternate implementation or no implementation at all is extremely important, especially in the event of an audit. If you are ever audited or investigated by the OCR, they will thoroughly review the documentation that you have for any decisions related to the addressable standards, among other investigative actions. If they determine that your reasoning for choosing an alternate solution is not sufficient, then you may be fined and monitored for noncompliance.
You cannot be penalized for “over complying” with addressable standards in any capacity, but you can (and will!) be penalized for failing to comply with one of these standards. Whether that is due to you forgetting about it or not justifying and documenting your reasoning behind your choice implementation sufficiently, you can definitely be punished. That is why this situation it is certainly better to be safe than sorry!