Compliance with the requirements of the HIPAA Security Rule starts with understanding how it is constructed. The HIPAA Security Rule is part of the overall HIPAA Privacy and Security Rule and is comprised of standards and implementation specifications.
Each Security Rule standard is a requirement: a covered entity must comply with all of the standards of the Security Rule with respect to the EPHI (electronic private health information) it creates, transmits, or maintains.
Many of the standards contain implementation specifications. An implementation specification is a more detailed description of the method or approach covered entities can use to meet the requirements of a particular standard.
Standard and Implementation Specification Example:
Required standard 164.308(a)(1)(ii)(D) is an Information System Activity Review. The associated implementation specification is: “Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports” (source). The standard is broad and the implementation specification is a description of how to meet the requirement.
Why is the Rule Structured This Way?
The Security Rule is structured to be both scalable and flexible, so that covered entities of different types and sizes can implement the standards and implementation specifications in a manner that is reasonable and appropriate to their circumstances. HIPAA did not mandate the use of specific technologies or require uniform policies and procedures for compliance because the regulatory authorities recognized the diversity of regulated entities and appreciated the unique characteristics of their environments.
The Security Rule’s scalability and flexibility are made possible through the use of implementation specifications, each of which are labeled in the Rule as either “required” or “addressable.” The differences in these designations may be confusing so we’ll do a quick review of each with examples to help illustrate how they are applied.
What are Required Implementation Specifications?
A “required” implementation specification is exactly that: required. In that regard, “required” implementation specifications are similar to standards. A covered entity must comply with required implementation specifications, and failure to do so is an automatic failure to comply with the HIPAA Security Rule.
- An example of a “required” implementation specification is the requirement that “all covered entities must implement policies and procedures to address security incidents in accordance with Section 164.308(a)(6)(i) of the Security Rule”.
- The Security Rule is inflexible with regard to developing, maintaining, and documenting Security Incident Procedures.
What are Addressable Implementation Specifications?
For “addressable” implementation specifications, the covered entity must assess whether the security safeguard is reasonable and appropriate in the entity’s environment.
- An example of an “addressable” implementation specification is the requirement that all covered entities must determine whether “Encryption and Decryption” is reasonable and appropriate for their environment in accordance with Section 164.312(a)(1) of the Security Rule.
- The Security Rule is flexible with regard to the use of encryption as it is allows reasonableness and appropriateness to be considered. In practice, this may lend support to a decision not to encrypt ePHI at rest within the confines of a data center while concluding that all portable workstation hard drives must be encrypted because of the risk that they may be lost or stolen.
Are Addressable Implementation Specifications Optional?
No. It is important to remember that “addressable” does not mean “optional” when it comes to implementation specifications. After assessing whether the security safeguard is reasonable and appropriate in the entity’s environment for the addressable implementation specifications, the covered entity must decide whether it will:
- Implement the implementation specification.
- Implement an equivalent alternative measure that allows the entity to comply with the standard.
- Not implement the implementation specification or any alternative measures, if equivalent measures are not reasonable and appropriate within its environment.
Covered entities are required to document their assessments and all decisions.
Documentation: To comply with the HIPAA Security Rule, documentation is crucial. To reiterate, “addressable” does not mean it can be ignored. Each addressable should either be implemented as described in the specification or alternative measures should be documented. If an organization makes a judgement call that neither the specified safeguards or alternative measures are not reasonable or appropriate within the environment, the factors influencing this decision making must be documented.
What constitutes Reasonable and Appropriate?
Factors that determine what is “reasonable” and “appropriate” could include cost, size, technical infrastructure, and resources. Small covered entities tend to have fewer factors/variables (i.e. fewer workforce members and information systems) to consider when making decisions regarding how to safeguard EHPI. As a result, the appropriate security measures that reduce the likelihood of risk to the confidentiality, availability, and integrity of EPHI in a small covered entity may differ from those that are appropriate in large covered entities.
While cost and resources are real and tangible factors in business decisions, it does not free covered entities from meeting the requirements identified in the rule, alone. The most important factor that should be considered (and documented) is the risk to confidentiality, availability, and integrity of the EPHI in the organization’s environment, which is documented in a security risk assessment.
Use of the Risk Analysis
In addition to being a required implementation specification, performing a security risk analysis is critical in determining the treatment of the addressable implementation specifications and judging reasonable and appropriate measures to safeguard EPHI.
A security risk analysis first identifies all EPHI an organization has created, received, maintained, or transmitted and the source or location in the organization’s environment. With this in mind, the risk analysis should then identify potential threats and vulnerabilities. From here, the estimated the likelihood and potential impact of an exploited vulnerability or triggered threat should be documented. These estimations will help prioritize the security measures which should be developed and implemented or improved upon. The risk analysis documents the factors that determine what are “reasonable” and “appropriate” security safeguards, as mentioned above.
For additional information on the importance of the security risk analysis, see the following article: The Security Risk Analysis and HIPAA Compliance.
Are There Tools to Assist Documentation and Compliance?
The Office of the National Coordinator for Health Information Technology (ONC) and the HHS Office for Civil Rights (OCR) have jointly launched a HIPAA Security Risk Assessment (SRA) Tool. The tool’s features make it especially helpful by assisting small and medium-sized health care practices and business associates to comply with the HIPAA Security Rule. If the tool is used properly, it can serve as the required documented risk assessment and guide organizations through documenting any safeguards that differ from the addressable implementation specifications. It covers each of the standards and implementation specifications. It also asks questions about current safeguards in place to help organizations determine the implementation specifications or alternative measures that are reasonable and appropriate within its environment.
HIPAA Security Services and Resources
Linford & Company provides HIPAA Compliance audits that are designed to assess an organization’s risk management and regulatory compliance effectiveness. Most engagements are scoped to include the requirements of the HIPAA Security and Breach Notification Rules. Contact us if you would like to discuss HIPAA audits and compliance, further.
For more education, see the following past HIPAA related posts on the Linford & Company blog:
- HIPAA Wall of Shame
- HIPAA Record Retention Requirements
- Importance of HIPAA Business Associate Agreements
Linford & Co., LLP, founded in 2008, is comprised of professional and certified auditors with specialized expertise in SOC 1, SOC 2, HIPAA, HITRUST, FedRAMP and royalty/licensing audits. Our auditors hold CPA, CISA, CISSP, GSEC licenses and certifications. Learn more about our company and our leadership team.