HIPAA Security Rule Requirements & Implementation Specifications

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 consists of standards and implementation specifications.

Per HIPAA Security Safeguards: 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. This is where the Security Rule sets itself apart from the overall HIPAA Privacy Rule as there is a strong focus shift to the protection of ePHI.

Many of the Security Rule 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.

What Are the Requirements of the HIPAA Security Rule?

The Security Rule is comprised of various safeguards that are categorized into three different types:

1. Administrative Safeguards – These include organization-wide activities such as policies and procedures, risk mitigation, employee training, and contingency plans.
2. Physical Safeguards  – These safeguards are related to physical components such as locked facility doors, datacenter cameras, workstations, and even employee’s remote devices.
3. Technical Safeguards – As the name suggests, these include more technical protections of ePHI such as encryption or access controls.

Within these safeguards, you have standards and implementation specifications, which we dive into detail below.

What is a Security Rule Standard and Implementation Specification?

The best way to explain standards and implementation specifications is through an example. One standard, 164.308(a)(1)(ii)(D), is the requirement of 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 a broad safeguard that should be in place and the implementation specification is a description of how to meet the requirement.

You might ask why the rule is structured in this manner. Per this summary from HHS, 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 is 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 Is the Difference Between “Required” and “Addressable” 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.

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” are 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 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 note that “addressable” does not technically mean “optional” when it comes to implementation specifications. For addressable implementation specifications, the covered entity must assess whether the security safeguard is reasonable and appropriate in the entity’s environment and the outcome of that assessment will result in one of the following decisions (again sourced from HIPAA Security):

• Implement the addressable implementation specification.
• Implement an equivalent alternative measure(s) that allows the entity to comply with the standard.
• Not implement the addressable implementation specification or any alternative measures, if equivalent measures are not reasonable and appropriate within its environment.

Covered entities are required to document, in writing, their assessment and factors considered to support the decision made.*

*Documentation: To comply with the HIPAA Security Rule, documentation is crucial. To reiterate, “addressable” does not mean it can be ignored. Each addressable implementation specification should either be implemented as described in the specification or alternative measures should be documented. If an organization makes a judgment call that neither the specified safeguards nor alternative measures are unreasonable and inappropriate within the environment, the assessments and 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 ePHI. 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 larger covered entities (also sourced from the HIPAA Security Series).

 

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 security 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.

What Is the Purpose of A 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 (like a potential security breach) and vulnerabilities. From here, the estimated 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.

Are There Tools to Assist Documentation and Compliance?

HHS.gov has provided comprehensive and easy to understand guidance on documenting the risk analysis, implementing a risk management program, and complying with the standards.

Per the Guidance on Risk Analysis from HHS: 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 and 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. The current and past versions of the SRA tool can be found at the link above.

Summary

In summary, the standards and implementation specifications within the Security rule may be broad and confusing at first glance, but with proper risk analysis and documentation, requirements can be met. At Linford & Company, we provide HIPAA Compliance audits to assess an organization’s regulatory compliance effectiveness. The typical audit scope includes HIPAA Security and Breach Notification Rules, however the engagement can be tailored to also include the HIPAA Privacy Rule and other state regulation requirements.

If you have any further questions or would like to discuss how Linford and Company can help your organization with HIPAA Compliance, please Contact us.