[Federal Register: February 20, 2003 (Volume 68, Number 34)]
[Rules and Regulations]
[Page 8333-8381]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr20fe03-4]
[[Page 8333]]
-----------------------------------------------------------------------
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
Office of the Secretary
-----------------------------------------------------------------------
45 CFR Parts 160, 162, and 164
Health Insurance Reform: Security Standards; Final Rule
[[Page 8334]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 160, 162, and 164
[CMS-0049-F]
RIN 0938-AI57
Health Insurance Reform: Security Standards
AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule adopts standards for the security of
electronic protected health information to be implemented by health
plans, health care clearinghouses, and certain health care providers.
The use of the security standards will improve the Medicare and
Medicaid programs, and otherFederal health programs and private health
programs, and the effectiveness and efficiency of the health care
industry in general by establishing a level of protection for certain
electronic health information. This final rule implements some of the
requirements of the Administrative Simplification subtitle of the
Health Insurance Portability andAccountability Act of 1996 (HIPAA).
DATES: Effective Date: These regulations are effective on April 21,
2003.
Compliance Date: Covered entities, with the exception of small
health plans, must comply with the requirements of this final rule by
April 21, 2005. Small health plans must comply with the requirements of
this final rule by April 21, 2006.
FOR FURTHER INFORMATION CONTACT: William Schooler, (410) 786-0089.
SUPPLEMENTARY INFORMATION:
Availability of Copies and Electronic Access
To order copies of the Federal Register containing this document,
send your request to: New Orders, Superintendent of Documents, P.O. Box
371954, Pittsburgh, PA 15250-7954. Specify the date of the issue
requested and enclose a check or money order payable to the
Superintendent of Documents, or enclose your Visa or Master Card number
and expiration date. Credit card orders can also be placed by calling
the order desk at (202) 512-1800 or by faxing to (202) 512-2250. The
cost for each copy is $10. As an alternative, you can view and
photocopy the Federal Register document at most libraries designated as
Federal Depository Libraries and at many other public and academic
libraries throughout the country that receive the Federal Register.
This Federal Register document is also available from the Federal
Register online database through GPO access, a service of the U.S.
Government Printing Office. The Web site address is http://www.access.gpo.gov/nara/index.html
.
I. Background
The Department of Health and Human Services (HHS) Medicare Program,
other Federal agencies operating health plans or providing health care,
State Medicaid agencies, private health plans, health care providers,
and health care clearinghouses must assure their customers (for
example, patients, insured individuals, providers, and health plans)
that the integrity, confidentiality, and availability of electronic
protected health information they collect, maintain, use, or transmit
is protected. The confidentiality of health information is threatened
not only by the risk of improper access to stored information, but also
by the risk of interception during electronic transmission of the
information. The purpose of this final rule is to adopt national
standards for safeguards to protect the confidentiality, integrity, and
availability of electronic protected health information. Currently, no
standard measures exist in the health care industry that address all
aspects of the security of electronic health information while it is
being stored or during the exchange of that information between
entities.
This final rule adopts standards as required under title II,
subtitle F, sections 261 through 264 of the Health Insurance
Portability and Accountability Act of 1996 (HIPAA), Pub. L. 104-191.
These standards require measures to be taken to secure this information
while in the custody of entities covered by HIPAA (covered entities) as
well as in transit between covered entities and from covered entities
to others.
The Congress included provisions to address the need for
safeguarding electronic health information and other administrative
simplification issues in HIPAA. In subtitle F of title II of that law,
the Congress added to title XI of the Social Security Act a new part C,
entitled ``Administrative Simplification'' (hereafter, we refer to the
Social Security Act as ``the Act''; we refer to the other laws cited in
this document by their names). The purpose of subtitle F is to improve
the Medicare program under title XVIII of the Act, the Medicaid program
under title XIX of the Act, and the efficiency and effectiveness of the
health care system, by encouraging the development of a health
information system through the establishment of standards and
requirements to enable the electronic exchange of certain health
information.
Part C of title XI consists of sections 1171 through 1179 of the
Act. These sections define various terms and impose requirements on
HHS, health plans, health care clearinghouses, and certain health care
providers. These statutory sections are discussed in the Transactions
Rule, at 65 FR 50312, on pages 50312 through 50313, and in the final
rules adopting Standards for Privacy of Individually Identifiable
Health Information, published on December 28, 2000 at 65 FR 82462
(Privacy Rules), on pages 82470 through 82471, and on August 14, 2002
at 67 FR 53182. The reader is referred to those discussions.
Section 1173(d) of the Act requires the Secretary of HHS to adopt
security standards that take into account the technical capabilities of
record systems used to maintain health information, the costs of
security measures, the need to train persons who have access to health
information, the value of audit trails in computerized record systems,
and the needs and capabilities of small health care providers and rural
health care providers. Section 1173(d) of the Act also requires that
the standards ensure that a health care clearinghouse, if part of a
larger organization, has policies and security procedures that isolate
the activities of the clearinghouse with respect to processing
information so as to prevent unauthorized access to health information
by the larger organization. Section 1173(d) of the Act provides that
covered entities that maintain or transmit health information are
required to maintain reasonable and appropriate administrative,
physical, and technical safeguards to ensure the integrity and
confidentiality of the information and to protect against any
reasonably anticipated threats or hazards to the security or integrity
of the information and unauthorized use or disclosure of the
information. These safeguards must also otherwise ensure compliance
with the statute by the officers and employees of the covered entities.
II. General Overview of the Provisions of the Proposed Rule
On August 12, 1998, we published a proposed rule (63 FR 43242) to
establish a minimum standard for security of electronic health
information. We proposed that the standard would require the
safeguarding of all electronic health information by covered entities.
The proposed rule also proposed a
[[Page 8335]]
standard for electronic signatures. This final rule adopts only
security standards. All comments concerning the proposed electronic
signature standard, responses to these comments, and a final rule for
electronic signatures will be published at a later date. A detailed
discussion of the provisions of the August 12, 1998 proposed rule can
be found at 63 FR 43245 through 43259.
We originally proposed to add part 142, entitled ``Administrative
Requirements,'' to title 45 of the Code of Federal Regulations (CFR).
It has now been determined that this material will reside in subchapter
C of title 45, consisting of parts 160, 162, and 164. Subpart A of part
160 contains the general provisions applicable to all the
Administrative Simplification rules; other subparts of part 160 will
contain other requirements applicable to all standards. Part 162
contains the standards for transactions and code sets and will contain
the identifier standards. Part 164 contains the standards relating to
privacy and security. Subpart A of part 164 contains general provisions
applicable to part 164; subpart E contains the privacy standards.
Subpart C of part 164, which is adopted in this final rule, adopts
standards for the security of electronic protected health information.
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 Sec. 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.
[[Page 8336]]
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
[[Page 8337]]
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/snip./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.
B. Applicability (Sec. 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 Sec.
164.306 (see the discussion under that section below regarding the
changes and revisions to the scope of information covered).
1. Comment: A number of commenters requested clarification of who
must comply with the standards. The preamble and proposed Sec. 142.102
and Sec. 142.302 stated: ``Each person described in section 1172(a) of
the Act who maintains or transmits health information shall maintain
reasonable and appropriate administrative, technical, and physical
safeguards.'' Commenters suggested that this statement is in conflict
with the law, which defines a covered entity as a health plan, a
clearinghouse, or a health care provider that conducts certain
transactions electronically. The commentors apparently did not realize
that section 1172(a) of the Act contains the definition of covered
entities.
Response: Section 164.302 below makes the security standards
applicable to ``covered entities.'' The term ``covered entity'' is
defined at Sec. 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.
[[Page 8338]]
2. Comment: Several commenters recommended expansion of
applicability, either to other specific entities, or to all entities
involved in health care. Others wanted to know whether the standards
apply to entities such as employers, public health organizations,
medical schools, universities, research organizations, plan brokers, or
non-EDI providers. One commenter asked whether the standards apply to
State data organizations operating in capacities other than as plans,
clearinghouses, or providers. Still other commenters stated that it was
inappropriate to include physicians and other health care professionals
in the same category as plans and clearinghouses, arguing that
providers should be subject to different, less burdensome requirements
because they already protect health information.
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.
3. Comment: One commenter asked whether the standards would apply
to research organizations, both to those affiliated with health care
providers and those that are not.
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 Sec. 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.
4. Comment: Several commenters stated that internal networks and
external networks should be treated differently. One commenter asked
for further clarification of the difference between what needs to be
secured external to a corporation versus the security of data movement
within an organization. Another stated that complying with the security
standards for internal communications may prove difficult and costly to
monitor and control. In contrast, one commenter stated that the
existence of requirements should not depend on whether use of
information is for internal or external purposes.
Another commenter argued that the regulation goes beyond the intent
of the law, and while communication of electronic information between
entities should be covered, the law was never intended to mandate
changes to an entity's internal automated systems. One commenter
requested that raw data that are only for the internal use of a
facility be excluded, provided that reasonable safeguards are in place
to keep the raw data under the control of the facility.
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).
5. Comment: Several commenters found the following statement in the
proposed rule (63 FR 43245) at section II.A. confusing and asked for
clarification: ``With the exception of the security standard,
transmission within a corporate entity would not be required to comply
with the standards.''
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.
6. Comment: One commenter stated that research would be hampered if
proposed Sec. 142.306(a) applied. The commenter believes that research
uses of health information should be excluded or the standard should be
revised to allow appropriate flexibility for research depending on the
risk to patients or subjects (for example, if the information is
anonymous, there is no risk, and it would not be necessary to meet the
security standards).
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.
7. Comment: One commenter asked to what extent individual patients
are subject to the standards. For example, some telemedicine practices
support the use of diagnostic systems in the patient's home, which can
be used to conduct tests and send results to a remote physician. In
other cases, patients may be responsible for the filing of insurance
claims directly and will need the ability to verify facts, confirm
receipt of claims, and so on. The commenter asked if it is the intent
of the rule to include electronic transmission to or from the patient.
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.
[[Page 8339]]
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 Sec. 164.308 through Sec. 164.312.
Definitions of terms relevant to the security standards now appear
in the regulations text provisions as indicated below:
Sec. 160.103: Definitions of the following terms relevant to this
rule appear in Sec. 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.
Sec. 162.103: We have moved the definition of ``electronic media''
at Sec. 162.103 to Sec. 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 Sec. 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 Sec. 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.
Sec. 164.103: The following term ``plan sponsor'' now appears in
the new Sec. 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 Sec. 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.
Sec. 164.304: Definitions specifically applicable to the Security
Rule appear in Sec. 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 Sec. 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.''
Sec. 164.314: Four terms were defined in Sec. 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 Sec.
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 (Sec. 160.103)
Comment: One commenter asked if transcription services were covered
entities. The question arose because transcription is often the first
electronic or printed source of clinical information. Concern was
expressed about the application of physical safeguard standards to the
transcribers working for transcription companies or health care
providers, either as employees or as independent contractors.
Another commenter expressed concern that scalability was limited to
only small providers. The commenter explained that Third Party
Administrators (TPAs) allow claim processors to work at home. Some TPAs
have noted that it would be impossible to comply with the security
standards for home-based claims processors.
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 Sec. 164.308(b)(1) and Sec. 164.314(c) of this final
rule.
2. Health Care and Medical Care (Sec. 160.103)
Comment: One commenter asked whether ``medical care,'' which is
defined in the proposed rule, and ``health care,'' which is not, are
synonymous.
Response: The term ``medical care,'' as used in the proposed rule
(63 FR 43242), was intended to be synonymous with ``health care.'' The
term ldquo;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).
[[Page 8340]]
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.
a. Comment: A number of commenters asked that the definition of
``health information'' be expanded to include information collected by
additional entities. Several commenters wanted the definition to
include health information collected, maintained, or transmitted by any
entity, and one commenter suggested the inclusion of aggregated
information not identifiable to an individual. Several commenters asked
that eligibility information be excluded from the definition of
information. Several commenters wanted the definition broadened to
include demographics.
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.
b. Comment: Several commenters asked that we clarify the difference
between ``health information'' and ``individually identifiable'' and
``health information pertaining to an individual'' as used in the
August 12, 1998 proposed rule (63 FR 43242). Additionally, commenters
asked that we be more consistent in the use of these terms and
recommended use of the term ``individually identifiable health
information.''
Two commenters stated that it is important to distinguish between
``health information pertaining to an individual'' and ``individually
identifiable health information,'' as in reporting statistics at
various levels there will always be a need to bring forth information
pertaining to an individual.
One commenter recommended that the standards apply only to
individually identifiable health information. Another stated that in
Sec. 142.306(b) of the proposed rule, ``health information pertaining
to an individual'' should be changed to ``individually identifiable
health information,'' as nonidentifiable information can be used for
utilization review and other purposes. As written, the regulation text
could limit the ability to use data, for example, from a clearinghouse
for compliance monitoring.
Response: In general, we agree with these commenters, and note that
these comments are largely mooted by the decision, reflected in Sec.
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.
c. Comment: Several commenters stated that the definition of
``individually identifiable health information'' is not in the
regulations and should be added.
Response: We note that the definition of ``individually
identifiable health information'' appears at Sec. 160.103, which
applies to this final rule.
4. Protected Health Information (Sec. 160.103)
This term is moved from Sec. 164.501 to Sec. 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 Sec. 164.103.
5. Breach (Sec. 164.304)
Comment: One commenter asked that ``breach'' be defined.
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.
6. Facility (Sec. 164.304)
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 (Sec. 164.304)
Comment: We received comments asking that this term be defined.
Response: This final rule defines ``Security incident'' in Sec.
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.''
8. System (Sec. 164.304)
Comment: One commenter asked that ``system'' be defined.
Response: This final rule defines ``system,'' in the context of an
information system, in Sec. 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.''
9. Workstation (Sec. 164.304)
Comment: One commenter expressed concern that the use of the term
``workstation'' implied limited applicability to fixed devices (such as
terminals), excluding laptops and other portable devices.
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 Sec. 164.308(a)(7)
below.
a. Comment: We received comments requesting that we define the
following terms: ``token'' and ``documentation.''
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 Sec. 164.316 below.
b. Comment: We received several comments that ``small'' and
``rural'' should be defined as those terms apply
[[Page 8341]]
to providers. We received an equal number of comments stating that
there is no need to define these terms. One commenter stated that
definitions for these terms would be necessary only if special
exemptions existed for small and rural providers. Several commenters
suggested initiation of a study to determine limitations and potential
barriers small and rural providers will have in implementing these
regulations.
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.
c. Comment: In the proposed rule, we proposed the following
definition for the term ``Access control'': ``A method of restricting
access to resources, allowing only privileged entities access. Types of
access control include, among others, mandatory access control,
discretionary access control, time-of-day, classification, and subject-
object separation.'' One commenter believed the proposed definition is
too restrictive and requested revision of the definition to read:
``Access control refers to a method of restricting access to resources,
allowing access to only those entities which have been specifically
granted the desired access rights.'' Another commenter wanted the
definition expanded to include partitioned rule-based access control
(PRBAC).
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 Sec. 164.308(a)(4), Sec. 164.310(a)(1), and Sec.
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 (Sec. 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 Sec. 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 Sec. 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 Sec. 164.306(a)(3)). In Sec. 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 Sec. 164.306 discusses various factors covered entities must
consider in complying with the standards.
The provisions of Sec. 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 Sec. 164.306(a). Thus, an entity's risk analysis and risk
management measures required by Sec. 164.308(a)(1) must be designed to
lead to the implementation of security measures that will comply with
Sec. 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 Sec. 164.306(a)(3) of this rule.
Paragraph (d) of Sec. 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, Sec.
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 Sec. 164.306 addresses the requirement for
covered entities to maintain the security measures
[[Page 8342]]
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 (Sec. 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.
a. Comment: One commenter stated that the rule should apply to
aggregate information that is not identifiable to an individual. In
contrast, another commenter asked that health information used for
statistical analysis be exempted if the covered entity may reasonably
expect that the removed information cannot be used to re-identify an
individual.
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
Sec. 164.502(d) and Sec. 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.
b. Comment: Several commenters asked whether systems that determine
eligibility of clients for insurance coverage under broad categories
such as medical coverage groups are considered health information. One
commenter asked that we specifically exclude eligibility information
from the standards.
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.
c. Comment: Several commenters requested clarification as to
whether the standards apply to identifiable health information in paper
form. Some commenters believed the rule should be applicable to paper;
others argued that it should apply to all confidential, identifiable
health information.
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.''
d. Comment: The proposed rule would have excluded ``telephone voice
response'' and ``faxback'' systems from the security standards, and we
specifically solicited comments on that issue. A number of commenters
agreed that telephone voice response and faxback should be excluded
from the regulation, suggesting that the privacy standards rather than
the security standards should apply. Others wanted those systems
included, on the grounds that inclusion is necessary for consistency
and in keeping with the intent of the Act. Still others specifically
wanted personal computer-fax transmissions included. One commenter
asked for clarification of when we would cover faxes, and another
commenter asked why we were excluding them. Several commenters
suggested that the other security requirements provide for adequate
security of these systems.
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 Sec. 160.103.
[[Page 8343]]
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.
e. Comment: One commenter asked whether there is a need to
implement special security practices to address the shipping and
receiving of health information and asked that we more fully explain
our expectations and solutions in the final rules.
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 Sec.
164.310(d)(1) addresses this situation.
f. Comment: One commenter wanted the ``HTML'' statement reworded to
eliminate a specific exemption for HTML from the regulation.
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.
g. Comment: One commenter asked to what degree ``family history''
is considered health information under this rule and what protections
apply to family members included in a patient's family history.
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.
h. Comment: Two commenters asked that the rule prohibit re-
identification of de-identified data. In contrast, several commenters
asked that we identify a minimum list or threshold of specific re-
identification data elements (for example, name, city, and ZIP) that
would fall under this final rule so that, for example, the rule would
not affect numerous systems, for example, network adequacy and
population-based clinical analysis databases. One commenter asked that
we establish a means to use re-identified information if the entity
already has access to the information or is authorized to have access.
Response: The issue of re-identification is addressed in the
Privacy Rule at Sec. 164.502(d) and Sec. 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 re-identification. 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
Comment: Many commenters expressed support for our efforts to
develop standards for the security of health information. A number of
comments were made in support of the technology-neutral approach of the
proposed rule. For example, one commenter stated, ``By avoiding
prescription of the specific technologies health care entities should
use to meet the law's requirements, you are opening the door for
industry to apply innovation. Technologies that don't currently exist
or are impractical today could, in the near future, enhance health
information security while minimizing the overall cost.'' Several other
commenters stated that the requirements should be general enough to
withstand changes to technology without becoming obsolete. One
commenter anticipates no problems with meeting the standards.
In contrast, one commenter suggested that whenever possible,
specific technology recommendations should provide sufficient detail to
promote systems interoperability and decrease the tendency toward
adoption of multiple divergent standards. Several commenters stated
that by letting each organization determine its own rules, the rules
impose procedural burdens without any substantive benefit to security.
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
a. Comment: Some commenters stated that the requirements and
implementation features set out in the proposed rule were not specific
enough to be considered standards, and that the actual standards are
delegated to the discretion of the covered entities, at the expense of
medical record privacy. Several commenters stated that it was
inappropriate to balance the interests of those seeking to use
identifiable medical information without patient consent against the
interest of patients. Several other commenters believe that allowing
covered entities to make their own decisions about the adequacy and
balance of security measures undermined patient confidentiality
interests, and stated that the proposed rule did not appear to
adequately consider patient concerns and viewpoints.
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.
b. Comment: Several commenters requested we withdraw the
regulations, citing resource shortages due to Y2K preparation, upcoming
privacy legislation, and/or the ``excessive micro-management''
contained in the rules. One commenter stated that, to insurers, these
rules were onerous, not necessary, and not justified as cost-effective,
as they already have effective practices for computer security and are
subject to rigorous State laws for the safeguarding of health
information. Another
[[Page 8344]]
commenter stated that these rules would adversely affect a provider's
practice environment.
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
Sec. 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 cost-effective
solutions. We believe that insurers who already have effective security
programs in place will have met many of the requirements of this
regulation.
c. Comment: One commenter believes the rule is arbitrary and
capricious in its requirements without any justification that they will
significantly improve the security of medical records and with the
likelihood that their implementation may actually increase the
vulnerability of the data. The commenter noted that the data backup
requirements increase access to data and that security awareness
training provides more information to employees.
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.
d. Comment: Several commenters suggested that the proposed rule
appears to reflect the Medicare program's perspective on security risks
and solutions, and that it should be noted that not all industry
segments share all the same risks as Medicare. One commenter stated
that as future proposed rules are drafted, we should solicit input from
those most significantly affected, for example, providers, plans, and
clearinghouses.
Others stated that Medicaid agencies were not sufficiently involved
in the discussions and debate. Still another stated that States would
be unable to perform some basic business functions if all the standards
are not designed to meet their needs.
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.
e. Comment: One commenter stated that there is a need to ensure the
confidentiality of risk analysis information that may contain sensitive
information.
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.
f. Comment: One commenter expressed concern over the statement in
the preamble of the proposed rule (63 FR 43250) that read: ``No one
item is considered to be more important than another.'' The commenter
suggested that security management should be viewed as most critical
and perhaps what forms the foundation for all other security actions.
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 Sec. 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.
g. Comment: One commenter stated that there is a need for
requirements concerning organizational practices (for example,
education, training, and security and confidentiality policies), as
[[Page 8345]]
well as technical practices and procedures.
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.
h. Comment: One commenter stated that internal and external
security requirements should be separated and dealt with independently.
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.
i. Comment: Two commenters stated that the standards identified in
Addendum 3 of the proposed rule may not all have matured to
implementation readiness.
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.
j. Comment: One commenter suggested we include a revised preamble
in the final publication. Another questioned how clarification of
points in the preamble will be handled if the preamble is not part of
the final regulation.
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.
k. Comment: One commenter asked that we clarify that no third party
can require implementation of more security features than are required
in the final rule, for example, a third party could not require
encryption but may choose to accept it if the other party so desires.
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.
l. Comment: One commenter asked how privacy legislation would
affect these rules. The commenter inquired whether covered entities
will have to reassess and revise actions already taken in the spirit of
compliance with the security regulations.
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.
m. Comment: One commenter stated that a data classification policy,
that is a method of assigning sensitivity ratings to specific pieces of
data, should be part of the final regulations.
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.
n. Comment: One commenter stated that this proposed rule conflicts
with previously stated rules that acceptable ``standards'' must have
been developed by ANSI-recognized Standards Development Organizations
(SDOs).
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 ANSI-recognized 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.
o. Comment: One commenter stated that this regulation goes beyond
the scope of the law, unjustifiably extending into business practices,
employee policies, and facility security.
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.
p. Comment: One commenter stated that all sections regarding
confidentiality and privacy should be removed, since they do not belong
in this regulation.
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.
[[Page 8346]]
However, we have relocated material that relates to both security and
privacy (including definitions) to the general section of part 164.
q. Comment: One commenter asked that data retention be addressed
more specifically, since this will become a significant issue over
time. It is recommended that a national work group be convened to
address this issue.
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 Sec. 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.
r. Comment: One commenter stated that requiring provider practices
to develop policies, procedures, and training programs and to implement
record keeping and documentation systems would be tremendously
resource-intensive and increase the costs of health care.
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.
s. Comment: One commenter stated that there is no system for which
risk has been eliminated and expressed concern over phrases such as
covered entities must ``assure that electronic health information
pertaining to an individual remains secure.''
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 Sec. 164.306(b).
E. Administrative Safeguards (Sec. 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 Sec. 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 Sec. 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.
1. Security Management Process (Sec. 164.308(a)(1)(i))
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.
a. Comment: Three commenters asked that this requirement be
deleted. Two commenters cited this requirement as a possible burden.
Several commenters asked that the implementation features be made
optional.
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 Sec. 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 Sec. 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 Sec. 164.306(e) as a
more precise way of communicating that security measures
[[Page 8347]]
in general that must be periodically reassessed and updated as needed.
The risk analysis implementation specification contains other terms
that merit explanation. Under Sec. 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.
b. Comment: Relative to the development of an entity's sanction
policy, one commenter asked that we describe the sanction penalties for
breach of security. Another suggested establishment of a standard to
which one's conduct could be held and adoption of mitigating
circumstances so that the fact that a person acted in good faith would
be a factor that could be used to reduce or otherwise minimize any
sanction imposed. Another commenter suggested sanction activities not
be implemented before the full implementation and testing of all
electronic transaction standards.
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.
c. Comment: Commenters requested the definitions of ``risk
analysis'' and ``breach.''
Response: ``Risk analysis'' is defined and described in the
specification of the security management process standard, and is
discussed in the preamble discussion of Sec. 164.308(a)(1)(ii)(A) of
this final rule. The term breach is no longer used and is, therefore,
not defined.
d. Comment: One commenter asked whether all health information is
considered equally ``sensitive,'' the thought being that, in
determining risk, an entity may consider the loss of a smaller amount
of extraordinarily sensitive data to be more significant than the loss
of a larger amount of routinely collected data. The commenter stated
that common reasoning would suggest that the smaller amount of data
would be considered more sensitive.
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.
e. Comment: One commenter asked that we add ``threat assessment''
to this requirement.
Response: We have not done this because we view threat assessment
as an inherent part of a risk analysis; adding it would be redundant.
f. Comment: We proposed a requirement for internal audit, the in-
house review of the records of system activity (for example, logins,
file accesses, and security incidents) maintained by an entity. Several
commenters wanted this requirement deleted. One suggested the audit
trail requirement should not be mandatory, while another stated that
internal audits would be unnecessary if physical security requirements
are implemented.
A number of commenters asked that we clarify the nature and scope
of what an internal audit covers and what the audit time frame should
be. Several commenters offered further detail concerning what should
and should not be required in an internal audit for security purposes.
One commenter stated that ongoing intrusion detection should be
included in this requirement. Another wanted us to specify the
retention times for archived audit logs.
Several commenters had difficulty with the term ``audit'' and
suggested we change the title of the requirement to ``logging and
violation monitoring.''
A number of commenters stated this requirement could result in an
undue burden and would be economically unfeasible.
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 (Sec. 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 Sec.
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.
a. Comment: Commenters were concerned that delegation of assigned
security responsibility, especially in large organizations, needs to be
to more than a single individual. Commenters believe that a large
health organization's security concerns would likely cross many
departmental boundaries requiring group responsibility.
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.
b. Comment: One commenter disagreed with placing assigned security
responsibility as part of physical safeguards. The commenter suggested
that assigned security responsibility should be included under the
Administrative Procedures.
[[Page 8348]]
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 Sec.
164.308.
3. Workforce Security (Sec. 164.308(a)(3)(i))
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.
a. Comment: The majority of comments concerned the supervision of
maintenance personnel by an authorized knowledgeable person. Commenters
stated this would not be feasible in smaller settings. For example, the
availability of technically knowledgeable persons to ensure this
supervision would be an issue. We were asked to either reword this
implementation feature or delete it.
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 Sec.
164.308(a)(3)(ii)(A)). Entities can decide on the feasibility of
meeting this specification based on their risk analysis.
b. Comment: The second largest group of comments requested
assurance that, with regard to the proposed ``Personnel clearance
procedure'' implementation feature, having appropriate clearances does
not mean performing background checks on everyone. We were asked to
delete references to ``clearance'' and use the term ``authorization''
in its place.
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 Sec. 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 Sec. 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.''
c. Comment: One commenter asked that we expand the implementation
features to include the identification of the restrictions that should
be placed on members of the workforce and others.
Response: We have not adopted this comment in the interest of
maintaining flexibility as discussed in Sec. 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, Sec. 164.514(d)(2) (relating to
minimum necessary requirements), and Sec. 164.530(c) (relating to
safeguards).
Comment: One commenter believes that the proposed ``Personnel
security'' requirement was reasonable, since an administrative
determination of trustworthiness is needed before allowing access to
sensitive information. Two commenters asked that we delete the
requirement entirely. A number of commenters requested that we delete
the implementation features. Another commenter stated that all the
implementation features may not be applicable or even appropriate to a
given entity and should be so qualified.
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 Sec.
164.308(a)(3)(ii)(B)).
e. Comment: The majority of commenters on the ``Termination
procedures'' requirement asked that it be made optional, stating that
it may not be applicable or even appropriate in all circumstances and
should be so qualified or posed as guidelines. A number of commenters
stated that the requirement should be deleted. One commenter stated
that much of the material covered under the ``Termination procedures''
requirement is already covered in ``Information access control.'' A
number of commenters stated that this requirement
[[Page 8349]]
was too detailed and some of the requirements excessive.
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.
f. Comment: One commenter asked whether human resource employee
termination policies and procedures must be documented to show the
types of security breaches that would result in termination.
Response: Policies and procedures implemented to adhere to this
standard must be documented (see Sec. 164.316 below). The purpose of
termination procedure documentation under this implementation
specification is not to detail when or under which circumstances an
employee should be terminated. This information would more
appropriately be part of the entity's sanction policy. The purpose of
termination procedure documentation is to ensure that termination
procedures include security-unique actions to be followed, for example,
revoking passwords and retrieving keys when a termination occurs.
4. Information Access Management (Sec. 164.308(a)(4))
We proposed an ``information access control'' requirement for
establishment and maintenance of formal, documented policies and
procedures defining levels of access for all personnel authorized to
access health information, and how access is granted and modified. In
Sec. 164.308(a)(4)(ii)(B) and (C) below, the proposed implementation
features are made addressable specifications. We have added in Sec.
164.308(a)(4)(ii)(A), a required implementation specification to
isolate health care clearinghouse functions to address the provisions
of section 1173(d)(1)(B) of the Act which related to this area.
a. Comment: One commenter asked that the requirement be deleted,
expressing the opinion that this requirement goes beyond ``reasonable
boundaries'' into regulating common business practices. In contrast,
another asked that we expand this requirement to identify participating
parties and access privileges relative to specific data elements.
Response: We disagree that this requirement improperly imposes upon
business functions. Restricting access to those persons and entities
with a need for access is a basic tenet of security. By this mechanism,
the risk of inappropriate disclosure, alteration, or destruction of
information is minimized. We cannot, however, specifically identify
participating parties and access privileges relative to data elements
within this regulation. These will vary depending upon the entity, the
needs within the user community, the system in which the data resides,
and the specific data being accessed. This standard is consistent with
Sec. 164.514(d) in the Privacy Rule (minimum necessary requirements
for use and disclosure of protected health information), and is,
therefore, being retained.
b. Comment: Several commenters asked that we not mandate the
implementation features, but leave them as optional, a suggested means
of compliance. The commenters noted that this might make the rules more
scalable and flexible, since this approach would allow providers to
implement safeguards that best addressed their needs. Along this line,
one commenter expressed the belief that each organization should
implement features deemed necessary based on its own risk assessment.
Response: While the information access management standard in this
final rule must be met, we agree that the implementation specifications
at Sec. 164.308(a)(4)(ii)(B) and (C) should not be mandated but posed
as a suggested means of compliance, which must be addressed. These
specifications may not be applicable to all entities based on their
size and degree of automation. A fully automated covered entity
spanning multiple locations and involving hundreds of employees may
determine it has a need to adopt a formal policy for access
authorization, while a small provider may decide that a desktop
standard operating procedure will meet the specifications. The final
rule has been revised accordingly.
c. Comment: Clarification was requested concerning the meaning of
''formal.''
Response: The word ``formal'' has caused considerable concern among
commenters, as it was thought ``formal'' carried the connotation of a
rigidly defined structure similar to what might be found in the
Department of Defense instructions. As used in the proposed rule, this
word was not intended to convey such a strict structure. Rather, it was
meant to convey that documentation should be an official organizational
statement as opposed to word-of-mouth or cryptic notes scratched on a
notepad. While documentation is still required (see Sec. 164.316), to
alleviate confusion, the word ``formal'' has been deleted.
d. Comment: One commenter asked that we clarify that this
requirement relates to both the establishment of policies for the
access control function and to access control (the implementation of
those policies).
Response: ``Information access management'' does address both the
establishment of access control policies and their implementation. We
use the term ``implement'' to clarify that the procedures must be in
use, and we believe that the requirement to implement policies and
procedures requires, as an antecedent condition, the establishment or
adaptation of those policies and procedures.
5. Security Awareness and Training (Sec. 164.308(a)(5)(i))
We proposed, under the requirement ``Training,'' that security
training be required for all staff, including management. Training
would include awareness training for all personnel, periodic security
reminders, user education concerning virus protection, user education
in the importance of monitoring login success/failure, and how to
report discrepancies, and user education in password management.
In this final rule, we adopt this proposed requirement in modified
form. For the standard ``Security awareness and training,'' in Sec.
164.308(a)(5), we require training of the workforce as reasonable and
appropriate to carry out their functions in the facility. All proposed
training features have been combined as implementation specifications
under this standard. Specific implementation specifications relative to
content are addressable. The ``Virus protection'' implementation
feature has been renamed ``protection from malicious software,''
because we did not intend by the nomenclature to exclude coverage of
malicious acts that might not come within the prior term, such as
worms.
a. Comment: One commenter believes that security awareness training
for all
[[Page 8350]]
system users would be too difficult to do in a large organization.
Response: We disagree with the commenter. Security awareness
training is a critical activity, regardless of an organization's size.
This feature would typically become part of an entity's overall
training program (which would include privacy and other information
technology items as well). For example, the Government Information
Systems Reform ACT (GISRA) of 2000 requires security awareness training
as part of Federal agencies' information security programs, including
Federal covered entities, such as the Medicare program. In addition,
National Institute of Standards and Technology (NIST) SP 800-16,
Information Technology Security Training Requirements, A role and
performance base model, April 1998, provides an excellent source of
information and guidance on this subject and is targeted at industry as
well as government activities. We also note that covered entities must
have discretion in how they implement the requirement, so they can
incorporate this training in other existing activities. One approach
would be to require this training as part of employee orientation.
b. Comment: A number of commenters asked that this requirement be
made optional or used as a guideline only. Several commenters stated
that this requirement is too specific and is burdensome. Several asked
that the implementation features be removed.
Several others stated that this requirement is not appropriate for
agents or contractors. One commenter asked how to apply this
requirement to outsiders having access to data. Another asked if this
requirement included all subcontractor staff. Others stated that
contracts, signed by entities such as consultants, that address
training should be sufficient.
Response: Security training remains a requirement because of its
criticality; however, we have revised the implementation specifications
to indicate that the amount and type of training needed will be
dependent upon an entity's configuration and security risks. Business
associates must be made aware of security policies and procedures,
whether through contract language or other means. Covered entities are
not required to provide training to business associates or anyone else
that is not a member of their workforce.
c. Comment: Several commenters questioned why security awareness
training appeared in two places, under ``Physical safeguards'' as well
as ``Administrative safeguards.'' Others questioned the appropriateness
of security awareness training under ``Physical safeguards.''
Response: We reviewed the definitions of the proposed ``Awareness
training for all personnel'' (``Administrative safeguards'')
implementation feature and the proposed ``Security awareness training''
(``Physical safeguards'') requirement. We agree that, to avoid
confusion and eliminate redundancy, security awareness and training
should appear in only one place. We believe the appropriate location
for it is under ``Administrative safeguards,'' as such training is
essentially an administrative function.
d. Comment: Several commenters objected to the blanket requirement
for security awareness training of individuals who may be on site for a
limited time period (for example, a single day).
Response: Each individual who has access to electronic protected
health information must be aware of the appropriate security measures
to reduce the risk of improper access, uses, and disclosures. This
requirement does not mean lengthy training is appropriate in every
instance; there are alternative methods to inform individuals of
security responsibilities (for example, provisions of pamphlets or
copies of security policies, and procedures).
e. Comment: One commenter asked that ``training'' be changed to
``orientation.''
Response: We believe the term ``training,'' as presented within
this rule is the more appropriate term. The rule does not contemplate a
one-time type of activity as connoted by ``orientation,'' but rather an
on-going, evolving process as an entity's security needs and procedures
change.
f. Comment: Several commenters asked how often training should be
conducted and asked for a definition of ``periodic,'' as it appears in
the proposed implementation feature ``Periodic security reminders.''
One asked if the training should be tailored to job need.
Response: Amount and timing of training should be determined by
each covered entity; training should be an on-going, evolving process
in response to environmental and operational changes affecting the
security of electronic protected health information. While initial
training must be carried out by the compliance date, we provide
flexibility for covered entities to construct training programs.
Training can be tailored to job need if the covered entity so desires.
6. Security Incident Procedures (Sec. 164.308(a)(6))
We proposed a requirement for implementation of accurate and
current security incident procedures: formal, documented report and
response procedures so that security violations would be reported and
handled promptly. We adopt this standard in the final rule, along with
an implementation specification for response and reporting, since
documenting and reporting incidents, as well as responding to incidents
are an integral part of a security program.
a. Comment: Several commenters asked that we further define the
scope of a breach of security. Along this same line, another commenter
stated that the proposed security incident procedures were too vague as
stated. We were asked to specify what a security incident would be,
what the internal chain for reporting procedures would be, and what
should be included in the documentation (for example, hardware/
software, personnel responses).
Response: We define a security incident in Sec. 164.304. Whether a
specific action would be considered a security incident, the specific
process of documenting incidents, what information should be contained
in the documentation, and what the appropriate response should be will
be dependent upon an entity's environment and the information involved.
An entity should be able to rely upon the information gathered in
complying with the other security standards, for example, its risk
assessment and risk management procedures and the privacy standards, to
determine what constitutes a security incident in the context of its
business operations.
b. Comment: One commenter asked what types of incidents must be
reported to outside entities. Another commented that we clarify that
incident reporting is internal.
Response: Internal reporting is an inherent part of security
incident procedures. This regulation does not specifically require any
incident reporting to outside entities. External incident reporting is
dependent upon business and legal considerations.
c. Comment: One commenter stated that network activity should be
included here.
Response: We see no reason to exclude network activity under this
requirement. Improper network activity should be treated as a security
incident, because, by definition, it represents an improper instance of
access to or use of information.
[[Page 8351]]
d. Comment: One commenter stated that this requirement should
address suspected misuse also.
Response: We agree that security incidents include misuse of data;
therefore, this requirement is addressed.
e. Comment: Several commenters asked that this requirement be
deleted. One commenter asked that we delete the implementation
features.
Response: As indicated above, we have adopted the proposed standard
and combined the implementation specifications.
7. Contingency Plan (Sec. 164.308(a)(7)(i))
We proposed that a contingency plan must be in effect for
responding to system emergencies. The plan would include an
applications and data criticality analysis, a data backup plan, a
disaster recovery plan, an emergency mode operation plan, and testing
and revision procedures.
In this final rule, we make the implementation specifications for
testing and revision procedures and an applications and data
criticality analysis addressable, but otherwise require that the
contingency features proposed be met.
a. Comment: Several