4MED1072 Lesson

Understanding the HIPAA Security Rule

The HIPAA Security Rule is designed to create safeguards to protect primarily electronic
Protected Health Information (ePHI). Just as the Minimum Necessary principle is central
to the Privacy Rule, safeguarding the Confidentiality, Integrity, and Availability (CIA) of
ePHI is central to the Security Rule. The Security Rule was originally implemented in 2005
and was updated in 2013 by the HIPAA Omnibus Final Rule.
The Security Rule is a risk-based security framework, that enables organizations to identify
risks, manage them, and maintain security over time. The Rule is broken down into Technical,
Physical, and Administrative Safeguards. The Safeguards are further divided into Standards
and Implementation specifications.
About half of Security Rule regulations are Administrative Safeguards, which are designed to
create a culture of compliance and security through properly implemented policies,
procedures, and documentation. Physical Safeguards address the physical security of devices
that access or store ePHI. The Technical Safeguards include rules on passwords, encryption,
and other electronic security tools.

Flexible Requirements

HIPAA Security Rule implementation specifications range from relatively simple requirements,
such as the Assigned Security Responsibilityofficially appointing an employee as the HIPAA
Security Officerto the requirement for an Emergency Mode Operations Plan, which may
require extensive planning if the organization is large. Like many other elements of HIPAA, the
specifications are general, to accommodate the diverse requirements of the many different
types of organizations that must comply.

Business Associates
Although the HITECH Act requires Business Associates to comply to the same extent as
Covered Entities, Business Associate should craft their policies and procedures with careful
thought about the circumstances in which they encounter protected information.
For instance, many IT service providers will not encounter PHI on their own systems. Such a
companys policies and procedures should be appropriate for the technical services it offers.
Hard drive replacements, computer repairs, and moving data using portable devices may all
create compliance risks if the devices are not properly tracked and controlled. A technician
losing a hard drive after a repair can easily breach thousands of patient records. By contrast, a
document shredding company will face a different set of concerns. Because Business
Associates represent a wide range of services, HIPAA compliance presents an unusual
challenge.

Required or Addressable
Some implementation specifications are Required, while others are Addressable. It is important
to understand that Addressable Specifications are not optional or voluntary. Rather, Covered
Entities and Business Associates must provide an account of the alternate procedure they are
using to satisfy the specification, and provide a documented explanation of why the specification
does not apply to the organization.
For example, consider the specification that calls for encryption of ePHI at rest. This
specification is addressable, but that does not mean it can be ignored. In 2014, Concentra
Health was fined more than $1.7 million because it failed to adequately execute risk

management measures to reduce its identified lack of encryption to a reasonable and

appropriate level. Thus, an organization must implement addressable requirements or
document how other controls accomplish the same result.

Security Rule Specifications

This section details safeguards, standards, and implementation specifications of the Security
Rule, along with the corresponding citation in the Code of Federal Regulations (CFR). It also
indicates whether the specification is Required (R) or Addressable (A). Safeguards are marked
in orange. The standards are underlined. Specifications appear in bold beneath the standards,
where applicable.
The descriptions below are general, partly because the specifications themselves are general.
See the Guidance Section at the end of this lesson for resources that provide more detailed
descriptions of the requirements.

Administrative Safeguards
Security Management Process 164.308(a)(1)

Risk Analysis (R)

The Risk Analysis is the first requirement of the Security Rule, and in many respects, it is also
the most important requirement. The Risk Analysis is essential to identifying compliance gaps
and vulnerabilities. A proper Risk Analysis examines the IT environment and assesses
compliance, including implementation of proper HIPAA policies and procedures. The Risk
Analysis should produce a remediation report, which provides detailed guidance on actions the
organization can take to close compliance gaps and vulnerabilities. In essence, the Risk
Analysis ensures that the other requirements of the Security Rule are satisfied.
Although it is not a requirement, the government advises that = doing a thorough and
professional risk analysis that will stand up to a compliance review will require expert knowledge
that could be obtained through services of an experienced outside professional. Covered
Entities and Business Associates should seriously consider employing independent Security

