III. Analysis of, and Responses to, Public Comments on the Proposed Rules
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 should 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.
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.wedi.org/snip.
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.
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
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.
B. Applicability ([164.302])
We proposed that the security standards would apply to health plans,
health care clearinghouses, and to health care providers that maintain
or transmit health information electronically. The proposed security
standards would apply to all electronic health information maintained
or transmitted, regardless of format (standard transaction or a
proprietary format). No distinction would be made between internal
corporate entity communication or communication
external to the corporate entity. Electronic transmissions would
include transactions using all media, even when the information is
physically moved from one location to another using magnetic tape,
disk, or other machine readable media. Transmissions over the Internet
(wide-open), extranet (using Internet technology to link a business
with information only accessible to collaborating parties), leased
lines, dial-up lines, and private networks would be included. We
proposed that telephone voice response and “faxback” systems (a
request for information made via voice using a fax machine and
requested information returned via that same machine as a fax) would
not be included but we solicited comments on this proposed exclusion.
This final rule simplifies the applicability statement
greatly. Section 164.302 provides that the security standards apply to
covered entities; the scope of the information covered is specified in
[164.306] (see the discussion under that section below regarding the
changes and revisions to the scope of information
covered).
Response: Section 164.302 below makes the security standards
applicable to “covered entities.” The term “covered entity” is
defined at § 160.103 as one of the following: (1) A health plan; (2) a
health care clearinghouse; (3) a health care provider who transmits
any health information in electronic form in connection with a
transaction covered by part 162 of title 45 of the Code of Federal
Regulations (CFR). The rationale for the use and the meaning of the
term “covered entity” is discussed in the preamble to the Privacy
Rule (65 FR 82476 through 82477). As that discussion makes clear, the
standards only apply to health care providers who engage
electronically in the transactions for which standards have been
adopted.
Response: The statute does not cover all health care entities that
transmit or maintain individually identifiable health
information. Section 1172(a) of the Act provides that only health
plans, health care clearinghouses, and certain health care providers
(as discussed above) are covered. With respect to the comments
regarding the difference between providers and plans/ clearinghouses,
we have structured the Security Rule to be scalable and flexible
enough to allow different entities to implement the standards in a
manner that is appropriate for their circumstances. Regarding the
coverage of entities not within the jurisdiction of HIPAA, see the
Privacy Rule at 82567 through 82571.
Response: Only health plans, health care clearinghouses, and certain
health care providers are required to comply with the security
standards. Researchers who are members of a covered entity's work
force may be covered by the security standards as part of the covered
entity. See the definition of “workforce” at 45 CFR 160.103. Note,
however, that a covered entity could, under appropriate circumstances,
exclude a researcher or research division from its health care
component or components (see [164.105(a)]). Researchers who are not
part of the covered entity's workforce and are not themselves covered
entities are not subject to the standards.
Response:
Section 1173(d)(2) of the Act states: Each person described in section
1172(a) who maintains or transmits health information shall maintain
reasonable and appropriate administrative, technical, and physical
safeguards--(A) to ensure the integrity and confidentiality of the
information; (B) to protect against any reasonably anticipated--(i)
threats or hazards to the security or integrity of the information;
and (ii) unauthorized uses or disclosures of the information; and (C)
otherwise to ensure compliance with this part by the officers and
employees of such person. This language draws no distinction between
internal and external data movement. Therefore, this final rule covers
electronic protected health information at rest (that is, in storage)
as well as during transmission. Appropriate protections must be
applied, regardless of whether the data are at rest or being
transmitted. However, because each entity's security needs are
unique, the specific protections determined appropriate to adequately
protect information will vary and will be determined by each entity in
complying with the standards (see the discussion below).
Response: In the final Transactions Rule, we revised our
approach concerning the transaction and code set exemptions,
replacing this concept with other tests that determine whether a
particular transaction is subject to those standards (see the
discussion in the Transactions Rule at 65 FR 50316 through
50318). We also note that the Privacy Rule regulates a covered
entity's use, as well as disclosure, of protected health
information.
Response: If electronic protected health information is de-identified
(as truly anonymous information would be), it is not covered by this
rule because it is no longer electronic protected health information
(see 45 CFR 164.502(d) and 164.514(a)). Electronic protected health
information received, created, or maintained by a covered entity, or
that is transmitted by covered entities, is covered by the security
standards and must be protected. To the extent a researcher is a
covered entity, the researcher must comply with these standards with
respect to electronic protected health information. Otherwise, the
conditions for release of such information to researchers is governed
by the Privacy Rule. See, for example, 45 CFR 164.512(i), 164.514(e)
and 164.502(d). These standards would not apply to the researchers as
such in the latter circumstances.
Response: Patients are not covered entities and, thus, are not
subject to these standards. With respect to transmissions from
covered entities, covered entities must protect electronic
protected health information when they transmit that
information. See also the discussion of encryption in section
III.G.
C. Transition to the Final Rule
The proposed rule included definitions for a number of terms that
have now already been promulgated as part of the Transactions Rule or
the Privacy Rule. Comments related to the definitions of “code set,”
“health care” clearinghouse,” “health plan,” “health care
provider,” “small health plan,” “standard” and “transaction,”
are addressed in the Transactions Rule at 65 FR 50319 through
50320. Comments concerning the definition of “individually
identifiable health information” are discussed below, but are also
addressed in the Privacy Rule at 65 FR 82611 through 82613. In
addition, a few terms were redefined in the final Standards for
Privacy of Individually Identifiable Health Information (67 FR 53182),
issued on August 14, 2002 (Privacy Modifications). Certain terms that
were defined in the proposed rule are not used in the final rule
because they are no longer necessary. Other terms defined in the
proposed rule are defined within the explanation of the standards in
the final rule and are discussed in the preamble discussions in
[164.308] through [164.312].
Definitions of terms relevant to the security standards now appear in
the regulations text provisions as indicated below:
§ 160.103: Definitions of the following terms relevant to this rule
appear in
§ 160.103: “business associate,” “covered entity,” “disclosure,”
“electronic media,” “electronic protected health information,”
“health care,” “health care clearinghouse,” “health care
provider,” “health information,” “health plan,” “individual,”
“individually identifiable health information,” “implementation
specification,” “organized health care arrangement,” “protected
health information,” “standard,” “use,” and “workforce.” These
terms were discussed in connection with the Transaction and Privacy
Rules and with the exception of the terms “covered entity”
“disclosure” “electronic protected health information,” “health
information,” “individual,” “organized health care arrangement,”
“protected health information,” and “use,” we will not discuss
them in this document. We note that the definition of those terms are
not changed in the final rule.
§ 162.103: We have moved the definition of “electronic media” at
§ 162.103 to § 160.103 and have modified it to clarify that the term
includes storage of information. The term “electronic media” is used
in the definition of “protected health
information.” Both the privacy and security standards apply to
information “at rest” as well as to information being transmitted.
We note that we have deleted the reference to § 162.103 in paragraph
(1)(ii) of the definition of “protected health information,” since
both definitions, “electronic media” and “protected health
information,” have been moved to this section. Also, it is
unnecessary, because the definitions of
§ 160.103 apply to all of the rule in parts 160, 162, and 164.
We have also clarified that the physical movement of electronic media
from place to place is not limited to magnetic tape, disk, or compact
disk. This clarification removes a restriction as to what is
considered to be physical electronic media, thereby allowing for
future technological innovation. We further clarified that
transmission of information not in electronic form before the
transmission, for example, paper or voice, is not covered by this
definition. [164.103]: The following term “plan sponsor” now appears
in the new [164.103], which consists of definitions of terms common to
both subpart C and subpart E (the privacy standards). This definition
was moved, without substantive change, from
§164.501
and has the
meaning given to it in that section, and comments relating to this
definition are discussed in connection with that section in the
Privacy Rule at 65 FR 82607, 82611 through 82613, 82618 through 82622,
and 82629.
[164.304]: Definitions specifically applicable to the Security Rule
appear in [164.304], and these are discussed below. These definitions
are from, or derived from, currently accepted definitions in industry
publications, such as, the International Organization for Standards
(ISO) 7498-2 and the American Society for Testing and Materials (ASTM)
E1762-95.
The following terms in [164.304] are taken from the proposed rule text
or the glossary in Addendum 2 of the proposed rule (63 FR 43271), were
not commented on, and/or are unchanged or have only minor technical
changes for purposes of clarification and are not discussed below:
“access,” “authentication,” “availability,” “confidentiality,”
“encryption,” “password,” and “security.” [164.314]: Four terms
were defined in
§164.504(a) of the Privacy Rule (“common control,” “common
ownership,” “health care component,” and “hybrid
entity”). Because these terms apply to both security and privacy,
their definitions have been moved to [164.103] without change.
Those terms are discussed in the Privacy Rule at 65 FR 82502 through
82503 and at 67 FR 53203 through 53207.
1. Covered Entity (§ 160.103)
Response: A covered entity's responsibility to implement security
standards extends to the members of its workforce, whether they work
at home or on-site. Because a covered entity is responsible for
ensuring the security of the information in its care, the covered
entity must include “at home” functions in its security
process. While an independent transcription company or a TPA may not
be covered entities, they will be a business associate of the covered
entity because their activities fall under paragraph (1)(i)(a) of the
definition of that term. For business associate provisions see
proposed preamble section III.E.8. and [164.308(b)(1)] and [164.314(c)] of this final rule.
2. Health Care and Medical Care (§ 160.103)
Response: The term “medical care,” as used in the proposed rule (63
FR
43242), was intended to be synonymous with “health care.” The term
“medical care” is not included in this final rule. It is,
however, included in the definition of “health plan,” where its
meaning is not synonymous with “health care.” For a full discussion
of this issue and its resolution, see the Privacy Rule (65 FR 82578).
3. Health Information and Individually Identifiable Health Information 160.103)
We note that the definitions of “health information” and
“individually identifiable health information” remain unchanged from
those published in the Transactions and Privacy Rules.
Response: Our definition of health information
is taken from the definition in section 1171(4) of the Act, which
provides that health information relates to the health or condition of
an individual, the provision of health care to an individual, or
payment for the provision of health care to an individual. The
statutory definition also specifies the entities by which health
information is created or received. We note that, because
“individually identifiable health information” is a subset of
“health information” and by statute includes demographic
information, “health information” necessarily includes demographic
information. We think this is clear as a matter of statutory
construction and does not require further regulatory change.
Response: In general, we agree with these commenters, and note
that these comments are largely mooted by the decision,
reflected in [164.306] below and discussed in section
III.D.1. of this final rule, to cover only electronic protected
health information in this final rule.
Response: We note that the definition of “individually
identifiable health information” appears at § 160.103, which
applies to this final rule.
4. Protected Health Information (§ 160.103)
This term is moved from §164.501 to § 160.103 because it applies to
both subparts C (security) and E (privacy). See 67 FR 53192 through
531936 regarding the definition of “protected health information.”
Also, the term “electronic media” is included in paragraphs (1)(i)
and (ii) of the definition of “protected health information,” as
specified in this section.
In addition, we added the definitions of “covered functions,” “plan
sponsor,”
and “Required by law” to [164.103].
Response: The term “breach” has been deleted and therefore not
defined. Instead, we define the term “security incident,” which
better describes the types of situations we were referring to as
breaches.
This new term has been added as a result of changing the name of the
“physical access control” standard to “facility access control.”
This change was made based on comments indicating that the original
term was not descriptive. We have defined the term “facility” as the
physical premises and interior and exterior of a building.
7. Security Incident ([164.304])
Response: This final rule defines “Security incident” in [164.304]
as “the attempted or successful unauthorized access, use, disclosure,
modification, or destruction of information or interference with
system operations in an information system.”
Response: This final rule defines “system,” in the context of an
information system, in [164.304] as “an interconnected set of
information resources under the same direct management control that
shares common functionality. A system normally includes hardware,
software, information, data, applications, communications, and
people.”
Response: We have added a definition of the term “workstation” to
clarify that portable devices are also included. This final rule
defines workstation as “an electronic computing device, for example,
a laptop or desktop computer, or any other device that performs
similar functions, and electronic media stored in its immediate
environment.”
10. Definitions Not Adopted
Several definitions in the proposed regulations text and glossary are
not
adopted as definitions in the final rule: “participant,”
“contingency plan,” “risk,” “role-based access control,” and
“user-based access control.” The terms “participant,” “role-based
access control,” and “user-based access control” are not used in
this final rule and thus are not defined. “Risk” is not defined as
its meaning is generally understood. While we do not define the term,
we address “contingency plan” as a standard in [164.308(a)(7)]
below.
Response: These terms were defined in Addendum 2 of the proposed
rule. In this final rule, we do not adopt a definition for
“token” because it is not used in the final
rule. “Documentation” is discussed in [164.316] below.
Response: The statute requires that we address the needs of small and
rural providers. We believe that we have done this through the
provisions, which require the risk assessment and the response to be
assessment based on the needs and capabilities of the entity. This
scalability concept takes the needs of those providers into account
and eliminates any need to define those terms.
Response: We agree with the commenter who suggested that the
definition as proposed seemed too restrictive. In this case, as in
many others, a number of commenters believed the examples given in the
proposed rule provided the only acceptable compliance actions. As
previously noted, in order to clarify that the examples listed were
not to be considered all-inclusive, we have generalized the proposed
requirements in this final rule. In this case, we have also
generalized the requirements and placed the substantive provisions
governing access control at
[164.308(a)(4)], [164.310(a)(1)], and [164.312(a)(1)]. With respect to
PRBAC, the access control standard does not exclude this control, and
entities should adopt it if appropriate to their circumstances.
D. General Rules ([164.306])
In the proposed rule, we proposed to cover all health information
maintained
or transmitted in electronic form by a covered entity. We proposed to
adopt, in § 142.308, a nation-wide security standard that would
require covered entities to implement security measures that would be
technology-neutral and scalable, and yet integrate all the components
of security (administrative procedures, physical safeguards, technical
security services, and technical security mechanisms) that must be in
place to preserve health information confidentiality, integrity, and
availability (three basic elements of security). Since no
comprehensive, scalable, and technology-neutral set of standards
currently exists, we proposed to designate a new standard, which would
define the security requirements to be fulfilled.
The proposed rule proposed to define the security standard as a set of
scalable, technology-neutral requirements with implementation features
that providers, plans, and clearinghouses would have to include in
their operations to ensure that health information pertaining to an
individual that is electronically maintained or electronically
transmitted remains safeguarded. The proposed rule would have required
that each affected entity assess its own security needs and risks and
devise, implement, and maintain appropriate security to address its
own unique security needs. How individual security requirements would
be satisfied and which technology to use would be business decisions
that each entity would have to make. In the final rule we adopt this
basic framework. In [164.306], we set forth general rules pertaining
to the security standards. In paragraph (a), we describe the general
requirements. Paragraph (a) generally reflects section 1173(d)(2) of
the Act, but makes explicit the connection between the security
standards and the privacy standards (see
[164.306(a)(3)]). In [164.306(a)(1)], we provide that the security
standards apply to all electronic protected health information the
covered entity creates, receives, maintains, or transmits. In
paragraph (b)(1), we provide explicitly for the scalability of this
rule by discussing the flexibility of the standards, and paragraph
(b)(2) of [164.306] discusses various factors covered entities must
consider in complying with the standards.
The provisions of [164.306(c)] provide the framework for the security
standards, and establish the requirement that covered entities must
comply with the standards. The administrative,
physical, and technical safeguards a covered entity employs must be
reasonable and appropriate to accomplish the tasks outlined in
paragraphs (1) through (4) of [164.306(a)]. Thus, an entity's risk
analysis and risk management measures required by [164.308(a)(1)] must
be designed to lead to the implementation of security measures that
will comply with [164.306(a)]. It should be noted that the
implementation of reasonable and appropriate security measures also
supports compliance with the privacy standards, just as the lack of
adequate security can increase the risk of violation of the privacy
standards. If, for example, a particular safeguard is inadequate
because it routinely permits reasonably anticipated uses or
disclosures of electronic protected health information that are not
permitted by the Privacy Rule, and that could have been prevented by
implementation of one or more security measures appropriate to the
scale of the covered entity, the covered entity would not only be
violating the Privacy Rule, but would also not be in compliance with [164.306(a)(3)] of this rule. Paragraph (d) of [164.306] establishes two
types of implementation specifications, required and addressable. It
provides that required implementation specifications must be
met. However, with respect to implementation specifications that are
addressable, [164.306(d)(3)] specifies that covered entities must
assess whether an implementation specification is a reasonable and
appropriate safeguard in its environment, which may include
consideration of factors such as the size and capability of the
organization as well as the risk. If the organization determines it is
a reasonable and appropriate safeguard, it must implement the
specification. If an addressable implementation specification is
determined not to be a reasonable and appropriate answer to a covered
entity's security needs, the covered entity must do one of two things:
implement another equivalent measure if reasonable and appropriate; or
if the standard can otherwise be met, the covered entity may choose to
not implement the implementation specification or any equivalent
alternative measure at all. The covered entity must document the
rationale behind not implementing the implementation
specification. See the detailed discussion in section II.A.3.
Paragraph (e) of [164.306] addresses the requirement for covered
entities to maintain the security measures
implemented by reviewing and modifying
the measures as needed to continue the provision of reasonable and
appropriate protections, for example, as technology moves forward, and
as new threats or vulnerabilities are discovered.
1. Scope of Health Information Covered by the Rule ([164.306(a)])
We proposed to cover health information maintained or transmitted by a
covered entity in electronic form. We have modified, by narrowing, the
scope of health information to be safeguarded under this rule from
that which was proposed. The statute requires the privacy standards to
cover individually identifiable health information. The Privacy Rule
covers all individually identifiable information except for: (1)
Education records covered by the Family and Educational Rights and
Privacy Act (FERPA); (2) records described in 20
U.S.C. 1232g(a)(4)(B)(iv); and (3) employment records. (see the
Privacy Rule at 65 FR 82496. See also 67 FR 53191 through 53193). The
scope of information covered in the Privacy Rule is referred to as
“protected health information.” Based upon the comments we received,
we align the requirements of the Security and Privacy Rules with
regard to the scope of information covered, in order to eliminate
confusion and ease implementation. Thus, this final rule requires
protection of the same scope of information as that covered by the
Privacy Rule, except that it only covers that information if it is in
electronic form.
We note that standards for the security of all health information or
protected health information in nonelectronic form may be proposed at
a later date.
Response: As a general proposition,
any electronic protected health information received, created,
maintained, or transmitted by a covered entity is covered by this
final rule. We agree with the second commenter that certain
information, from which identifiers have been stripped, does not come
within the purview of this final rule. Information that is
de-identified, as defined in the Privacy Rule at
§164.502(d) and
§164.514(a), is not
“individually identifiable” within the meaning of these rules and,
thus, does not come within the definition of “protected health
information.” It accordingly is not covered by this final rule. For a
full discussion of the issues of de-identification and
re-identification of individually identifiable health information see
65 FR 82499 and 82708 through 82712 and 67 FR 53232 through
53234.
Response: We cannot accept the latter suggestion. Eligibility
information will typically be individually identifiable, and
much eligibility information will also contain health
information. If the information is “individually identifiable”
and is “health information,” (with three very specific
exceptions noted in the general discussion above) and it is in
electronic form, it is covered by the security standards if
maintained or transmitted by a covered entity.
Response: While we agree that protected health information in
paper or other form also should have appropriate security
protections, the proposed rule proposing the security standards
proposed to apply those standards to health information in
electronic form only. We are, accordingly, not extending the
scope in this final rule.
We may establish standards to secure protected health information in
other media in a future rule, in accordance with our statutory
authority to do so. See discussion, supra, responding to a comment on
the definition of “health information” and “individually
identifiable health information.”
Response: In light of these comments, we
have decided that telephone voice response and “faxback” (that is, a
request for information from a computer made via voice or telephone
keypad input with the requested information returned as a fax) systems
fall under this rule because they are used as input and output devices
for computers, not because they have computers in them. Excluding
these features would provide a huge loophole in any system concerned
with security of the information contained and/or processed
therein. It should be noted that employment of telephone voice
response and/or faxback systems will generally require security
protection by only one of the parties involved, and not the
other. Information being transmitted via a telephone (either by voice
or a DTMP tone pad) is not in electronic form (as defined in the first
paragraph of the definition of “electronic media”) before
transmission and therefore is not subject to the Security
Rule. Information being returned via a telephone voice response system
in response to a telephone request is data that is already in
electronic form and stored in a computer. This latter transmission
does require protection under the Security Rule.
Although most recently made electronic devices contain microprocessors
(a form of computer) controlled by firmware (an unchangeable form of
computer program), we intend the term “computer” to include only
software programmable computers, for example, personal computers,
minicomputers, and mainframes. Copy machines, fax machines, and
telephones, even those that contain memory and can produce multiple
copies for multiple people are not intended to be included in the term
“computer.” Therefore, because “paper-to-paper” faxes,
person-to-person telephone calls, video teleconferencing, or messages
left on voice-mail were not in electronic form before the
transmission, those activities are not covered by this rule. See also
the definition of “electronic media” at
§ 160.103.
We note that this guidance differs from the
guidance regarding the applicability of the Transactions Rule to
faxback and voice response systems. HHS has stated that faxback and
voice response systems are not required to follow the standards
mandated in the Transactions Rule. This new guidance refers only to
this rule.
Response: If the handling of electronic protected health information
involves shipping and receiving, appropriate measures must be taken to
protect the information. However, specific solutions are not provided
within this rule, as discussed in section III.A.3 of this final
rule. The device and media controls standard under [164.310(d)(1)]
addresses this situation.
Response: The Transactions Rule did not adopt the proposed
exemption for HTML. The use of HTML or any other electronic
protocol is not exempt from the security standards. Generally,
if protected health information is contained in any form of
electronic transmission, it must be appropriately safeguarded.
Response: Any health-related “family history” contained in a
patient's record that identifies a patient, including a person
other than the patient, is individually identifiable health
information and, to the extent it is also electronic protected
health information, must be afforded the security protections.
Response: The issue of re-identification is addressed in the Privacy
Rule at
§164.502(d) and §164.514(c). The reader is referred to those
sections and the related discussion in the preamble to the Privacy
Rule (65 FR 82712) and the preamble to the Privacy Modifications (67
FR 53232 through 53234) for a full discussion of the issues of
reidentification. We note that once information in the possession (or
constructive possession) of a covered entity is re-identified and
meets the definition of electronic protected health information, the
security standards apply.
2. Technology-Neutral Standards
Response: The overwhelming majority of comments supported
our position. We do not believe it is appropriate to make the
standards technology-specific because technology is simply moving too
fast, for example, the increased use and sophistication of
internet-enabled hand held devices. We believe that the implementation
of these rules will promote the security of electronic protected
health information by (1) providing integrity and confidentiality; (2)
allowing only authorized individuals access to that information; and
(3) ensuring its availability to those authorized to access the
information. The standards do not allow organizations to make their
own rules, only their own technology choices.
3. Miscellaneous Comments
Response: Again, the overwhelming majority of commenters supported our
approach. This final rule sets forth requirements with which covered
entities must comply and labels those requirements as standards and
implementation specifications. Adequate implementation of this final
rule by covered entities will ensure that the electronic protected
health information in a covered entity's care will be as protected as
is feasible for that entity.We disagree that covered entities are
given complete discretion to determine their security polices under
this rule, resulting in effect, in no standards. While cost is one
factor a covered identity may consider in determining whether to
implement a particular implementation specification, there is
nonetheless a clear requirement that adequate security measures be
implemented, see 45 CFR 164.306(b). Cost is not meant to free covered
entities from this responsibility.
Response: The
HIPAA statute requires us to promulgate a rule adopting security
standards for health information. Resource concerns due to Y2K should
no longer be an issue. Covered entities will have 2 years (or, in the
case of small health plans, 3 years) from the adoption of this final
rule in which to comply. Concerns relative to effective and compliance
dates and the Privacy Rule are discussed under
[164.318], Compliance dates for initial implementation, below and at
65 FR 82751 through 82752. We disagree that these standards will
adversely affect a provider's practice environment. The scalability of
the standards allows each covered entity to implement security
protections that are appropriate to its specific needs, risks, and
environments. These protections are necessary to maintain the
confidentiality, integrity, and availability of patient data. A
covered entity that lacks adequate protections risks inadvertent
disclosure of patient data, with resulting loss of public trust, and
potential legal action. For example, a covered entity with poor
facility access controls and procedures would be susceptible to
hacking of its databases. A provider with appropriate security
protections already in place would only need to ensure that the
protections are documented and are reassessed periodically to ensure
that they continue to be appropriate and are actually being
implemented. Our decision to classify many implementation
specifications as addressable, rather than mandatory, provides even
more flexibility to covered entities to develop costeffective
solutions. We believe that insurers who already have effective
security programs in place will have met many of the requirements of
this regulation.
Response:
The standards are based on generally accepted security procedures,
existing industry standards and guidelines, and recommendations
contained in the National Research Council's 1997 report For The
Record:
Protecting Electronic Health Information, Chapter 6. We also consulted
extensively with experts in the field of security throughout the
health care industry. The standards are consistent with generally
accepted security principles and practices that are already in
widespread use.
Data backup need not result in increased access to that data. Backups
should be stored in a secure location with controlled access. The
appropriate secure location and access control will vary, based upon
the security needs of the covered entity. For example, a procedure as
simple as locking backup diskettes in a safe place and restricting who
has access to the key may be suitable for one entity, whereas another
may need to store backed-up information off-site in a secure computer
facility. The information provided in security awareness training
heightens awareness of security anomalies and helps to prevent
security incidents.
Response: We believe that the
standards are consistent with common industry practices and equitable,
and that there has been adequate consultation with interested parties
in the development of the standards. These standards are the result of
an intensive process of public consultation. We consulted with the
National Uniform Billing Committee, the National Uniform Claim
Committee, the American Dental Association, and the Workgroup for
Electronic Data Interchange, in the course of developing the proposed
rule. Those organizations were specifically named in the Act to advise
the Secretary, and their membership is drawn from the full spectrum of
industry segments. In addition, the National Committee on Vital and
Health Statistics (NCVHS), an independent advisory group to the
Secretary, held numerous public hearings to obtain the views of
interested parties. Again, many segments of the health care industry,
including provider groups, health plans, clearinghouses, vendors, and
government programs participated actively. The NCVHS developed
recommendations to the Secretary, which were relied upon as we
developed the proposed rule. Finally, we note that the opportunity to
comment was available to all during the public comment period.
Response: The information included in a risk
analysis would not be subject to the security standards if it does
not include electronic protected health information. We agree that
risk analysis data could contain sensitive information, just as
other business information can be sensitive. Covered entities may
wish to develop their own business rules regarding access to and
protections for risk analysis data.
Response: The majority of comments received on this subject requested
that we prioritize the standards. In response, we have regrouped the
standards and implementation specifications in what we believe is a
logical order within each of three categories: “Administrative
safeguards,” “Physical safeguards,” and “Technical safeguards.”
In this final rule, we order the standards in such a way that the
“Security management process” is listed first under the
“Administrative safeguards” section, as we believe this forms the
foundation on which all of the other standards depend. The
determination of the specific security measures to be implemented to
comply with the standards will, in large part, be dependent upon
completion of the implementation specifications within the security
management process standard (see [164.308(a)(1)]). We emphasize,
however, that an entity implementing these standards may choose to
implement them in any order, as long as the standards are met.
Response: We agree. Section 164.308 of this final rule describes
administrative safeguards that address these topics. Section 164.308
requires covered entities to implement standards and required
implementation specifications, as well as consider and implement, when
appropriate and reasonable, addressable implementation
specifications. For example, the security management process standard
requires implementation of a risk analysis, risk management, a
sanction policy, and an information system activity review. The
information access management standard requires consideration, and
implementation where appropriate and reasonable, of access
authorization and access establishment and modification policies and
procedures. Other areas addressed are assigned security
responsibility, workforce security, security awareness and training,
security incident procedures, contingency planning, business associate
contracts, and evaluation.
Response: The presentation of the standards within this final rule
could have been structured in numerous ways, including by addressing
separate internal and external security standards. We chose the
current structure as we considered it a logical breakout for purposes
of display within this final rule. Under our structure a covered
entity may apply a given standard to internal activities and to
external activities. Had we displayed separately the standards for
internal security and the standards for external security, we would
have needed to describe a number of the standards twice, as many apply
to both internal and external security. However, a given entity may
address the standards in whatever order it chooses, as long as the
standards are met.
Response: Addendum 3 of the proposed rule cross-referred individual
requirements on the matrix to existing industry standards of varying
levels of maturity. Addendum 3 was intended to show what we evaluated
in searching for existing industry standards that could be adopted on
a national level. No one standard was found to be comprehensive enough
to be adopted, and none were proposed as the
standards to be met under the Security Rule.
Response: Preambles to proposed rules are not republished in the
final rule. The preamble in this final rule contains summaries
of the information presented in the preamble of the proposed
rule, summaries of the comments received during the public
comment period, and responses to questions and concerns raised
in those comments and a summary of changes made. Additional
clarification will be provided by HHS on an ongoing basis
through written documents and postings on HHS's websites.
Response: The security standards establish a minimum level of security
to be met by covered entities. It is not our intent to limit the level
of security that may be agreed to between trading partners or others
above this floor.
Response: We cannot predict if or how future legislation may
affect the rules below. At present, the privacy standards at
subpart E of 42 CFR part 164 have been adopted, and this final
rule is compatible with them.
Response: We did not adopt such a policy because this final rule
requires a floor of protection of all electronic protected health
information. A covered entity has the option to exceed this floor. The
sensitivity of information, the risks to and vulnerabilities of
electronic protected health information and the means that should be
employed to protect it are business determinations and decisions to be
made by each covered entity.
Response: In general, HHS is
required to adopt standards developed by ANSI-accredited SDOs when
such standards exist. The currently existing security standards
developed by ANSIrecognized SDOs are targeted to specific technologies
and/or activities. No existing security standard, or group of
standards, is technology-neutral, scaleable to the extent required by
HIPAA, and broad enough to be adopted in this final rule. Therefore,
this final rule adopts standards under section 1172(c)(2)(B) of the
Act, which permits us to develop standards when no industry standards
exist.
Response: We do not believe that this regulation goes beyond the scope
of the law. The law requires HHS to adopt standards for reasonable and
appropriate security safeguards concerning such matters as compliance
by the officers and employees of covered entities, protection against
reasonably anticipated unauthorized uses and disclosures of health
information, and so on. Such standards will inevitably address the
areas the commenter pointed to. The intent of this regulation is to
provide standards for the protection of electronic protected health
information in accordance with the Act. In order to do this, covered
entities are required to implement administrative, physical, and
technical safeguards. Those entities must ensure that data are
protected, to the extent feasible, from inappropriate access,
modification, dissemination, and destruction. As noted above, however,
this final rule has been modified to increase flexibility as to how
this protection is accomplished.
Response: As the discussion in section III.A above of this final rule
makes clear, the privacy and security standards are very closely
related. Section 1173(d)(2) of the Act specifically mentions
“confidentiality” and authorizes uses and disclosures of information
as part of what security safeguards must address. Thus, we cannot omit
all references to confidentiality and privacy in discussions of the
security standards. However, we have relocated material that
relates to both security and privacy (including definitions) to the
general section of part 164.
Response: The commenter's concern is noted. While the documentation
relating to Security Rule implementation must be retained for a period
of 6 years (see [164.316(b)(2)]), it is not within the scope of this
final rule to address data retention time frames for administrative or
clinical records.
Response: We expect that many of the standards of this final rule are
already being met in one form or another by covered entities. For
example, as part of normal business operations, health care providers
already take measures to protect the health information in their
keeping. Health care providers already keep records, train their
employees, and require employees to follow office policies and
procedures. Similarly, health plans are already frequently required by
State law to keep information confidential. While revisions to a
practice's or plan's current activities may be necessary, the
development of entirely new systems or procedures may not be
necessary.
Response: We agree
with the commenter that there is no such thing as a totally secure
system that carries no risks to security. Furthermore, we believe
the Congress' intent in the use of the word “ensure” in section
1173(d) of the Act was to set an exceptionally high goal for the
security of electronic protected health information. However, we
note that the Congress also recognized that some trade-offs would
be necessary, and that “ensuring” protection did not mean
providing protection, no matter how expensive. See section
1173(d)(1)(A)(ii) of the Act. Therefore, when we state that a
covered entity must ensure the safety of the information in its
keeping, we intend
that a covered entity take steps, to the best of its ability, to
protect that information. This will involve establishing a balance
between the information's identifiable risks and vulnerabilities, and
the cost of various protective measures, and will also be dependent
upon the size, complexity, and capabilities of the covered entity, as
provided in [164.306(b)].
E. Administrative Safeguards ([164.308])
We proposed that measures taken to comply with the rule be appropriate
to protect the health information in a covered entity's care. Most
importantly, we proposed to require that both the measures taken and
documentation of those measures be kept current, that is, reviewed and
updated periodically to continue appropriately to protect the health
information in the care of covered entities. We would have required
the documentation to be made available to those individuals
responsible for implementing the procedure.
We proposed a number of administrative requirements and
supporting implementation features, and required documentation for
those administrative requirements and implementation features.
In this final rule, we have placed these administrative standards in
[164.308]. We have reordered them, deleted much of the detail of the
proposed requirements, as discussed below, and omitted two of the
proposed sets of requirements (system configuration requirements and a
requirement for a formal mechanism for processing records) as
discussed in paragraph 10 of the discussion of [164.308] of section
III.E. of this preamble. Otherwise, the basic elements of the
administrative safeguards are adopted in this final rule as
proposed.
We proposed the establishment of a formal security management process
to involve the creation, administration, and oversight of policies to
address the full range of security issues and to ensure the
prevention, detection, containment, and correction of security
violations. This process would include implementation features
consisting of a risk analysis, risk management, and sanction and
security policies.
We also proposed, in a separate requirement under administrative
procedures, an internal audit, which would be an in-house review of
the records of system activity (for example,
logins, file accesses, and security incidents) maintained by an
entity.
In this final rule, risk analysis, risk management, and sanction
policy are adopted as required implementation specifications although
some of the details are changed, and the proposed internal audit
requirement has been renamed as “information system activity review”
and incorporated here as an additional implementation specification.
Response: This standard and its component implementation
specifications form the foundation upon which an entity's necessary
security activities are built. See NIST SP 800-30, “Risk Management
Guide for Information Technology Systems,” chapters 3 and 4, January
2002. An entity must identify the risks to and vulnerabilities of the
information in its care before it can take effective steps to
eliminate or minimize those risks and vulnerabilities. Some form of
sanction or punishment activity must be instituted for
noncompliance. Indeed, we question how the statutory requirement for
safeguards “to ensure compliance * * * by a [covered entity's]
officers and employees” could be met without a requirement for a
sanction policy. See section 1176(d)(2)(C) of the Act. Accordingly,
implementation of these specifications remains mandatory. However, it
is important to note that covered entities have the flexibility to
implement the standard in a manner consistent with numerous factors,
including such things as, but not limited to, their size, degree of
risk, and environment. We have deleted the implementation
specification calling for an organizational security policy, as it
duplicated requirements of the security management and training
standard. We note that the implementation specification for a risk
analysis at [164.308(a)(1)(ii)](A) does not specifically require that
a covered entity perform a risk analysis often enough to ensure that
its security measures are adequate to provide the level of security
required by [164.306(a)]. In the proposed rule, an assurance of
adequate security was framed as a requirement to keep security
measures “current.” We continue to believe that security measures
must remain current, and have added regulatory language in [164.306(e)] as a more precise way of communicating that security
measures in general that must be periodically
reassessed and updated as needed.
The risk analysis implementation specification contains other terms
that merit explanation. Under [164.308(a)(1)(ii)](A), the risk
analysis must look at risks to the covered entity's electronic
protected health information. A thorough and accurate risk analysis
would consider “all relevant losses” that would be expected if the
security measures were not in place. “Relevant losses” would include
losses caused by unauthorized uses and disclosures and loss of data
integrity that would be expected to occur absent the security
measures.
Response: The
sanction policy is a required implementation specification
because--(1) the statute requires covered entities to have safeguards
to ensure compliance by officers and employees; (2) a negative
consequence to noncompliance enhances the likelihood of compliance;
and (3) sanction policies are recognized as a usual and necessary
component of an adequate security program. The type and severity of
sanctions imposed, and for what causes, must be determined by each
covered entity based upon its security policy and the relative
severity of the violation.
Response: “Risk analysis” is defined and described in the
specification of the security management process standard, and is
discussed in the preamble discussion of [164.308(a)(1)(ii)](A) of this
final rule. The term breach is no longer used and is, therefore, not
defined.
Response: All electronic protected health information must be
protected at least to the degree provided by these standards. If
an entity desires to protect the information to a greater degree
than the risk analysis would indicate, it is free to do so.
Response: We have not done this because we view
threat assessment as an inherent part of a risk analysis; adding it
would be redundant.
Response: Our intent for this requirement was to promote the
periodic review of an entity's internal security controls, for
example, logs, access reports, and incident tracking. The
extent, frequency, and nature of the reviews would be determined
by the covered entity's security environment. The term
“internal audit” apparently, based on the comments received,
has certain rigid formal connotations we did not intend. We
agree that the implementation of formal internal audits could
prove burdensome or even unfeasible, to some covered entities
due to the cost and effort involved. However, we do not want to
overlook the value of internal reviews. Based on our review of
the comments and the text to which they refer, it is clear that
this requirement should be renamed for clarity and that it
should actually be an implementation specification of the
security management process rather than an independent
standard. We accordingly remove “internal audit” as a separate
requirement and add “information system activity review” under
the security management process standard as a mandatory
implementation specification.
2. Assigned Security Responsibility ([164.308(a)(2)])
We proposed that the responsibility for security be assigned to a
specific individual or organization to provide an organizational focus
and importance to security, and that the assignment be
documented. Responsibilities would include the management and
supervision of (1) the use of security measures to protect data, and
(2) the conduct of personnel in relation to the protection of data. In
this final rule, we clarify that the final responsibility for a
covered entity's security must be assigned to one official. The
requirement for documentation is retained, but is made part of [164.316] below. This policy is consistent with the analogous policy in
the Privacy Rule, at 45 CFR 164.530(a), and the same considerations
apply. See 65 FR 82744 through 87445. The same person could fill the
role for both security and privacy.
Response: The assigned security responsibility standard adopted in
this final rule specifies that final security responsibility must rest
with one individual to ensure accountability within each covered
entity. More than one individual may be given specific security
responsibilities, especially within a large organization, but a single
individual must be designated as having the overall final
responsibility for the security of the entity's electronic protected
health information. This decision also aligns this rule with the final
Privacy Rule provisions concerning the Privacy Official.
Response: Upon review of the matrix and regulations text, we agree
with the commenter, because this requirement involves an
administrative decision at the highest levels of who should be
responsible for ensuring security measures are implemented and
maintained. Assigned security responsibility has been removed from
“Physical safeguards” and is now located under “Administrative
safeguards” at [164.308].
We proposed implementation of a number of features for personnel
security, including ensuring that maintenance personnel are supervised
by a knowledgeable person, maintaining a record of access
authorizations, ensuring that operating and maintenance personnel have
proper access authorization, establishing personnel clearance
procedures, establishing and maintaining personnel security policies
and procedures, and ensuring that system users have proper training.
In this final rule, to provide clarification and reduce duplication,
we have combined the “Assure supervision of maintenance personnel by
authorized, knowledgeable person” implementation feature and the
“Operating, and in some cases, maintenance personnel have proper
access authorization” feature into one addressable implementation
specification titled “Authorization and/or supervision.”
In a related, but separate, requirement entitled “Termination
procedures,” we proposed implementation features for the ending of an
employee's employment or an internal or external user's access. These
features would include things such as changing combination locks,
removal from access lists, removal of user account(s), and the turning
in of keys, tokens, or cards that allow access. In this final rule,
“Termination procedures” has been made an addressable implementation
specification under “Workforce security.” This is addressable
because in certain circumstances, for example, a solo physician
practice whose staff consists only of the physician's spouse, formal
procedures may not be necessary. The proposed “Personnel security
policy/procedure” and “record of access authorizations”
implementation features have been removed from this final rule, as
they have been determined to be redundant. Implementation of the
balance of the “Workforce security” implementation specifications
and the
other standards contained within this final rule will result in
assurance that all personnel with access to electronic protected
health information have the required access authority as well as
appropriate clearances.
Response: We agree that a “knowledgeable” person may not be
available to supervise maintenance personnel. We have
accordingly modified this implementation specification so that,
in this final rule, we are adopting an addressable
implementation specification titled, “Authorization and/or
supervision,” requiring that workforce members, for example,
operations and maintenance personnel, must either be supervised
or have authorization when working with electronic protected
health information or in locations where it resides (see
[164.308(a)(3)(ii)](A)). Entities can decide on the feasibility of
meeting this specification based on their risk analysis.
Response: We agree with the commenters concerning background
checks. This feature was not intended to be interpreted as an
absolute requirement for background checks. We retain the use of
the term “clearance,” however, because we believe that it more
accurately conveys the screening process intended than does the
term “authorization.” We have attempted to clarify our intent
in the language of [164.308(a)(3)(ii)](B), which now reads,
“Implement procedures to determine that the access of a
workforce member to electronic protected health information is
appropriate.” The need for and extent of a screening process is
normally based on an assessment of risk, cost, benefit, and
feasibility as well as other protective measures in
place. Effective personnel screening processes may be applied in
a way to allow a range of implementation, from minimal
procedures to more stringent procedures
based on the risk analysis performed by the covered entity. So long as
the standard is met and the underlying standard of [164.306(a)] is
met, covered entities have choices in how they meet these
standards. To clarify the intent of this provision, we retitle the
implementation specification “Workforce clearance procedure.”
Response: We have not adopted this comment in the interest of
maintaining flexibility as discussed in [164.306]. Restrictions
would be dependent upon job responsibilities, the amount and
type of supervision required and other factors. We note that a
covered entity should consider in this regard the applicable
requirements of the Privacy Rule (see, for example, §164.514(d)(2)
(relating to minimum necessary requirements), and
§164.530(c) (relating to safeguards).
Response:
While we do not believe this requirement should be eliminated, we
agree that all the implementation specifications may not be applicable
or even appropriate to a given entity. For example, a personal
clearance may not be reasonable or appropriate for a small provider
whose only assistant is his or her spouse. The implementation
specifications are not mandatory, but must be addressed. This final
rule has been changed to reflect this approach (see [164.308(a)(3)(ii)](B)).
Response: Based upon the comments received, we agree that termination
procedures should not be a separate standard; however, consideration
of termination procedures remains relevant for any covered entity with
employees, because of the risks associated with the potential for
unauthorized acts by former employees, such as acts of retribution or
use of proprietary information for personal gain. We further agree
with the reasoning of the commenters who asked that these procedures
be made optional; therefore, “Termination procedures” is now
reflected in this final rule as an addressable implementation
specification. We also removed reference to all specific termination
activities, for example, changing locks, because, although the
activities may be considered appropriate for some covered entities,
they may not be reasonable for others.
Response: Policies and procedures implemented to adhere to thi
