This is the html version of the file http://cms.hhs.gov/regulations/hipaa/cms0003-5/0049f-econ-ofr-2-12-03.pdf.
G o o g l e automatically generates html versions of documents as we crawl the web.
To link to or bookmark this page, use the following url: http://www.google.com/cobrand?q=cache:nkEaJGWqhl8J:cms.hhs.gov/regulations/hipaa/cms0003-5/0049f-econ-ofr-2-12-03.pdf+security&hl=en&ie=UTF-8


Google is not affiliated with the authors of this page nor responsible for its content.

These search terms have been highlighted:  security                 BACK

Page 1

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 other Federal 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 and Accountability Act of 1996

(HIPAA).


Page 2

2

DATES: Effective Date: These regulations are effective on

[OFR: insert date 60 days after the date of publication in

the Federal Register].

Compliance Date: Covered entities, with the exception of

small health plans, must comply with the requirements of

this final rule [OFR: insert 24 months after the effective

date of this regulation]. Small health plans must comply

with the requirements of this final rule by [OFR: insert

36 months after the effective date of this regulation].

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


Page 3

3

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 website 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


Page 4

4

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


Page 5

5

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


Page 6

6

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


Page 7

7

(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 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


Page 8

8

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


Page 9

9

"implementation features." In this final rule, we replace

the term "requirement" with "standard." We also replace

the phrase "implementation feature" with "implementation

specification." We do this to maintain consistency with

the use of those terms as they appear in the statute, the

Transactions Rule, and the Privacy Rule. Within the

comment and response portion of this final rule, for

purposes of continuity, however, we use "requirement" and

"implementation feature" when we are referring specifically

to matters from the proposed rule. In all other instances,

we use "standard" and "implementation specification."

The proposed rule would require that each covered

entity (as now described in § 160.102) engaged in the

electronic maintenance or transmission of health

information pertaining to individuals assess potential

risks and vulnerabilities to such information in its

possession in electronic form, and develop, implement, and

maintain appropriate security measures to protect that

information. Importantly, these measures would be required

to be documented and kept current.

The proposed security standard was based on three

basic concepts that were derived from the Administrative

Simplification provisions of HIPAA. First, the standard


Page 10

10

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


Page 11

11

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


Page 12

12

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


Page 13

13

has authority to cover "health information," which, by

statute, includes information in other than electronic

form. However, because the proposed rule proposed to cover

only health information in electronic form, we do not

include security standards for health information in non-

electronic form in this final rule.

We received a number of comments that pertained to

privacy issues. These issues were considered in the

development of the Privacy Rule and many of these comments

were addressed in the preamble of the Privacy Rule.

Therefore, we are referring the reader to that document for

a discussion of those issues.

2. Level of Detail

We solicited comments as to the level of detail

expressed in the required implementation features; that is,

we specifically wanted to know whether commenters believe

the level of detail of any proposed requirement went beyond

what is necessary or appropriate. We received numerous

comments expressing the view that the security standards

should not be overly prescriptive because the speed with

which technology is evolving could make specific

requirements obsolete and might in fact deter technological

progress. We have accordingly written the final rule to


Page 14

14

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


Page 15

15

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


Page 16

16

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


Page 17

17

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.


Page 18

18

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.


Page 19

19

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.wedo.org/snip. We believe that these and other

future industry-developed guidelines and/or models may

provide valuable assistance to covered entities

implementing these standards but must caution that HHS does

not rate or endorse any such guidelines and/or models and

the value of its content must be determined 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


Page 20

20

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


Page 21

21

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


Page 22

22

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 (§ 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


Page 23

23

transmissions would include transactions using all media,

even when the information is physically moved from one

location to another using magnetic tape, disk, or other

machine readable media. Transmissions over the Internet

(wide-open), extranet (using Internet technology to link a

business with information only accessible to collaborating

parties), leased lines, dial-up lines, and private networks

would be included. We proposed that telephone voice

response and "faxback" systems (a request for information

made via voice using a fax machine and requested

information returned via that same machine as a fax) would

not be included but we solicited comments on this proposed

exclusion.

This final rule simplifies the applicability statement

greatly. Section 164.302 provides that the security

standards apply to covered entities; the scope of the

information covered is specified in § 164.306 (see the

discussion under that section below regarding the changes

and revisions to the scope of information covered).

1. Comment: A number of commenters requested

clarification of who must comply with the standards. The

preamble and proposed § 142.102 and § 142.302 stated:

"Each person described in section 1172(a) of the Act who


Page 24

24

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 § 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 25

25

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


Page 26

26

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 § 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.


Page 27

27

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


Page 28

28

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


Page 29

29

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 § 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


Page 30

30

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.


Page 31

31

Response: Patients are not covered entities and,

thus, are not subject to these standards. With respect to

transmissions from covered entities, covered entities must

protect electronic protected health information when they

transmit that information. See also the discussion of

encryption in section III.G.

C.

Transition to the Final Rule

The proposed rule included definitions for a number of

terms that have now already been promulgated as part of the

Transactions Rule or the Privacy Rule. Comments related to

the definitions of "code set," "health care clearinghouse,"

"health plan," "health care provider," "small health plan,"

"standard" and "transaction," are addressed in the

Transactions Rule at 65 FR 50319 through 50320. Comments

concerning the definition of "individually identifiable

health information" are discussed below, but are also

addressed in the Privacy Rule at 65 FR 82611 through 82613.

In addition, a few terms were redefined in the final

Standards for Privacy of Individually Identifiable Health

Information (67 FR 53182), issued on August 14, 2002

(Privacy Modifications). Certain terms that were defined

in the proposed rule are not used in the final rule because

they are no longer necessary. Other terms defined in the


Page 32

32

proposed rule are defined within the explanation of the

standards in the final rule and are discussed in the

preamble discussions in § 164.308 through

§ 164.312.

Definitions of terms relevant to the security

standards now appear in the regulations text provisions as

indicated below:

§

160.103: Definitions of the following terms

relevant to this rule appear in § 160.103: "business

associate," "covered entity," "disclosure," "electronic

media," "electronic protected health information," health

care," "health care clearinghouse," "health care provider,"

"health information," "health plan," "individual,"

"individually identifiable health information,"

"implementation specification," "organized health care

arrangement," "protected health information," "standard,"

"use," and "workforce." These terms were discussed in

connection with the Transaction and Privacy Rules and with

the exception of the terms "covered entity", "disclosure"

"electronic protected health information", "health

information," "individual," "organized health care

arrangement," "protected health information," and "use," we

will not discuss them in this document. We note that the


Page 33

33

definition of those terms are not changed in the final

rule.

§

162.103: We have moved the definition of

"electronic media" at § 162.103 to § 160.103 and have

modified it to clarify that the term includes storage of

information. The term "electronic media" is used in the

definition of "protected health information." Both the

privacy and security standards apply to information "at

rest" as well as to information being transmitted.

We note that we have deleted the reference to

§ 162.103 in paragraph (1)(ii) of the definition of

"protected health information," since both definitions,

"electronic media" and "protected health information," have

been moved to this section. Also, it is unnecessary,

because the definitions of § 160.103 apply to all of the

rule in parts 160, 162, and 164.

We have also clarified that the physical movement of

electronic media from place to place is not limited to

magnetic tape, disk, or compact disk. This clarification

removes a restriction as to what is considered to be

physical electronic media, thereby allowing for future

technological innovation. We further clarified that

transmission of information not in electronic form before


Page 34

34

the transmission, for example, paper or voice, is not

covered by this definition.

§

164.103: The following term "plan sponsor" now

appears in the new § 164.103, which consists of definitions

of terms common to both subpart C and subpart E (the

privacy standards). This definition was moved, without

substantive change, from § 164.501 and has the meaning

given to it in that section, and comments relating to this

definitions are discussed in connection with that section

in the Privacy Rule at 65 FR 82607, 82611 through 82613,

82618 through 82622, and 82629.

§

164.304: Definitions specifically applicable to the

Security Rule appear in § 164.304, and these are discussed

below. These definitions are from, or derived from,

currently accepted definitions in industry publications,

such as, the International Organization for Standards (ISO)

7498-2 and the American Society for Testing and Materials

(ASTM) E1762-95.

The following terms in § 164.304 are taken from the

proposed rule text or the glossary in Addendum 2

of the proposed rule (63 FR 43271), were not commented on,

and/or are unchanged or have only minor technical changes

for purposes of clarification and are not discussed below:


Page 35

35

"access," "authentication," "availability,"

“confidentiality," "encryption," "password," and

"security."

§

164.314: Four terms were defined in § 164.504(a) of

the Privacy Rule ("common control," "common ownership,"

"health care component," and "hybrid entity"). Because

these terms apply to both security and privacy, their

definitions have been moved to § 164.103 without change.

Those terms are discussed in the Privacy Rule at

65 FR 82502 through 82503 and at 67 FR 53203 through 53207.

1.

Covered Entity (§ 160.103)

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


Page 36

36

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 § 164.308(b)(1) and § 164.314(c) of this final

rule.

2.

Health Care and Medical Care (§ 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 "medical care" is not

included in this final rule. It is, however, included in


Page 37

37

the definition of "health plan," where its meaning is not

synonymous with "health care." For a full discussion of

this issue and its resolution, see the Privacy Rule

(65 FR 82578).

3.

Health Information and Individually Identifiable

Health Information (§ 160.103)

We note that the definitions of "health information"

and "individually identifiable health information" remain

unchanged from those published in the Transactions and

Privacy Rules.

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 health 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,


Page 38

38

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


Page 39

39

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 § 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 § 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

§ 160.103, which applies to this final rule.


Page 40

40

4.

Protected Health Information (§ 160.103)

This term is moved from § 164.501 to § 160.103 because

it applies to both subparts C (security) and E (privacy).

See 67 FR 53192 through 531936 regarding the definition of

"protected health information."

Also, the term "electronic media" is included in

paragraphs (1)(i) and (ii) of the definition of "protected

health information," as specified in this section.

In addition, we added the definitions of "covered

functions," "plan sponsor," and "Required by law" to

§ 164.103.

5.

Breach (§ 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 (§ 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


Page 41

41

comments indicating that the original term was not

descriptive. We have defined the term "facility" as the

physical premises and interior and exterior of a building.

7.

Security Incident (§ 164.304)

Comment: We received comments asking that this term

be defined.

Response: This final rule defines "security incident"

in § 164.304 as "the attempted or successful unauthorized

access, use, disclosure, modification, or destruction of

information or interference with system operations in an

information system."

8.

System (§ 164.304)

Comment: One commenter asked that "system" be

defined.

Response: This final rule defines "system," in the

context of an information system, in § 164.304 as "an

interconnected set of information resources under the same

direct management control that shares common functionality.

A system normally includes hardware, software, information,

data, applications, communications, and people."

9.

Workstation (§ 164.304)

Comment: One commenter expressed concern that the use

of the term "workstation" implied limited applicability to


Page 42

42

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 § 164.308(a)(7) below.

a. Comment: We received comments requesting that we

define the following terms: "token" and "documentation."


Page 43

43

Response: These terms were defined in Addendum 2 of

the proposed rule. In this final rule, we do not adopt a

definition for "token" because it is not used in the final

rule. "Documentation" is discussed in § 164.316 below.

b. Comment: We received several comments that

"small" and "rural" should be defined as those terms apply

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


Page 44

44

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

§ 164.308(a)(4), § 164.310(a)(1), and § 164.312(a)(1).


Page 45

45

With respect to PRBAC, the access control standard does not

exclude this control, and entities should adopt it if

appropriate to their circumstances.

D.

General Rules (§ 164.306)

In the proposed rule, we proposed to cover all health

information maintained or transmitted in electronic form by

a covered entity. We proposed to adopt, in § 142.308, a

nation-wide security standard that would require covered

entities to implement security measures that would be

technology-neutral and scalable, and yet integrate all the

components of security (administrative procedures, physical

safeguards, technical security services, and technical

security mechanisms) that must be in place to preserve

health information confidentiality, integrity, and

availability (three basic elements of security). Since no

comprehensive, scalable, and technology-neutral set of

standards currently exists, we proposed to designate a new

standard, which would define the security requirements to

be fulfilled.

The proposed rule proposed to define the security

standard as a set of scalable, technology-neutral

requirements with implementation features that providers,

plans, and clearinghouses would have to include in their


Page 46

46

operations to ensure that health information pertaining to

an individual that is electronically maintained or

electronically transmitted remains safeguarded. The

proposed rule would have required that each affected entity

assess its own security needs and risks and devise,

implement, and maintain appropriate security to address its

own unique security needs. How individual security

requirements would be satisfied and which technology to use

would be business decisions that each entity would have to

make.

In the final rule we adopt this basic framework. In

§ 164.306, we set forth general rules pertaining to the

security standards. In paragraph (a), we describe the

general requirements. Paragraph (a) generally reflects

section 1173(d)(2) of the Act, but makes explicit the

connection between the security standards and the privacy

standards (see § 164.306(a)(3)). In § 164.306(a)(1), we

provide that the security standards apply to all electronic

protected health information the covered entity creates,

receives, maintains, or transmits. In paragraph (b)(1), we

provide explicitly for the scalability of this rule by

discussing the flexibility of the standards, and paragraph

(b)(2) of § 164.306 discusses various factors covered


Page 47

47

entities must consider in complying with the standards.

The provisions of § 164.306(c) provide the framework

for the security standards, and establish the requirement

that covered entities must comply with the standards. The

administrative, physical, and technical safeguards a

covered entity employs must be reasonable and appropriate

to accomplish the tasks outlined in paragraphs (1) through

(4) of § 164.306(a). Thus, an entity's risk analysis and

risk management measures required by § 164.308(a)(1) must

be designed to lead to the implementation of security

measures that will comply with § 164.306(a).

It should be noted that the implementation of

reasonable and appropriate security measures also supports

compliance with the privacy standards, just as the lack of

adequate security can increase the risk of violation of the

privacy standards. If, for example, a particular safeguard

is inadequate because it routinely permits reasonably

anticipated uses or disclosures of electronic protected

health information that are not permitted by the Privacy

Rule, and that could have been prevented by implementation

of one or more security measures appropriate to the scale

of the covered entity, the covered entity would not only be

violating the Privacy Rule, but would also not be in


Page 48

48

compliance with § 164.306(a)(3) of this rule.

Paragraph (d) of § 164.306 establishes two types of

implementation specifications, required and addressable.

It provides that required implementation specifications

must be met. However, with respect to implementation

specifications that are addressable, § 164.306(d)(3)

specifies that covered entities must assess whether an

implementation specification is a reasonable and

appropriate safeguard in its environment, which may include

consideration of factors such as the size and capability of

the organization as well as the risk. If the organization

determines it is a reasonable and appropriate safeguard, it

must implement the specification. If an addressable

implementation specification is determined not to be a

reasonable and appropriate answer to a covered entity's

security needs, the covered entity must do one of two

things: implement another equivalent measure if reasonable

and appropriate; or if the standard can otherwise be met,

the covered entity may choose to not implement the

implementation specification or any equivalent alternative

measure at all. The covered entity must document the

rationale behind not implementing the implementation

specification. See the detailed discussion in section


Page 49

49

II.A.3.

Paragraph (e) of § 164.306 addresses the requirement

for covered entities to maintain the security measures

implemented by reviewing and modifying the measures as

needed to continue the provision of reasonable and

appropriate protections, for example, as technology moves

forward, and as new threats or vulnerabilities are

discovered.

1.

Scope of Health Information Covered by the Rule

(§ 164.306(a))

We proposed to cover health information maintained or

transmitted by a covered entity in electronic form. We

have modified, by narrowing, the scope of health

information to be safeguarded under this rule from that

which was proposed. The statute requires the privacy

standards to cover individually identifiable health

information. The Privacy Rule covers all individually

identifiable information except for: (1) education records

covered by the Family and Educational Rights and Privacy

Act (FERPA); (2) records described in

20 U.S.C. 1232g(a)(4)(B)(iv); and (3) employment records.

(see the Privacy Rule at 65 FR 82496. See also 67 FR 53191

through 53193). The scope of information covered in the


Page 50

50

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


Page 51

51

information, from which identifiers have been stripped,

does not come within the purview of this final rule.

Information that is de-identified, as defined in the

Privacy Rule at § 164.502(d) and § 164.514(a), is not

"individually identifiable" within the meaning of these

rules and, thus, does not come within the definition of

"protected health information." It accordingly is not

covered by this final rule. For a full discussion of the

issues of de-identification and re-identification of

individually identifiable health information see

65 FR 82499 and 82708 through 82712 and 67 FR 53232 through

53234.

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,"


Page 52

52

(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."


Page 53

53

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


Page 54

54

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


Page 55

55

included in the term "computer." Therefore, because

"paper-to-paper" faxes, person-to-person telephone calls,

video teleconferencing, or messages left on voice-mail were

not in electronic form before the transmission, those

activities are not covered by this rule. See also the

definition of "electronic media" at § 160.103.

We note that this guidance differs from the guidance

regarding the applicability of the Transactions Rule to

faxback and voice response systems. HHS has stated that

faxback and voice response systems are not required to

follow the standards mandated in the Transactions Rule.

This new guidance refers only to this rule.

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


Page 56

56

§ 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


Page 57

57

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 § 164.502(d) and § 164.514(c). The

reader is referred to those sections and the related

discussion in the preamble to the Privacy Rule

(65 FR 82712) and the preamble to the Privacy Modifications

(67 FR 53232 through 53234) for a full discussion of the

issues of 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


Page 58

58

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


Page 59

59

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


Page 60

60

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

specifications, 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


Page 61

61

"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

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 § 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


Page 62

62

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


Page 63

63

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


Page 64

64

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


Page 65

65

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


Page 66

66

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


Page 67

67

standard (see § 164.308(a)(1)). We emphasize, however,

that an entity implementing these standards may choose to

implement them in any order, as long as the standards are

met.

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 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


Page 68

68

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


Page 69

69

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


Page 70

70

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


Page 71

71

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


Page 72

72

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


Page 73

73

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. 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

§ 164.316(b)(2)), it is not within the scope of this final


Page 74

74

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


Page 75

75

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 § 164.306(b).

E.

Administrative Safeguards (§ 164.308)

We proposed that measures taken to comply with the


Page 76

76

rule be appropriate to protect the health information in a

covered entity's care. Most importantly, we proposed to

require that both the measures taken and documentation of

those measures be kept current, that is, reviewed and

updated periodically to continue appropriately to protect

the health information in the care of covered entities. We

would have required the documentation to be made available

to those individuals responsible for implementing the

procedure.

We proposed a number of administrative requirements

and supporting implementation features, and required

documentation for those administrative requirements and

implementation features.

In this final rule, we have placed these

administrative standards in § 164.308. We have reordered

them, deleted much of the detail of the proposed

requirements, as discussed below, and omitted two of the

proposed sets of requirements (system configuration

requirements and a requirement for a formal mechanism for

processing records) as discussed in paragraph 10 of the

discussion of § 164.308 of section III.E. of this preamble.

Otherwise, the basic elements of the administrative

safeguards are adopted in this final rule as proposed.


Page 77

77

1.

Security management process (§ 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


Page 78

78

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


Page 79

79

policy, as it duplicated requirements of the security

management and training standard.

We note that the implementation specification for a

risk analysis at § 164.308(a)(1)(ii)(A) does not

specifically require that a covered entity perform a risk

analysis often enough to ensure that its security measures

are adequate to provide the level of security required by

§ 164.306(a). In the proposed rule, an assurance of

adequate security was framed as a requirement to keep

security measures "current." We continue to believe that

security measures must remain current, and have added

regulatory language in § 164.306(e) as a more precise way

of communicating that security measures in general that

must be periodically reassessed and updated as needed.

The risk analysis implementation specification

contains other terms that merit explanation. Under

§ 164.308(a)(1)(ii)(A), the risk analysis must look at

risks to the covered entity's electronic protected health

information. A thorough and accurate risk analysis would

consider "all relevant losses" that would be expected if

the security measures were not in place. "Relevant losses"

would include losses caused by unauthorized uses and

disclosures and loss of data integrity that would be


Page 80

80

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.


Page 81

81

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

§ 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


Page 82

82

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


Page 83

83

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.


Page 84

84

2.

Assigned Security Responsibility (§ 164.308(a)(2))

We proposed that the responsibility for security be

assigned to a specific individual or organization to

provide an organizational focus and importance to security,

and that the assignment be documented. Responsibilities

would include the management and supervision of (1) the use

of security measures to protect data, and (2) the conduct

of personnel in relation to the protection of data.

In this final rule, we clarify that the final

responsibility for a covered entity's security must be

assigned to one official. The requirement for

documentation is retained, but is made part of § 164.316

below. This policy is consistent with the analogous policy

in the Privacy Rule, at 45 CFR 164.530(a), and the same

considerations apply. See 65 FR 82744 through 87445. The

same person could fill the role for both security and

privacy.

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.


Page 85

85

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.

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


Page 86

86

§ 164.308.

3.

Workforce Security (§ 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


Page 87

87

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


Page 88

88

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 § 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


Page 89

89

interpreted as an absolute requirement for background

checks. We retain the use of the term "clearance,"

however, because we believe that it more accurately conveys

the screening process intended than does the term

"authorization." We have attempted to clarify our intent

in the language of § 164.308(a)(3)(ii)(B), which now reads,

"Implement procedures to determine that the access of a

workforce member to electronic protected health information

is appropriate." The need for and extent of a screening

process is normally based on an assessment of risk, cost,

benefit, and feasibility as well as other protective

measures in place. Effective personnel screening processes

may be applied in a way to allow a range of implementation,

from minimal procedures to more stringent procedures based

on the risk analysis performed by the covered entity. So

long as the standard is met and the underlying standard of

§ 164.306(a) is met, covered entities have choices in how

they meet these standards. To clarify the intent of this

provision, we retitle the implementation specification

"Workforce clearance procedure."

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


Page 90

90

workforce and others.

Response: We have not adopted this comment in the

interest of maintaining flexibility as discussed in

§ 164.306. Restrictions would be dependent upon job

responsibilities, the amount and type of supervision

required and other factors. We note that a covered entity

should consider in this regard the applicable requirements

of the Privacy Rule (see, for example, § 164.514(d)(2)

(relating to minimum necessary requirements),

and § 164.530(c) (relating to safeguards).

d. 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


Page 91

91

be reasonable or appropriate for a small provider whose

only assistant is his or her spouse. The implementation

specifications are not mandatory, but must be addressed.

This final rule has been changed to reflect this approach

(see § 164.308(a)(3)(ii)(B)).

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 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


Page 92

92

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 § 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


Page 93

93

keys when a termination occurs.

4.

Information Access Management (§ 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 § 164.308(a)(4)(ii)(B) and (C) below, the proposed

implementation features are made addressable

specifications. We have added in § 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


Page 94

94

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 § 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 § 164.308(a)(4)(ii)(B) and


Page 95

95

(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 § 164.316), to

alleviate confusion, the word "formal" has been deleted.


Page 96

96

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 (§ 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 § 164.308(a)(5), we require training of the


Page 97

97

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 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


Page 98

98

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.


Page 99

99

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


Page 100

100

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.


Page 101

101

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 (§ 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


Page 102

102

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 § 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


Page 103

103

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.

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


Page 104

104

specifications.

7.

Contingency Plan (§ 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 commenters suggested the

contingency plan requirement be deleted. Several thought

that this aspect of the proposed regulation went beyond its

intended scope. Another believed that more discussion and

development is needed before developing regulatory guidance

on contingency plans. Others wanted this to be an optional

requirement. In contrast, one commenter requested more

guidance concerning contingency planning. Still others

wanted to require that a contingency plan be in place but

stated that we should not regulate its contents. One

comment stated that data backup, disaster recovery, and


Page 105

105

emergency mode operation should not be part of this

requirement.

Response: A contingency plan is the only way to

protect the availability, integrity, and security of data

during unexpected negative events. Data are often most

exposed in these events, since the usual security measures

may be disabled, ignored, or not observed.

Each entity needs to determine its own risk in the

event of an emergency that would result in a loss of

operations. A contingency plan may involve highly complex

processes in one processing site, or simple manual

processes in another. The contents of any given

contingency plan will depend upon the nature and

configuration of the entity devising it.

While the contingency plan standard must be met, we

agree that the proposed testing and revision implementation

feature should be an addressable implementation

specification in this final rule. Dependent upon the size,

configuration, and environment of a given covered entity,

the entity should decide if testing and revision of all

parts of a contingency plan should be done or if there are

more reasonable alternatives. The same is true for the

proposed applications and data criticality analysis


Page 106

106

implementation feature. We have revised the final rule to

reflect this approach.

b. Comment: One commenter believed that adhering to

this requirement could prove burdensome. Another stated

that testing of certain parts of a contingency plan would

be burdensome, and even infeasible, for smaller entities.

Response: Without contingency planning, a covered

entity has no assurance that its critical data could

survive an emergency situation. Recent events, such as

September 11, 2001, illustrate the importance of such

planning. Contingency planning will be scalable based

upon, among other factors, office configuration, and risk

assessment. However, in response to the scalability issue

raised by the commenter, we have made the testing and

revision implementation specification addressable (see

§ 164.308(a)(7)(ii)).

c.

Comment: Two commenters considered a 2-year

implementation time frame for this requirement inadequate

for large health plans. Another commenter stated that

implementation of measures against natural disaster would

be too big an issue for this regulation.

Response: The statute sets forth the compliance dates

for the initial standards. The statute requires that


Page 107

107

compliance with initial standards is not later than 2 years

after adoption of the standards for all covered entities

except small health plans for which the compliance date is

not later than 3 years after adoption.

The final rule calls for covered entities to consider

how natural disasters could damage systems that contain

electronic protected health information and develop

policies and procedures for responding to such situations.

We consider this to be a reasonable precautionary step to

take since in many cases the risk would be deemed to be

low.

d.

Comment: A commenter requested clarification of

the term "Emergency mode" with regard to the proposed

"Emergency mode operation plan" implementation feature.

Response: We have clarified the "Emergency mode

operations plan" to show that it only involves those

critical business processes that must occur to protect the

security of electronic protected health information during

and immediately after a crisis situation.


Page 108

108

8.

Evaluation (§ 164.308(a)(8))

We proposed that certification would be required and

could be performed internally or by an external accrediting

agency. We solicited input on appropriate mechanisms to

permit an independent assessment of compliance. We were

particularly interested in input from those engaging in

health care electronic data interchange (EDI), as well as

independent certification and auditing organizations

addressing issues of documentary evidence of steps taken

for compliance; need for, or desirability of, independent

verification, validation, and testing of system changes;

and certifications required for off-the-shelf products used

to meet the requirements of this regulation. We also

solicited comments on the extent to which obtaining

external certification would create an undue burden on

small or rural providers.

In this final rule, we require covered entities to

periodically conduct an evaluation of their security

safeguards to demonstrate and document their compliance

with the entity's security policy and the requirements of

this subpart. Covered entities must assess the need for a

new evaluation based on changes to their security

environment since their last evaluation, for example, new


Page 109

109

technology adopted or responses to newly recognized risks

to the security of their information.

a.

Comment: We received several comments that

certification should be performed externally. A larger

group of commenters preferred self-certification. The

majority of the comments, however, were to the effect that

external certification should be encouraged but not

mandated.

A number of commenters thought that mandating external

certification would create an undue financial burden,

regardless of the size of the entity being certified. One

commenter stated that external certification would not

place an undue burden on a small or rural provider.

Response: Evaluation by an external entity is a

business decision to be left to each covered entity.

Evaluation is required under § 164.308(a)(8), but a covered

entity may comply with this standard either by using its

own workforce or an external accreditation agency, which

would be acting as a business associate. External

evaluation may be too costly an option for small entities.

b.

Comment: Several commenters stated that the

certification should cover all components of the proposed

rule, not just the information systems.


Page 110

110

Response: We agree. We have revised this section to

reflect that evaluation would be both technical and

nontechnical components of security.

c.

Comment: A number of commenters expressed a

desire for the creation of certification guides or models

to complement the rule.

Response: We agree that creation of compliance

guidelines or models for different business environments

would help in the implementation and evaluation of HIPAA

security requirements and we encourage professional

associations and others to do so. We may develop technical

assistance materials, but do not intend to create

certification criteria because we do not have the resources

to address the large number of different business

environments.

d.

Comment: Some commenters asked how certification

is possible without specifying the level of risk that is

permissible.

Response: The level of risk that is permissible is

specified by § 164.306(a). How such risk is managed will

be determined by a covered entity through its security risk

analysis and the risk mitigation activities it implements

in order to ensure that the level of security required by


Page 111

111

§ 164.306 is provided.

e.

Comment: Several commenters requested creation

of a list of Federally "certified" security software and

off-the-shelf products. Several others stated that this

request was not feasible. Regarding certification of

off-the-shelf products, one commenter thought this should

be encouraged, but not mandated; several thought this would

be an impractical endeavor.

Response: While we will not assume the task of

certifying software and off-the-shelf products for the

reason described above, we have noted with interest that

other Government agencies such as the National Institute of

Standards and Technology (NIST) are working towards that

end. The health care industry is encouraged to monitor the

activity of NIST and provide comments and suggestions when

requested (see http://www.niap.nist.gov.).

f.

Comment: One commenter stated, "With HCFA's

publishing of these HIPAA standards, and their desire to

retain the final responsibility for determining violations

and imposing penalties of the statute, it also seems

appropriate for HCFA to also provide certifying services to

ensure security compliance."


Page 112

112

Response: In view of the enormous number and variety

of covered entities, we believe that evaluation can best be

handled through the marketplace, which can develop more

usable and targeted evaluation instruments and processes.

8. Business Associate Contracts or Other Arrangements

(§ 164.308(b)(1))

In the proposed rule § 142.308(a)(2) "Chain of trust"

requirement, we proposed that covered entities be required

to enter into a chain of trust partner agreement with their

business partners, in which the partners would agree to

electronically exchange data and protect the integrity,

confidentiality, and availability of the data exchanged.

This standard has been modified from the proposed

requirement to reflect, in § 164.308(b)(1) "Business

associate contracts and other arrangements," the business

associate structure put in place by the Privacy Rule.

In this final rule, covered entities must enter into a

contract or other arrangement with persons that meet the

definition of business associate in § 160.103. The covered

entity must obtain satisfactory assurances from the

business associate that it will appropriately safeguard the

information in accordance with these standards (see

§ 164.314(a)(1)).


Page 113

113

The comments received on the proposed chain of trust

partner agreements are discussed in section 2 "Business

associate contracts and other arrangements" of the

discussion of § 164.314 below.

9. Proposed Requirements Not Adopted in This Final Rule

a. Security Configuration Management

We proposed that an organization would be required to

implement measures, practices, and procedures regarding

security configuration management. They would be

coordinated and integrated with other system configuration

management practices for the security of information

systems. These would include documentation, hardware

and/or software installation and maintenance review and

testing for security features, inventory procedures,

security testing, and virus checking.

Comment: Several commenters asked that the entire

requirement be deleted. Several others asked that the

inventory and virus checking implementation features be

removed as they believe those features are not germane to

security configuration management. A number of commenters

requested that security testing be deleted because this

implementation feature is too detailed, unreasonable,

impractical, and beyond the scope of the legislation.


Page 114

114

Others stated that the testing would be very complex and

expensive. Others wanted more clarification of what we

intend by security testing, and how much would be enough.

A number of commenters asked that all of the implementation

features be deleted. Others asked that the implementation

features be made optional. Several commenters wanted to

know the scope of organizational integration required.

Several others asked if what we meant by Security

Configuration Management was change or version control.

Response: Upon review, this requirement appears

unnecessary because it is redundant of other requirements

we are adopting in this rule. A covered entity will have

addressed the activities described by the features under

this proposed requirement by virtue of having implemented

the risk analysis, risk management measures, sanction

policies, and information systems criticality review called

for under the security management process. The proposed

documentation implementation feature has been made a

separate standard (see § 164.316). As a result, the

Security Configuration Management requirement is not

adopted in this final rule.

b. Formal Mechanism for Processing Records

The proposed rule proposed requiring a formal


Page 115

115

mechanism for processing records, and documented policies

and procedures for the routine and nonroutine receipt,

manipulation, storage, dissemination, transmission, and/or

disposal of health information. This requirement has not

been adopted in the final rule.

Comment: Several commenters thought this requirement

concerned the regulation of formal procedures for how an

entity does business and stated that such procedures should

not be regulated. Others asked for additional

clarification of what is meant by this requirement. One

commenter thought the requirement too ambiguous and asked

for clarification as to whether we meant such things as

"the proper handling of storage media, databases,

transmissions," or "the clinical realm of processes."

Two commenters asked how extensive this requirement

would be and whether systems' user manuals and policies and

procedures for handling health information would suffice

and what level of detail would be expected.

Several thought this requirement could result in a

significant resource and monetary burden to develop and

maintain formal procedures. Two asked for an explanation

of the benefit to be derived from this requirement.


Page 116

116

One asked that covered entities be required to

document processes that create a security risk only and

suggested that a risk assessment would determine the need

for this documentation.

Response: We agree with the commenters that the

standard is ambiguous, and upon review, is unnecessary

because the remaining standards, for example, device and

media controls, provide adequate safeguards. Accordingly,

this requirement is not adopted in this final rule.

F. Physical Safeguards (§ 164.310)

We proposed requirements and implementation features

for documented physical safeguards to guard data integrity,

confidentiality, and availability. We proposed to require

safeguards in the following areas: assigned security

responsibility; media controls; physical access controls;

policies and guidelines on workstation use; a secure

workstation location; and security awareness training. A

number of specific implementation features were proposed

under the media controls and physical access controls

requirements.

In § 164.310 of this final rule, most of the proposed

implementation features are adopted as addressable

implementation specifications. The proposed requirements


Page 117

117

for the assigned security responsibility and security

awareness training requirements are relocated in

§ 164.308.

1. General Comments

a. Comment: Several commenters made suggestions to

modify the language to more clearly describe "Physical

safeguards."

Response: In response to comments, we have revised

the definition of "Physical safeguards" to read as follows:

"Physical safeguards are security measures to protect a

covered entity's electronic information systems and related

buildings and equipment, from natural and environmental

hazards, and unauthorized intrusion."

b.

Comment: One commenter was concerned that

electronic security systems could not be used in lieu of

physical security systems.

Response: This final rule does not preclude the use

of electronic security systems in lieu of, or in

combination with, physical security systems to meet a

"Physical safeguard" standard.

2. Facility Access Controls (§ 164.310(a)(1))

We proposed, under the "Physical access controls"

requirement, formal, documented policies and procedures for


Page 118

118

limiting physical access to an entity while ensuring that

properly authorized access is allowed. These controls

would include the following implementation features:

disaster recovery, emergency mode operation, equipment

control (into and out of site), a facility security plan,

procedures for verifying access authorizations before

physical access, maintenance records, need-to-know

procedures for personnel access, sign-in for visitors and

escort, if appropriate, and testing and revision.

In § 164.310(a)(2) below, we combine and restate these

as addressable implementation specifications. These are

contingency operations, facility security plan, access

control and validation procedures, and maintenance records.

a.

Comment: Many commenters were concerned because

the proposed language would require implementation of all

physical access control features. Other commenters were

concerned that the language did not allow entities to use

the results of their risk assessment and risk management

process to arrive at the appropriate solutions for them.

Response: We agree that implementation of all

implementation specifications may not be appropriate in all

situations. While the facility access controls standard

must be met, we agree that the implementation


Page 119

119

specifications should not be required in all circumstances,

but should be addressable. In this final rule, all four

implementation specifications are addressable.

We have also determined, based on "level of detail"

comments requesting consolidation of the list of

implementation features, that the proposed implementation

feature "Equipment control (into and out of site)" was

redundant. "Equipment control" is already covered

under the "Device and media controls" standard at

§ 164.310(d)(1). Accordingly, we have eliminated it as a

separate implementation specification.

b.

Comment: One commenter raised the issue of a

potential conflict of authority between those having access

to the data and those responsible for checking and

maintaining access controls.

Response: Any potential conflicts should be

identified, addressed, and resolved in the policies and

procedures developed according to the standards under

§ 164.308.

c. Comment: Several commenters questioned whether

"Physical Access Controls" was a descriptive phrase to

describe a technology to be used, or whether the phrase

referred to a facility.


Page 120

120

Response: We agree that the term "Physical" may be

misleading; to remove any confusion, the requirement is

reflected in this final rule as a standard titled "Facility

access controls." We believe this is a more precise term

to describe that the standard, and its associated

implementation specifications, is applicable to an entity's

business location or locations.

d.

Comment: Several commenters requested that the

disaster recovery and emergency mode operations features be

moved to "Administrative safeguards." Other commenters

recommended that disaster recovery and emergency mode

operations should be replaced by, and included in, a

"Contingency Operations" implementation feature.

Response: The "Administrative safeguards" section

addresses the contingency planning that must be done to

contend with emergency situations. The placement of the

disaster recovery and emergency mode operations

implementation specifications in the "Physical safeguards"

section is also appropriate, however, because "Physical

safeguards" defines the physical operations (processes)

that provide access to the facility to implement the

associated plans, developed under § 164.308. We agree,

however, that the term "contingency operations" better


Page 121

121

describes, and would include, disaster recovery and

emergency mode operations, and have modified the regulation

text accordingly (see § 164.310(a)(1)).

e.

Comment: Commenters were concerned about having

to address in their facility security plan the

exterior/interior security of a building when they are

one of many occupants rather than the sole occupant.

Additional commenters were concerned that the

responsibility for physical security of the building could

not be delegated to a third party when the covered entity

shares the building with other offices.

Response: The facility security plan is an

addressable implementation specification. However, the

covered entity retains responsibility for considering

facility security even where it shares space within a

building with other organizations. Facility security

measures taken by a third party must be considered and

documented in the covered entity's facility security plan,

when appropriate.

3. Workstation Use (§ 164.310(b))

We proposed policy and guidelines on workstation use

that included documented instructions/procedures

delineating the proper functions to be performed and the


Page 122

122

manner in which those functions are to be performed (for

example, logging off before leaving a workstation

unattended) to maximize the security of health information.

In this final rule, we adopt this standard.

Comment: One commenter was concerned most people may

be misled by the use of "terminal" as an example in the

definition of workstation. The concern was that the

standard only addresses "fixed location devices," while in

many instances the workstation has become a laptop

computer.

Response: For clarity, we have added the definition

of "workstation" to § 164.304 and deleted the word

"terminal" from the description of workstation use in

§ 164.310(b).

4. Workstation Security (§ 164.310(c))

We proposed that each organization would be required

to put in place physical safeguards to restrict access to

information. In this final rule, we retain the general

requirement for a secure workstation.

Comment: Comments were directed toward the example

profiled in the definition of a secure workstation

location. It was believed that what constitutes a secure

workstation location must be dependent upon the entity's


Page 123

123

risk management process.

Response: We agree that what constitutes an

appropriate solution to a covered entity's workstation

security issues is dependent on the entity’s risk analysis

and risk management process. Because many commenters

incorrectly interpreted the examples as the required and

only solution for securing the workstation location, we

have modified the regulations text description to

generalize the requirement (see § 164.310(c)). Also, for

clarity, the title "Secure workstation location" has been

changed to "Workstation security" (see also the definition

of "Workstation" at § 164.304).

5. Device and Media Controls (§ 164.310(d)(1))

We proposed that covered entities have media controls

in the form of formal, documented policies and procedures

that govern the receipt and removal of hardware and/or

software (for example, diskettes and tapes) into and out of

a facility. Implementation features would have included

"Access control," "Accountability" (tracking mechanism),

"Data backup," "Data storage," and "Disposal."

In this final rule, we adopt most of these provisions

as addressable implementation specifications and add a

specification for media re-use. We change the name from


Page 124

124

"Media controls" to "Device and media controls" to more

clearly reflect that this standard concerns hardware as

well as electronic media. The proposed "Access control"

implementation feature has been removed, as it is addressed

as part of other standards (see section III.C.12.c of this

preamble).

a.

Comment: One commenter was concerned about the

exclusion of removable media devices from examples of

physical types of hardware and/or software.

Response: The media examples used were not intended

to represent all possible physical types of hardware and/or

software. Removable media devices, although not

specifically listed, are not intended to be excluded.

b.

Comment: Comments were made that the issue of

equipment re-use or recycling of media containing mass

storage was not addressed in "Media controls."

Response: We agree that equipment re-use or recycling

should be addressed, since this equipment may contain

electronic protected health information. The "Device and

media controls" standard is accordingly expanded to include

a required implementation specification that addresses the

re-use of media (see § 164.310(d)(2)(ii)).


Page 125

125

c.

Comment: Several commenters asked for a

definition of the term "facility," as used in the proposed

"Media controls" requirement description. Commenters were

unclear whether we were talking about a corporate entity or

the physical plant.

Response: The term "facility" refers to the physical

premises and the interior and exterior of a building(s).

We have added this definition to § 164.304.

d.

Comment: Several commenters believe the "Media

controls" implementation features are too onerous and

should be deleted.

Response: While the "Device and media controls"

standard must be met, we believe, based upon further

review, that implementation of all specifications would

not be necessary in every situation, and might even be

counter-productive in some situations. For example, small

providers would be unlikely to be involved in large-scale

moves of equipment that would require systematic tracking,

unlike, for example, large health care providers or health

plans. We have, therefore, reclassified the

"Accountability and data backup" implementation

specification as addressable to provide more flexibility in

meeting the standard.


Page 126

126

e.

Comment: One commenter was concerned about the

accountability impact of audit trails on system resources

and the pace of system services.

Response: The proposed audit trail implementation

feature appears as the addressable "Accountability"

implementation specification. The name change better

reflects the purpose and intended scope of the

implementation specification. This implementation

specification does not address audit trails within systems

and/or software. Rather it requires a record of the

actions of a person relative to the receipt and removal of

hardware and/or software into and out of a facility that

are traceable to that person. The impact of maintaining

accountability on system resources and services will depend

upon the complexity of the mechanism to establish

accountability. For example, the appropriate mechanism for

a given entity may be manual, such as receipt and removal

restricted to specific persons, with logs kept.

Maintaining accountability in such a fashion should have a

minimal, if any, effect on system resources and services.

f.

Comment: A commenter was concerned about the

resource expenditure (system and fiscal) for total e-mail

backup and wanted a clarification of the extensiveness of


Page 127

127

data backup.

Response: The data an entity needs to backup, and

which operations should be used to carry out the backup,

should be determined by the entity's risk analysis and risk

management process. The data backup plan, which is part of

the required contingency plan (see § 164.308(a)(7)(ii)(A)),

should define exactly what information is needed to be

retrievable to allow the entity to continue business "as

usual" in the face of damage or destruction of data,

hardware, or software. The extent to which e-mail backup

would be needed would be determined through that analysis.

G. Technical Safeguards (§ 164.312)

We proposed five technical security services

requirements with supporting implementation features:

Access control; Audit controls; Authorization control; Data

authentication; and Entity authentication. We also

proposed specific technical security mechanisms for data

transmitted over a communications network,

Communications/network controls with supporting

implementation features; Integrity controls; Message

authentication; Access controls; Encryption; Alarm; Audit

trails; Entity authentication; and Event reporting.

In this final rule, we consolidate these provisions


Page 128

128

into § 164.312. That section now includes standards

regarding access controls, audit controls, integrity

(previously titled data authentication), person or entity

authentication, and transmission security. As discussed

below, while certain implementation specifications are

required, many of the proposed security implementation

features are now addressable implementation specifications.

The function of authorization control has been incorporated

into the information access management standard under

§ 164.308, Administrative safeguards.

1. Access Control (§ 164.312(a)(1))

In the proposed rule, we proposed to require that the

access controls requirement include features for emergency

access procedures and provisions for context-based,

role-based, and/or user-based access; we also proposed the

optional use of encryption as a means of providing access

control. In this final rule, we require unique user

identification and provision for emergency access

procedures, and retain encryption as an addressable

implementation specification. We also make "Automatic

logoff" an addressable implementation specification.

"Automatic logoff" and "Unique user identification" were

formerly implementation features under the proposed "Entity


Page 129

129

authentication" (see § 164.312(d)).

a. Comment: Some commenters believe that in

specifying "Context," "Role," and "User" based controls,

use of other controls would effectively be excluded, for

example, "Partition rule-based access controls," and the

development of new access control technology.

Response: We agree with the commenters that other

types of access controls should be allowed. There was no

intent to limit the implementation features to the named

technologies and this final rule has been reworded to make

it clear that use of any appropriate access control

mechanism is allowed. Proposed implementation features

titled "Context-based access," "Role-based access," and

"User-based access" have been deleted and the access

control standard at § 164.312(a)(1) states the general

requirement.

b. Comment: A large number of comments were received

objecting to the identification of "Automatic logoff" as a

mandatory implementation feature. Generally the comments

asked that we not be so specific and allow other forms of

inactivity lockout, and that this type of feature be made

optional, based more on the particular configuration in use

and a risk assessment/analysis.


Page 130

130

Response: We agree with the comments that mandating

an automatic logoff is too specific. This final rule has

been written to clarify that the proposed implementation

feature of automatic logoff now appears as an addressable

access control implementation specification and also

permits the use of an equivalent measure.

c. Comment: We received comments asking that

encryption be deleted as an implementation feature and

stating that encryption is not required for "data at rest."

Response: The use of file encryption is an acceptable

method of denying access to information in that file.

Encryption provides confidentiality, which is a form of

control. The use of encryption, for the purpose of access

control of data at rest, should be based upon an entity's

risk analysis. Therefore, encryption has been adopted as

an addressable implementation specification in this final

rule.

d. Comment: We received one comment stating that the

proposed implementation feature "Procedure for emergency

access," is not access control and recommending that

emergency access be made a separate requirement.

Response: We believe that emergency access is a

necessary part of access controls and, therefore, is


Page 131

131

properly a required implementation specification of the

"Access controls" standard. Access controls will still be

necessary under emergency conditions, although they may be

very different from those used in normal operational

circumstances. For example, in a situation when normal

environmental systems, including electrical power, have

been severely damaged or rendered inoperative due to a

natural or man-made disaster, procedures should be

established beforehand to provide guidance on possible ways

to gain access to needed electronic protected health

information.

2. Audit Controls (§ 164.312(b))

We proposed that audit control mechanisms be put in

place to record and examine system activity. We adopt this

requirement in this final rule.

a. Comment: We received a comment stating that

"Audit controls" should be an implementation feature rather

than the standard, and suggesting that we change the title

of the standard to "Accountability," and provide additional

detail to the audit control implementation feature.

Response: We do not adopt the term "Accountability"

in this final rule because it is not descriptive of the

requirement, which is to have the capability to record and


Page 132

132

examine system activity. We believe that it is appropriate

to specify audit controls as a type of technical safeguard.

Entities have flexibility to implement the standard in a

manner appropriate to their needs as deemed necessary by

their own risk analyses. For example, see NIST Special

Publication 800-14, Generally Accepted Principles and

Practices for Securing Information Technology Systems and

NIST Special Publication 800-33, Underlying Technical

Models for Information Technology Security.

b.

Comment: One commenter recommended that this

final rule state that audit control mechanisms should be

implemented based on the findings of an entity's risk

assessment and risk analysis. The commenter asserted that

audit control mechanisms should be utilized only when

appropriate and necessary and should not adversely affect

system performance.

Response: We support the use of a risk assessment and

risk analysis to determine how intensive any audit control

function should be. We believe that the audit control

requirement should remain mandatory, however, since it

provides a means to assess activities regarding the

electronic protected health information in an entity's

care.


Page 133

133

c.

Comment: One commenter was concerned about the

interplay of State and Federal requirements for auditing of

privacy data and requested additional guidance on the

interplay of privacy rights, laws, and the expectation for

audits under the rule.

Response: In general, the security standards will

supercede any contrary provision of State law. Security

standards in this final rule establish a minimum level of

security that covered entities must meet. We note that

covered entities may be required by other Federal law to

adhere to additional, or more stringent security measures.

Section 1178(a)(2) of the statute provides several

exceptions to this general rule. With regard to protected

health information, the preemption of State laws and the

relationship of the Privacy Rule to other Federal laws is

discussed in the Privacy Rule beginning at 65 FR 82480; the

preemption provisions of the rule are set out at

45 CFR part 160, subpart B.

It should be noted that although the Privacy Rule does

not incorporate a requirement for an "audit trail"

function, it does call for providing an accounting of

certain disclosures of protected health information to an

individual upon request. There has been a tendency to


Page 134

134

assume that this Privacy Rule requirement would be

satisfied via some sort of process involving audit trails.

We caution against assuming that the Security Rule's

requirement for an audit capability will satisfy the

Privacy Rule's requirement regarding accounting for

disclosures of protected health information. The two rules

cover overlapping, but not identical information. Further,

audit trails are typically used to record uses within an

electronic information system, while the Privacy Rule

requirement for accounting applies to certain disclosures

outside of the covered entity (for example, to public

health authorities).

3. Integrity (§ 164.312(c)(1))

We proposed under the "Data authentication"

requirement, that each organization be required to

corroborate that data in its possession have not been

altered or destroyed in an unauthorized manner and provided

examples of mechanisms that could be used to accomplish

this task. We adopt the proposed requirement for data

authentication in the final rule as an addressable

implementation specification "Mechanism to authenticate

data," under the "Integrity" standard.


Page 135

135

a.

Comment: We received a large number of comments

requesting clarification of the "Data authentication"

requirement. Many of these comments suggested that the

requirement be called "Data integrity" instead of "Data

authentication." Others asked for guidance regarding just

what "data" must be authenticated. A significant number of

commenters indicated that this requirement would put an

extraordinary burden on large segments of the health care

industry, particularly when legacy systems are in use.

Requests were received to make this an "optional"

requirement, based on an entity's risk assessment and

analysis.

Response: We adopt the suggested "integrity"

terminology because it more clearly describes the intent of

the standard. We retain the meaning of the term "Data

authentication" under the addressable implementation

specification "Mechanism to authenticate data," and provide

an example of a potential means to achieve data integrity.

Error-correcting memory and magnetic disc storage are

examples of the built-in data authentication mechanisms

that are ubiquitous in hardware and operating systems

today. The risk analysis process will address what data

must be authenticated and should provide answers


Page 136

136

appropriate to the different situations faced by the

various health care entities implementing this regulation.

Further, we believe that this standard will not prove

difficult to implement, since there are numerous techniques

available, such as processes that employ digital signature

or check sum technology to accomplish the task.

b.

Comment: We received numerous comments suggesting

that "Double keying" be deleted as a viable "Data

authentication" mechanism, since this practice was

generally associated with the use of punched cards.

Response: We agree that the process of "Double

keying" is outdated. This final rule omits any reference

to "Double keying."

4. Person or Entity Authentication (§ 164.312(d))

We proposed that an organization implement the

requirement for "Entity authentication", the corroboration

that an entity is who it claims to be. "Automatic logoff"

and "Unique user identification" were specified as

mandatory features, and were to be coupled with at least

one of the following features: (1) a "biometric"

identification system; (2) a "password" system; (3) a

"personal identification number"; and (4) "telephone

callback," or a "token" system that uses a physical device


Page 137

137

for user identification.

In this final rule, we provide a general requirement

for person or entity authentication without the specifics

of the proposed rule.

Comment: We received comments from a number of

organizations requesting that the implementation features

for entity authentication be either deleted in their

entirety or at least be made optional. On the other hand,

comments were received requesting that the use of digital

signatures and soft tokens be added to the list of

implementation features.

Response: We agree with the commenters that many

different mechanisms may be used to authenticate entities,

and this final rule now reflects this fact by not

incorporating a list of implementation specifications, in

order to allow covered entities to use whatever is

reasonable and appropriate. "Digital signatures" and "soft

tokens" may be used, as well as many other mechanisms, to

implement this standard.

The proposed mandatory implementation feature, "Unique

user identification," has been moved from this standard and

is now a required implementation specification under

"Access control" at § 164.312(a)(1). "Automatic logoff"


Page 138

138

has also been moved from this standard to the "Access

control" standard and is now an addressable implementation

specification.

5.

Transmission Security (§ 164.312(e)(1))

Under "Technical Security Mechanisms to Guard Against

Unauthorized Access to Data that is Transmitted Over a

Communications Network," we proposed that

"Communications/network controls" be required to protect

the security of health information when being transmitted

electronically from one point to another over open

networks, along with a combination of mandatory and

optional implementation features. We proposed that some

form of encryption must be employed on "open" networks such

as the internet or dial-up lines.

In this final rule, we adopt integrity controls and

encryption, as addressable implementation specifications.

a.

Comment: We received a number of comments asking

for overall clarification as well as a definition of terms

used in this section. A definition for the term "open

networks" was the most requested action, but there was a

general expression of dislike for the manner in which we

approached this section, with some comments suggesting that

the entire section be rewritten. A significant number of


Page 139

139

comments were received on the question of encryption

requirements when dial-up lines were to be employed as a

means of connectivity. The overwhelming majority strongly

urged that encryption not be mandatory when using any

transmission media other than the Internet, but rather be

considered optional based on individual entity risk

assessment/analysis. Many comments noted that there are

very few known breaches of security over dial-up lines and

that nonjudicious use of encryption can adversely affect

processing times and become both financially and

technically burdensome. Only one commenter suggested that

"most" external traffic should be encrypted.

Response: In general, we agree with the commenters

who asked for clarification and revision. This final

rule has been significantly revised to reflect a much

simpler and more direct requirement. The term

"Communications/network controls" has been replaced with

"Transmission security" to better reflect the requirement

that, when electronic protected health information is

transmitted from one point to another, it must be protected

in a manner commensurate with the associated risk.

We agree with the commenters that switched, point-to-

point connections, for example, dial-up lines, have a very


Page 140

140

small probability of interception.

Thus, we agree that encryption should not be a

mandatory requirement for transmission over dial-up lines.

We also agree with commenters who mentioned the financial

and technical burdens associated with the employment of

encryption tools. Particularly when considering situations

faced by small and rural providers, it became clear that

there is not yet available a simple and interoperable

solution to encrypting e-mail communications with patients.

As a result, we decided to make the use of encryption in

the transmission process an addressable implementation

specification. Covered entities are encouraged, however,

to consider use of encryption technology for transmitting

electronic protected health information, particularly over

the internet.

As business practices and technology change, there may

arise situations where electronic protected health

information being transmitted from a covered entity would

be at significant risk of being accessed by unauthorized

entities. Where risk analysis showed such risk to be

significant, we would expect covered entities to encrypt

those transmissions, if appropriate, under the addressable

implementation specification for encryption.


Page 141

141

We do not use the term "open network" in this final

rule because its meaning is too broad. We include as an

addressable implementation specification the requirement

that transmissions be encrypted when appropriate based on

the entity's risk analysis.

b.

Comment: We received comments requesting that the

implementation features be deleted or made optional. Three

commenters asked that the requirement for an alarm be

deleted.

Response: This final rule has been revised to reflect

deletion of the following implementation features: (1) the

alarm capability; (2) audit trail; (3) entity

authentication; and (4) event reporting. These features

were associated with a proposed requirement for

"Communications/network controls" and have been deleted

since they are normally incorporated by telecommunications

providers as part of network management and control

functions that are included with the provision of network

services. A health care entity would not expect to be

responsible for these technical telecommunications

features. "Access controls" has also been deleted from the

implementation features since the consideration of the use

of encryption will satisfy the intent of this feature. We


Page 142

142

retain as addressable implementation specifications two

features: (1) "integrity controls" and "encryption".

"Message authentication" has been deleted as an

implementation feature because the use of data

authentication codes (called for in the "integrity

controls" implementation specification) satisfies the

intent of "Message authentication."

c.

Comment: A number of comments were received

asking that this final rule establish a specific (or at

least a minimum) cryptographic algorithm strength. Others

recommended that the rule not specify an encryption

strength since technology is changing so rapidly. Several

commenters requested guidelines and minimum encryption

standards for the Internet. Another stated that, since an

example was included (small or rural providers for

example), the government should feel free to name a

specific encryption package. One commenter stated that the

requirement for encryption on the Internet should reference

the "CMS Internet Security Policy."

Response: We remain committed to the principle of

technology neutrality and agree with the comment that

rapidly changing technology makes it impractical and

inappropriate to name a specific technology. Consistent


Page 143

143

with this principle, specification of an algorithm strength

or specific products would be inappropriate. Moreover,

rapid advances in the success of "brute force"

cryptanalysis techniques suggest that any minimum

specification would soon be outmoded. We maintain that it

is much more appropriate for this final rule to state a

general requirement for encryption protection when

necessary and depend on covered entities to specify

technical details, such as algorithm types and strength.

Because "CMS Internet Security Policy" is the policy of a

single organization and applies only to information sent to

CMS, and not between all covered entities, we have not

referred to it here.

d. Comment: The proposed definition of "Integrity

controls" generated comments that asked that the word

"validity" be changed to "Integrity." Commenters were

concerned about the ability of an entity to ensure that

information was "valid."

Response: We agree with the commenters about the

meaning of the word "validity" in the context of the

proposed definition of "Integrity controls." We have named

"integrity controls" as an implementation specification in

this final rule to require mechanisms to ensure that


Page 144

144

electronically transmitted information is not improperly

modified without detection (see § 164.312(c)(1)).

e.

Comment: Three commenters asked for clarification

and guidance regarding the unsolicited electronic receipt

of health information in an unsecured manner, for example,

when the information was submitted by a patient via e-mail

over the Internet. Commenters asked for guidance as to

what was their obligation to protect data received in this

manner.

Response: The manner in which electronic protected

health information is received by a covered entity does not

affect the requirement that security protection must

subsequently be afforded to that information by the covered

entity once that information is in possession of the

covered entity.

6.

Proposed Requirements Not Adopted in This Final Rule

a. Authorization

Control

We proposed, under "Technical Security Services to

Guard Data Integrity, Confidentiality, and Availability,"

that a mechanism be required for obtaining consent for the

use and disclosure of health information using either

"Role-based access" or "User-based access" controls. In

this final rule, we do not adopt this requirement.


Page 145

145

Comment: We received a large number of comments

regarding use of the word "consent." It was pointed out

that this could be construed to mean patient consent to the

use or disclosure of patient information, which would make

this a privacy issue, rather than one of security. Other

comments suggested deletion of the requirement in its

entirety. We received a comment asking for clarification

about the distinction between "Access control" and

"Authorizations."

Response: These requirements were intended to address

authorization of workforce members and others for the use

and disclosure of health information, not patient consent.

Upon reviewing the differences between "Access control" and

"Authorization control," we found it to be unnecessary to

retain "Authorization control" as a separate requirement.

Both the access control and the authorization control

proposed requirements involved implementation of types of

automated access controls, that is, role-based access and

user-based access. It can be argued that the process of

managing access involves allowing and restricting access to

those individuals that have been authorized to access the

data. The intent of the proposed authorization control

implementation feature is now incorporated in the access


Page 146

146

authorization implementation specification under the

information access management standard in § 164.308(a)(4).

Under the information access management standard, a covered

entity must implement, if appropriate and reasonable to its

situation, policies and procedures first to authorize a

person to access electronic protected health information

and then to actually establish such access. These

policies and procedures will enable entities to follow the

Privacy Rule minimum necessary requirements, which provide

when persons should have access to information.

H. Organizational Requirements (§ 164.314)

We proposed that each health care clearinghouse must

comply with the security standards to ensure all health

information and activities are protected from unauthorized

access. If the clearinghouse is part of a larger

organization, then unauthorized access by the larger

organization must be prevented. We also proposed that

parties processing data through a third party would be

required to enter into a chain of trust partner agreement,

a contract in which the parties agree to electronically

exchange data and to protect the transmitted data in

accordance with the security standards.


Page 147

147

In this final rule, we have adopted the concepts of

hybrid and affiliated entities, as previously defined in

§ 164.504, and now defined in § 164.103, and business

associates as defined in § 160.103, to be consistent with

the Privacy Rule. General organizational requirements

related to affiliated covered entities and hybrid entities

are now contained in a new § 164.105. The proposed chain

of trust partner agreement has been replaced by the

standards for business associate contracts or other

arrangements and the standards for group health plans.

Consistent with the statute and the policy of the Privacy

Rule, this final rule does not require noncovered entities

to comply with the security standards.

1. Health Care Clearinghouses

The proposed rule proposed that if a health care

clearinghouse were part of a larger organization, it would

be required to ensure that all health information

pertaining to an individual is protected from unauthorized

access by the larger organization; this statement closely

tracked the statutory language in section 1173(d)(1)(B) of

the Act. Since the point of the statutory language is to

ensure that health care information in the possession of a

health care clearinghouse is not inappropriately accessed


Page 148

148

by the larger organization of which it is a part, this

final rule implements the statutory language through the

information access management provision of

§ 164.308(a)(4)(ii)(A).

The final rule, at § 164.105, makes the health care

component and affiliated entity standards of the Privacy

Rule applicable to the security standards. Therefore, we

have not changes those standards substantively. In

pertaining to the Privacy Rule, we have simply moved them

to a new location in part 164. Any differences between

§ 164.105 and § 164.504(a) through (d) reflects the

addition of requirements specific to the security

standards.

The health care component approach was developed in

response to extensive comment received principally on the

Privacy Rule. See 65 FR 82502 through 82503 and 82637

through 82640 for a discussion of the policy concerns

underlying the health care component approach. Since the

security standards are intended to support the protection

of electronic information protected by the Privacy Rule, it

makes sense to incorporate organizational requirements that

parallel those required of covered entities by the Privacy

Rule. This policy will also minimize the burden of


Page 149

149

complying with both rules.

a.

Comment: Relative to the following preamble

statement (63 FR 43258): "If the clearinghouse is part of

a larger organization, then security must be imposed to

prevent unauthorized access by the larger organization."

One commenter asked what is considered to be "the larger

organization." For example, if a clearinghouse function

occurs in a department of a larger business entity, will

the regulation cover all internal electronic communication,

such as e-mail, within the larger business and all external

electronic communication, such as e-mail with its owners?

Response: The "larger organization" is the overall

business entity that a clearinghouse would be part of.

Under the Security Rule, the larger organization must

assure that the health care clearinghouse function has

instituted measures to ensure only that electronic

protected health information that it processes is not

improperly accessed by unauthorized persons or other

entities, including the larger organization. Internal

electronic communication within the larger organization

will not be covered by the rule if it does not involve the

clearinghouse, assuming that it has designated health care

components, of which the health care clearinghouse is one.


Page 150

150

External communication must be protected as sent by the

clearinghouse, but need not be protected once received.

b.

Comment: One commenter asked that the first

sentence in § 142.306(b) of the proposed rule, "If a health

care clearinghouse is part of a larger organization, it

must assure all health information is protected from

unauthorized access by the larger organization" be expanded

to read, "If a health care clearinghouse or any other

health care entity is part of a larger organization . . ."

Response: The Act specifically provides, at section

1173(d)(1)(B), that the Secretary must adopt standards to

ensure that a health care clearinghouse, if part of a

larger organization, has policies and security procedures

to protect information from unauthorized access by the

larger organization.

Health care providers and health plans are often part

of larger organizations that are not themselves health care

providers or health plans. The security measures

implemented by health plans and covered health care

providers should protect electronic protected health

information in circumstances such as the one identified by

the commenter. Therefore, we agree with the comment that

the requirement should be expanded as suggested by the


Page 151

151

commenter. In this final rule, those components of a

hybrid entity that are designated as health care components

must comply with the security standards and protect against

unauthorized access with respect to the other components of

the larger entity in the same way as they must deal with

separate entities.

2.

Business Associate Contracts and Other Arrangements

We proposed that parties processing data through a

third party would be required to enter into a chain of

trust partner agreement, a contract in which the parties

agree to electronically exchange data and to protect the

transmitted data. This final rule narrows the scope of

agreements required. It essentially tracks the provisions

in § 164.502(e) and § 164.504(e) of the Privacy Rule,

although appropriate modifications have been made in this

rule to the required elements of the contract.

In this final rule, a contract between a covered

entity and a business associate must provide that the

business associate must--(1) implement safeguards that

reasonably and appropriately protect the confidentiality,

integrity, and availability of the electronic protected

health information that it creates, receives, maintains, or

transmits on behalf of the covered entity; (2) ensure that


Page 152

152

any agent, including a subcontractor, to whom it provides

this information agrees to implement reasonable and

appropriate safeguards; (3) report to the covered entity

any security incident of which it becomes aware; (4) make

its policies and procedures, and documentation required by

this subpart relating to such safeguards, available to the

Secretary for purposes of determining the covered entity's

compliance with this subpart; and (5) authorize termination

of the contract by the covered entity if the covered entity

determines that the business associate has violated a

material term of the contract.

When a covered entity and its business associate are

both governmental entities, an "other arrangement" is

sufficient. The covered entity is in compliance with this

standard if it enters into a memorandum of understanding

with the business associate that contains terms that

accomplish the objectives of the above-described business

associate contract. However, the covered entity may omit

from this memorandum the termination authorization required

by the business associate contract provisions if this

authorization is inconsistent with the statutory

obligations of the covered entity or its business

associate. If other law (including regulations adopted by


Page 153

153

the covered entity or its business associate) contains

requirements applicable to the business associate that

accomplish the objectives of the above-described business

associate contract, a contract or agreement is not

required. If a covered entity enters into other

arrangements with another governmental entity that is a

business associate, such arrangements may omit provisions

equivalent to the termination authorization required by the

business associate contract, if inconsistent with the

statutory obligation of the covered entity or its business

associate.

If a business associate is required by law to perform

a function or activity on behalf of a covered entity or to

provide a service described in the definition of business

associate in § 160.103 of this subchapter to a covered

entity, the covered entity may permit the business

associate to receive, create, maintain, or transmit

electronic protected health information on its behalf to

the extent necessary to comply with the legal mandate

without meeting the requirements of the above-described

business associate contract, provided that the covered

entity attempts in good faith to obtain satisfactory

assurances as required by the above described business


Page 154

154

associate contract and documents the attempt and the

reasons that these assurances cannot be obtained.

We have added a standard for group health plans that

parallels the provisions of the Privacy Rule. It became

apparent during the course of the security and privacy

rulemaking that our original chain of trust approach was

both overly broad in scope and failed to address

appropriately the circumstances of certain covered

entities, particularly the ERISA group health plans. These

latter considerations and the solutions arrived at in the

Privacy Rule are described in detail in the Privacy Rule at

65 FR 82507 through 82509. Because the purpose of the

security standards is in part to reinforce privacy

protections, it makes sense to align the organizational

policies of the two rules. This decision should also make

compliance less burdensome for covered entities than would

a decision to have different organizational requirements

for the two sets of rules.

Thus, we have added at § 164.314(b) a standard for

group health plan that tracks the standard at § 164.504(f)

very closely. The purpose of these provisions is to ensure

that, except when the electronic protected health

information disclosed to a plan sponsor is summary health


Page 155

155

information or enrollment or disenrollment information as

provided for by § 164.504(f), group health plan documents

provide that the plan sponsor will reasonably and

appropriately safeguard electronic protected health

information created, received, maintained or transmitted to

or by the plan sponsor on behalf of the group health plan.

The plan documents of the group health plan must be amended

to incorporate provisions to require the plan sponsor to

implement reasonable and appropriate safeguards to protect

the confidentiality, integrity, and availability of the

electronic protected health information that it creates,

receives, maintains, or transmits on behalf of the group

health plan; ensure that the adequate separation required

by § 164.504(f)(2)(iii) is supported by reasonable and

appropriate security measures; ensure that any agents,

including a subcontractor, to whom it provides this

information agrees to implement reasonable and appropriate

safeguards to protect the information; report to the group

health plan any security incident of which it becomes

aware; and make its policies and procedures and

documentation relating to these safeguards available to the

Secretary for purposes of determining the group health

plan's compliance with this subpart.


Page 156

156

a.

Comment: Several commenters expressed confusion

concerning the applicability of proposed § 142.104 to

security.

Response: The proposed preamble included language

generally applicable to most of the proposed standards

under HIPAA. Proposed § 142.104 concerned general

requirements for health plans relative to processing

transactions. We proposed that plans could not refuse to

conduct a transaction as a standard transaction, or delay

or otherwise adversely affect a transaction on the grounds

that it was a standard transaction; health information

transmitted and received in connection with a transaction

must be in the form of standard data elements; and plans

conducting transactions through an agent must ensure that

the agent met all the requirements that applied to the

health plan. Except for the statement that a plan's agent

("business associate" in the final rule) must meet the

requirements (which would include security) that apply to

the health plan, this proposed section did not pertain to

the security standards and was addressed in the Transaction

Rule.

b.

Comment: The majority of comments concerned

proposed rule language stating "the same level of security


Page 157

157

will be maintained at all links in the chain . . ."

Commenters believed the current language will have an

adverse impact on one of the security standard's basic

premises, which is scalability. It was requested that the

language be changed to indicate that, while appropriate

security must be maintained, all partners do not need to

maintain the same level of security.

A number of commenters expressed some confusion

concerning their responsibility for the security of

information once it has passed from their control to their

trading partner's control, and so on down the trading

partner chain. Requests were made that we clarify that

chain of trust partner agreements were really between two

parties, and that, if a trading partner agreement has been

entered into, any given partner would not be responsible,

or liable, for the security of data once it is out of his

or her control.

In line with this concern, several commenters were

concerned that they would have some responsibility to

ensure the level of security maintained by their trading

partner.

Several commenters believe a chain of trust partner

agreement should not be a security requirement. One


Page 158

158

commenter stated that because covered entities must already

conform to the regulation requirements, a "chain of trust"

agreement does not add to overall security. Compliance

with the regulation should be sufficient.

Response: We believe the commenters are correct that

the rule as proposed would--(1) not allow for scalability;

and (2) would lead an entity to believe it is responsible,

and liable, for making sure all entities down the line

maintain the same level of security. The confusion here

seems to come from the phrase "same level of security."

Our intention was that each trading partner would maintain

reasonable and appropriate safeguards to protect the

information. We did not mean that partners would need to

implement the same security technology or measures and

procedures.

We have replaced the proposed "Chain of trust"

standard with a standard for "Business associate contracts

and other arrangements."

When another entity is acting as a business associate

of a covered entity, we require the covered entity to

require the other entity to protect the electronic

protected health information that it creates, receives,

maintains or transmits on the covered entity's behalf. The


Page 159

159

level of security afforded particular electronic protected

health information should not decrease just because the

covered entity has made the business decision to entrust a

business associate with using or disclosing that

information in connection with the performance of certain

functions instead of doing those functions itself. Thus,

the rule below requires covered entities to require their

business associates to implement certain safeguards and

take other measures to ensure that the information is

safeguarded (see § 164.308(b)(1) and § 164.314(a)(1)).

The specific requirements of § 164.314(a)(1) are drawn

from the analogous requirements at 45 CFR 164.504(e) of the

Privacy Rule, although they have been adapted to reflect

the objectives and context of the security standards.

Compare, in particular, 45 CFR 164.504(e)(2)(ii) with

§ 164.314(a)(1). We have not imported all of the

requirements of 45 CFR 164.504(e), however, as many have no

clear analog in the security context (see, for example,

45 CFR 164.504(e)(2)(i) regarding permitted and required

uses and disclosures made by a business associate). HHS

had previously committed to reconciling its security

and privacy policies regarding business associates

(see 65 FR 82643). The close relationship of many of the


Page 160

160

organizational requirements in section § 164.314 with the

analogous requirements of the Privacy Rule should

facilitate the implementation and coordination of security

and privacy policies and procedures by covered entities.

In contrast, when another entity is not acting as a

business associate for the covered entity, but rather is

acting in the capacity of some other sort of trading

partner, we do not require the covered entity to require

the other entity to adopt particular security measures, as

previously proposed. This policy is likewise consistent

with the general approach of the Privacy Rule (see the

discussion in the Privacy Rule at 65 FR 82476). The

covered entity is free to negotiate security arrangements

with its non-business associate trading partners, but this

rule does not require it to do so.

A similar approach underlies § 164.314(b) below.

These provisions are likewise drawn from, and intended to

support, the analogous privacy protections provided for by

45 CFR 164.504(f) (see the discussion of § 164.504(f) of

the Privacy Rule at 65 FR 82507 through 82509, and 82646

through 82648). As with the business associate contract

provisions, however, they are imported and adapted only to

the extent they make sense in the security context. Thus,


Page 161

161

for example, the requirement at § 164.504(f)(2)(ii)(C)

prohibits the plan documents from permitting disclosure of

protected health information to the plan sponsor for

employment-related purposes. As this prohibition goes

entirely to the permissibility of a particular type of

disclosure, it has no analog in § 164.314(b).

c.

Comment: Several commenters stated that if

security features are determined by agreements established

between "trading partners," as stated in the proposed

regulations, there should be some guidelines or boundaries

for those agreements so that extreme or unusual provisions

are not permitted.

Response: This final rule sets a baseline, or minimum

level, of security measures that must be taken by a covered

entity and stipulates that a business associate must also

implement reasonable and appropriate safeguards. This

final rule does not, however, prohibit a covered entity

from employing more stringent security measures or from

requiring a business associate to employ more stringent

security measures. A covered entity may determine that, in

order to do business with it, a business associate must

also employ equivalent measures. This would be a business

decision and would not be governed by the provisions of


Page 162

162

this rule. Security mechanisms relative to the

transmission of electronic protected health information

between entities may need to be agreed upon by both parties

in order to successfully complete the transmission.

However, the determination of the specific transmission

mechanisms and the specific security features to be

implemented remains a business decision.

d.

Comment: Several commenters asked whether

existing contracts could be used to meet the requirement

for a trading partner agreement, or does the rule require

entry into a new contract specific to this purpose. Also,

the commenters want to know about those whose working

agreements do not involve written contractual agreement: