|
Security
Standard/Rule (HIPAA)
Health
Insurance Portability and Accountability Act (HIPAA) regulations
are divided into four Standards or Rules: (1) Privacy,
(2) Security, (3) Identifiers,
and (4) Transactions
and Code Sets. We discuss the Security Rule here.
The Security Rule
will take effect in April 2005 for large covered
entities, and one year later for small ones. (See the
HIPAA compliance calendar
for details.) Its
requirements are divided into administrative,
physical and
technical
safeguards. These safeguard categories are further divided
into standards
and implementation specifications that provide instructions
for putting in place the components of the three categories.
(For more detail on each of the three safeguard categories,
follow the links above.)
Unlike the HIPAA
Privacy Rule, which applies
to protected health
information (PHI) in "any form or medium," the
Security Rule covers only PHI that is electronically
stored or transmitted by covered entities. (Hence the
common abbreviation ePHI or EHI.) This "electronic focus"
is true of the Identifier and Transactions / Code Set rules
as well. DHHS has indicated that it may establish standards
to protect health information in other, non-electronic media
in a future rule.
Though narrower
in that regard, the Security Rule has a broader aim than the
confidentiality focus of the Privacy Rule. Although protection
against unauthorized use or disclosure is also a core goal
here, this standard aims at assuring the integrity
and availability of electronic PHI too. As such, the Security
Rule addresses issues such as data backup, disaster recovery
and emergency operations.
The general requirement
of the Security Rule can be simply stated: covered entities
that "collect, maintain, use or transmit" PHI in
electronic form must construct "reasonable and appropriate
administrative, physical and technical safeguards" that
ensure integrity, availability and confidentiality. Such measures
-- notably in the form of policies
and procedures -- must provide protection against "any
reasonably anticipated threats or hazards."
That construction
of administrative, physical and technical safeguards can be
described as including three major steps for the covered entity:
- "assess
potential risks and vulnerabilities" to electronic
PHI that it maintains or transmits;
- "develop,
implement and maintain appropriate security measures"
given those anticipated risks; and
- document
those measures and keep them current.
Safeguards must
also "ensure compliance" with the requirements by
the covered entity's officers and employees -- hence this
Rule, like the Privacy Rule, has a training
component.
DHHS believes that
the security standards it has mandated fulfill three (yes,
another threesome) concepts derived from the administrative
simplification provisions of HIPAA. Specifically, the
Rule's requirements are:
- "comprehensive
and coordinated," so as to address all aspects of security;
- "scalable,"
and so suitable for covered entities of any size or type;
and
- "technology
neutral," to allow for changes as security technologies
evolve (viz., as the cost-effectiveness of particular devices
and methods shift).
The last of these
is worth particular emphasis, especially in combination with
the second. What is reasonable and appropriate to meet a given
set of anticipated risks will change over time, given changes
in technologies. Risk pattern shifts can be expected to shift
what is "suitable" as well. And, at any given time,
what is reasonable and appropriate will also depend on the
size and type of covered entity.
"[E]ntities
affected by this regulation are so varied in terms of installed
technology, size, resources, and relative risk, that it would
be impossible to dictate a specific solution or set of solutions
that would be usable by all...." (Final Security Rule,
p.11)
The downside of
such flexibility is, of course, that each covered entity must
continually evaluate its current suite of security
provisions against evolving technology capabilities and costs,
as well as relative to the "community standard"
set by security provisions at similarly situated health care
institutions. And it must do so systematically, since
a security regime only works as well as its weakest parts.
In other words,
"reasonableness" and "appropriateness"
do not yield once-and-for-all recipes for security that can
be applied in cookie-cutter fashion. How individual security
requirements are to be satisfied and which technologies to
use are "business decisions that each entity [has] to
make ... reviewing and modifying the measures as needed to
continue the provision of reasonable and appropriate protections."
(Final Security Rule, pp.46, 49)
While many organizations
have proposed elements of a security model, DHHS has stated
that it believes the HIPAA Security Rule establishes the only
"comprehensive, scalable, and technology-neutral standard"
to safeguard electronically maintained or transmitted information.
(Final Security Rule, p.45) It has promised to issue guidance
documents in future, to clarify further the various elements
of the Rule.
Note that
this Rule establishes only a national "minimum standard"
for security of electronic health information.. Covered entities
may for various reasons need or want to exceed that. (For
example, state law,
which is not preempted unless it is in conflict, may establish
a higher benchmark.)
Note also that
the earlier (proposed) versions of the Security Rule included
a standard for electronic
signatures -- a topic that will now be addressed separately
at a later date.
See also:
|
