|
|
Security Standards
III. Analysis of, and Responses to,
Public Comments on the Proposed Rule
We received approximately 2,350 timely public comments on the August
12, 1998 proposed rule. The comments came from professional associations
and societies, health care workers, law firms, health insurers,
hospitals, and private individuals. We reviewed each commenter's
letter and grouped related comments. Some comments were identical.
After associating like comments, we placed them in categories based
on subject matter or based on the section(s) of the regulations
affected and then reviewed the comments.
In this section of the preamble, we summarize the provisions of
the proposed regulations, summarize the related provisions in this
final rule, and respond to comments received concerning each area.
It should be noted that the proposed Security Rule contained multiple
proposed "requirements" and implementation features."
In this final rule, we replace the term "requirement"
with "standard." We also replace the phrase "implementation
feature" with "implementation specification." We
do this to maintain consistency with the use of those terms as they
appear in the statute, the Transactions Rule, and the Privacy Rule.
Within the comment and response portion of this final rule, for
purposes of continuity, however, we use "requirement"
and "implementation feature" when we are referring specifically
to matters from the proposed rule. In all other instances, we use
"standard" and "implementation specification."
The proposed rule would require that each covered entity (as now
described in § 160.102) engaged in the electronic maintenance
or transmission of health information pertaining to individuals
assess potential risks and vulnerabilities to such information in
its possession in electronic form, and develop, implement, and maintain
appropriate security measures to protect that information. Importantly,
these measures would be required to be documented and kept current.
The proposed security standard was based on three basic concepts
that were derived from the Administrative Simplification provisions
of HIPAA. First, the standard hould be comprehensive and coordinated
to address all aspects of security. Second, it should be scalable,
so that it can be effectively implemented by covered entities of
all types and sizes. Third, it should not be linked to specific
technologies, allowing covered entities to make use of future technology
advancements.
The proposed standard consisted of four categories of requirements
that a covered entity would have to address in order to safeguard
the integrity, confidentiality, and availability of its electronic
health information pertaining to individuals: administrative procedures,
physical safeguards, technical security services, and technical
mechanisms. The implementation features described the requirements
in greater detail when that detail was needed. Within the four categories,
the requirements and implementation features were presented in alphabetical
order to convey that no one item was considered to be more important
than another.
The four proposed categories of requirements and implementation
features were depicted in tabular form along with the electronic
signature standard in a combined matrix located at Addendum 1. We
also provided a glossary of terms, at Addendum 2, to facilitate
a common understanding of the matrix entries, and at Addendum 3,
we mapped available existing industry standards and guidelines to
the proposed security requirements.
A. General Issues
The comment process overwhelmingly validated our basic assumptions
that the entities 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 useable by all covered entities. Many commenters
also supported the concept of technological neutrality, which would
afford them the flexibility to select appropriate technology solutions
and to adopt new technology over time.
1. Security Rule and Privacy Rule Distinctions
As many commenters recognized, security and privacy are inextricably
linked. The protection of the privacy of information depends in
large part on the existence of security measures to protect that
information. It is important that we note several distinct differences
between the Privacy Rule and the Security Rule.
The security standards below define administrative, physical, and
technical safeguards to protect the confidentiality, integrity,
and availability of electronic protected health information. The
standards require covered entities to implement basic safeguards
to protect electronic protected health information from unauthorized
access, alteration, deletion, and transmission. The Privacy Rule,
by contrast, sets standards for how protected health information
should be controlled by setting forth what uses and disclosures
are authorized or required and what rights patients have with respect
to their health information.
As is discussed more fully below, this rule narrows the scope of
the information to which the safeguards must be applied from that
proposed in the proposed rule, electronic health information pertaining
to individuals, to protected health information in electronic form.
Thus, the scope of information covered in this rule is consistent
with the Privacy Rule, which addresses privacy protections for "protected
health information." However, the scope of the Security Rule
is more limited than that of the Privacy Rule. The Privacy Rule
applies to protected health information in any form, whereas this
rule applies only to protected health information in electronic
form. It is true that, under section 1173(d) of the Act, the Secretary
has authority to cover "health information," which, by
statute, includes information in other than electronic form. However,
because the proposed rule proposed to cover only health information
in electronic form, we do not include security standards for health
information in non-electronic form in this final rule.
We received a number of comments that pertained to privacy issues.
These issues were considered in the development of the Privacy Rule
and many of these comments were addressed in the preamble of the
Privacy Rule. Therefore, we are referring the reader to that document
for a discussion of those issues.
2. Level of Detail
We solicited comments as to the level of detail expressed in the
required implementation features; that is, we specifically wanted
to know whether commenters believe the level of detail of any proposed
requirement went beyond what is necessary or appropriate. We received
numerous comments expressing the view that the security standards
should not be overly prescriptive because the speed with which technology
is evolving could make specific requirements obsolete and might
in fact deter technological progress. We have accordingly written
the final rule to frame the standards in terms that are as generic
as possible and which, generally speaking, may be met through various
approaches or technologies.
3. Implementation Specifications
In addition to adopting standards, this rule adopts implementation
specifications that provide instructions for implementing those
standards. However, in some cases, the standard itself includes
all the necessary instructions for implementation. In these instances,
there may be no corresponding implementation specification for the
standard specifically set forth in the regulations text. In those
instances, the standards themselves also serve as the implementation
specification. In other words, in those instances, we are adopting
one set of instructions as both the standard and the implementation
specification. The implementation specification would, accordingly,
in those instances be required.
In this final rule, we adopt both "required" and "addressable"
implementation specifications. We introduce the concept of "addressable
implementation specifications" to provide covered entities
additional flexibility with respect to compliance with the security
standards.
In meeting standards that contain addressable implementation specifications,
a covered entity will ultimately do one of the following: (a) implement
one or more of the addressable implementation specifications; (b)
implement one or more alternative security measures; (c) implement
a combination of both; or (d) not implement either an addressable
implementation specification or an alternative security measure.
In all cases, the covered entity must meet the standards, as explained
below.
The 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 will
depend on a variety of factors, such as, among others, the entity's
risk analysis, risk mitigation strategy, what security measures
are already in place, and the cost of implementation. Based upon
this decision the following applies:
(a) If a given addressable implementation specification is determined
to be reasonable and appropriate, the covered entity must implement
it.
(b) If a given addressable implementation specification is determined
to be an inappropriate and/or unreasonable security measure for
the covered entity, but the standard cannot be met without implementation
of an additional security safeguard, the covered entity may implement
an alternate measure that accomplishes the same end as the addressable
implementation specification. An entity that meets a given standard
through alternative measures must document the decision not to
implement the addressable implementation specification, the rationale
behind that decision, and the alternative safeguard implemented
to meet the standard. For example, the addressable implementation
specification for the integrity standard calls for electronic
mechanisms to corroborate that data have not been altered or destroyed
in an unauthorized manner (see 45 CFR 164.312 (c)(2)). In a small
provider's office environment, it might well be unreasonable and
inappropriate to make electronic copies of the data in question.
Rather, it might well be more practical and afford a sufficient
safeguard to make paper copies of the data.
(c) A covered entity may also decide that a given implementation
specification is simply not applicable (that 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. In this scenario,
the covered entity must document the decision not to implement
the addressable specification, the rationale behind that decision,
and how the standard is being met. For example, under the information
access management standard, an access establishment and modification
implementation specification reads: "implement policies and
procedures that, based upon the entity's access authorization
policies, establish, document, review, and modify a user's right
of access to a workstation, transaction, program, or process"
(45 CFR 164.308(a)(4)(ii)(c)). It is possible that a small practice,
with one or more individuals equally responsible for establishing
and maintaining all automated patient records, will not need to
establish policies and procedures for granting access to that
electronic protected health information because the access rights
are equal for all of the individuals.
a. Comment: A large number of commenters indicated that
mandating 69 implementation features would result in a regulation
that is too burdensome, intrusive, and difficult to implement. These
commenters requested that the implementation features be made optional
to meet the requirements. A number of other commenters requested
that all implementation features be removed from the regulation.
Response: Deleting the implementation specifications would
result in the standards being too general to understand, apply effectively,
and enforce consistently. Moreover, a number of implementation specifications
are so basic that no covered entity could effectively protect electronic
protected health information without implementing them. We selected
13 of these mandatory implementation specifications based on (1)
the expertise of Federal security experts and generally accepted
industry practices and, (2) the recommendation for immediate implementation
of certain technical and organizational practices and procedures
described in Chapter 6 of For The Record: Protecting Electronic
Health Information, a 1997 report by the National Research Council
(NRC). These mandatory implementation specifications are referred
to as required implementation specifications and are reflected in
the NRC report's recommendations. Risk Analysis and Risk management
are found in the NRC recommendation title System Assessment; Sanction
Policy is required in the Sanctions recommendation; Information
system Activity Review is discussed in Audit Trails; Response and
Reporting circumstances. In addition, a number of voluntary national
and regional organizations have been formed to address HIPAA implementation
issues and to facilitate communication among trading partners. These
include the Strategic National Implementation Process (SNIP) developed
under the auspices of the Workgroup for Electronic Data Interchange
(WEDI), an organization named in the HIPAA statute to consult with
the Secretary of HHS on HIPAA issues. Some of these organizations
have developed white papers, tools, and recommended best practices
addressing a number of HIPAA issues, including security. Covered
entities may wish to examine these products to determine if they
are relevant and useful in their own implementation efforts. A partial
list of these organizations can be found at http://www.snip.wedi.org.
We believe that these and other future industry-developed guidelines
and/or models may provide valuable assistance to covered entities
implementing these standards but must caution that HHS does not
rate or endorse any such guidelines and/or models and the value
of its content must be determine by the user.
b. Comment: Many commenters asked us to develop guidelines
and models to aid in complying with the Security Rule. Several commenters
either offered to participate in the development of guidelines and
models or suggested entities that should be invited to participate.
Response: We agree that creation of compliance tools and
guidelines for different business environments could assist covered
entities to implement the HIPAA Security Rule. We plan to issue
guidance documents after the publication of this final rule. However,
it is critical for each covered entity to establish policies and
procedures that address its own unique risks and circumstances.
In addition, a number of voluntary national and regional organizations
have been formed to address HIPAA implementation issues and to facilitate
communication among trading partners. These include the Strategic
National Implementation Process (SNIP) developed under the auspices
of the Workgroup for Electronic Data Interchange (WEDI), an organization
named in the HIPAA statute to consult with the Secretary of HHS
on HIPAA issues. Some of these organizations have developed white
papers, tools, and recommended best practices addressing a number
of HIPAA issues, including security. Covered entities may wish to
examine these products to determine if they are relevant and useful
in their own implementation efforts. A partial list of these organizations
can be found at http://www.snip.wedi.org.
We believe that these and other future industry-developed guidelines
and/or models may provide valuable assistance to covered entities
implementing these standards but must caution that HHS does not
rate or endorse any such guidelines and/or models and the value
of its content must be determined by the user.
4. Examples
Comment: We received a number of comments that demonstrated
confusion regarding the purpose of the examples of security solutions
that were included throughout the proposed rule. Commenters stated
that they could not, or did not wish to, adopt various security
measures suggested in examples. Other commenters asked that we include
additional options within the examples. Some commenters referred
specifically to the example provided in the proposed rule demonstrating
how a small or rural provider might comply with the standards. One
commenter asked for clarification that the examples are not mandatory
measures that are required to demonstrate compliance, but are merely
meant as a guide when implementing the security standards. Another
commenter expressed support for the use of examples to clarify the
intent of text descriptions.
Response: We wish to clarify that examples are used only
as illustrations of possible approaches, and are included to serve
as a springboard for ideas. The steps that a covered entity will
actually need to take to comply with these regulations will be dependent
upon its own particular environment and circumstances and risk assessment.
The examples do not describe mandatory measures, nor do they represent
the only, or even the best, way of achieving compliance. The most
appropriate means of compliance for any covered entity can only
be determined by that entity assessing its own risks and deciding
upon the measures that would best mitigate those risks.
|
 |
 |
