Breaking Down the HIPAA Security Standards
Today I am breaking down the HIPAA Security Rule, 45 CFR § 164.308, into byte-size portions to help you understand how they are significant to your organization. The HIPAA Security Rule establishes security standards for protecting all electronic protected health information (ePHI), 45 CFR Part 160 and Part 164, Subparts A and C.
The HIPAA Security Standards provide a structure for healthcare regulated entities (health plans, clearinghouses, or covered health care providers) to develop and implement policies and procedures to guard against and react to security incidents. All healthcare regulated entities must comply with the applicable standards, implementation specifications, and requirements of the Security Rule with respect to electronic PHI, 45 C.F.R § 164.302.
The Security Rule allows regulated entities of all sizes to implement reasonable and appropriate measures that enable them to comply with the Rule. The standards were designed to be scalable, flexible and technology neutral to allow regulated entities to comply in a manner consistent with the complexity of their organization. The rule does not specify any specific technology. This is intentional so the healthcare community will is not be bound by specific systems and/or software that may become obsolete.
HIPAA Security Rule Basic Concepts
First let me set the ground work to help you with the basic concepts that make up the security standards and implementation specifications. Each HIPAA Security Rule standard is a requirement: a regulated entity must comply with all of the standards of the Security Rule with respect to the electronic PHI it creates, receives, maintains, or transmits.
Many of the standards contain implementation specifications. An implementation specification is a more detailed description of the method or approach regulated entities can use to meet a particular standard. Regardless of whether a standard includes one or more implementation specifications, regulated entities must comply with each standard.
Implementation specifications are either required or addressable. Here is a breakdown of each:
Required is similar to a standard, in that a regulated entity must comply with it. For example, all regulated entities including small providers must conduct a complete and thorough “Risk Analysis,” 45 CFR § 164.308(a)(1).
Addressable requires regulated entities to perform an assessment to determine if the specification is a reasonable and appropriate safeguard in their environment. After performing the assessment, a regulated entity decides if:
- It will implement the addressable implementation specification.
- Implement an equivalent alternative measure that allows the entity to comply with the standard.
- Or not implement the addressable specification or any alternative measures, if equivalent measures are not reasonable and appropriate within their environment.
Regulated entities are required to document assessments and all decisions. For example, all regulated entities including small providers must determine whether “Encryption and Decryption” is reasonable and appropriate for their environment, 45 CFR § 164.312(a)(1).
Factors that determine what is “reasonable” and “appropriate” include cost, size, technical infrastructure and resources. While cost is one factor entities must consider in determining whether to implement a particular security measure, some appropriate measure must be implemented. An addressable implementation specification is not optional, and the potential cost of implementing a particular security measure does not free covered entities from meeting the requirements identified in the rule.
HIPAA Security Rule Main Sections
The HIPAA Security Rule is divided into six main sections – each representing a set of standards and implementation specifications that must be addressed by all regulated entities.
The Security Rule is divided into six main sections – each representing a set of standards and implementation specifications that must be addressed by all regulated entities. They are:
- Administrative Safeguards
- Physical Safeguards
- Technical Safeguards
- Organizational Requirements
- Policies and Procedures
- Documentation
Each Security Rule standard is a requirement: all regulated entities must comply with all of the standards of the Security Rule with respect to the ePHI it create, receive, maintain, and/or transmit.
Many of the standards contain implementation specifications.
An implementation specification is a more detailed description of the method or approach regulated entities can use to meet a particular standard. Implementation specifications are either required or addressable.
Regardless of whether a standard includes one or more implementation specifications, all CEs and BAs must comply with each standard.
Administrative Safeguards
The Administrative Safeguards comprise over half of the HIPAA Security Rule. It establishes a national set of minimum security standards for protecting all ePHI that regulated entities create, receive, maintain, and/or transmit.
The HIPAA Security Rule defines Administrative Safeguards as:
“Administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of the regulated entities workforce in relation to the protection of that information.”
The Security Rule contains several types of safeguards and requirements which regulated entities must put in place to secure ePHI. When reviewing the Administrative Safeguards, they are generally identified as: administrative actions, policies, and procedures to prevent, detect, contain, and correct security violations.
Administrative Safeguards also involve the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of workforce members in relation to the protection of that information.
In general, these are the administrative functions that should be implemented to meet the security standards. These include security management processes, assignment or delegation of security responsibilities to an individual, and workforce security training requirements.
Physical Safeguards
As with all the standards in the HIPAA Security Rule, compliance with the Physical Safeguards standards requires regulated entities to perform an evaluation of their security controls already in place, an accurate and thorough risk analysis, and a series of documented solutions derived from a number of factors unique to each organization.
The HIPAA Security Rule defines Physical Safeguards as:
“Physical measures, policies, and procedures to protect a regulated entities electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.”
When evaluating and implementing these standards, regulated entities must consider all physical access to ePHI. This may extend outside of the actual office(s), and could include workforce members’ homes or other physical locations where they are able to access ePHI (i.e., mobile devices).
In general, these are the mechanisms required to protect electronic systems, equipment and the data they hold, from threats, environmental hazards and unauthorized intrusion. They also include restricting access to ePHI and the retaining of off-site computer backups.
Technical Safeguards
Technical Safeguards are increasingly more important due to advancements in technology used in healthcare. As technology improves, new security challenges emerge. Healthcare organizations are faced with the challenge of protecting ePHI from various internal and external risks and threats. To reduce these risks, regulated entities must implement Technical Safeguards.
The Security Rule defines Technical Safeguards as:
“The technology and the policy and procedures for its use that protect ePHI and control access to it.”
Organizational Requirements
As with all the standards in the HIPAA Security Rule, compliance with the Organizational Requirements standards requires regulated entities, and under certain circumstances third-party vendors, to have signed Business Associate Agreement (BAA) contract(s) or other arrangements before granting access to ePHI. The standards provide the specific criteria required for written contracts or other arrangements.
Policies and Procedures
The Policies and Procedures Standard requires regulated entities to implement and maintain reasonable and appropriate written policies and procedures and documentation necessary to comply with the provisions of the Security Rule. Specifically, it requires regulated entities to:
“Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in § 164.306(b)(2)(i), (ii), (iii), and (iv) [the Security Standards: General Rules, Flexibility of Approach].
This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. CEs and BAs may change their policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart.”
The Policies and Procedures standard is further explained and supported by the Documentation standard.
Documentation
The Documentation requires regulated entities to:
“(i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.”
Regulated entities must maintain, for a period of six years after the date of their creation or last effective date (whichever is later), written security policies and procedures and written records of required actions, activities, or assessments. Regulated entities must periodically review and update its documentation in response to environmental or organizational changes that affect the security of ePHI.
Note: Security is not a one-time project, but rather an on-going, dynamic process that will create new challenges as organizations and as technologies change.
Healthcare organizations and their third-party vendors should understand that patients are entrusting them with their most private and intimate details, they do expect it to remain secure.