Specialists to conduct the Security Risk Analysis. One reason is that the Risk Analysis requires
a depth of understanding of HIPAA and other security requirements, plus a knowledge of IT
systems and security tools, that is not available to most providers. Another reason is that an
independent Security Specialist can view the organizations compliance and security
environment with fresh eyes, with an understanding of the protocols used by auditors. Also, an
independent Security Specialist will have no conflicts of interest, which might otherwise apply,
such as in cases where an internal IT specialist is tasked with evaluating IT security.
Risk Management (R)
The Risk Management specification requires that measures be taken to limit risk. Again, this
specification should be satisfied by conducting a proper Security Risk Analysis and by
implementing HIPAA policies and procedures.
Sanction Policy (R)
The Sanction Policy specification requires the organization to have policies and procedures in
place to discipline employees that violate the organizations security and privacy policies.
Information System Activity Review (R)
The Information System Activity Review specification requires regularly reviewing audit logs or
similar records of how PHI has been accessed. This requirement essentially demands an
administrative commitment to actually use the audit capability that is required by other parts of
the Security Rule.
Assigned Security Responsibility (R) 164.308(a)(2)
This standard requires that an organization designate a HIPAA Security Officer. In most
organizations, a single individual will serve as both the Security and Privacy Officer, charged
with ensuring compliance with both the Privacy and the Security rules. In some organizations,
these roles are divided.
Workforce Security 164.308(a)(3)

Authorization and/or Supervision (A)

This specification calls for determining whether a particular user or computer system has the
right to access PHI or conduct certain operations. This specification is important for ensuring
Minimum Necessary access by limiting access to network shares and assigning rights in
Electronic Health Record (EHR) systems.
Workforce Clearance Procedure (A)
This specification directs organizations to implement policies and procedures that ensure that
only authorized employees have access to ePHI at an appropriate level.
Termination Procedures (A)
This specification helps to ensure that an employees access can be terminated, such as if their
employment ends with the organization or if a vendors relationship is terminated. With cloud
services and remote access to networks and business partners, detailed termination checklists
are required to identify all areas that a user can access.
Information Access Management 164.308(a)(4)

Isolating Healthcare Clearinghouse Function (R)

This specification applies to healthcare clearinghouses that are part of larger organizations.
Such clearinghouses must implement policies and procedures that protect the ePHI of the
clearinghouse from unauthorized access by the larger organization.
Access Authorization (A)
This specification calls for the implementation of policies and procedures for actually granting
access to ePHI, after the person or systems authorization has been confirmed.
Access Establishment and Modification (A)

This specification essentially calls for the implementation of policies and procedures to modify
the level of access available to a person or system.
Security Awareness and Training 164.308(a)(5)

Security Reminders (A)

The Security Reminders specification calls for regular HIPAA training and awareness reminders
for all employees who have access to ePHI. An important part of training is ensuring that
employees understand and actually follow the organizations HIPAA policies and procedures.
Periodic reminders supplement the annual training provided to employees.
Protection from Malicious Software (A)
This specification calls for the implementation of policies and procedures designed to guard
against malware and viruses.
Log-in Monitoring (A)
This specification calls for procedures for monitoring log-in attempts and reporting
discrepancies.
Password Management (A)
The Password Management specification calls for the creation of procedures that govern
creating, changing, and safeguarding passwords.
Security Incident Procedures 164.308(a)(6)
Response and Reporting (R)

This specification requires organizations to implement policies and procedures to address

security incidents. Security incidents are defined as attempted or successful unauthorized
access, use, disclosure, modification, or destruction of information or system operations.
Contingency Plan 164.308(a)(7)

Data Backup Plan (R)

The Data Backup Plan specification requires organizations to establish and implement written
procedures to create and maintain retrievable, exact copies of ePHI.
Disaster Recovery Plan (R)
The Disaster Recovery Plan requires organizations to establish written procedures to restore
any loss of data.
Emergency Mode Operation Plan (R)
The Emergency Mode Operation Plan requires that written procedures be established to enable
continuation of critical business processes for protection of ePHI during emergencies.
Testing and Revision Procedure (A)
The Testing and Revision specification calls for organizations to ensure that their written
contingency plans be kept current.
Applications and Data Criticality Analysis (A)
The Application and Data Criticality Analysis specification directs the organization to determine
which applications and data are most critical for emergency mode operations.
Evaluation (R) 164.308(a)(8)

The Evaluation standard essentially requires an organization to assess whether it is following its
HIPAA policies and procedures, and to keeps its Risk Analysis current.
Business Associate Contracts (R) 164.308(b)(1)

This standard requires that organizations maintain Business Associate Contracts with any
organization that provides service involving access to ePHI. The language required for Business
Associate Contracts was updated in 2013 to comply with the HIPAA Omnibus Final Rule.

Physical Safeguards
Facility Access Controls 164.310(a)(1)

Contingency Operations (A)

This specification calls for planning to provide access to the facility in case of an emergency.
Facility Security Plan (A)
The specification for a written Facility Security Plan calls for basic physical security measures,
such as locks on areas that contain PHI.
Access Control and Validation Procedures (A)
This specification calls for organizations to control access to their facility, including implementing
visitor policies.
Maintenance Records (A)
This specification calls for organizations to document and log changing of locks and other
changes to facility security.
Workstation Use (R) 164.310(b)

The Workstation Use standard requires written policies and procedures that specify the proper
functions to be performed on workstations that have access to PHI, along with the physical
surroundings of those workstations. An important element of this requirement is identifying all
devices that can access PHI.
Workstation Security (R) 164.310(c)
This standard requires physical safeguards for all workstations that access ePHI, such as locks
or other measures to provide physical security.
Device and Media Controls 164.310(d)(1)
Media Disposal (R)
The Media Disposal specification requires policies on how hardware and media that contain
ePHI are discarded. For example, hard drives could be degaussed, (exposed to a powerful
magnetic field to wipe all the data) or physically destroyed (smashed or shredded) prior to
disposal.
Media Re-Use (R)
Media Re-use requires procedures for completely removing ePHI from media such as hard
drives. For example, formatting a hard drive is not enough, because formatting typically only
removes the directory, leaving the ePHI accessible. Specialized software is available to
completely wipe all remnants of data from a device prior to re-use.
Media Accountability (A)
This specification calls for documentation of where media are moved, which could be critically
important during an audit or breach investigation.
Data Backup and Storage (A)
This specification directs organizations to back up the data on equipment before it is moved.

Technical Safeguards
Access Control 164.312(a)(1)
Unique User Identification (R)
Unique User Identification is essential to the Security Rule. Organizations must be able to
identify each user who has access to ePHI. This requirement prohibits the use of generic logins
to networks or EHR systems. Every user must log in using their own credentials.
Emergency Access Procedure (R)
This specification requires organizations to develop the technical means to access data during
an emergency.
Automatic Logoff (A)
Automatic logoff calls for users to be logged out of the system after a period of inactivity, which
can be accomplished by setting screen savers to black out screens and require a password to
resume.
Encryption and Decryption of Data At Rest (A)
Encryption and decryption of data at rest is addressable specification, but as the example above
illustrates, addressable specifications are not option. Generally, ePHI at rest should be
encrypted whenever possible.
Audit Controls (R) 164.312(b)
The Audit Controls standard requires the ability to monitor activity in computer systems that
house ePHI.
Integrity 164.312(c)(1)

Protection Against Improper Alteration or Destruction of Data (A)

This specification calls for implementing policies and procedures to ensure the integrity of
ePHIthat is, to protect it from improper alteration or destruction.
Person or Entity Authentication (R) 164.312(d)
This standard requires an organization to implement controls to verify that a user seeking
access to ePHI is the one claimed. For example, a user must enter a PIN, password, or some
other control to confirm their identity.
Transmission Security 164.312(e)(1)

Integrity Controls (A)

Integrity controls call for methods for detecting whether ePHI has been improperly altered during
transmission.
Encryption for Transmission Security (A)
This specification calls for ePHI that is transmitted via email, internet connection, or other
means to be encrypted during transmission. Again, this specification is addressable rather than
required, but organizations should generally only transmit ePHI that has been encrypted.

Guidance
The National Institute of Standards and Technology (NIST) has published the document NIST
800-66, offering best practices for implementing controls to comply with the HIPAA Security
Rule.
http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf

Powered by 4Medapproved. Educational Content Copyright 2015