Security Rule Savvy
The last of the three major HIPAA
regulations is nearing enactment.
Know how to ensure the integrity, confidentiality, and availability of
protected health information.
Know how to ensure the integrity, confidentiality, and availability of
protected health information.
Earlier this year, the U.S. Department of
Health and Human Services issued a final rule (68 FR 8334 et
seq.) entitled, “Health Insurance Reform: Security Standards” (a.k.a. the “Security
Rule”). The Security Rule
completes the triumvirate of the most significant and
anticipated portions of the so-called Administrative
Simplification rules following enactment of the Health
Insurance Portability and Accountability Act of 1996 (HIPAA). The Security Rule follows the
implementation of the Transaction and Code Set Rule and Privacy Rule standards
that have received considerable debate, scrutiny, and resources
from physician providers and other covered entities. Covered
entities—defined as health-care providers (e.g.,
physicians) who transmit any health information in electronic
form, health plans, or health-care clearinghouses—must be
in compliance with the Security Rule no later than April 20,
2005.
The Security Rule
establishes comprehensive administrative, physical, and
technical standards to protect the confidentiality, integrity,
and availability of electronic protected health information. By
contrast, the Privacy Rule applies to health information in any
context—electronic, paper, or oral. According to the
Security Rule, covered entities are required to implement basic
safeguards to protect electronic health information from
unauthorized access, alteration, deletion, or transmission.
To comply with the
Security Rule, a covered entity must do four things: 1)
Ensure the confidentiality, integrity, and availability of all
electronic protected health information the covered entity
creates, receives, maintains, or transmits; 2) Protect against
any reasonably anticipated threats or hazards to the security
or integrity of such information; 3) Protect against any
reasonably anticipated uses or disclosures of such information
that are not permitted or required by the Privacy Rule; and 4)
Ensure compliance with the Security Rule by its work force (45
CFR 164.306(a)).
Complying with the Security Rule
Unlike the Transaction and Code Set Rule
and the Privacy Rule, the Security Rule does not proscribe a
one-size-fits-all approach. In crafting the Security Rule, HHS
recognized that technology is evolving rapidly, so imposing
specific standards might actually impede technological progress
and innovation. The Security Rule frames its standards in a
broad fashion and allows covered entities flexibility in
achieving compliance.
The Security Rule
includes administrative, physical, and technical standards that
must be satisfied.
4 Administrative safeguards relate to the
selection, development, implementation, and maintenance of
security measures to protect electronic health information. In
addition, the safeguards refer to managing the conduct of the
covered entity’s work force regarding the protection of
that information.
4Physical
safeguards are the physical measures, policies, and procedures
to protect a covered entity’s electronic infor-mation
systems and related buildings and equipment from natural and
environmental hazards and unauthorized intrusion.
4Technical
safeguards are the technology, along with the policy and
procedures for its use, that protect electronic health
information and control access to it.
The Security Rule sets forth 18 security standards
that must be implemented through required implementation
specifications or addressable implementation specifications.
Because the Security Rule does not mandate compliance in one
particular manner, each of the safeguards includes standards
with “required” and “addressable”
implementation specifications. Essentially, each
“standard” describes what must be done to comply
with the Security Rule and the “implementation
specifications” explain the benchmark(s) to achieve the
standard. A covered entity must achieve the required
implementation specifications, but the addressable
specifications allow more flexibility. The organization may
review the addressable specifications to decide whether those
specifications apply to their particular needs and situation
and how to achieve compliance.
To meet a standard
that includes addressable implementation specifications, a
covered entity must decide whether a given addressable
implementation specification is a reasonable and appropriate
security measure to apply within its particular security
framework. This decision should be based on the covered
entity’s internal risk assessment and risk management
protocols. For instance, if an addressable implementation
specification is determined by the covered entity to be
reasonable and appropriate, the covered entity must implement
the specification.
If an addressable
implementation specification is determined to be an
inappropriate or unreasonable security measure for the covered
entity, but the standard cannot be met without an additional
security safeguard, the covered entity may implement an
alternative measure that accomplishes the same end as the
addressable specification. For example, one of the addressable
implementation specifications calls for electronic mechanisms
to corroborate that data has not been altered or destroyed in
an unauthorized manner. For some providers, it might be
unreasonable to make electronic copies of the data and it may
be more practical and be a sufficient safeguard to make paper
copies of the data.
Finally, a covered
entity may determine that a given implementation specification
is neither reasonable nor appropriate to its situation and that
the standard can be met without implementation of an
alternative measure in place of the addressable implementation
specification.
Because of the
flexibility provided by HHS for compliance with the addressable
implementation specifications, a covered entity must document
its decision-making processes. This is particularly important
if a covered entity decides that it does not need to make any
modifications to its operations to comply with an addressable
implementation specification.
For each of the standards,
there are required implementation specifications and there also
may be addressable implementation specifications. There are
nine administrative safeguards, four physical safeguards, and
five technical safeguards. (See “Security
Rule Specifications,”)
HHS noted in the
preamble to the Security Rule that there are over 600,000
providers that will need to determine compliance with the
Security Rule provisions. HHS realized that covered health-care
providers may incur costs to establish or update their security
systems and anticipated that the majority of these costs (e.g.,
the purchase and installation of computer hardware and
software, and various physical safeguards) would be incurred
during the initial implementation phase. Because of the
inherent flexibility in achieving compliance with the Security
Rule, the U.S. Department of Health and Human Services was not
able to project an actual dollar impact on covered entities.
Next steps: determining risks
The explicit flexibility in the Security
Rule requires a covered entity to assess the security risks
that it faces. The organization must conduct a risk analysis to
ascertain what losses it would face if security measures were
not in place. The entity must then implement countermeasures
proportional to those risks, and update those countermeasures
for new or increased risks.
Although it was not created
explicitly for the use of covered entities, there is a
publication which may help organizations assess whether they
are in compliance with the Security Rule. The National
Institute of Standards and Technology in the U.S. Department of
Commerce has published an Introductory Resource Guide for
Implementing the HIPAA Security Rule. This draft document
provides an overview of the various concepts included in the
Security Rule and of the “key activities”
associated with each Security Rule standard, as well as sample
questions to help determine whether or not the elements
described have actually been considered or completed. While the
document is intended as a resource for federal agencies, it
should provide a good starting point for organizations in the
private sector to achieve Security Rule compliance. The Draft
NIST document can be retrieved at www.csrc.nist.gov/publications/drafts/DRAFT-sp800-66.pdf
Complying with the
elements of the Security Rule is both harder and easier than
satisfying the elements of the Privacy Rule. It is easier
because the Security Rule recognizes there is no single
solution to achieving security and a covered entity can
therefore act creatively and take advantage of technological
advances. At the same time, the Security Rule poses a harder
challenge than the Privacy Rule because technology keeps
changing and the addressable implementation specifications give
a covered entity no security (pardon the intentional pun) that
it has selected the appropriate implementation methodology.
If you are a covered
entity, your mission, whether you choose to accept it or not,
is to ensure the confidentiality, integrity, and availability
of protected health information within your organization and
protect it from reasonably anticipated threats or hazards. You
should start the process of performing a security risk
assessment and taking the appropriate steps to ensure
compliance with the Security Rule immediately. Your deadline is
April 20, 2005. g
Bruce D. Armon, Esquire is a health-care
lawyer for Saul Ewing LLP and is a frequent speaker on HIPAA
implementation and compliance issues. He can be reached at barmon@saul.com.
