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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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.

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

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.

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

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

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

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.

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

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

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

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:

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

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

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,

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

71