HIPAA Security Rule


Summary:


Thursday, February 20, 2003

Part II

Department of Health and Human Services

Office of the Secretary

 

 

 

 

45 CFR Parts 160, 162, and 164

Health Insurance Reform: Security standards;

Final RuleVerDate Jan<31>2003 17:54 Feb 19, 2003

[CMS–0049–F]RIN 0938–AI57

Health Insurance Reform: Security standards

AGENCY:Centers for Medicare & Medicaid Services (CMS),HHS.

ACTION: Final rule.


Table of Contents

SUMMARY. 5

SECTION I Background. 6

SECTION II General Overview of the Provisions of the Proposed Rule. 7

SECTION III Analysis of, and Responses to, Public Comments on the Proposed Rule. 8

A.     General Issues. 9

Security Rule and Privacy Rule Distinctions. 9

Level of Detail 9

Implementation Specifications. 9

Examples. 11

B.     Applicability (§164.302) 12

C.    Transition to the Final Rule. 15

Health Care and Medical Care (§160.103) 17

Health Information and Individually Identifiable Health Information 160.103) 17

Protected Health Information (§160.103) 18

Breach (§164.304) 18

Facility (§164.304) 18

Security Incident (§164.304) 18

System (§164.304) 18

Workstation (§164.304) 18

Definitions Not Adopted. 18

D.    General Rules (§164.306) 20

Scope of Health Information Coveredby the Rule (§164.306 (a) ) 21

Technology-Neutral standards. 23

Miscellaneous Comments. 23

E.     Administrative Safeguards (§164.308) 28

1. Security Management Process (§164.308 (a) (1) (i) ) 28

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

3. Workforce Security (§164.308 (a) (3) (i) ) 30

4. Information Access Management (§164.308 (a) (4) ) 32

5. Security Awareness and Training (§164.308 (a) (5) (i) ) 33

6. Security Incident Procedures (§164.308 (a) (6) ) 34

7. Contingency Plan (§164.308 (a) (7) (i) ) 35

8. Evaluation (§164.308 (a) (8) ) 36

9. Business Associate Contracts or Other Arrangements (§164.308 (b) (1) ) 37

10. Proposed Requirements Not Adopted in This Final Rule. 37

a. Security Configuration Management 37

F.     Physical Safeguards (§164.310) 39

1. General Comments. 39

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

3. Workstation Use (§164.310 (b) ) 40

4. Workstation Security (§164.310 (c) ) 40

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

G.    Technical Safeguards (§164.312) 42

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

2. Audit Controls (§164.312 (b) ) 43

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

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

5. Transmission Security (§164.312 (e) (1) ) 44

6. Proposed Requirements Not Adoptedin This Final Rule. 46

Authorization Control 46

H.    Organizational Requirements (§164.314) 47

1. Health Care Clearinghouses. 47

2. Business Associate Contracts and Other Arrangements. 48

I.      Policies and Procedures and Documentation Requirements (§164.316) 52

J.     Compliance Dates for Initial Implementation (§164.318) 53

K.     Appendix. 55

L.     Miscellaneous Issues. 56

1. Preemption. 56

2. Enforcement 56

M.         Proposed Impact Analysis. 58

Section IV Provisions of the Final Regulation. 61

Section V Collection of Information Requirements. 62

Section 164.306 Security standards: General Rules. 62

Section 164.308 AdministrativeSafeguards. 62

Section 164.310 Physical Safeguards. 62

Section 164.314 OrganizationalRequirements. 63

Section 164.316 Policies and Procedures and Documentation Requirements. 63

Section VI Regulatory Impact Analysis. 64

A.     Overall Impact 64

B.     Anticipated Effects. 66

C.    Changes from the 1998 Impact Analysis. 67

Changes in Technology. 67

Synchronizing standards. 67

Relationship to Privacy standards. 67

Sensitivity to Security Concerns as aResult of September 11, 2001. 68

D.    Guiding Principles for “Standards Selection” 69

E.     Affected Entities. 70

1. Health Care Providers. 70

2. Health Plans. 70

3. Clearinghouses. 70

4. System Vendors. 70

F.     Factors in Establishing the SecurityStandard. 71

1. General Effect 71

2. Complexity of Conversion. 71

3. Cost of Conversion. 71

Section VII Federalism.. 73

A.     PART 160—GENERAL ADMINISTRATIVE REQUIREMENTS.. 74

§160.103 Authority Citation. 74

§160.103 Definitions. 74

B.     PART 162—ADMINISTRATIVE REQUIREMENTS.. 76

§162. 103 Authority citation. 76

§162. 103 Definitions. 76

C.    PART 164—SECURITY AND PRIVACY.. 77

§164.103 Authority citation. 77

§164.103 Definitions. 77

§164.104 Applicability. 77

§164.105 Organizational requirements. 78

Subpart C – Security standards for the Protection of Electronic Protected Health Information. 80

§164.302 Applicability. 80

§164.304 Definitions. 80

§164.306 Security standards: General rules. 81

§164.308 Administrative safeguards. 82

§164.310 Physical safeguards. 84

§164.312 Technical safeguards. 85

§164.314 Organizational requirements. 86

§164.318 Compliance dates for the initial implementation of the security standards. 87

Appendix A to Subpart C of Part 164—Security standards: Matrix. 88

§164.500 [Amended] 88

§165. 501 [Amended] 88

§164.504 [Amended] 88

SUMMARY

This final rule adopts standards for the security of electronic protected health information to be implemented by health plans, healthcare clearing houses, and certain healthcare 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).

DATES

Effective Date: These regulations are effective on April 21, 2003.

Compliance Date: Covered entities, with the exception of small health plans, must comply with the requirements of this final rule by April 21, 2005. Small health plans must comply with the requirements of this final rule by April 21, 2006.

FOR FURTHER INFORMATION CONTACT: William Schooler, (410) 786–0089.

SUPPLEMENTARY INFORMATION:Availability of Copies and Electronic Access: To order copies of the Federal Register containing this document, send your request to:

New Orders, Superintendent of Documents

P. O. Box371954

Pittsburgh, PA 15250–7954

Specify the date of the issue requested and enclose a check or money order payable to the Superintendent of Documents, or enclose your Visa or Master Card number and expiration date. Credit card orders can also be placed by calling the order desk at (202) 512–1800 or by faxing to (202) 512–2250. The cost for each copy is $10. As an alternative, you can view and photocopy the Federal Register document at most libraries designated as Federal Depository Libraries and at many other public and academic libraries throughout the country that receive the Federal Register. This Federal Register document is also available from the Federal Register online database through GPO access, a service of the U. S. Government Printing Office. The Web site address is http://www.access.gpo.gov/nara/index. html. I

SECTION 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, healthcare providers, and health care clearinghouses must assure their customers (for example, patients, insured individuals, providers, and health plans) that the integrity, confidentiality, and availability of electronic protected health information they collect, maintain, use, or transmit is protected.

The confidentiality of health information is threatened not only by the risk of improper access to stored information, but also by the risk of interception during electronic transmission of the information. The purpose of this final rule is to adopt national standards for safeguards to protect the confidentiality, integrity, and availability of electronic protected health information.

Currently, no standard measures exist in the healthcare 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” (here after, we refer to the Social Security Act as “the Act”; we refer to the other laws cited in this document by their names). The purpose of subtitle F is to improve the Medicare program under title XVIII of the Act, the Medicaid program under title XIX of the Act, and the efficiency and effectiveness of the health care system, by encouraging the development of a health information system through the establishment of standards and requirements to enable the electronic exchange of certain health information. Part C of title XI consists of sections1171 through 1179 of the Act. These sections define various terms and impose requirements on HHS, health plans, health care clearing houses, and certain health care providers. These statutory sections are discussed in the Transactions Rule, at 65 FR 50312, on pages 50312 through 50313, and in the final rules adopting standards for Privacy of Individually Identifiable Health Information, published on December 28, 2000 at 65 FR 82462 (Privacy Rules), on pages 82470 through 82471, and on August 14, 2002 at 67 FR 53182. The reader is referred to those discussions. Section 1173 (d) of the Act requires:

  • the Secretary of HHS to adopt security standards that take into account the technical capabilities of record systems used to maintain health information, the costs of security measures, the need to train persons who have access to health information, the value of audit trails in computerized record systems, and the needs and capabilities of small healthcare providers and rural health care providers.
  • requires that the standards ensure that a health care clearing house, 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.
  • 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.

SECTION II
General Overview of the Provisions of the Proposed Rule

On August 12, 1998, we published a proposed rule (63 FR 43242) to establish a minimum standard for security of electronic health information. We proposed that the standard would require the safeguarding of all electronic health information by covered entities. The proposed rule also proposed a 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 sub chapter C of title 45, consisting of parts 160, 162, and 164.Subpart A of part 160 contains the general provisions applicable to all the Administrative Simplification rules; other subparts of part 160 will contain other requirements applicable to all standards. Part 162 contains the standards for transactions and code sets and will contain the identifier standards. Part 164 contains the standards relating to privacy and security. Subpart A of part 164 contains general provisions applicable to part 164; subpart E contains the privacy standards. Subpart C of part 164, which is adopted in this final rule, adopts standards for the security of electronic protected health information.

SECTION III
Analysis of, and Responses to, Public Comments on the Proposed Rule

We received approximately 2,350 timely public comments on the August 12, 1998 proposed rule. The comments came from professional associations and societies, health care workers, law firms, health insurers, hospitals, and private individuals. We reviewed each commenter’s letter and grouped related comments. Some comments were identical. After associating like comments, we placed them in categories based on subject matter or based on the section(s) of the regulations affected and then reviewed the comments.

In this section of the preamble, we summarize the provisions of the proposed regulations, summarize the related provisions in this final rule, and respond to comments received concerning each area. It should be noted that the proposed Security Rule contained multiple proposed “requirements” and “implementation features.” In this final rule, we replace the term “requirement” with “standard”. We also replace the phrase “implementation feature” with “implementation specification”. We do this to maintain consistency with the use of those terms as they appear in the statute, the Transactions Rule, and the Privacy Rule. Within the comment and response portion of this final rule, for purposes of continuity, however, we use “requirement” and “implementation feature” when we are referring specifically to matters from the proposed rule. In all other instances, we use “standard” and “implementation specification”. The proposed rule would require that each covered entity (as now described in §160.102) engaged in the electronic maintenance or transmission of health information pertaining to individuals assess potential risks and vulnerabilities to such information in its possession in electronic form, and develop, implement, and maintain appropriate security measures to protect that information. Importantly, these measures would be required to be documented and kept current.

The proposed security standard was based on three basic concepts that were derived from the Administrative Simplification provisions of HIPAA.

  • it should be comprehensive and coordinated to address all aspects of security.
  • it should be scalable, so that it can be effectively implemented by covered entities of all types and sizes.
  • 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
  • Technical mechanisms

The implementation features described the requirements in greater detail when that detail was needed. Within the four categories, the requirements and implementation features were presented in alphabetical order to convey that no one item was considered to be more important than another. The four proposed categories of requirements and implementation features were depicted in tabular form along with the electronic signature standard in a combined matrix located at Addendum 1. We also provided a glossary of terms, at Addendum 2, to facilitate a common understanding of the matrix entries, and at Addendum 3, we mapped available existing industry standards and guidelines to the proposed security requirements.

A. General Issues

The comment process overwhelmingly validated our basic assumptions that the entities affected by this regulation are so varied in terms of installed technology, size, resources, and relative risk, that it would be impossible to dictate a specific solution or set of solutions that would be useable by all covered entities. Many commenters also supported the concept of technological neutrality, which would afford them the flexibility to select appropriate technology solutions and to adopt new technology over time.

Security Rule and Privacy Rule Distinctions

As many commenters recognized, security and privacy are inextricably linked. The protection of the privacy of information depends in large part on the existence of security measures to protect that information. It is important that we note several distinct differences between the Privacy Rule and the Security Rule.

·        The security standards below define administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information. The standards require covered entities to implement basic safeguards to protect electronic protected health information from unauthorized access, alteration, deletion, and transmission.

·        The Privacy Rule, by contrast, sets standards for how protected health information should be controlled by setting forth what uses and disclosures are authorized or required and what rights patients have with respect to their health information.

As is discussed more fully below, this rule narrows the scope of the information to which the safeguards must be applied from that proposed in the proposed rule, electronic health information pertaining to individuals, to protected health information in electronic form. Thus, the scope of information covered in this rule inconsistent with the Privacy Rule, which addresses privacy protections for “protected health information”. However, the scope of the Security Rule is more limited than that of the Privacy Rule. The Privacy Rule applies to protected health information in any form, whereas this rule applies only to protected health information in electronic form. It is true that, under section 1173 (d) of the Act, the Secretary has authority to cover “health information, “which, by statute, includes information in other than electronic form. However, because the proposed rule proposed to cover only health information in electronic form, we do not include security standards for health information in non-electronic form in this final rule. We received a number of comments that pertained to privacy issues. These issues were considered in the development of the Privacy Rule and many of these comments were addressed in the preamble of the Privacy Rule. Therefore, we are referring the reader to that document for a discussion of those issues.

Level of Detail

We solicited comments as to the level of detail expressed in the required implementation features; that is, we specifically wanted to know whether commenters believe the level of detail of any proposed requirement went beyond what is necessary or appropriate. We received numerous comments expressing the view that the security standards should not be overly prescriptive because the speed with which technology is evolving could make specific requirements obsolete and might in fact deter technological progress. We have accordingly written the final rule to frame the standards in terms that are as generic as possible and which, generally speaking, may be met through various approaches or technologies.

Implementation Specifications

In addition to adopting standards, this rule adopts implementation specifications that provide instructions for implementing those standards. However, in some cases, the standard itself includes all the necessary instructions for implementation. In these instances, there may be no corresponding implementation specification for the standard specifically set forth in the regulations text. In those instances, the standards themselves also serve as the implementation specification. In other words, in those instances, we are adopting one set of instructions as both the standard and the implementation specification. The implementation specification would, accordingly, in those instances be required. In this final rule, we adopt both “required” and “addressable” implementation specifications. We introduce the concept of “addressable implementation specifications” to provide covered entities additional flexibility with respect to compliance with the security standards. In meeting standards that contain addressable implementation specifications, a covered entity will ultimately do one of the following:

·        Implement one or more of the addressable implementation specifications;

·        implement one or more alternative security measures;

·        implement a combination of both

·        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

·        cost of implementation.

Based upon this decision the following applies:

·        If a given addressable implementation specification is determined to be reasonable and appropriate, the covered entity must implement it.

·        If a given address able implementation specification is determined to be an inappropriate and /or unreasonable security measure for the covered entity, but the standard cannot be met without implementation of an additional security safeguard, the covered entity may implement an alternate measure that accomplishes the same end as the addressable implementation specification. An entity that meets a given standard through alternative measures must document the decision not to implement the addressable implementation specification, the rationale behind that decision, and the alternative safeguard implemented to meet the standard. For example, the addressable implementation specification for the integrity standard calls for electronic mechanisms to corroborate that data have not been altered or destroyed in an unauthorized manner (see 45 CFR164.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.

A covered entity may also decide that a given implementation specification is simply not applicable (that is, neither reasonable nor appropriate) to its situation and that the standard can be met without implementation of an alternative measure in place of the addressable implementation specification. In this scenario, the covered entity must document the decision not to implement the addressable specification, the rationale behind that decision, and how the standard is being met.  For example, under the information access management standard, an access establishment and modification implementation specification reads: “implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process” (45 CFR 164.308 (a) (4) (ii) (c) ). It is possible that a small practice, with one or more individuals equally responsible for establishing and maintaining all automated patient records, will not need to establish policies and procedures for granting access to that electronic protected health information because the access rights are equal for all of the individuals.

a. Comment: A large number of commenters indicated that mandating 69 implementation features would result in a regulation that is too burdensome, intrusive, and difficult to implement. These commenters requested that the implementation features be made optional to meet the requirements. A number of other commenters requested that all implementation features be removed from the regulation.

Response: Deleting the implementation specifications would result in the standards being too general to understand, apply effectively, and enforce consistently. Moreover, a number of implementation specifications are so basic that no covered entity could effectively protect electronic protected health information without implementing them. We selected 13 of these mandatory implementation specifications based on

the expertise of Federal security experts and generally accepted industry practices

the recommendation for immediate implementation of certain technical and organizational practices and procedures described in Chapter 6 of For The Record: Protecting Electronic Health Information, a 1997 report by the National Research Council (NRC).

These mandatory implementation specifications are referred to as required implementation specifications and are reflected in the NRC report’s recommendations. Risk Analysis and Risk management are found in the NRC recommendation title System Assessment; Sanction Policy is required in the Sanctions recommendation; Information system Activity Review is discussed in Audit Trails; Response and Reporting circumstances. In addition, a number of voluntary national and regional organizations have been formed to address HIPAA implementation issues and to facilitate communication among trading partners. These include the Strategic National Implementation Process (SNIP) developed under the auspices of the Workgroup for Electronic Data Interchange (WEDI), an organization named in the HIPAA statute to consult with the Secretary of HHS on HIPAA issues. Some of these organizations have developed white papers, tools, and recommended best practices addressing a number of HIPAA issues, including security. Covered entities may wish to examine these products to determine if they are relevant and useful in their own implementation efforts. A partial list of these organizations can be found at http://www.wedi/snip./org. We believe that these and other futureindustry-developed guidelines and /ormodels may provide valuable assistanceto covered entities implementing these standards but must caution that HHSdoes not rate or endorse any such guidelines and /or models and the value of its content must be determine by the user.

b. Comment: Many commenters asked us to develop guidelines and models to aid in complying with the Security Rule. Several commenters either offered to participate in the development of guidelines and models or suggested entities that should be invited to participate.

Response: We agree that creation ofcompliance tools and guidelines for different business environments could assist covered entities to implement theHIPAA Security Rule. We plan to issue guidance documents after the publication of this final rule. However, it is critical for each covered entity to establish policies and procedures that address its own unique risks and circumstances. In addition, a number of voluntary national and regional organizations have been formed to address HIPAA implementation issues and to facilitate communication among trading partners. These include the Strategic National Implementation Process (SNIP) developed under the auspices of the Workgroup for Electronic Data Interchange (WEDI), an organization named in the HIPAA statute to consult with the Secretary of HHS on HIPAA issues. Some of these organizations have developed white papers, tools, and recommended best practices addressing a number of HIPAA issues, including security. Covered entities may wish to examine these products to determine if they are relevant and useful in their own implementation efforts. A partial list of these organizations can be found at http://www.snip.wedi.org. We believe that these and other future industry developed guidelines and /or models may provide valuable assistance to covered entities implementing these standards but must caution that HHS does not rate or endorse any such guidelines and /or models and the value of its content must be determined by the user.

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 commenter referred specifically to the exampleprovided in the proposed ruledemonstrating how a small or ruralprovider might comply with the standards. One commenter asked forclarification that the examples are notmand atory measures that are required todemonstrate compliance, but are merelymeant as a guide when implementingthe security standards. Anothercommenter expressed support for theuse of examples to clarify the intent oftext 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 proprietaryformat). No distinction would be madebetween internal corporate entitycommunication or communicationexternal to the corporate entity. Electronic transmissions would includetransactions using all media, even whenthe information is physically movedfrom one location to another usingmagnetic tape, disk, or other machinereadable media. Transmissions over theInternet (wide-open), extranet (usingInternet technology to link a businesswith information only accessible tocollaborating parties), leased lines, dialuplines, and private networks would beincluded. We proposed that telephonevoice response and “faxback” systems (arequest for information made via voiceusing a fax machine and requestedinformation returned via that samemachine as a fax) would not be includedbut we solicited comments on thisproposed exclusion. This final rule simplifies theapplicability 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 ofwho 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 maintains or transmits healthinformation 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 healthcare provider that conducts certain transactions electronically. The commentors apparently did not realizethat 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:

·        A healthplan;

·        a health care clearinghouse;

·        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 ofthe term “covered entity” is discussedin the preamble to the Privacy Rule (65FR 82476 through 82477).

As that discussion makes clear, the standards only apply to health careproviders who engage electronically in the transactions for which standards have been adopted.

2. Comment: Several commenters recommended expansion ofapplicability, either to other specificentities, or to all entities involved inhealth care. Others wanted to knowwhether the standards apply to entitiessuch as employers, public healthorganizations, medical schools, universities, research organizations, plan brokers, or non-EDI providers. Onecommenter asked whether the standards apply to State data organizationsoperating in capacities other than asplans, clearinghouses, or providers. Stillother commenters stated that it wasinappropriate to include physicians and other health care professionals in thesame category as plans and clearinghouses, arguing that providersshould be subject to different, lessburdensome requirements because theyalready protect health information.

Response: The statute does not coverall health care entities that transmit ormaintain individually identifiablehealth information. Section 1172 (a) ofthe Act provides that only health plans, health care clearinghouses, and certainhealth care providers (as discussedabove) are covered. With respect to thecomments regarding the differencebetween providers and plans/clearinghouses, we have structured theSecurity Rule to be scalable and flexibleenough to allow different entities toimplement the standards in a mannerthat is appropriate for theircircumstances. Regarding the coverageof entities not within the jurisdiction ofHIPAA, 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, healthcare clearinghouses, and certain healthcare providers are required to complywith the security standards. Researcherswho are members of a covered entity’swork force may be covered by thesecurity standards as part of the coveredentity. See the definition of “workforce”at 45 CFR 160.103. Note, however, thata covered entity could, underappropriate circumstances, exclude aresearcher or research division from itshealth care component or components (see §164.105 (a) ). Researchers who arenot part of the covered entity’sworkforce and are not themselvescovered entities are not subject to the standards.

4. Comment: Several commenter stated that internal networks and external networks should be treateddifferently. One commenter asked for further clarification of the differencebetween what needs to be securedexternal to a corporation versus thesecurity of data movement within anorganization. Another stated thatcomplying with the security standards for internal communications may provedifficult and costly to monitor and control. In contrast, one commenters tated that the existence of requirementsshould not depend on whether use ofinformation is for internal or externalpurposes. Another commenter argued that theregulation goes beyond the intent of thelaw, and while communication ofelectronic information between entitiesshould be covered, the law was neverintended to mand ate changes to anentity’s internal automated systems. One commenter requested that raw datathat are only for the internal use of afacility be excluded, provided thatreasonable safeguards are in place tokeep the raw data under the control ofthe facility.

Response: Section 1173 (d) (2) of the Act states: Each person described insection 1172 (a) who maintains or transmits health information shall maintain reasonable and appropriate administrative, technical, and physical safeguards—

to ensure the integrityand confidentiality of the information;

to protect against any reasonablyanticipated—

threats or hazards to thesecurity or integrity of the information;and

unauthorized uses ordisclosures of the information;

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 healthinformation at rest (that is, in storage) aswell 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 entityin complying with the standards (seethe discussion below).

5. Comment: Several commenters found the following statement in theproposed rule (63 FR 43245) at sectionII. A. confusing and asked forclarification: “With the exception of thesecurity standard, transmission within acorporate entity would not be requiredto comply with the standards”.

Response: In the final TransactionsRule, we revised our approachconcerning the transaction and code setexemptions, replacing this concept withother tests that determine whether aparticular transaction is subject to those standards (see the discussion in theTransactions Rule at 65 FR 50316through 50318). We also note that thePrivacy Rule regulates a covered entity’suse, as well as disclosure, of protected health information.

6. Comment: One commenter stated that research would be hampered ifproposed §142. 306 (a) applied. The commenter believes that research usesof health information should beexcluded or the standard should berevised to allow appropriate flexibilityfor research depending on the risk topatients or subjects (for example, if theinformation is anonymous, there is norisk, and it would not be necessary tomeet the security standards ).

Response: If electronic protectedhealth information is de-identified (astruly anonymous information wouldbe), it is not covered by this rulebecause it is no longer electronicprotected health information (see 45CFR 164.502 (d) and 164.514 (a) ). Electronic protected health information received, created, or maintained by acovered 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 CFR164.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 towhat extent individual patients aresubject to the standards. For example, some telemedicine practices support theuse of diagnostic systems in thepatient’s home, which can be used toconduct tests and send results to aremote physician. In other cases, patients may be responsible for thefiling 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 intentof the rule to include electronictransmission to or from the patient.

Response: Patients are not coveredentities and, thus, are not subject tothese standards. With respect totransmissions from covered entities, covered entities must protect electronicprotected health information when theytransmit that information. See also thediscussion 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 are addressed in the Transactions Rule at 65FR 50319 through 50320:

·        code set

·        health care clearinghouse

·        health plan

·        healthcare provider

·        small health plan

·        standard

·        transaction

Comments concerning the definition of “individually identifiable health information” are discussed below, but are also addressed in the Privacy Ruleat 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 notused in the final rule because they are no longer necessary. Other terms defined in the proposed rule are defined within the explanation of the standards in the final rule and are discussed in the preamble discussions in §164.308 through §164.312. Definitions of terms relevant to the security standards now appear in the regulations text provisions as indicated below:§160.103: Definitions of the followingterms relevant to this rule appear in§160.103:

·        business associate

·        covered entity

·        disclosure

·        electronic media

·        electronic protected health information

·        healthcare

·        health care clearinghouse

·        health care provider

·        healthinformation

·        health plan

·        individual

·        individually identifiable health information,

·        implementation specification

·        organized health carearrangement

·        protected healthinformation

·        standard

·        use

·        workforce

These terms were discussed in connection with the Transaction and Privacy Rules and with the exception of the terms “covered entity” “disclosure” “electronic protected health information, “ “health information, “ “individual, “ “organized health care arrangement, “ “protected health information, “ and “use, “ we will not discuss them in this document. We note that the definition of those terms are not changed in the final rule. §162.103: We have moved the definition of “electronic media” at §162.103 to §160.103 and have modified it to clarify that the term includes storage of information. The term “electronic media” is used in the definition of “protected health information”. Both the privacy and security standards apply to information”at rest” as well as to information being transmitted. We note that we have deleted the reference to §162. 103 in paragraph (1) (ii) of the definition of “protected health information, “ since both definitions, “electronic media” and “protected health information, “ have been moved to this section. Also, it is unnecessary, because the definitions of§160.103 apply to all of the rule in parts160, 162, and 164.We have also clarified that the physical movement of electronic media from place to place is not limited to magnetic tape, disk, or compact disk. This clarification removes a restriction as to what is considered to be physical electronic media, thereby allowing for future technological innovation. We further clarified that transmission of information not in electronic form before the transmission, for example, paper or voice, is not covered by this definition. §164.103: The following term “plan sponsor” now appears in the new§164.103, which consists of definitions of terms common to both subpart C and subpart E (the privacy standards). This definition was moved, without substantive change, from §164.501 and has the meaning given to it in that section, and comments relating to this definition are discussed in connection with that section in the Privacy Rule at 65 FR 82607, 82611 through 82613, 82618 through 82622, and 82629. §164.304: Definitions specifically applicable to the Security Rule appearin §164.304, and these are discussed below. These definitions are from, orderived from, currently accepteddefinitions in industry publications, such as, the International Organization for standards (ISO) 7498–2 and the American Society for Testing and Materials (ASTM) E1762–95.

The following terms in §164.304 are taken from the proposed rule text or the glossary in Addendum 2 of the proposed rule (63 FR 43271), were not commented on, and /or are unchanged or have only minor technical changes for purposes of clarification and are not discussed below:

·        access

·        authentication

·        availability

·        confidentiality

·        encryption

·        password

·        security.

§164.314:

Four terms were defined in§164.504(a) of the Privacy Rule:

·        common control

·        common ownership

·        health care component

·        hybrid entity

Because theseterms apply to both security and privacy, their definitions have beenmoved to §164.103 without change. Those terms are discussed in thePrivacy Rule at 65 FR 82502 through82503 and at 67 FR 53203 through53207.Covered Entity (§160.103)

Comment: One commenter asked if transcription services were covered entities. The question arose because transcription is often the first electronicor printed source of clinicalinformation. Concern was expressedabout the application of physicalsafeguard standards to the transcribersworking for transcription companies orhealth care providers, either asemployees or as independentcontractors. Another commenter expressedconcern that scalability was limited toonly small providers. The commenter explained that Third Party Administrators (TPAs) allow claim processors to work at home. Some TPAs have noted that it would be impossible to comply with the security standards for home-based claims processors.

Response: A covered entity’s responsibility to implement security standards extends to the members of its workforce, whether they work at home or on-site. Because a covered entity is responsible for ensuring the security ofthe information in its care, the coveredentity must include “at home” functionsin its security process. While an independent transcription company or aTPA 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.

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 FR43242), was intended to be synonymouswith “health care”. The termldquo; medical care” is not included inthis final rule. It is, however, includedin the definition of “health plan, “ whereits meaning is not synonymous with”health care”. For a full discussion ofthis issue and its resolution, see thePrivacy Rule (65 FR 82578).

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 theTransactions and Privacy Rules.

a. Comment: A number ofcommenters asked that the definition of”health information” be expand ed toinclude information collected byadditional entities. Several commenters wanted the definition to include healthinformation collected, maintained, ortransmitted by any entity, and onecommenter suggested the inclusion ofaggregated information not identifiableto an individual. Several commenters asked that eligibility information be excluded from the definition ofinformation. Several commenters wanted the definition broadened toinclude demographics.

Response: Our definition of healthinformation is taken from the definitionin section 1171 (4) of the Act, whichprovides that health information relatesto the health or condition of anindividual, the provision of health careto an individual, or payment for theprovision of health care to anindividual. The statutory definition alsospecifies the entities by which healthinformation is created or received. Wenote that, because “individuallyidentifiable health information” is asubset of “health information” and bystatute includes demographicinformation, “health information”necessarily includes demographicinformation. We think this is clear as amatter of statutory construction and does not require further regulatorychange.

b. Comment: Several commenters asked that we clarify the differencebetween “health information” and “individually identifiable” and “healthinformation pertaining to an individual”as used in the August 12, 1998 proposedrule (63 FR 43242). Additionally, commenters asked that we be moreconsistent in the use of these terms and recommended use of the term”individually identifiable healthinformation”. Two commenters stated that it isimportant to distinguish between”health information pertaining to anindividual” and “individuallyidentifiable health information, “ as inreporting statistics at various levelsthere will always be a need to bringforth information pertaining to anindividual. One commenter recommended thatthe standards apply only to individuallyidentifiable health information. An other stated that in §142.306(b) of theproposed rule, “health informationpertaining to an individual” should bechanged to “individually identifiablehealth information, “ as nonidentifiableinformation can be used for utilizationreview and other purposes. As written, the regulation text could limit theability to use data, for example, from aclearinghouse for compliancemonitoring.

Response: In general, we agree with these commenters , and note that thesecomments are largely mooted by thedecision, 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.

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

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.

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

Security Incident (§164.304)

Comment: We received commentsasking 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”.

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”

Workstation (§164.304)

Comment: One commenter expressed concern that the use of the term “workstation” implied limited applicability to fixed devices (such as terminals), excluding laptops and otherportable 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”.

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

user-based access control

NOTE: 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 followingterms: “token” and “documentation.”

Response: These terms were definedin Addendum 2 of the proposed rule. Inthis final rule, we do not adopt adefinition for “token” because it is notused 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 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 thedefinition 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). 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 haveto include in their operations to ensure that health information pertaining to an individual that is electronically maintained or electronically transmitted remains safeguarded. The proposed rule would have required that each affected entity assess its own security needs and risks and devise, implement, and maintain appropriate security to address its own unique security needs. How individual security requirements would be satisfied and which technology to use would be business decisions that each entity would have to make. In the final rule we adopt this basic framework. In §164.306, we set forth general rules pertaining to the security standards. In paragraph (a), we describe the general requirements. Paragraph (a) generally reflects section 1173 (d) (2) of the Act, but makes explicit the connection between the security standards and the privacy standards (see §164.306 (a) (3) ). In §164.306 (a) (1), we provide that the security standards apply to all electronic protected healthinformation the covered entity creates, receives, maintains, or transmits. In paragraph (b) (1), we provide explicitly for the scalability of this rule by discussing the flexibility of the standards, and paragraph (b) (2) of §164.306 discusses various factors covered entities must consider incomplying 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 riskanalysis and risk management measuresrequired by §164.308 (a) (1) must bedesigned to lead to the implementationof security measures that will complywith §164.306 (a). It should be noted that theimplementation of reasonable and appropriate security measures alsosupports compliance with the privacy standards, just as the lack of adequatesecurity can increase the risk ofviolation of the privacy standards. If, forexample, a particular safeguard isinadequate because it routinely permitsreasonably anticipated uses ordisclosures of electronic protectedhealth information that are notpermitted by the Privacy Rule, and thatcould have been prevented byimplementation of one or more securitymeasures appropriate to the scale of thecovered entity, the covered entity wouldnot only be violating the Privacy Rule, but would also not be in compliancewith §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 bemet. However, with respect toimplementation specifications that areaddressable, §164.306 (d) (3) specifiesthat covered entities must assesswhether an implementation specification is a reasonable and appropriate safeguard in itsenvironment, which may includeconsideration of factors such as the sizeand capability of the organization aswell as the risk. If the organizationdetermines it is a reasonable and appropriate safeguard, it mustimplement the specification. If anaddressable implementation specification is determined not to be areasonable and appropriate answer to acovered entity’s security needs, thecovered entity must do one of twothings: implement another equivalentmeasure if reasonable and appropriate;or if the standard can otherwise be met, the covered entity may choose to notimplement the implementation specification or any equivalentalternative measure at all. The coveredentity must document the rationalebehind not implementing theimplementation specification. See the detailed discussion in section II. A. 3. Paragraph (e) of §164.306 addresses the requirement for covered entities to maintain the security measures implemented by reviewing and modifying the measures as needed tocontinue the provision of reasonableand appropriate protections, forexample, as technology moves forward, and as new threats or vulnerabilities arediscovered.

Scope of Health Information Coveredby the Rule (§164.306 (a) )

We proposed to cover healthinformation maintained or transmittedby 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 healthinformation. 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)

(3)   employment records (see the Privacy Rule at 65 FR82496. See also 67 FR 53191 through 53193).

The scope of information covered in the Privacy Rule is referred to as “protected health information”. Based upon the comments we received, we align the requirements of the Security and Privacy Rules with regard to the scope of information covered, in order to eliminate confusion and ease implementation. Thus, this final rule requires protection of the same scope of information as that covered by the Privacy Rule, except that it only coversthat 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 healthinformation used for statistical analysis be exempted if the covered entity may reasonably expect that the removed information cannot be used to reidentify an individual.

Response: As a general proposition, any electronic protected healthinformation received, created, maintained, or transmitted by a covered entity is covered by this final rule. We agree with the second commenter that certain information, from which identifiers have been stripped, does not come within the purview of this final rule. Information that is de-identified, as defined in the Privacy Rule at §164.502 (d) and §164.514 (a), is not “individually identifiable” within the meaning of these rules and, thus, does not come within the definition of “protected health information”. It accordingly is not covered by this final rule. For a full discussion of the issues of de-identification and re-identification of individually identifiable health information see 65 FR 82499 and 82708 through 82712 and 67 FR 53232 through 53234.

b. Comment: Several commenters asked whether systems that determine eligibility of clients for insurance coverage under broad categories such as medical coverage groups are considered health information. One commenter asked that we specifically exclude eligibility information from the standards.

Response: We cannot accept the latter suggestion. Eligibility information will typically be individually identifiable, and much eligibility information will also contain health information. If the information is “individually identifiable” and is “health information, “ (with three very specific exceptions noted in the general discussion above) and it is in electronic form, it is covered by the security standards if maintained or transmitted by a covered entity.

c. Comment: Several commenters requested clarification as to whether the standards apply to identifiable health information in paper form. Some commenters believed the rule should be applicable to paper; others argued that it should apply to all confidential, identifiable health information.

Response: While we agree that protected health information in paper or other form also should have appropriate security protections, the proposed rule proposing the security standards proposed to apply those standards to health information in electronic form only. We are, accordingly, not extending the scope in this final rule. We may establish standards to secure protected health information in other media in a future rule, in accordance with our statutory authority to do so. See discussion, supra, responding to a comment on the definition of “healthinformation” and “individually identifiable health information”.

d. Comment: The proposed rule would have excluded “telephone voice response” and “faxback” systems from the security standards, and we specifically solicited comments on that issue. A number of commenters agreedt hat 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 securityrequirements provide for adequate security of these systems.

Response: In light of these comments, we have decided that telephone voiceresponse and “faxback” (that is, a request for information from a computer made via voice or telephone key pad input with the requested information returned as a fax) systems fall under this rule because they are used as input and output devices for computers, not because they have computers in them. Excluding these features would providea huge loophole in any systemconcerned with security of theinformation contained and /or processedtherein. It should be noted thatemployment of telephone voiceresponse and /or faxback systems willgenerally require security protection byonly one of the parties involved, and notthe other. Information being transmittedvia a telephone (either by voice or aDTMP tone pad) is not in electronicform (as defined in the first paragraphof the definition of “electronic media”) before transmission and therefore is notsubject to the Security Rule. Informationbeing returned via a telephone voiceresponse system in response to atelephone request is data that is alreadyin electronic form and stored in acomputer. This latter transmission does require protection under the Security Rule. Although most recently madeelectronic devices containmicroprocessors (a form of computer) controlled by firmware (anunchangeable form of computerprogram), we intend the term”computer” to include only softwareprogrammable computers, for example, personal computers, minicomputers, and mainframes. Copy machines, faxmachines, and telephones, even thosethat contain memory and can producemultiple copies for multiple people arenot intended to be included in the term”computer”. Therefore, because “paperto-paper” faxes, person-to-persontelephone calls, video teleconferencing, or messages left on voice-mail were notin electronic form before thetransmission, those activities are notcovered by this rule. See also the definition of “electronic media” at §160.103. We note that this guidance differsfrom the guidance regarding theapplicability of the Transactions Rule tofaxback and voice response systems. HHS has stated that faxback and voiceresponse systems are not required tofollow the standards mand ated in theTransactions Rule. This new guidance refers only to this rule.

e. Comment: One commenter askedwhether 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 §164.310 (d) (1) addresses this situation.

f. Comment: One commenter wantedthe “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 healthinformation and, to the extent it is also electronic protected health information, must be afforded the security protections.

h. Comment: Two commenters asked that the rule prohibit re-identification of de-identified data. In contrast, several commenters asked that we identify a minimum list or threshold of specific reidentification 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 ameans to use re-identified information if the entity already has access to the information or is authorized to have access.

Response: The issue of reidentificationis addressed in the Privacy Rule at §164.502 (d) and §164.514 (c). The reader is referred to those sections and the related discussion in the preamble to the Privacy Rule (65 FR 82712) and the preamble to the Privacy Modifications (67 FR 53232 through 53234) for a full discussion of the issues of reidentification. We note that once information in the possession (orconstructive possession) of a coveredentity is re-identified and meets thedefinition of electronic protected healthinformation, the security standards apply.

Technology-Neutral standards

Comment: Many commenters expressed support for our efforts to develop standards for the security of health information. A number of comments were made in support of the technology-neutral approach of the proposed rule. For example, one commenter stated, “By avoiding prescription of the specific technologies health care entities should use to meet the law’s requirements, you are opening the door for industry to apply innovation. Technologies that don’t currently exist or are impractical today could, in the near future, enhance health information security while minimizing the overall cost”. Several other commenters stated that the requirements should be general enough to withstand changes to technology without becoming obsolete. One commenter anticipates no problems with meeting the standards. In contrast, one commenter suggested that whenever possible, specific technology recommendations should provide sufficient detail to promote systems interoperability and decrease the tendency toward adoption of multiple divergent standards. Several commenters stated that by letting each organization determine its own rules, the rules impose procedural burdens without any substantive benefit to security.

Response: The overwhelming majority of comments supported our position. We do not believe it is appropriate to make the standards technology-specific because technology is simply moving too fast, for example, the increased useand 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 individualsaccess to that information;

(3)   ensuring its availability to thoseauthorized to access the information.

The standards do not allow organizations to make their own rules, only their own technology choices.

Miscellaneous Comments

a. Comment: Some commenters stated that the requirements and implementation features set out in the proposed rule were not specific enough to be considered standards, and that the actual standards are delegated to the discretion of the covered entities, at the expense of medical record privacy. Several commenters stated that it was inappropriate to balance the interests of those seeking to use identifiable medical information without patient consent against the interest of patients. Several other commenters believe that allowing covered entities to make their own decisions about the adequacy and balance of security measures undermined patient confidentiality interests, and stated that the proposedrule 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 coveredentities 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 healthinformation in a covered entity’s carewill be as protected as is feasible for that entity. We disagree that covered entities are given complete discretion to determine their security polices under this rule, resulting in effect, in no standards. While cost is one factor a covered identity may consider in determining whether to implement a particular implementation specification, there is nonetheless a clear requirement that adequate security measures be implemented, see 45 CFR 164.306 (b). Cost is not meant to free covered entities from this responsibility.

b. Comment: Several commenters requested we withdraw the regulations, citing resource shortages due to Y2K preparation, up coming privacy legislation, and /or the “excessive micromanagement” 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 healthinformation. Resource concerns due toY2K 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 FR82751 through 82752. We disagree that these standards will adversely affect a provider’s practice environment. The scalability of the standards allows each covered entity to implement security protections that are appropriate to its specific needs, risks, and environments. These protections are necessary to maintain the confidentiality, integrity, and availability of patient data. A covered entity that lacks adequate protections risks inadvertent disclosure of patient data, with resulting loss of public trust, and potential legal action. For example, a covered entity with poor facility access controls and procedures would be susceptible to hacking of its databases. A provider with appropriate security protections already in place would only need to ensure that the protections are documented and are reassessed periodically to ensure that they continue to be appropriate and are actually being implemented. Our decision to classify many implementation specifications as addressable, rather than mandatory, provides even more flexibility to covered entities to develop cost effective solutions. We believe that insurers who already have effective security programs in place will have met many of the requirements of this regulation.

c. Comment: One commenter believes the rule is arbitrary and capricious in its requirements without any justification that they will significantly improve the security of medical records and with the likelihood that their implementationmay actually increase the vulnerabilityof the data. The commenter noted that the data backup requirements increase access to data and that security awareness training provides more information to employees.

Response: The standards are based on generally accepted security procedures, existing industry standards and guidelines, and recommendations contained in the National Research Council’s 1997 report For The Record: Protecting Electronic HealthInformation, 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 ofthe covered entity. For example, aprocedure as simple as locking backup diskettes in a safe place and restricting who has access to the key may be suitable for one entity, whereas another may need to store backed-up information off-site in a secure computer facility. The information provided in security awareness training heightens awareness of security anomalies and helps to prevent security incidents.

d. Comment: Several commenters suggested that the proposed rule appears to reflect the Medicare program’s perspective on security risks and solutions, and that it should be noted that not all industry segments share all the same risks as Medicare. One commenter stated that as future proposed rules are drafted, we should solicit input from those most significantly affected, for example, providers, plans, and clearinghouses. Others stated that Medicaid agencies were not sufficiently involved in the discussions and debate. Still another stated that States would be unable to perform some basic business functions if all the standards are not designed to meet their needs.

Response: We believe that the standards are consistent with common industry practices and equitable, and that there has been adequate consultation with interested parties in the development of the standards. These standards are the result of an intensive process of public consultation. In the course of developing the proposed rule we consulted with the:

·        National Uniform Billing Committee

·        NationalUniform Claim Committee

·        American Dental Association

·        Workgroup for Electronic Data Interchange.

Those organizations were specifically named in the Act to advise the Secretary, and their membership is drawn from the full spectrum of industry segments. In addition, the National Committee on Vital and Health Statistics (NCVHS), an independent advisory group to the Secretary, held numerous public hearings to obtain the views of interested parties. Again, many segments of the health care industry, including provider groups, health plans, clearinghouses, vendors, and government programs participated actively. The NCVHS developed recommendations to the Secretary, which were relied upon as we developed the proposed rule. Finally, we note that the opportunity to comment was available to all during the public comment period.

e. Comment: One commenter stated that there is a need to ensure the confidentiality of risk analysis information that may contain sensitive information.

Response: The information included in a risk analysis would not be subject to the security standards if it does not include electronic protected healthinformation. 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 ownbusiness rules regarding access to and protections for risk analysis data.

f. Comment: One commenter expressed concern over the statement in the preamble of the proposed rule (63FR 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

·        Technical safeguards

In this final rule, we order the standards in such away that the “Security management process” is listed first under the”Administrative safeguards” section, as we believe this forms the foundation on which all of the other standards depend. The determination of the specific security measures to be implemented to comply with the standards will, in large part, be dependent upon completion of the implementation specifications within the security management process standard (see §164.308 (a) (1) ). We emphasize, however, that an entity implementing these standards may choose to implement them in any order, as long as the standards are met.

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 assigned security responsibility, workforce security, security awareness and training, security incident procedures, contingency planning, business associate contracts, and evaluation.

h. Comment: One commenter stated that internal and external security requirements should be separated and dealt with independently.

Response: The presentation of the standards within this final rule could have been structured in numerous ways, including by addressing separate internal and external security standards. We chose the current structure as we considered it a logical breakout for purposes of display within this final rule. Under our structure a covered entity may apply a given standard to internal activities and to external activities. Had we displayed separately the standards for internal security and the standards for external security, we would have needed to describe a number of the standards twice, as many apply to both internal and external security. However, a given entity may address the standards in whatever order it chooses, as long as the standards are met.

i. Comment: Two commenters stated that the standards identified in Addendum 3 of the proposed rule may not all have matured to implementation readiness.

Response: Addendum 3 of the proposed rule cross-referred individual requirements on the matrix to existing industry standards of varying levels of maturity. Addendum 3 was intended to show what we evaluated in searching for existing industry standards that could be adopted on a national level. Noone 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 commenters uggested we include a revised preamble in the final publication. Another questioned how clarification of points in the preamble will be handled if the preamble is not part of the final regulation.

Response: Preambles to proposed rules are not republished in the final rule. The preamble in this final rule contains summaries of the information presented in the preamble of the proposed rule, summaries of the comments received during the public comment period, and responses to questions and concerns raised in those comments and a summary of changes made. Additional clarification will be provided by HHS on an ongoing basis through written documents and postings on HHS’s websites.

k. Comment: One commenter asked that we clarify that no third party can require implementation of more security features than are required in the final rule, for example, a third party could not require encryption but may choose to accept it if the other party so desires.

Response: The security standards establish a minimum level of security to be met by covered entities. It is not our intent to limit the level of security that may be agreed to between trading partners or others above this floor.

l. Comment: One commenter asked how privacy legislation would affectthese 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 part164 have been adopted, and this final rule is compatible with them.

m. Comment: One commenter stated that a data classification policy, that is a method of assigning sensitivity ratings to specific pieces of data, should be part of the final regulations.

Response: We did not adopt such apolicy 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 developedby ANSI-recognized standards Development Organizations (SDOs).

Response: In general, HHS is requiredto 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. Noexisting security standard, or group of standards, is technology-neutral, scaleable to the extent required byHIPAA, and broad enough to be adoptedin this final rule. Therefore, this final rule adopts standards under section1172 (c) (2) (B) of the Act, which permitsus to develop standards when no industry standards exist.

o. Comment: One commenter stated that this regulation goes beyond the scope of the law, unjustifiably extendingin to 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 complianceby the officers and employees of covered entities, protection against reasonably anticipated unauthorized uses and disclosures of healthinformation, 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 informationin accordance with the Act. In order todo this, covered entities are required to implement administrative, physical, and technical safeguards. Those entities must ensure that data are protected, to the extent feasible, from inappropriate access, modification, dissemination, and destruction. As noted above, however, this final rule has been modified to increase flexibility as to how this protection is accomplished.

p. Comment: One commenter stated that all sections regarding confidentiality and privacy should be removed, since they do not belong in this regulation.

Response: As the discussion insection 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 indiscussions 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 workgroup 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)), itis not within the scope of this final rule to address data retention time frames for administrative or clinical records.

r. Comment: One commenter stated that requiring provider practices todevelop policies, procedures, and training programs and to implementrecord keeping and documentationsystems would be tremendouslyresource-intensive and increase thecosts of health care.

Response: We expect that many of the standards of this final rule are alreadybeing met in one form or another by covered entities. For example, as part ofnormal business operations, health careproviders already take measures toprotect the health information in theirkeeping. 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 riskhas been eliminated and expressedconcern over phrases such as coveredentities must “assure that electronichealth information pertaining to anindividual remains secure”.

Response: We agree with the commenter that there is no such thingas a totally secure system that carries norisks to security. Furthermore, webelieve the Congress’ intent in the useof the word “ensure” in section 1173 (d) of the Act was to set an exceptionallyhigh goal for the security of electronicprotected health information. However, we note that the Congress alsorecognized that some trade-offs wouldbe necessary, and that “ensuring”protection did not mean providingprotection, no matter how expensive. See section 1173 (d) (1) (A) (ii) of the Act. Therefore, when we state that a coveredentity must ensure the safety of theinformation in its keeping, we intendthat a covered entity take steps, to thebest of its ability, to protect thatinformation. This will involveestablishing a balance between theinformation’s identifiable risks and vulnerabilities, and the cost of variousprotective measures, and will also bedependent upon the size, complexity, and capabilities of the covered entity, asprovided in §164.306 (b).

E.  Administrative Safeguards (§164.308)

We proposed that measures taken tocomply with the rule be appropriate toprotect the health information in acovered entity’s care. Most importantly, we proposed to require that both themeasures taken and documentation ofthose measures be kept current, that is, reviewed and updated periodically tocontinue appropriately to protect thehealth information in the care ofcovered entities. We would haverequired the documentation to be madeavailable to those individualsresponsible for implementing theprocedure. We proposed a number ofadministrative requirements and supporting implementation features, and required documentation for thoseadministrative requirements and implementation features. In this final rule, we have placedthese administrative standards in§164.308. We have reordered them, deleted much of the detail of theproposed requirements, as discussedbelow, and omitted two of the proposedsets of requirements (systemconfiguration requirements and arequirement for a formal mechanism forprocessing records) as discussed inparagraph 10 of the discussion of§164.308 of section III. E. of this preamble. Otherwise, the basic elementsof the administrative safeguards are adopted in this final rule as proposed.

1. Security Management Process (§164.308 (a) (1) (i) )

We proposed the establishment of aformal security management process toinvolve the creation, administration, and oversight of policies to address thefull range of security issues and toensure the prevention, detection, containment, and correction of securityviolations. This process would includeimplementation features consisting of arisk analysis, risk management, and sanction and security policies. We also proposed, in a separaterequirement under administrativeprocedures, an internal audit, which would be an in-house review of therecords of system activity (for example, logins, file accesses, and securityincidents) maintained by an entity. In this final rule, risk analysis, riskmanagement, and sanction policy areadopted as required implementation specifications although some of thedetails are changed, and the proposedinternal audit requirement has beenrenamed as “information system activityreview” and incorporated here as anadditional implementation specification.

a. Comment: Three commenters askedthat this requirement be deleted. Twocommenters cited this requirement as apossible burden. Several commenters asked that the implementation features be made optional.

Response: This standard and itscomponent implementation specifications form the foundation uponwhich an entity’s necessary securityactivities are built. See NIST SP 800–30, “Risk Management Guide forInformation Technology Systems, “chapters 3 and 4, January 2002. Anentity must identify the risks to and vulnerabilities of the information in itscare before it can take effective steps toeliminate or minimize those risks and vulnerabilities. Some form of sanctionor punishment activity must beinstituted for noncompliance. Indeed, we question how the statutoryrequirement for safeguards “to ensurecompliance * * * by a [coveredentity’s] officers and employees” couldbe met without a requirement for asanction policy. See section1176 (d) (2) (C) of the Act. Accordingly, implementation of these specifications remains mandatory. However, it isimportant to note that covered entitieshave the flexibility to implement thestandard in a manner consistent withnumerous factors, including such thingsas, but not limited to, their size, degreeof risk, and environment. We havedeleted the implementation specification calling for anorganizational security policy, as itduplicated requirements of the securitymanagement 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 entityperform a risk analysis often enough toensure that its security measures areadequate to provide the level of securityrequired by §164.306 (a). In theproposed rule, an assurance of adequatesecurity was framed as a requirement tokeep 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 analysismust look at risks to the covered entity’selectronic protected health information. A thorough and accurate risk analysiswould consider “all relevant losses”that would be expected if the securitymeasures were not in place”. Relevantlosses” would include losses caused byunauthorized uses and disclosures and loss of data integrity that would beexpected to occur absent the securitymeasures.

b. Comment: Relative to thedevelopment of an entity’s sanctionpolicy, one commenter asked that wedescribe the sanction penalties forbreach of security. Another suggestedestablishment of a standard to whichone’s conduct could be held and adoption of mitigating circumstances sothat the fact that a person acted in goodfaith would be a factor that could beused to reduce or otherwise minimizeany sanction imposed. Anothercommenter suggested sanction activitiesnot be implemented before the fullimplementation and testing of allelectronic transaction standards.

Response: The sanction policy is arequired implementation specificationbecause— (1) the statute requirescovered entities to have safeguards toensure compliance by officers and employees; (2) a negative consequenceto noncompliance enhances thelikelihood of compliance; and (3) sanction policies are recognized as ausual and necessary component of anadequate security program. The typeand severity of sanctions imposed, and for what causes, must be determined byeach covered entity based upon itssecurity policy and the relative severityof the violation.

c. Comment: Commenters requestedthe definitions of “risk analysis” and “breach”.

Response: “Risk analysis” is definedand described in the specification of thesecurity management process standard, and is discussed in the preamblediscussion of §164.308 (a) (1) (ii) (A) ofthis final rule. The term breach is nolonger used and is, therefore, notdefined. d.

Comment: One commenter askedwhether all health information isconsidered equally “sensitive, “ thethought being that, in determining risk, an entity may consider the loss of asmaller amount of extraordinarilysensitive data to be more significantthan the loss of a larger amount ofroutinely collected data. The commenters tated that common reasoning wouldsuggest that the smaller amount of datawould be considered more sensitive.

Response: All electronic protectedhealth information must be protected atleast to the degree provided by these standards. If an entity desires to protectthe information to a greater degree thanthe risk analysis would indicate, it is free to do so.

e. Comment: One commenter askedthat we add “threat assessment” to thisrequirement.

Response: We have not done thisbecause we view threat assessment as aninherent part of a risk analysis; addingit would be redundant.

f. Comment: We proposed arequirement for internal audit, the inhousereview of the records of systemactivity (for example, logins, fileaccesses, and security incidents) maintained by an entity. Severalcommenters wanted this requirementdeleted. One suggested the audit trailrequirement should not be mand atory, while another stated that internal auditswould be unnecessary if physicalsecurity requirements are implemented. A number of commenters asked thatwe clarify the nature and scope of whatan internal audit covers and what theaudit time frame should be. Severalcommenters offered further detailconcerning what should and should notbe required in an internal audit forsecurity purposes. One commenters tated that ongoing intrusion detectionshould be included in this requirement. Another wanted us to specify theretention times for archived audit logs. Several commenters had difficultywith the term “audit” and suggested wechange the title of the requirement to”logging and violation monitoring”. A number of commenters stated thisrequirement could result in an undueburden and would be economicallyunfeasible.

Response: Our intent for thisrequirement was to promote theperiodic review of an entity’s internalsecurity controls, for example, logs, access reports, and incident tracking. The extent, frequency, and nature of thereviews would be determined by thecovered entity’s security environment. The term “internal audit” apparently, based on the comments received, hascertain rigid formal connotations we didnot intend. We agree that theimplementation of formal internalaudits could prove burdensome or evenunfeasible, to some covered entities dueto the cost and effort involved. However, we do not want to overlookthe value of internal reviews. Based onour review of the comments and the textto which they refer, it is clear that thisrequirement should be renamed forclarity and that it should actually be animplementation specification of thesecurity management process ratherthan an independent standard. Weaccordingly remove “internal audit” asa separate requirement and add”information system activity review”under the security management processstandard as a mand atoryimplementation specification.

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

We proposed that the responsibilityfor security be assigned to a specificindividual or organization to provide anorganizational focus and importance tosecurity, and that the assignment bedocumented. Responsibilities would include the management and supervision of

the use of security measures to protect data,

the conduct of personnel in relation to theprotection of data.

In this final rule, we clarify that thefinal responsibility for a covered entity’ssecurity must be assigned to one official. The requirement for documentation isretained, but is made part of §164.316below. 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 82744through 87445. The same person could fill the role for both security and privacy.

a. Comment: Commenters wereconcerned that delegation of assignedsecurity responsibility, especially inlarge organizations, needs to be to morethan a single individual. Commenters believe that a large health organization’ssecurity concerns would likely crossmany departmental boundariesrequiring group responsibility.

Response: The assigned securityresponsibility standard adopted in thisfinal rule specifies that final securityresponsibility must rest with oneindividual to ensure accountabilitywithin each covered entity. More thanone individual may be given specificsecurity responsibilities, especiallywithin a large organization, but a singleindividual must be designated as havingthe overall final responsibility for thesecurity of the entity’s electronicprotected health information. Thisdecision also aligns this rule with thefinal Privacy Rule provisionsconcerning the Privacy Official.

b. Comment: One commenterdisagreed with placing assigned securityresponsibility as part of physicalsafeguards. The commenter suggestedthat assigned security responsibilityshould be included under theAdministrative Procedures.

Response: Upon review of the matrixand regulations text, we agree with thecommenter, because this requirementinvolves an administrative decision atthe highest levels of who should beresponsible for ensuring securitymeasures are implemented and maintained. Assigned securityresponsibility has been removed from”Physical safeguards” and is nowlocated under “Administrativesafeguards” at §164.308.

3. Workforce Security (§164.308 (a) (3) (i) )

We proposed implementation of anumber of features for personnelsecurity, including ensuring thatmaintenance personnel are supervisedby a knowledgeable person, maintaininga record of access authorizations, ensuring that operating and maintenance personnel have properaccess authorization, establishingpersonnel clearance procedures, establishing and maintaining personnelsecurity policies and procedures, and ensuring that system users have propertraining. In this final rule, to provideclarification and reduce duplication, wehave combined the “Assure supervisionof maintenance personnel byauthorized, knowledgeable person”implementation feature and the”Operating, and in some cases, maintenance personnel have proper access authorization” feature into oneaddressable implementation specification titled “Authorization and /or supervision”. In a related, but separate, requirementen titled “Termination procedures, “ we proposed implementation features forthe ending of an employee’semployment or an internal or externaluser’s access. These features wouldinclude things such as changingcombination locks, removal from accesslists, removal of user account (s), and theturning in of keys, tokens, or cards thatallow access. In this final rule, “Terminationprocedures” has been made anaddressable implementation specification under “Workforcesecurity”. This is addressable because incertain circumstances, for example, asolo physician practice whose staffconsists only of the physician’s spouse, formal procedures may not benecessary. The proposed “Personnel securitypolicy/procedure” and “record of accessauthorizations” implementation featureshave been removed from this final rule, as they have been determined to beredundant. Implementation of thebalance of the “Workforce security”implementation specifications and theother standards contained within thisfinal rule will result in assurance thatall personnel with access to electronicprotected health information have therequired access authority as well asappropriate clearances. a.

Comment: The majority ofcomments concerned the supervision ofmaintenance personnel by anauthorized knowledgeable person. Commenters stated this would not befeasible in smaller settings. Forexample, the availability of technicallyknowledgeable persons to ensure thissupervision would be an issue. We wereasked to either reword thisimplementation feature or delete it.

Response: We agree that a”knowledgeable” person may not beavailable to supervise maintenancepersonnel. We have accordinglymodified 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, forexample, operations and maintenancepersonnel, must either be supervised orhave authorization when working withelectronic protected health informationor in locations where it resides (see §164.308 (a) (3) (ii) (A) )

. Entities cand ecide on the feasibility of meeting thisspecification based on their riskanalysis. b.

Comment: The second largest groupof comments requested assurance that, with regard to the proposed “Personnelclearance procedure” implementationfeature, having appropriate clearancesdoes not mean performing backgroundchecks on everyone. We were asked todelete references to “clearance” and usethe term “authorization” in its place.

Response: We agree with thecommenters concerning backgroundchecks. This feature was not intended tobe interpreted as an absoluterequirement for background checks. Weretain the use of the term “clearance, “however, because we believe that itmore accurately conveys the screeningprocess intended than does the term”authorization”. We have attempted toclarify our intent in the language of§164.308 (a) (3) (ii) (B), which now reads, “Implement procedures to determinethat the access of a workforce memberto electronic protected healthinformation is appropriate”. The needfor and extent of a screening process isnormally based on an assessment ofrisk, cost, benefit, and feasibility as wellas other protective measures in place. Effective personnel screening processesmay be applied in a way to allow arange of implementation, from minimalprocedures to more stringent proceduresbased on the risk analysis performed bythe covered entity. So long as thestandard is met and the underlyingstandard of §164.306 (a) is met, coveredentities have choices in how they meetthese standards. To clarify the intent ofthis provision, we retitle theimplementation specification”Workforce clearance procedure”. c.

Comment: One commenter askedthat we expand the implementationfeatures to include the identification ofthe restrictions that should be placed onmembers of the workforce and others.

Response: We have not adopted thiscomment in the interest of maintainingflexibility as discussed in §164.306. Restrictions would be dependent uponjob responsibilities, the amount and type of supervision required and otherfactors. We note that a covered entityshould consider in this regard theapplicable requirements of the Privacy Rule (see, for example, §164.514 (d) (2) (relating to minimum necessaryrequirements), and §164.530 (c) (relatingto safeguards).

Comment: One commenter believesthat the proposed “Personnel security”requirement was reasonable, since anadministrative determination oftrustworthiness is needed beforeallowing access to sensitive information. Two commenters asked that we deletethe requirement entirely. A number ofcommenters requested that we deletethe implementation features. Anothercommenter stated that all theimplementation features may not beapplicable or even appropriate to agiven entity and should be so qualified.

Response: While we do not believethis requirement should be eliminated, we agree that all the implementation specifications may not be applicable oreven appropriate to a given entity. Forexample, a personal clearance may notbe reasonable or appropriate for a smallprovider whose only assistant is his orher spouse. The implementation specifications are not mand atory, butmust be addressed. This final rule hasbeen changed to reflect this approach (see §164.308 (a) (3) (ii) (B) )

e. Comment: The majority ofcommenters on the “Terminationprocedures” requirement asked that itbe made optional, stating that it may notbe applicable or even appropriate in allcircumstances and should be soqualified or posed as guidelines. Anumber of commenters stated that therequirement should be deleted. Onecommenter stated that much of thematerial covered under the”Termination procedures” requirementis already covered in “Informationaccess control”. A number ofcommenters stated that this requirement was too detailed and some of therequirements excessive.

Response: Based upon the commentsreceived, we agree that terminationprocedures should not be a separatestandard; however, consideration oftermination procedures remainsrelevant for any covered entity withemployees, because of the risksassociated with the potential forunauthorized acts by former employees, such as acts of retribution or use ofproprietary information for personalgain. We further agree with thereasoning of the commenters who askedthat 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 askedwhether human resource employeetermination policies and proceduresmust be documented to show the typesof security breaches that would result intermination.

Response: Policies and proceduresimplemented to adhere to this standardmust be documented (see §164.316below). The purpose of terminationprocedure documentation under thisimplementation specification is not todetail when or under whichcircumstances an employee should beterminated. This information wouldmore appropriately be part of theentity’s sanction policy. The purpose oftermination procedure documentation isto ensure that termination proceduresinclude security-unique actions to befollowed, for example, revokingpasswords and retrieving keys when atermination occurs.

4. Information Access Management (§164.308 (a) (4) )

We proposed an “information accesscontrol” requirement for establishmentand maintenance of formal, documentedpolicies and procedures defining levelsof access for all personnel authorized toaccess health information, and howaccess is granted and modified. In§164.308 (a) (4) (ii) (B) and (C) below, theproposed implementation features aremade addressable specifications. Wehave added in §164.308 (a) (4) (ii) (A), arequired implementation specificationto isolate health care clearinghouse functions to address the provisions ofsection 1173 (d) (1) (B) of the Act which related to this area.

a. Comment: One commenter asked that the requirement be deleted, expressing the opinion that this requirement goes beyond “reasonable boundaries” into regulating common business practices. In contrast, another asked that we expand this requirement to identify participating parties and access privileges relative to specific data elements.

Response: We disagree that this requirement improperly imposes upon business functions. Restricting access to those persons and entities with a need for access is a basic tenet of security. By this mechanism, the risk of inappropriate disclosure, alteration, or destruction of information is minimized. We cannot, however, specifically identify participating parties and access privileges relative to data elements within this regulation. These will vary depending upon the entity, the needs within the user community, the system in which the data resides, and the specific data being accessed. This standard is consistent with §164.514 (d) in the Privacy Rule (minimum necessary requirements foruse and disclosure of protected healthinformation), and is, therefore, beingretained.

b. Comment: Several commenters asked that we not mand ate theimplementation features, but leave themas optional, a suggested means ofcompliance. The commenters noted thatthis might make the rules more scalableand flexible, since this approach wouldallow providers to implementsafeguards that best addressed theirneeds. Along this line, one commenterexpressed the belief that eachorganization should implement featuresdeemed necessary based on its own riskassessment.

Response: While the informationaccess management standard in thisfinal rule must be met, we agree that theimplementation specifications at §164.308 (a) (4) (ii) (B) and (C) should notbe mand ated but posed as a suggestedmeans of compliance, which must beaddressed. These specifications may notbe applicable to all entities based ontheir size and degree of automation. Afully automated covered entity spanningmultiple locations and involvinghundreds of employees may determineit has a need to adopt a formal policyfor access authorization, while a smallprovider may decide that a desktopstandard operating procedure will meetthe specifications. The final rule hasbeen revised accordingly.

c. Comment: Clarification was requested concerning the meaning of “formal”.

Response: The word “formal” hascaused considerable concern amongcommenters , as it was thought “formal”carried the connotation of a rigidlydefined structure similar to what mightbe found in the Department of Defenseinstructions. As used in the proposedrule, this word was not intended toconvey such a strict structure. Rather, itwas meant to convey thatdocumentation should be an officialorganizational statement as opposed toword-of-mouth or cryptic notesscratched on a notepad. Whiledocumentation is still required (see §164.316), to alleviate confusion, theword “formal” has been deleted.

d. Comment: One commenter askedthat we clarify that this requirementrelates to both the establishment ofpolicies for the access control functionand to access control (theimplementation 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 berequired for all staff, including management. Training would include awareness training for all personnel, periodic security reminders, usereducation concerning virus protection, user education in the importance ofmonitoring login success/failure, and how to report discrepancies, and usereducation in password management. In this final rule, we adopt thisproposed requirement in modified form. For the standard “Security awarenessand training, “ in §164.308 (a) (5), werequire training of the workforce asreasonable and appropriate to carry outtheir functions in the facility. Allproposed training features have beencombined as implementation specifications under this standard. Specific implementation specificationsrelative to content are addressable. The”Virus protection” implementationfeature has been renamed “protectionfrom malicious software, “ because wedid not intend by the nomenclature toexclude coverage of malicious acts thatmight not come within the prior term, such as worms.

a. Comment: One commenter believesthat security awareness training for allVerDate Jan<31>2003 18:40 Feb 19, 2003 Jkt 200001 PO 00000 Frm 00017 Fmt 4701 Sfmt 4700 E:\FR\FM\20FER2. SGM 20FER2 system users would be too difficult todo in a large organization.

Response: We disagree with thecommenter. Security awareness trainingis a critical activity, regardless of anorganization’s size. This feature wouldtypically become part of an entity’soverall training program (which wouldinclude privacy and other informationtechnology items as well). For example, the Government Information SystemsReform ACT (GISRA) of 2000 requiressecurity awareness training as part ofFederal agencies’ information securityprograms, including Federal coveredentities, such as the Medicare program. In addition, National Institute of standards and Technology (NIST) SP800–16, Information TechnologySecurity Training Requirements, A roleand performance base model, April1998, provides an excellent source ofinformation and guidance on thissubject and is targeted at industry aswell as government activities. We alsonote that covered entities must havediscretion in how they implement therequirement, so they can incorporatethis training in other existing activities. One approach would be to require thistraining as part of employee orientation. b.

b. Comment: A number ofcommenters asked that this requirementbe made optional or used as a guidelineonly. Several commenters stated thatthis requirement is too specific and isburdensome. Several asked that theimplementation features be removed. Several others stated that thisrequirement is not appropriate foragents or contractors. One commenterasked how to apply this requirement tooutsiders having access to data. Anotherasked if this requirement included allsubcontractor staff. Others stated thatcontracts, signed by entities such asconsultants, that address trainingshould be sufficient.

Response: Security training remains arequirement because of its criticality;however, we have revised theimplementation specifications toindicate that the amount and type oftraining needed will be dependent uponan entity’s configuration and securityrisks. Business associates must be madeaware of security policies and procedures, whether through contractlanguage or other means. Coveredentities are not required to providetraining to business associates or anyoneelse that is not a member of theirworkforce. c.

c. Comment: Several commenters questioned why security awarenesstraining appeared in two places, under”Physical safeguards” as well as”Administrative safeguards”. Othersquestioned the appropriateness ofsecurity awareness training under”Physical safeguards”.

Response: We reviewed thedefinitions of the proposed “Awarenesstraining for all personnel” (“Administrative safeguards”) implementation feature and theproposed “Security awareness training” (“Physical safeguards”) requirement. We agree that, to avoid confusion and eliminate redundancy, securityawareness and training should appear inonly one place. We believe theappropriate location for it is under “Administrative safeguards” as such training is essentially an administrative function.

d. Comment: Several commenters objected to the blanket requirement forsecurity awareness training ofindividuals who may be on site for alimited time period (for example, asingle day).

Response: Each individual who hasaccess to electronic protected healthinformation must be aware of theappropriate security measures to reducethe risk of improper access, uses, and disclosures. This requirement does notmean lengthy training is appropriate inevery instance; there are alternativemethods to inform individuals ofsecurity responsibilities (for example, provisions of pamphlets or copies ofsecurity policies, and procedures). e.

e. Comment: One commenter askedthat “training” be changed to”orientation”.

Response: We believe the term”training, “ as presented within this ruleis the more appropriate term. The ruledoes not contemplate a one-time type ofactivity as connoted by “orientation, “but rather an on-going, evolving processas an entity’s security needs and procedures change.

f. Comment: Several commenters asked how often training should beconducted and asked for a definition of”periodic, “ as it appears in theproposed implementation feature”Periodic security reminders”. Oneasked if the training should be tailoredto job need.

Response: Amount and timing oftraining should be determined by eachcovered entity; training should be an ongoing, evolving process in response toenvironmental and operational changesaffecting the security of electronicprotected health information. Whileinitial training must be carried out bythe compliance date, we provideflexibility for covered entities toconstruct training programs. Trainingcan be tailored to job need if the coveredentity so desires.

6. Security Incident Procedures (§164.308 (a) (6) )

We proposed a requirement forimplementation of accurate and currentsecurity incident procedures: formal, documented report and responseprocedures so that security violationswould be reported and hand ledpromptly. We adopt this standard in thefinal rule, along with an implementation specification for response and reporting, since documenting and reportingincidents, as well as responding toincidents are an integral part of asecurity program.

a. Comment: Several commenters asked that we further define the scopeof a breach of security. Along this sameline, another commenter stated that theproposed security incident procedureswere too vague as stated. We were askedto specify what a security incidentwould be, what the internal chain forreporting procedures would be, and what should be included in thedocumentation (for example, hardware/software, personnel responses).

Response: We define a securityincident in §164.304. Whether aspecific action would be considered asecurity incident, the specific process ofdocumenting incidents, whatinformation should be contained in thedocumentation, and what theappropriate response should be will bedependent upon an entity’senvironment and the informationinvolved. An entity should be able torely upon the information gathered incomplying with the other security standards, for example, its riskassessment and risk managementprocedures and the privacy standards, to determine what constitutes a securityincident in the context of its businessoperations.

b. Comment: One commenter askedwhat types of incidents must bereported to outside entities. Anothercommented that we clarify that incidentreporting is internal.

Response: Internal reporting is aninherent part of security incidentprocedures. This regulation does notspecifically require any incidentreporting to outside entities. Externalincident reporting is dependent uponbusiness and legal considerations. c.

Comment: One commenter stated that network activity should beincluded here.

Response: We see no reason toexclude network activity under thisrequirement. Improper network activityshould be treated as a security incident, because, by definition, it represents animproper instance of access to or use ofinformation. d.

Comment: One commenter stated that this requirement should addresssuspected misuse also.

Response: We agree that securityincidents 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 theimplementation features.

Response: As indicated above, wehave adopted the proposed standardand combined the implementation 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 bemet.

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 databackup, disaster recovery, and 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 maybe 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 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 evening feasible, 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 agains tnatural 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 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 healthinformation 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 bedeemed 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.

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 in put 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 takenfor compliance; need for, or desirabilityof, independent verification, validation, and testing of system changes; and certifications required for off-the-shelf products used to meet the requirementsof 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 technology adopted or responses to newly recognized risks to the security of their information.

a. Comment: We received severalcomments 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 externalentity 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 coverall components of the proposed rule, not just the information systems.

Response: We agree. We have revised this section to reflect that evaluation would be both technical and non technical 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 §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 impracticalendeavor.

Response: While we will not assumethe task of certifying software and offthe-shelf products for the reasondescribed above, we have noted withinterest that other Government agenciessuch as the National Institute of standards and Technology (NIST) areworking towards that end. The healthcare industry is encouraged to monitorthe activity of NIST and providecomments and suggestions whenrequested (see http://www. niap. nist. gov. ).

f. Comment: One commenter stated, “With HCFA’s publishing of theseHIPAA standards, and their desire toretain the final responsibility fordetermining violations and imposingpenalties of the statute, it also seemsappropriate for HCFA to also providecertifying services to ensure securitycompliance”.

Response: In view of the enormousnumber and variety of covered entities, we believe that evaluation can best behand led through the marketplace, which can develop more usable and targeted evaluation instruments and processes.

9. Business Associate Contracts or Other Arrangements (§164.308 (b) (1) )

In the proposed rule §142. 308 (a) (2) ”Chain of trust” requirement, weproposed that covered entities berequired to enter into a chain of trustpartner agreement with their businesspartners, in which the partners wouldagree to electronically exchange dataand protect the integrity, confidentiality, and availability of thedata exchanged. This standard has beenmodified from the proposedrequirement 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 informationin accordance with these standards (see §164.314 (a) (1) ). The comments received on the proposed chain of trust partner agreements are discussed in section 2 “Business associate contracts and otherarrangements” of the discussion of §164.314 below.

10. 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 askedt hat 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. 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 wouldbe 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 toknow the scope of organizationalintegration required. Several othersasked if what we meant by SecurityConfiguration Management was changeor version control.

Response: Upon review, thisrequirement appears unnecessarybecause it is redundant of otherrequirements we are adopting in thisrule. A covered entity will haveaddressed the activities described by thefeatures under this proposedrequirement by virtue of havingimplemented the risk analysis, riskmanagement measures, sanctionpolicies, and information systemscriticality review called for under thesecurity management process. Theproposed documentationimplementation feature has been madea separate standard (see §164.316). Asa result, the Security ConfigurationManagement requirement is not adoptedin this final rule.

b. Formal Mechanism for Processing Records

The proposed rule proposed requiringa formal mechanism for processingrecords, 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 adoptedin the final rule.

Comment: Several commenters thought this requirement concerned theregulation of formal procedures for howan entity does business and stated thatsuch procedures should not beregulated. Others asked for additionalclarification of what is meant by thisrequirement. One commenter thoughtthe requirement too ambiguous and asked for clarification as to whether wemeant such things as “the properhand ling of storage media, databases, transmissions, “ or “the clinical realm ofprocesses”. Two commenters asked howextensive this requirement would beand whether systems’ user manuals and policies and procedures for hand linghealth information would suffice and what level of detail would be expected. Several thought this requirementcould result in a significant resourceand monetary burden to develop and maintain formal procedures. Two askedfor an explanation of the benefit to bederived from this requirement. One asked that covered entities berequired to document processes thatcreate a security risk only and suggestedthat a risk assessment would determinethe need for this documentation.

Response: We agree with thecommenters that the standard isambiguous, and upon review, isunnecessary because the remaining standards, for example, device and media controls, provide adequatesafeguards. Accordingly, thisrequirement is not adopted in this final rule.

F.  Physical Safeguards (§164.310)

We proposed requirements and implementation features fordocumented physical safeguards toguard data integrity, confidentiality, and availability. We proposed to requiresafeguards 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 featuresare adopted as addressable implementation specifications. The proposed requirements 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 thelanguage to more clearly describe”Physical safeguards”.

Response: In response to comments, we have revised the definition of”Physical safeguards” to read asfollows: “Physical safeguards aresecurity measures to protect a coveredentity’s electronic information systemsand related buildings and equipment, from natural and environmentalhazards, and unauthorized intrusion”.

b. Comment: One commenter wasconcerned that electronic securitysystems could not be used in lieu ofphysical security systems.

Response: This final rule does notpreclude the use of electronic securitysystems in lieu of, or in combinationwith, physical security systems to meeta “Physical safeguard” standard.

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

We proposed, under the “Physicalaccess controls” requirement, formal, documented policies and procedures forlimiting physical access to an entitywhile ensuring that properly authorizedaccess is allowed. These controls wouldinclude the following implementationfeatures: disaster recovery, emergencymode operation, equipment control (into and out of site), a facility securityplan, procedures for verifying accessauthorizations before physical access, maintenance records, need-to-knowprocedures for personnel access, sign-infor visitors and escort, if appropriate, and testing and revision. In §164.310 (a) (2) below, we combineand restate these as addressable implementation specifications. Theseare contingency operations, facilitysecurity plan, access control and validation procedures, and maintenancerecords.

a. Comment: Many commenters wereconcerned because the proposedlanguage would require implementationof all physical access control features. Other commenters were concerned thatthe language did not allow entities touse the results of their risk assessmentand risk management process to arriveat the appropriate solutions for them.

Response: We agree thatimplementation of all implementation specifications may not be appropriate inall situations. While the facility accesscontrols standard must be met, we agreethat the implementation specificationsshould not be required in allcircumstances, but should beaddressable. In this final rule, all four implementation specifications areaddressable. We have also determined, based on”level of detail” comments requestingconsolidation of the list ofimplementation features, that theproposed implementation feature”Equipment control (into and out ofsite) ” was redundant”. Equipmentcontrol” is already covered under the”Device and media controls” standardat §164.310 (d) (1). Accordingly, we have eliminated it as a separate implementation specification.

b. Comment: One commenter raisedthe issue of a potential conflict ofauthority between those having accessto the data and those responsible forchecking and maintaining accesscontrols.

Response: Any potential conflictsshould be identified, addressed, and resolved in the policies and proceduresdeveloped according to the standards under §164.308.

c. Comment: Several commenters questioned whether “Physical AccessControls” was a descriptive phrase todescribe a technology to be used, orwhether the phrase referred to a facility.

Response: We agree that the term”Physical” may be misleading; toremove any confusion, the requirementis reflected in this final rule as astandard titled “Facility accesscontrols”. We believe this is a moreprecise term to describe that thestandard, and its associatedimplementation specifications, isapplicable to an entity’s businesslocation or locations.

d. Comment: Several commenters requested that the disaster recovery and emergency mode operations features bemoved to “Administrative safeguards”. Other commenters recommended thatdisaster recovery and emergency modeoperations should be replaced by, and included in, a “ContingencyOperations” implementation feature.

Response: The “Administrativesafeguards” section addresses thecontingency planning that must be doneto contend with emergency situations. The placement of the disaster recoveryand emergency mode operationsimplementation specifications in the”Physical safeguards” section is alsoappropriate, however, because”Physical safeguards” defines thephysical operations (processes) thatprovide access to the facility toimplement the associated plans, developed under §164.308. We agree, however, that the term “contingencyoperations” better describes, and wouldinclude, disaster recovery and emergency mode operations, and havemodified the regulation text accordingly (see §164.310 (a) (1) )

e. Comment: Commenters wereconcerned about having to address intheir facility security plan the exterior/interior security of a building when theyare one of many occupants rather thanthe sole occupant. Additionalcommenters were concerned that theresponsibility for physical security ofthe building could not be delegated toa third party when the covered entityshares the building with other offices.

Response: The facility security plan isan addressable implementation specification. However, the coveredentity retains responsibility forconsidering facility security even whereit shares space within a building withother organizations. Facility securitymeasures taken by a third party must beconsidered and documented in thecovered entity’s facility security plan, when appropriate.

3. Workstation Use (§164.310 (b) )

We proposed policy and guidelineson workstation use that includeddocumented instructions/proceduresdelineating the proper functions to beperformed and the manner in whichthose functions are to be performed (forexample, logging off before leaving aworkstation unattended) to maximizethe security of health information. Inthis final rule, we adopt this standard.

Comment: One commenter wasconcerned most people may be misledby the use of “terminal” as an examplein the definition of workstation. Theconcern was that the standard onlyaddresses “fixed location devices, “while in many instances the workstationhas become a laptop computer.

Response: For clarity, we have addedthe definition of “workstation” to§164.304 and deleted the word”terminal” from the description ofworkstation use in §164.310 (b).

4. Workstation Security (§164.310 (c) )

We proposed that each organizationwould be required to put in placephysical safeguards to restrict access toinformation. In this final rule, we retainthe general requirement for a secureworkstation.

Comment: Comments were directedtoward the example profiled in thedefinition of a secure workstationlocation. It was believed that whatconstitutes a secure workstationlocation must be dependent upon theentity’s risk management process.

Response: We agree that whatconstitutes an appropriate solution to acovered entity’s workstation securityissues is dependent on the entity’s riskanalysis and risk management process. Because many commenters incorrectlyinterpreted the examples as the requiredand only solution for securing theworkstation location, we have modifiedthe regulations text description togeneralize the requirement (see §164.310 (c) )

. Also, for clarity, the title”Secure workstation location” has beenchanged to “Workstation security” (seealso the definition of “Workstation” at §164.304).

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

We proposed that covered entitieshave media controls in the form offormal, documented policies and procedures that govern the receipt and removal of hardware and /or software (for example, diskettes and tapes) intoand out of a facility. Implementationfeatures would have included “Accesscontrol, “ “Accountability” (trackingmechanism), “Data backup, “ “Datastorage, “ and “Disposal”. In this final rule, we adopt most ofthese provisions as addressable implementation specifications and adda specification for media re-use. Wechange the name from “Media controls”to “Device and media controls” to moreclearly reflect that this standardconcerns hardware as well as electronicmedia. The proposed “Access control”implementation feature has beenremoved, as it is addressed as part ofother standards (see section III. C. 12. c ofthis preamble).

a. Comment: One commenter wasconcerned about the exclusion ofremovable media devices from examplesof physical types of hardware and /orsoftware.

Response: The media examples usedwere not intended to represent allpossible physical types of hardwareand /or software. Removable mediadevices, although not specifically listed, are not intended to be excluded.

b. Comment: Comments were madethat the issue of equipment re-use orrecycling of media containing massstorage was not addressed in “Mediacontrols”.

Response: We agree that equipmentre-use or recycling should be addressed, since this equipment may containelectronic protected health information. The “Device and media controls”standard is accordingly expand ed toinclude a required implementation specification that addresses the re-use ofmedia (see §164.310 (d) (2) (ii) )

c. Comment: Several commenters asked for a definition of the term”facility, “ as used in the proposed”Media controls” requirementdescription. Commenters were unclearwhether we were talking about acorporate entity or the physical plant.

Response: The term “facility” refers tothe physical premises and the interiorand exterior of a building (s). We havea dded this definition to §164.304.

d. Comment: Several commenters believe the “Media controls”implementation features are too onerousand should be deleted.

Response: While the “Device and media controls” standard must be met, we believe, based upon further review, that implementation of all specificationswould not be necessary in everysituation, and might even be counterproductivein some situations. Forexample, small providers would beunlikely to be involved in large-scalemoves of equipment that would requiresystematic tracking, unlike, for example, large health care providers or healthplans. We have, therefore, reclassifiedthe “Accountability and data backup”implementation specification asaddressable to provide more flexibilityin meeting the standard.

e. Comment: One commenter wasconcerned about the accountabilityimpact of audit trails on systemresources and the pace of systemservices.

Response: The proposed audit trailimplementation feature appears as theaddressable “Accountability”implementation specification. The namechange better reflects the purpose and intended scope of the implementation specification. This implementation specification does not address audittrails within systems and /or software. Rather it requires a record of the actionsof a person relative to the receipt and removal of hardware and /or softwareinto and out of a facility that aretraceable to that person. The impact ofmaintaining accountability on systemresources and services will dependupon the complexity of the mechanismto establish accountability. For example, the appropriate mechanism for a givenentity may be manual, such as receiptand removal restricted to specificpersons, 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 wasconcerned about the resourceexpenditure (system and fiscal) for totale-mail backup and wanted aclarification of the extensiveness of databackup.

Response: The data an entity needs tobackup, and which operations should beused to carry out the backup, should bedetermined by the entity’s risk analysisand risk management process. The databackup plan, which is part of therequired contingency plan (see §164.308 (a) (7) (ii) (A) )

, should defineexactly what information is needed tobe retrievable to allow the entity tocontinue business “as usual” in the faceof damage or destruction of data, hardware, or software. The extent towhich e-mail backup would be neededwould be determined through thatanalysis.

G. Technical Safeguards (§164.312)

We proposed five technical securityservices requirements with supportingimplementation features: Accesscontrol; Audit controls; Authorizationcontrol; Data authentication; and Entityauthentication. We also proposedspecific technical security mechanismsfor data transmitted over acommunications network, Communications/network controls withsupporting implementation features;Integrity controls; Messageauthentication; Access controls; Encryption; Alarm; Audit trails; Entityauthentication; and Event reporting. In this final rule, we consolidate theseprovisions into §164.312. That sectionnow includes standards regardingaccess controls, audit controls, integrity (previously titled data authentication), person or entity authentication, and transmission security. As discussedbelow, while certain implementation specifications are required, many of theproposed security implementationfeatures are now addressable implementation specifications. Thefunction of authorization control hasbeen incorporated into the informationaccess management standard under§164.308, Administrative safeguards.

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

In the proposed rule, we proposed torequire that the access controlsrequirement include features foremergency access procedures and provisions for context-based, role-based, and /or user-based access; we alsoproposed the optional use of encryptionas a means of providing access control. In this final rule, we require unique useridentification and provision foremergency access procedures, and retain encryption as an addressable implementation specification. We alsomake “Automatic logoff” an addressable implementation specification”. Automatic logoff” and “Unique useridentification” were formerlyimplementation features under theproposed “Entity authentication” (see §164.312 (d) )

a. Comment: Some commenters believe that in specifying “Context, “”Role, “ and “User” based controls, useof other controls would effectively beexcluded, for example, “Partition rulebasedaccess controls, “ and thedevelopment of new access controltechnology.

Response: We agree with thecommenters that other types of accesscontrols should be allowed. There wasno intent to limit the implementationfeatures to the named technologies and this final rule has been reworded tomake it clear that use of any appropriateaccess control mechanism is allowed. Proposed implementation features titled”Context-based access, “Role-basedaccess”, 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 ofcomments were received objecting tothe identification of “Automatic logoff”as a mand atory implementation feature. Generally the comments asked that wenot be so specific and allow other formsof inactivity lockout, and that this typeof feature be made optional, based moreon the particular configuration in useand a risk assessment/analysis.

Response: We agree with thecomments that mandating an automaticlogoff is too specific. This final rule hasbeen written to clarify that the proposedimplementation feature of automaticlogoff now appears as an addressableaccess control implementation specification and also permits the use ofan equivalent measure. c.

Comment: We received commentsasking that encryption be deleted as animplementation feature and stating thatencryption is not required for “data atrest”.

Response: The use of file encryptionis an acceptable method of denyingaccess to information in that file. Encryption provides confidentiality, which is a form of control. The use ofencryption, for the purpose of accesscontrol of data at rest, should be basedupon an entity’s risk analysis. Therefore, encryption has been adoptedas an addressable implementation specification in this final rule. d.

Comment: We received onecomment stating that the proposedimplementation feature “Procedure foremergency access, “ is not access controland recommending that emergencyaccess be made a separate requirement.

Response: We believe that emergencyaccess is a necessary part of accesscontrols and, therefore, is properly arequired implementation specificationof the “Access controls” standard. Access controls will still be necessaryunder emergency conditions, althoughthey may be very different from thoseused in normal operationalcircumstances. For example, in asituation when normal environmentalsystems, including electrical power, have been severely damaged or renderedinoperative due to a natural or manmadedisaster, procedures should beestablished beforehand to provideguidance on possible ways to gainaccess to needed electronic protectedhealth information.

2. Audit Controls (§164.312 (b) )

We proposed that audit controlmechanisms be put in place to recordand examine system activity. We adoptthis requirement in this final rule.

a. Comment: We received a commentstating that “Audit controls” should bean implementation feature rather thanthe standard, and suggesting that wechange the title of the standard to”Accountability, “ and provideadditional detail to the audit controlimplementation feature.

Response: We do not adopt the term”Accountability” in this final rulebecause it is not descriptive of therequirement, which is to have thecapability to record and examine systemactivity. We believe that it isappropriate to specify audit controls asa type of technical safeguard. Entitieshave flexibility to implement thestandard in a manner appropriate totheir needs as deemed necessary bytheir own risk analyses. For example, see NIST Special Publication 800–14, Generally Accepted Principles and Practices for Securing InformationTechnology Systems and NIST SpecialPublication 800–33, UnderlyingTechnical Models for InformationTechnology Security.

b. Comment: One commenterrecommended that this final rule statethat audit control mechanisms shouldbe implemented based on the findingsof an entity’s risk assessment and riskanalysis. The commenter asserted thataudit control mechanisms should beutilized only when appropriate and necessary and should not adverselyaffect system performance.

Response: We support the use of arisk assessment and risk analysis todetermine how intensive any auditcontrol function should be. We believethat the audit control requirementshould remain mand atory, however, since it provides a means to assessactivities regarding the electronicprotected health information in anentity’s care.

c. Comment: One commenter wasconcerned about the interplay of Stateand Federal requirements for auditing ofprivacy data and requested additionalguidance on the interplay of privacyrights, laws, and the expectation foraudits under the rule.

Response: In general, the security standards will supercede any contraryprovision of State law. Security standards in this final rule establish aminimum level of security that coveredentities must meet. We note thatcovered entities may be required byother Federal law to adhere toadditional, or more stringent securitymeasures. Section 1178 (a) (2) of thestatute provides several exceptions tothis general rule. With regard toprotected health information, thepreemption of State laws and therelationship of the Privacy Rule to otherFederal laws is discussed in the Privacy Rule beginning at 65 FR 82480; thepreemption provisions of the rule are setout at 45 CFR part 160, subpart B. It should be noted that although thePrivacy Rule does not incorporate arequirement for an “audit trail”function, it does call for providing anaccounting of certain disclosures ofprotected health information to an individual upon request. There has beena tendency to assume that this Privacy Rule requirement would be satisfied viasome sort of process involving audittrails. We caution against assuming thatthe Security Rule’s requirement for anaudit capability will satisfy the Privacy Rule’s requirement regarding accountingfor disclosures of protected healthinformation. The two rules coveroverlapping, but not identicalinformation. Further, audit trails aretypically used to record uses within anelectronic information system, while thePrivacy Rule requirement for accountingapplies to certain disclosures outside ofthe covered entity (for example, topublic health authorities).

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

We proposed under the “Dataauthentication” requirement, that eachorganization be required to corroboratethat data in its possession have not beenaltered or destroyed in an unauthorizedmanner and provided examples ofmechanisms that could be used toaccomplish this task. We adopt theproposed requirement for dataauthentication in the final rule as anaddressable implementation specification “Mechanism toauthenticate data, “ under the”Integrity” standard.

a. Comment: We received a largenumber of comments requestingclarification of the “Dataauthentication” requirement. Many ofthese comments suggested that therequirement be called “Data integrity”instead of “Data authentication”. Othersasked for guidance regarding just what”data” must be authenticated. Asignificant number of commenters indicated that this requirement wouldput an extraordinary burden on largesegments of the health care industry, particularly when legacy systems are inuse. Requests were received to makethis an “optional” requirement, basedon an entity’s risk assessment and analysis.

Response: We adopt the suggested”integrity” terminology because it moreclearly describes the intent of thestandard. We retain the meaning of theterm “Data authentication” under theaddressable implementation specification “Mechanism toauthenticate data, “ and provide anexample of a potential means to achievedata integrity. Error-correcting memory and magnetic disc storage are examples ofthe built-in data authenticationmechanisms that are ubiquitous inhardware and operating systems today. The risk analysis process will addresswhat data must be authenticated and should provide answers appropriate tothe different situations faced by thevarious health care entitiesimplementing this regulation. Further, we believe that this standardwill not prove difficult to implement, since there are numerous techniquesavailable, such as processes that employdigital signature or check sumtechnology to accomplish the task. b.

Comment: We received numerouscomments suggesting that “Doublekeying” be deleted as a viable “Dataauthentication” mechanism, since thispractice was generally associated with the use of punched cards.

Response: We agree that the processof “Double keying” is outdated. Thisfinal rule omits any reference to”Double keying”.

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

We proposed that an organizationimplement the requirement for “Entityauthentication”, the corroboration thatan entity is who it claims to be”. Automatic logoff” and “Unique useridentification” were specified asmand atory features, and were to becoupled with at least one of thefollowing features: (1) A “biometric”identification system; (2) a “password”system; (3) a “personal identificationnumber”; and (4) “telephone callback, “or a “token” system that uses a physicaldevice for user identification. In this final rule, we provide a generalrequirement for person or entityauthentication without the specifics ofthe proposed rule.

Comment: We received commentsfrom a number of organizationsrequesting that the implementationfeatures for entity authentication beeither deleted in their entirety or at leastbe made optional. On the other hand, comments were received requesting thatthe use of digital signatures and softtokens be added to the list ofimplementation features.

Response: We agree with thecommenters that many differentmechanisms may be used toauthenticate entities, and this final rulenow reflects this fact by notincorporating a list of implementation specifications, in order to allow coveredentities to use whatever is reasonableand appropriate”. Digital signatures”and “soft tokens” may be used, as wellas many other mechanisms, toimplement this standard. The proposed mand atoryimplementation feature, “Unique useridentification, “ has been moved fromthis standard and is now a requiredimplementation specification under”Access control” at §164.312 (a) (1) ”. Automatic logoff” has also been movedfrom this standard to the “Accesscontrol” standard and is now anaddressable implementation specification.

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

Under “Technical SecurityMechanisms to Guard AgainstUnauthorized Access to Data that isTransmitted Over a CommunicationsNetwork, “ we proposed that”Communications/network controls” berequired to protect the security of healthinformation when being transmittedelectronically from one point to anotherover open networks, along with acombination of mand atory and optionalimplementation features. We proposedthat some form of encryption must beemployed on “open” networks such asthe Internet or dial-up lines. In this final rule, we adopt integritycontrols and encryption, as addressable implementation specifications.

a. Comment: We received a number ofcomments asking for overallclarification as well as a definition ofterms used in this section. A definitionfor the term “open networks” was themost requested action, but there was ageneral expression of dislike for themanner in which we approached thissection, with some comments suggestingthat the entire section be rewritten. Asignificant number of comments werereceived on the question of encryptionrequirements when dial-up lines were tobe employed as a means of connectivity. The overwhelming majority stronglyurged that encryption not be mand atorywhen using any transmission mediaother than the Internet, but rather beconsidered optional based on individualentity risk assessment/analysis. Manycomments noted that there are very fewknown breaches of security over dial-uplines and that nonjudicious use ofencryption can adversely affectprocessing times and become bothfinancially and technically burdensome. Only one commenter suggested that”most” external traffic should beencrypted.

Response: In general, we agree with the commenters who asked forclarification and revision. This final rulehas been significantly revised to reflecta much simpler and more directrequirement. The term”Communications/network controls”has been replaced with “Transmissionsecurity” to better reflect therequirement that, when electronicprotected health information istransmitted from one point to another, it must be protected in a mannercommensurate with the associated risk. We agree with the commenters thatswitched, point-to-point connections, for example, dial-up lines, have a verysmall probability of interception. Thus, we agree that encryption shouldnot be a mand atory requirement fortransmission over dial-up lines. We alsoagree with commenters who mentionedthe financial and technical burdensassociated with the employment ofencryption tools. Particularly whenconsidering situations faced by smalland rural providers, it became clear thatthere is not yet available a simple and interoperable solution to encrypting emailcommunications with patients. Asa result, we decided to make the use ofencryption in the transmission processan addressable implementation specification. Covered entities areencouraged, however, to consider use ofencryption technology for transmittingelectronic protected health information, particularly over the internet. As business practices and technologychange, there may arise situations whereelectronic protected health informationbeing transmitted from a covered entitywould be at significant risk of beingaccessed by unauthorized entities. Where risk analysis showed such risk tobe significant, we would expect coveredentities to encrypt those transmissions, if appropriate, under the addressable implementation specification forencryption. We do not use the term “opennetwork” in this final rule because itsmeaning is too broad. We include as anaddressable implementation specification the requirement thattransmissions be encrypted whenappropriate based on the entity’s riskanalysis.

b. Comment: We received commentsrequesting that the implementationfeatures be deleted or made optional. Three commenters asked that therequirement for an alarm be deleted.

Response: This final rule has beenrevised to reflect deletion of thefollowing implementation features: (1) The alarm capability; (2) audit trail; (3) entity authentication; and (4) eventreporting. These features wereassociated with a proposed requirementfor “Communications/network controls”and have been deleted since they arenormally incorporated bytelecommunications providers as part ofnetwork management and controlfunctions that are included with theprovision of network services. A healthcare entity would not expect to beresponsible for these technicaltelecommunications features”. Accesscontrols” has also been deleted from theimplementation features since theconsideration of the use of encryptionwill satisfy the intent of this feature. Weretain as addressable implementation specifications two features: (1) ”Integrity controls” and “encryption”“. Message authentication” has beendeleted as an implementation featurebecause the use of data authenticationcodes (called for in the “integritycontrols” implementation specification) satisfies the intent of “Messageauthentication”.

c. Comment: A number of commentswere received asking that this final ruleestablish a specific (or at least aminimum) cryptographic algorithmstrength. Others recommended that therule not specify an encryption strengthsince technology is changing so rapidly. Several commenters requestedguidelines and minimum encryption standards for the Internet. Anotherstated that, since an example wasincluded (small or rural providers forexample), the government should feelfree to name a specific encryptionpackage. One commenter stated that therequirement for encryption on theInternet should reference the “CMSInternet Security Policy”.

Response: We remain committed tothe principle of technology neutralityand agree with the comment thatrapidly changing technology makes itimpractical and inappropriate to name aspecific technology. Consistent with thisprinciple, specification of an algorithmstrength or specific products would beinappropriate. Moreover, rapidadvances in the success of “brute force”cryptanalysis techniques suggest thatany minimum specification would soonbe outmoded. We maintain that it ismuch more appropriate for this final rule to state a general requirement forencryption protection when necessaryand depend on covered entities tospecify technical details, such asalgorithm types and strength. Because”CMS Internet Security Policy” is thepolicy of a single organization and applies only to information sent to CMS, and not between all covered entities, wehave not referred to it here. d.

Comment: The proposed definitionof “Integrity controls” generatedcomments that asked that the word”validity” be changed to “Integrity”. Commenters were concerned about theability of an entity to ensure thatinformation was “valid”.

Response: We agree with thecommenters about the meaning of theword “validity” in the context of theproposed definition of “Integritycontrols”. We have named “integritycontrols” as an implementation specification in this final rule to requiremechanisms to ensure thatelectronically transmitted information isnot improperly modified withoutdetection (see §164.312 (c) (1))

e. Comment: Three commenters askedfor clarification and guidance regardingthe unsolicited electronic receipt ofhealth information in an unsecuredmanner, for example, when theinformation was submitted by a patientvia e-mail over the Internet. Commenters asked for guidance as towhat was their obligation to protect datareceived in this manner.

Response: The manner in whichelectronic protected health informationis received by a covered entity does notaffect the requirement that securityprotection must subsequently beafforded to that information by thecovered entity once that information isin possession of the covered entity.

6. Proposed Requirements Not Adoptedin This Final Rule

Authorization Control

We proposed, under “TechnicalSecurity Services to Guard DataIntegrity, Confidentiality, and Availability, “ that a mechanism berequired for obtaining consent for theuse and disclosure of health informationusing either “Role-based access” or”User-based access” controls. In thisfinal rule, we do not adopt thisrequirement.

Comment: We received a largenumber of comments regarding use ofthe word “consent”. It was pointed outthat this could be construed to meanpatient consent to the use or disclosureof patient information, which wouldmake this a privacy issue, rather thanone of security. Other commentssuggested deletion of the requirement inits entirety. We received a commentasking for clarification about thedistinction between “Access control”and “Authorizations”.

Response: These requirements wereintended to address authorization ofworkforce members and others for theuse and disclosure of healthinformation, not patient consent. Uponreviewing the differences between”Access control” and “Authorizationcontrol, “ we found it to be unnecessaryto retain “Authorization control” as aseparate requirement. Both the accesscontrol and the authorization controlproposed requirements involvedimplementation of types of automatedaccess controls, that is, role-basedaccess and user-based access. It can beargued that the process of managingaccess involves allowing and restrictingaccess to those individuals that havebeen authorized to access the data. Theintent of the proposed authorizationcontrol implementation feature is now incorporated in the access authorizationimplementation specification under theinformation access managementstandard in §164.308 (a) (4). Under theinformation access managementstandard, a covered entity mustimplement, if appropriate and reasonable to its situation, policies and procedures first to authorize a person toaccess electronic protected healthinformation and then to actuallyestablish such access. These policiesand procedures will enable entities tofollow the Privacy Rule minimumnecessary requirements, which providewhen persons should have access toinformation.

H. Organizational Requirements (§164.314)

We proposed that each health careclearinghouse must comply with thesecurity standards to ensure all healthinformation and activities are protectedfrom unauthorized access. If theclearinghouse is part of a largerorganization, then unauthorized accessby the larger organization must beprevented. We also proposed thatparties processing data through a thirdparty would be required to enter into achain of trust partner agreement, acontract in which the parties agree toelectronically exchange data and toprotect the transmitted data inaccordance with the security standards. In this final rule, we have adopted theconcepts of hybrid and affiliatedentities, as previously defined in§164.504, and now defined in§164.103, and business associates asdefined in §160.103, to be consistentwith the Privacy Rule. Generalorganizational requirements related toaffiliated covered entities and hybridentities are now contained in a new§164.105. The proposed chain of trustpartner agreement has been replaced bythe standards for business associatecontracts or other arrangements and the standards for group health plans. Consistent with the statute and thepolicy of the Privacy Rule, this final ruledoes not require noncovered entities tocomply with the security standards.

1. Health Care Clearinghouses

The proposed rule proposed that if ahealth care clearinghouse were part of alarger organization, it would be requiredto ensure that all health informationpertaining to an individual is protectedfrom unauthorized access by the largerorganization; this statement closelytracked the statutory language in section1173 (d) (1) (B) of the Act. Since the pointof the statutory language is to ensurethat health care information in thepossession of a health careclearinghouse is not inappropriatelyaccessed by the larger organization ofwhich it is a part, this final ruleimplements the statutory languagethrough the information accessmanagement provision of§164.308 (a) (4) (ii) (A). The final rule, at §164.105, makes thehealth care component and affiliatedentity standards of the Privacy Ruleapplicable to the security standards. Therefore, we have not changed those standards substantively. In pertaining tothe Privacy Rule, we have simplymoved them to a new location in part164.Any differences between §164.105and §164.504 (a) through (d) reflects theaddition of requirements specific to thesecurity standards. The health care component approachwas developed in response to extensivecomment received principally on thePrivacy Rule. See 65 FR 82502 through82503 and 82637 through 82640 for adiscussion of the policy concernsunderlying the health care componentapproach. Since the security standards are intended to support the protection ofelectronic information protected by thePrivacy Rule, it makes sense toincorporate organizational requirementsthat parallel those required of coveredentities by the Privacy Rule. This policywill also minimize the burden ofcomplying with both rules.

a. Comment: Relative to the followingpreamble statement (63 FR 43258) : “Ifthe clearinghouse is part of a largerorganization, then security must beimposed to prevent unauthorized accessby the larger organization”. Onecommenter asked what is considered tobe “the larger organization”. Forexample, if a clearinghouse functionoccurs in a department of a largerbusiness entity, will the regulationcover all internal electroniccommunication, such as e-mail, withinthe larger business and all externalelectronic communication, such as emailwith its owners?

Response: The “larger organization”is the overall business entity that aclearinghouse would be part of. Underthe Security Rule, the largerorganization must assure that the healthcare clearinghouse function hasinstituted measures to ensure only thatelectronic protected health informationthat it processes is not improperlyaccessed by unauthorized persons orother entities, including the largerorganization. Internal electroniccommunication within the largerorganization will not be covered by therule if it does not involve theclearinghouse, assuming that it hasdesignated health care components, ofwhich the health care clearinghouse isone. External communication must beprotected as sent by the clearinghouse, but need not be protected once received.

b. Comment: One commenter askedthat the first sentence in §142. 306 (b) ofthe proposed rule, “If a health care clearinghouse is part of a larger organization, it must assure all healthinformation is protected fromunauthorized access by the largerorganization” be expanded to read, “If a health care clearinghouse or any otherhealth care entity is part of a largerorganization..”.

Response: The Act specificallyprovides, at section 1173 (d) (1) (B), thatthe Secretary must adopt standards toensure that a health care clearinghouse, if part of a larger organization, haspolicies and security procedures toprotect information from unauthorizedaccess by the larger organization. Health care providers and healthplans are often part of largerorganizations that are not themselveshealth care providers or health plans. The security measures implemented by health plans and covered health care providers should protect electronic protected health information incircumstances such as the one identifiedby the commenter. Therefore, we agreewith the comment that the requirement should be expanded as suggested by the commenter. In this final rule, thosecomponents of a hybrid entity that aredesignated as health care componentsmust comply with the security standards and protect againstunauthorized access with respect to theother components of the larger entity inthe same way as they must deal withseparate entities.

2. Business Associate Contracts and Other Arrangements

We proposed that parties processingdata through a third party would be required to enter into a chain of trust partner agreement, a contract in whichthe parties agree to electronicallyexchange data and to protect thetransmitted data. This final rule narrowsthe scope of agreements required. Itessentially tracks the provisions in§164.502 (e) and §164.504 (e) of thePrivacy Rule, although appropriate modifications have been made in this rule to the required elements of the contract. In this final rule, a contract betweena covered entity and a businessassociate must provide that the businessassociate must:

implementsafeguards that reasonably and appropriately protect theconfidentiality, integrity, and availability of the electronic protectedhealth information that it creates, receives, maintains, or transmits onbehalf of the covered entity;

ensurethat any agent, including asubcontractor, to whom it provides thisinformation agrees to implementreasonable and appropriate safeguards;

report to the covered entity anysecurity incident of which it becomesaware;

make its policies and procedures, and documentationrequired by this subpart relating to suchsafeguards, available to the Secretary forpurposes of determining the coveredentity’s compliance with this subpart;and

authorize termination of the contract by the covered entity if thecovered entity determines that thebusiness associate has violated amaterial term of the contract.

When a covered entity and itsbusiness associate are bothgovernmental entities, an “otherarrangement” is sufficient. The coveredentity is in compliance with thisstandard if it enters into a memorand umof understand ing with the businessassociate that contains terms thataccomplish the objectives of the abovedescribedbusiness associate contract. However, the covered entity may omitfrom this memorand um the terminationauthorization required by the businessassociate contract provisions if thisauthorization is inconsistent with thestatutory obligations of the coveredentity or its business associate. If otherlaw (including regulations adopted bythe covered entity or its businessassociate) contains requirements applicable to the business associate thataccomplish the objectives of the above described business associate contract, acontract or agreement is not required. If a covered entity enters into otherarrangements with anothergovernmental entity that is a businessassociate, such arrangements may omitprovisions equivalent to the terminationauthorization required by the businessassociate contract, if inconsistent with the statutory obligation of the coveredentity 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 providea service described in the definition ofbusiness associate in §160.103 of thissubchapter to a covered entity, thecovered entity may permit the businessassociate to receive, create, maintain, ortransmit electronic protected healthinformation on its behalf to the extent necessary to comply with the legalmand ate without meeting therequirements of the above-describedbusiness associate contract, provided that the covered entity attempts in good faith to obtain satisfactory assurances asrequired by the above describedbusiness associate contract and documents the attempt and the reasonsthat these assurances cannot beobtained. We have added a standard for grouphealth plans that parallels the provisions of the Privacy Rule. Itbecame apparent during the course ofthe security and privacy rulemaking thatour original chain of trust approach was both overly broad in scope and failed toaddress appropriately the circumstancesof certain covered entities, particularlythe ERISA group health plans. These latter considerations and the solutions arrived at in the Privacy Rule are described in detail in the Privacy Ruleat 65 FR 82507 through 82509. Because the purpose of the security standards is in part to reinforce privacy protections, it makes sense to align theorganizational policies of the two rules. This decision should also makecompliance less burdensome forcovered entities than would a decisionto have different organizationalrequirements for the two sets of rules. Thus, we have added at §164.314 (b) a standard for group health plan thattracks the standard at §164.504 (f) veryclosely. The purpose of these provisionsis to ensure that, except when theelectronic protected health informationdisclosed to a plan sponsor is summaryhealth information or enrollment ordisenrollment information as providedfor by §164.504 (f), group health pland ocuments provide that the plansponsor will reasonably and appropriately safeguard electronicprotected health information created, received, maintained or transmitted toor by the plan sponsor on behalf of thegroup health plan. The plan documentsof the group health plan must beamended to incorporate provisions torequire the plan sponsor to implementreasonable and appropriate safeguardsto protect the confidentiality, integrity, and availability of the electronicprotected health information that itcreates, receives, maintains, or transmitson behalf of the group health plan;ensure that the adequate separationrequired by §164.504 (f) (2) (iii) issupported by reasonable and appropriate security measures; ensurethat any agents, including asubcontractor, to whom it provides thisinformation agrees to implementreasonable and appropriate safeguardsto protect the information; report to thegroup health plan any security incidentof which it becomes aware; and make itspolicies and procedures and documentation relating to thesesafeguards available to the Secretary forpurposes of determining the grouphealth plan’s compliance with thissubpart.

a. Comment: Several commenters expressed confusion concerning theapplicability of proposed §142.104 to security.

Response: The proposed preambleincluded language generally applicableto most of the proposed standards underHIPAA. Proposed §142. 104 concernedgeneral requirements for health plansrelative to processing transactions. Weproposed that plans could not refuse toconduct a transaction as a standardtransaction, or delay or otherwiseadversely affect a transaction on thegrounds that it was a standardtransaction; health informationtransmitted and received in connectionwith a transaction must be in the formof standard data elements; and plansconducting transactions through anagent must ensure that the agent met allthe requirements that applied to thehealth plan. Except for the statementthat a plan’s agent (“business associate”in the final rule) must meet therequirements (which would includesecurity) that apply to the health plan, this proposed section did not pertain tothe security standards and wasaddressed in the Transaction Rule.

b. Comment: The majority ofcomments concerned proposed rulelanguage stating “the same level ofsecurity will be maintained at all linksin the chain * * *” Commenters believed the current language will havean adverse impact on one of the securitystandard’s basic premises, which isscalability. It was requested that thelanguage be changed to indicate that, while appropriate security must bemaintained, all partners do not need tomaintain the same level of security. A number of commenters expressedsome confusion concerning theirresponsibility for the security ofinformation once it has passed fromtheir control to their trading partner’scontrol, and so on down the tradingpartner chain. Requests were made thatwe clarify that chain of trust partneragreements were really between twoparties, and that, if a trading partneragreement has been entered into, anygiven partner would not be responsible, or liable, for the security of data once itis out of his or her control. In line with this concern, severalcommenters were concerned that theywould have some responsibility toensure the level of security maintainedby their trading partner. Several commenters believe a chain oftrust partner agreement should not be asecurity requirement. One commenters tated that because covered entitiesmust already conform to the regulation requirements, a “chain of trust”agreement does not add to overallsecurity. Compliance with theregulation should be sufficient.

Response: We believe the commenters are correct that the rule as proposedwould— (1) not allow for scalability; and (2) would lead an entity to believe it isresponsible, and liable, for making sureall entities down the line maintain thesame level of security. The confusionhere 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 wouldneed to implement the same security technology or measures and procedures. We have replaced the proposed”Chain of trust” standard with astandard for “Business associatecontracts and other arrangements”. When another entity is acting as abusiness associate of a covered entity, we require the covered entity to requirethe other entity to protect the electronicprotected health information that itcreates, receives, maintains or transmitson the covered entity’s behalf. The levelof security afforded particular electronicprotected health information should notdecrease just because the covered entityhas made the business decision toentrust a business associate with usingor disclosing that information inconnection with the performance ofcertain functions instead of doing thosefunctions itself. Thus, the rule belowrequires covered entities to require theirbusiness associates to implement certainsafeguards and take other measures toensure 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 theanalogous requirements at 45 CFR164.504 (e) of the Privacy Rule, althoughthey have been adapted to reflect theobjectives and context of the security standards. Compare, in particular, 45CFR 164.504 (e) (2) (ii) with§164.314 (a) (1). We have not importedall of the requirements of 45 CFR164.504 (e), however, as many have noclear analog in the security context (see, for example, 45 CFR 164.504 (e) (2) (i) regarding permitted and required usesand disclosures made by a businessassociate). HHS had previouslycommitted to reconciling its securityand privacy policies regarding businessassociates (see 65 FR 82643). The closerelationship of many of the organizational requirements in section164.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 notacting as a business associate for thecovered entity, but rather is acting in thecapacity of some other sort of tradingpartner, we do not require the coveredentity to require the other entity toadopt particular security measures, aspreviously proposed. This policy islikewise consistent with the generalapproach of the Privacy Rule (see thediscussion in the Privacy Rule at 65 FR82476). The covered entity is free tonegotiate security arrangements with itsnon-business associate trading partners, but this rule does not require it to do so. A similar approach underlies§164.314 (b) below. These provisions arelikewise drawn from, and intended tosupport, the analogous privacyprotections provided for by 45 CFR164.504 (f) (see the discussion of§164.504 (f) of the Privacy Rule at 65 FR82507 through 82509, and 82646through 82648). As with the businessassociate contract provisions, however, they are imported and adapted only tothe extent they make sense in thesecurity context. Thus, for example, therequirement at §164.504 (f) (2) (ii) (C) prohibits the plan documents frompermitting disclosure of protectedhealth information to the plan sponsorfor employment-related purposes. Asthis prohibition goes entirely to thepermissibility of a particular type ofdisclosure, it has no analog in§164.314 (b).

c. Comment: Several commenters stated that if security features aredetermined by agreements establishedbetween “trading partners, “ as stated inthe proposed regulations, there shouldbe some guidelines or boundaries forthose agreements so that extreme orunusual provisions are not permitted.

Response: This final rule sets abaseline, or minimum level, of securitymeasures that must be taken by acovered entity and stipulates that abusiness associate must also implementreasonable and appropriate safeguards. This final rule does not, however, prohibit a covered entity fromemploying more stringent securitymeasures or from requiring a businessassociate to employ more stringentsecurity measures. A covered entity maydetermine that, in order to do businesswith it, a business associate must alsoemploy equivalent measures. Thiswould be a business decision and wouldnot be governed by the provisions ofthis rule. Security mechanisms relativeto the transmission of electronicprotected health information betweenentities may need to be agreed upon byboth parties in order to successfullycomplete the transmission. However, the determination of the specifictransmission mechanisms and thespecific security features to beimplemented remains a businessdecision.

d. Comment: Several commenters asked whether existing contracts couldbe used to meet the requirement for atrading partner agreement, or does therule require entry into a new contractspecific to this purpose. Also, thecommenters want to know about thosewhose working agreements do notinvolve written contractual agreement:Do they now need to set up formalagreements and incur the additionalexpense that would entail?

Response: This final rule requireswritten agreements between coveredentities and business associates. Newcontracts do not have to be entered intospecifically for this purpose, if existingwritten contracts adequately address theapplicable requirements (or can beamended to do so).

e. Comment: Several commenters asked whether covered entities areresponsible for the security of allindividual health information sent tothem, or only information sent by chainof trust partners. They also asked if theycan refuse to process standardtransactions sent to them in anunsecured fashion. In addition, theyinquired if they can refuse to sendsecured information in standardtransactions to entities not required bylaw to secure the information. Onecommenter asked if there is a formulafor understand ing in any particular setof relationships where the ultimateresponsibility for compliance with the standards would lie.

Response: Pursuant to theTransactions Rule, if a health planreceives an unsecured standardtransaction, it may not refuse to processthat transaction simply because it wassent in an unsecured manner. Thehealth plan is not responsible under thisrule, for how the transaction was sent toit (unless the transmission was made bya business associate, in which casedifferent considerations apply) ;however, once electronic protectedhealth information is in the possessionof a covered entity, the covered entity isresponsible for the security of theelectronic protected health informationreceived. The covered entity mustimplement technical securitymechanisms to guard againstunauthorized access to electronicprotected health information that istransmitted over an electroniccommunication network. In addition, the rule requires the transmitting covered entity to obtain writtenassurance from a business associatereceiving the transmission that it willprovide an adequate level of protectionto the information. For the businessassociate provisions, see §164.308 (b) and §164.314 (a) of this final rule.

f. Comment: One commenter askedwhat security standards a vendor havingaccess to a covered entity’s healthinformation during development, testing, and repair must meet and wanted to know whether the ruleanticipates having a double layer ofsecurity compliance (one at the userlevel and one at the vendor level). If so, the commenter believes this will causeduplication of work.

Response: In the situation described, the vendor would be acting as abusiness associate. The covered entitymust require the business associate toimplement reasonable and appropriatesecurity protections of electronicprotected health information. Thisrequirement, however, does not imposedetailed requirements for how that levelof protection must be achieved. Theresulting flexibility should permitentities and their business associates toadapt their security safeguards in waysthat make sense in their particularenvironments.

g. Comment: A number ofcommenters requested sample contractlanguage or models of contracts. We alsoreceived one comment that suggestedthat we should not dictate the contentsof contracted agreements.

Response: We will considerdeveloping sample contract language aspart of our guideline development.

I.     Policies and Procedures and Documentation Requirements (§164.316)

We proposed requiring documentedpolicies and procedures for the routineand nonroutine receipt, manipulation, storage, dissemination, transmission, and /or disposal of health information. We proposed that the documentation bereviewed and updated periodically. We have emphasized throughout thisfinal rule the scalability allowed by thesecurity standards. This final rulerequires covered entities to implementpolicies and procedures that arereasonably designed, taking intoaccount the size and type of activities ofthe covered entity that relate toelectronic protected health information, and requires that the policies and procedures must be documented inwritten form, which may be inelectronic form. This final rule alsoprovides that a covered entity maychange its policies and procedures at any time, provided that it documents and implements the changes in accordance with the applicable requirements. Covered entities mustalso document designations, forexample, of affiliation between coveredentities (see §164.105 (b) ), and otheractions, as required by other provisionsof the subpart.

1. Comment: One commenter wanteddevelopment of written policiesregarding such things as confidentialityand privacy rights for access to medicalrecords, and approval of research by areview board when appropriate.

Response: These issues are covered inthe Privacy Rule (65 FR 82462) (see, inparticular, §164.512 (i), §164.524, and §164.530 (i) ).

2. Comment: One commenter asked if standards will override agreements thatrequire others to maintain hardcopydocumentation (for example, signatureon file) and no longer require submittersto maintain hardcopy documentation.

Response: The security standards will require a minimum level of documentation of security practices. Any agreements between trading partners for the exchange of electronic protected health information that impose additional documentation requirements will not be over ridden by this final rule.

3. Comment: One commenter stated that there should be a requirement to document only applications deemed necessary by an applications and data criticality assessment.

Response: Electronic protected healthinformation must be afforded securityprotection under this rule regardless ofwhat application it resides in. The measures taken to protect that information must be documented.

4. Comment: One commenter askedhow detailed the documentation must be. Another commenter asked what”kept current” meant.

Response: Documentation must bedetailed enough to communicate thesecurity measures taken and to facilitateperiodic evaluations pursuant to§164.308 (a) (8). While the term”current” is not in the final rule, thisconcept has been adopted in therequirement that documentation mustbe updated as needed to reflect securitymeasures currently in effect.

5. Comment: We received onecomment concerning review and updating of implementingdocumentation suggesting that”periodically” be changed to “at leastannually”.

Response: We believe that therequirement should remain as written, in order to allow individual entities toestablish review and update cycles asdeemed necessary. The need for reviewand update will vary dependent upon agiven entity’s size, configuration, environment, operational changes, and the security measures implemented.

J.   Compliance Dates for Initial Implementation (§164.318)

We proposed that how the securitystandard would be implemented byeach covered entity would be dependentupon industry trading partneragreements for electronic transmissions. Covered entities would be able to adaptthe security matrix to meet businessneeds. We suggested that requirementsof the security standard may beimplemented earlier than thecompliance date. However, we wouldrequire implementation to be completeby the applicable compliance date, which is 24 months after adoption of thestandard, and 36 months after adoptionof the standard for small health plans, as provided by the Act. In the proposedrule, we suggested that an entitychoosing to convert from paper tostandard EDI transactions, before theeffective date of the security standard, consider implementing the securitystandard at the same time. In this final rule the dates by whichentities must be in compliance with the standards are called “compliancedates, “ consistent with our practice inthe Transactions, Privacy, and EmployerIdentifier Rules. Section 164.318 in thisfinal rule is also organized consistentwith the format of those rules. Thesubstantive requirements, which arestatutory, remain unchanged. Many of the comments receivedconcerning effective dates and compliance dates, including thecompliance dates for modifications of standards, were addressed in theTransactions Rule. Those that were not addressed in that publication a represented below.

1. Comment: A number ofcommenters expressed support for theeffective dates of the rules and stated that they should not be delayed. Incontrast, one commenter stated that weshould delay this rule to allow for anopen consensus building debate tooccur concerning security. Onecommenter asked that the rule bedelayed until after implementation ofthe ICD-CM changes. A number of comments were receivedexpressing the opinion that the securityregulation should not be published untileither the Congress has enactedlegislation governing standards withrespect to the privacy of individuallyidentifiable health information, or theSecretary of HHS has promulgated finalregulations containing these standards. One commenter stated, “we find ourselves in the difficult position ofreacting to proposed rules setting the standards for how information shouldbe physically and electronicallyprotected, without having reachedagreement on the larger issues ofconsent for and disclosure of individualmedical information”.

Response: The effective date of thefinal rule is 60 days after this final ruleis published in the Federal Register. The statute sets forth the compliancedates for the standards. Covered entitiesmust comply with this final rule no laterthan 24 months (36 months for smallplans) after the effective date. The final Privacy Rule has alreadybeen published. We note that numerouscomments concerning the timing of theadoption of privacy and security standards were also received in theprivacy rulemaking and are discussed inthe Privacy Rule at 65 FR 82752.

2. Comment: One commenter askedthat proposed §142. 312 be rewritten toseparate the effective dates for theSecurity Rule and the TransactionsRule.

Response: The proposed ruleincorporated general languageapplicable to all the proposedAdministrative Simplification standards. Language concerning standards other than Security is notincluded in §164.318. Because this final rule is adopted after the TransactionsRule was adopted, the compliance datesfor the security standards differ fromthose for the transactions standards. Comments concerning general effectivedates were addressed in theTransactions Rule. Comments specificto the security standards are addressedhere.

3. Comment: Several commenters suggested that we not allow earlyimplementation of the Security Rules. Anumber of others asked that we allow, but not require, early implementation bywilling trading partners. Anothercommenter suggested that earlyimplementation by willing tradingpartners be allowed as long as the datacontent transmitted is equal to thatrequired by statute. Another commenterrequested that it be stipulated thatentities cannot implement less than 1year from the date of this final rule and then only after successful testing, and that a “start testing by” date be defined.

Response: Whether or not toimplement before the compliance dateis a business decision that each coveredentity must make. Moreover, the vastmajority of the standards addressinternal policies and procedures thatcan be implemented at any time withoutany impact on trading partners.

4. Comment: One commenter asked usto establish a research site or testlaboratory for a trial implementation.

Response: The concept of a “trialimplementation” that would havewidespread relevance is inconsistentwith our basic principles of flexibility, scalability, and technology-neutrality.

5. Comment: One commenter stated that the 2-year time frame forimplementation of a contingency plan istoo short for health plans that servemultiple regions of the country.

Response: The Congress mand atedthat entities must be in compliance 2years from the initial standard’sadoption date (3 years for small plans).

K. Appendix

The proposed rule contained three addenda.

·        Addendum 1 set out in matrix form the proposed requirements and related implementation features of the proposed rule.

·        Addendum 2 set out inlist form a glossary of terms with citations to the sources of those terms.

·        Addendum 3 identified and map pedareas of overlap in the proposed securitystandard and implementation features. This final rule retains only the first proposed addendum, the matrix, as an appendix, that is modified to reflect the changes in the administrative, physical, and technical safeguard portions of the rule below. Numerous terms in the glossary now appear in the rule below, typically (but not always) as definitions.

1. Comment: Over two-thirds of thecomments received on this topic askedthat the matrix be incorporated into thefinal rule. One commenter asked that asimplified version be made part of thefinal rule. Six commenters wanted itkept in this final rule as an addendum. One commenter stated that it should bein an appendix to the rule, while othersstated that it should not be included inthis final rule.

Response: Since a significant majorityof commenters requested retention ofthe matrix, it has been incorporated intothis final rule as an appendix. Thematrix displays, in tabular form, theadministrative, physical, and technicalsafeguard standards and relatingimplementation specifications describedin this final rule in §164.308, §164.310, and §164.312. It should be noted thatthe requirements of §164.105, §164.314, and §164.316 are notpresented in the matrix.

2. Comment: A large majority ofcommenters stated that the glossarylocated in Addendum 2 of the proposedrule should be included as part of thefinal rule. Several commenters askedthat it be incorporated into thedefinitions section of the final rule. Onecommenter stated that the glossaryshould not be part of this final rule.

Response: The terms defined in theglossary in Addendum 2 of theproposed rule are found throughout thisfinal rule, either as part of the text of§164.306 through §164.312 or under§164.304, as appropriate. We includedonly terms relevant to the particular standards and implementation specifications being adopted.

3. Comment: Several commenters requested that the mapped matrixlocated in Addendum 3 of the proposedrule be included in this final rule, eitheras part of the rule or as an addendum, while others stated that it should not bepart of this final rule. Severalcommenters cited items to be added tothe mapped matrix.

Response: The mapped matrix wasmerely a snapshot of current standards and guidelines that the implementationteam was able to obtain for reviewduring the development of the securityand electronic signature requirementsand was provided in the proposed ruleas background material. Since thismatrix has not been fully populated orkept up-to-date, it is not beingpublished as part of this final rule. Where relevant, we do reference various standards and guidelines indicated inthe matrix in this preamble.

L.  Miscellaneous Issues

1. Preemption

The statute requires generally that thesecurity standards supersede contraryprovisions of State law including Statelaw requiring medical or health planrecords to be maintained or transmittedin written rather than electronicformats. The statute provides certainexceptions to the general rule; section1178 (a) (2) of the Act identifiesconditions under which an exceptionapplies. The proposed rule did notprovide for a process for makingexception determinations; rather, aprocess was proposed in the Privacy Rulemaking and was adopted with thePrivacy Rule (see part 160, subpart B). This process applies to exceptiondeterminations for all of theAdministrative Simplification rules, including this rule.

a. Comment: Several commenters stated that the proposed rule does notinclude substantive protections for theprivacy rights of patients’ electronicmedical records, while the rule attemptsto preempt State privacy laws withrespect to these records. Commentsstated that, by omitting a clarification ofState privacy law applicability, theproposed rule creates confusion. They believe that the rule must contain express and specific exemptions of Statelaws with respect to medical privacy.

Response: The Privacy Ruleestablishes standards for the rights ofpatients in regard to the privacy of theirmedical records and for the allowableuses and disclosures of protected healthinformation. The identified concernswere discussed in the Privacy Rule (see65 FR 82587 through 82588). Thesecurity standards do not specificallyaddress privacy but will safeguardelectronic protected health informationagainst unauthorized access ormodification.

b. Comment: One commenter askedhow these regulations relate toconfidentiality laws, which vary fromState to State.

Response: It is difficult to respond tothis question in the abstract without thebenefit of reference to a specific Statestatute. However, in general, thesesecurity standards will preemptcontrary State laws. Per section1178 (a) (2) of the Act, this general rulewould not hold if the Secretarydetermines that a contrary provision ofState law is necessary for certainidentified purposes to prevent fraud and abuse; to ensure appropriate Stateregulation of insurance and healthplans; for State reporting on health caredelivery costs; or if it addressescontrolled substances. See 45 CFR part160 subpart B. In such case, the contraryprovision of State law would preempt aFederal provision of these security standards. State laws that are related butnot contrary to this final rule, will notbe affected. Section 1178 of the Act also limits thepreemptive effect of the Federalrequirements on certain State laws otherthan where the Secretary makes certaindeterminations. Section 1178 (b) of theAct provides that State laws forreporting of disease and otherconditions and for public healthsurveillance, investigation, orintervention are not invalidated orlimited by the AdministrativeSimplification rules. Section 1178 (c) ofthe Act provides that the Federalrequirements do not limit States’abilities to require that health plansreport or provide access to certaininformation.

c. Comment: Several commenters stated that allowing State law toestablish additional security restrictionsconflicts with the purpose of the Federalrule and /or would makeimplementation very difficult. Onecommenter asked for clarification as towhether additional requirements tighterthan the requirements outlined in theproposed rule may be imposed.

Response: The general rule is that thesecurity standards in this final rulesupersede contrary State law. Onlywhere the Secretary has granted anexception under section 1178 (a) (2) (A) ofthe Act, or in situations under section1178 (b) or (c) of the Act, will the generalrule not hold true. Covered entities maybe required to adhere to stricter Stateimposedsecurity measures that are notcontrary to this final rule.

2. Enforcement

The proposed rule did not containspecific enforcement provisions. Thisfinal rule likewise does not containspecific enforcement provisions; it isexpected that enforcement provisionsapplicable to all AdministrativeSimplification rules will be proposed ina future rulemaking.

a. Comment: One commenter voicedsupport for the proposed rule’sapproach. Another stated that theprocess is poorly defined. Onecommenter stated that fines should beeliminated, or the scope of activitysubject to fines should be morenarrowly defined. While a number of commenters wereof the opinion that HHS must retainenforcement responsibility, stating thatit would be unconstitutional to give itto a private entity, several others stated that it may not be practical for HHS toretain the responsibility for determiningviolations and imposing penaltiesspecified by the statute. A concern wasvoiced over HHS’s ability to fairly and consistently apply the rules due tobudget constraints. Several commenters support industry solutions toenforcement with some level ofgovernment involvement. Onecommenter recommended a single auditprocess using accrediting bodies alreadyin place. Another stated that entitiesproviding accreditation services shouldnot be involved in enforcement as thiswould result in a conflict of interest. Clarification was requested, includingthe use of examples, concerning whatconstitutes a violation, and how apenalty applies to a “person”. Commenters asked if the term “person”referred to the people responsible forthe system and how penalties wouldapply to corporations and other entities.

Response: It is expected thatenforcement of HIPAA standards will beaddressed in regulations to be issued ata later date.

b. Comment: Several commenters stated that enforcement of the security standards will be arbitrarily delegated toprivate businesses that compete withphysicians and with each other.

Response: These comments arepremature for the reasons stated above. 3. Comment PeriodThe comment period on the proposedrule was 60 days.

Comment: We received commentssuggesting that significant changes tothe standards could occur in the final rule as a result of changes made inresponse to comments. The commenterbelieves such changes could adverselyaffect payers and providers, and suggested that the rule should berepublished as a proposed rule with anew comment period to allowadditional comments concerning anychanges. A “work-in-progress”approach was also suggested, to give allstakeholders time to read, analyze, and comment upon evolving versions of aparticular proposed rule.

Response: We have not accepted thesesuggestions. The numerous commentsreceived were thoughtful, analytical, detailed, and addressed every area ofthe proposed rule. This response to theproposed rule indicates that the publichad ample time to read, analyze, and comment upon the proposed rule. If wewere to treat the rule as a “work-inprogress”and issue evolving versions, allowing for comments to each version, we would never implement the statuteand achieve administrativesimplification as directed by theCongress.

M. Proposed Impact Analysis

The preamble to the Transactions Rule contains comments and responses on the impact of all the administratives implification standards in general except privacy. Comments and responses specific to the relative impact of implementing this final rule are presented below.

a. Comment: Several commenters stated that the proposed security standards are complex, costly, administratively burdensome, and couldresult in decreased use of EDI. Onecommenter stated that this rule runscounter to the explicit intent ofAdministrative Simplification thatrequires, “any standard adopted underthis part shall be consistent with theobjective of reducing the administrativecosts of providing and paying for healthcare”. Several commenters expressedconcern that there was no cost benefitanalysis provided for these proposedregulations, stating that, faced withincreasingly limited resources, it isessential that a security standards cost/benefit analysis for all health caretrading partners be provided. Anothersaid an independent cost estimate bythe General Accounting Office (GAO) should be performed on these rules and HHS cost estimates should bepublicized for comparison purposes. Still another commenter stated thatHHS must provide accurate publicsector implementation cost figures and provide funds to offset the cost burden. One commenter asked for cost benefitevaluations to understand therelationship between competingtechnologies, levels of security and potential threats to be guarded against. These would demonstrate the costs and the benefits to be gained for both largeand small organizations and wouldprovide an understand ing of how thelevels of security vary by organizationsize and what the inducements and support available to facilitate adoptionare. One commenter suggested that weestablish a workgroup to more fullyassess the costs and provide Federal funds to offset implementation costs. One commenter noted a seemingdisconnect between two statements inthe preamble. Section A, Security standards, states, “no individual smallentity is expected to experience directcosts that exceed benefits as a result ofthis rule”. In contrast, section E, Factorsin establishing the security standards reads, “We cannot estimate the perentitycost of implementation becausethere is no information availableregarding the extent to whichproviders’, plans’, and clearinghouses’current security practices are deficient”.

Response: We are unable to estimate, of the nation’s 2 million-plus healthplans and 1 million-plus providers thatconduct electronic transactions, thenumber of entities that would requirenew or modified security safeguards and procedures beyond what they currentlyhave in place. Nor are we able toestimate the number of entities thatneither conduct electronic transactionsnor maintain individually identifiableelectronic health information but maybecome covered entities at some futuretime. As we are unable to estimate thenumber of entities and what measuresare or are not already in place, or whatspecific implementation will be chosento meet the requirements of theregulation, we are also unable toestimate the cost to those entities. However, the use of electronictechnology to maintain or transmithealth information results in many newand potentially large risks. These risksrepresent expected costs, both monetaryand social. Leaving risk assessment upto individual entities will minimize theimpact and ensure that security effort isproportional to security risk. As discussed earlier, the securityrequirements are both scalable and technically flexible. We have madesignificant changes to this final rule, reducing the number of requiredimplementation features and providingfor greater flexibility in satisfaction ofthe requirements. In other words, wehave focused more on what needs to bedone and less on how it should beaccomplished. We have removed the statementregarding the extent of costs versusbenefits for small entities.

b. Comment: One commenter stated that on page 43262 of the proposed rule, it indicate that complexity of conversionto the security standards would beaffected by the choice to use aclearinghouse. The commenter stated that this choice would have little effecton implementation of security standards. Another commenter stated that the complexity (and cost) of theconversion to meet the security standards is affected by far more thanjust the “volume of claims health plansprocess electronically and the desire totransmit the claims or to use theservices of a VAN or clearinghouse” asis stated on page 43262. Because thesecurity standards apply to internalsystems as well as to transactionsbetween entities, a number of additionalfactors must be considered, for example, modification of existing securitymechanisms, legacy systems, architecture, and culture.

Response: We agree. We havemodified the Regulatory ImpactAnalysis section to take into accountthat there are other factors involved, such as the architecture and technologylimitations of existing systems.

c. Comment: One commenter stated that States will need 90 percent fundingof development and implementation, without the burden of an advancedplanning documents requirement, fromus for this costly process to succeed. Any new operational obligation shouldbe 100 percent funded. Also humanresource obligations will be significant. Some States believe they will havedifficulty obtaining the budget funds forthe State share of the costs. StateMedicaid agencies, as purchasers, mayalso face paying the implementationcosts of health care providers, clearinghouses, and health plans in theform of higher rates.

Response: The statute does notauthorize any new or special funding forimplementation of the regulations. Medicaid system changes, simplybecause they are “HIPAA related” donot automatically qualify for 90 percentFederal funding participation. As withany systems request, the usual rules willbe applied to determine fundingeligibility for State HIPAA initiatives. Nevertheless, HHS recognizes that thereare significant issues regarding thefunding and implementation of HIPAAby Medicaid State agencies, and intendsto address them through normalchannels of communication with States.

d. Comment: One commenter stated that the proposed rule does not establishhow the security standards willcontribute to reduced cost for providers. One commenter expected theunintended result of this regulation willbe impediment of EDI growth and perhaps even a decline in EDI use byproviders. Another stated that theproposed rule actively discouragesphysician EDI participation bysuggesting a fallback to paper processingfor those unable to meet the cost ofhighly complex security compliance.

Response: Ensuring the integrity of anelectronic message, its delivery to thecorrect person, and its confidentialitymust be an integral part of conductingelectronic commerce. We believe thatthe consistent application of themeasures provided in this rule willactually encourage use of EDI because itwill provide increased confidence in thereliability and confidentiality of healthinformation to all parties involved. Also, the implementation of thesesecurity requirements will reduce thepotential overall cost of risk to a greaterextent than additional security controlswill increase costs. Put another way, thepotential cost of not reasonablyaddressing security risks couldsubstantially exceed the cost ofcompliance.

e. Comment: One commenter stated that the implementation impact of thetechnical safeguards is clearlyunderstated for physicians who usedigitally-based equipment that has beenin place for some time. The commenterbelieves that the rule will likely havegreatest impact on the installed base ofdigital systems, including imagingmodalities and other medical devicesthat store or transmit patientinformation because software for legacysystems will likely require retrofitting orreplacement to come into compliance. The commenter believes that this is anegative impact and would outweighany benefits derived from the potentialrisk of security breaches. Thecommenter recommended compliancefor digital imaging devices be extendedby an additional 3 years to allow timeto upgrade systems and defray theassociated costs.

Response: Compliance dates for theinitial implementation of the initial standards are statutorily prescribed; therefore, we are unable to allowadditional time outside of the statutorytimeframes for compliance.

f. Comment: A commenter stated that, as a new regulatory mand ate, HIPAA costs must be factored into any baseyear calculations for the proposedprospective payment system. Withoutan adjustment, this will be anotherregulatory mand ate that comes at thecost of patient care.

Response: Costs included in theprospective payment system arelegislatively mand ated. The Congressdid not direct the inclusion of HIPAAcosts into the system, so they are notincluded. However, the Departmentbelieves that the HIPAA standards willprovide savings to the providercommunity over the next 10 years. g.

g. Comment: One commenters uggested that we include requirementsfor how a compliant business coulddually operate— (1) in a HIPAAcompliant manner; and (2) in theirformer noncompliant manner in order toaccommodate doing business with otherorganizations that are not yet compliant.

Response: The statute imposes a 2-year implementation period between theadoption of the initial standards and thedate by which covered entities (exceptsmall health plans) must be incompliance. An entity may come intocompliance at any point in time duringthe 2 years. Therefore, the rule does notrequire a covered entity to complybefore the established compliance date. Those entities that come intocompliance before the 2-year deadlineshould decide how best to deal withentities that are not yet compliant. Further, we note that, generallyspeaking, compliance by a coveredentity with these security rules will nothinge on compliance by other entities.

h. Comment: One commenter stated that privacy legislation could imposesignificant changes to written policiesand procedures on authorization, accessto health information, and how sensitiveinformation is disclosed to others. Thecommenter believes these changes couldmean the imposition of securityrequirements different from thosecontained in the proposed rule, and money spent complying with thesecurity provisions could be ill spent ifsignificant new requirements resultfrom the privacy legislation.

Response: The privacy standards atsubpart E of 42 CFR part 164 are nowin effect, and this final rule iscompatible with them. If, in the future, the Congress passes a law whoseprovisions differ from these standards, the standards would have to bemodified. i.

i. Comment: One commenter stated that the private sector should developeducational tools or models in order toassist physicians, other providers, and health plans to comply with the securityregulations.

Response: We agree. The health careindustry is striving to do this. HHS isalso considering provider outreach and education activities.

Section IV
Provisions of the Final Regulation

This section was not included in this document.

Section V
Collection of Information Requirements

Under the Paperwork Reduction Act of 1995 (PRA), we are required to provide 30-day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairlyevaluate whether an information collection should be approved by OMB, section 3506 (c) (2) (A) of the Paperwork Reduction Act of 1995 (PRA) requires that we solicit comment on the following issues:

  • The need for the information collection and its usefulness in carryingout the proper functions of our agency.
  • The accuracy of our estimate of the information collection burden.
  • The quality, utility, and clarity ofthe information to be collected.
  • Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

As discussed below, we are soliciting comment on the record keeping requirements, as referenced in §164.306, §164.308, §164.310, §164.314, and §164.316 of this document.

Section 164.306 Security standards: General Rules

Under paragraph (d), a covered entity must, if implementing the implementation specification is not reasonable and appropriate, document why it would not be reasonable and appropriate to implement the implementation specification. We estimate that 75,000 entities will be affected by this requirement and that they will have to create documentation 3 times for this requirement. We estimate each instance of documentation will take. 25 hours, for a one-time total burden of 56,250 hours.

Section 164.308 Administrative Safeguards

Under this section, a covered entity must document known security incidents and their outcomes. We estimate that there will be 50 known incidents annually and that it will take 8 hours to document this requirement, for an annual burden of 400 hours. This section further requires that each entity have a contingency plan, with specified components. We estimate that there will be 60, 000 entities affected by this requirement and that it will take each entity 8 hours to comply, for a total one-time burden of 480, 000 hours. This section also requires that the written contract or other arrangemen twith a business associate document the satisfactory assurances that the business associate will appropriately safeguardthe information through a writtencontract or other arrangement with thebusiness associate that meets theapplicable requirements of §164.314 (a). We believe that the burden associatedwith this requirement is not subject to the PRA. It is good business practice for entities to document their arrangements via written contracts and as such is usual and customary among the entities subject to them. A burden associated with a requirement conducted in the normal course of business is exempt from the PRA as defined in 5 CFR1320. 3 (b) (2).

Section 164.310 Physical Safeguards

This section requires that a covered entity implement policies and procedures to document repairs and modifications to the physical components of a facility that are related to security (for example, hardware, walls, doors, and locks).

We believe that 15, 500 entities willhave to repair or modify physicalcomponents, most of which will need tobe done in the first year ofimplementation. In the following years, we estimate that 500 entities will needto make repairs or modifications. We estimate that it will take 10 minutes to document each repair or modification for a burden of 2, 583 hours the first year and 83 hours annually subsequently. This section requires that a coveredentity create a retrievable, exact copy ofelectronic protected health information, where needed, before movement ofequipment. We believe that the burden associatedwith this requirement is not subject tothe PRA. It is good business practice forentities to backup their data files, and assuch is usual and customary among theentities subject to them. A burdenassociated with a requirementconducted in the normal course ofbusiness is exempt from the PRA asdefined in 5 CFR 1320. 3 (b) (2).

Section 164.314 Organizational Requirements

This section requires that a covered entity report to the Secretary problems with a business associate’s pattern of an activity or practice of the business associate that constitute a material breach or violation of the business associate’s obligation under the contractor other arrangement if it is not feasible to terminate the contract or arrangement. We believe that 10 entities will need to comply with this reporting requirement and that it will take them 60 minutes to comply with this requirement for an annual burden of 10 hours. This section also requires that a covered entity may, if a business associate is required by law to performa function or activity on behalf of a covered entity or to provide a service described in the definition of business associate as specified in §160.103 of this subchapter to a covered entity, permit the business associate to create, receive, maintain, or transmit electronic protected health information on its behalf to the extent necessary to comply with the legal mand ate without meeting the requirements of paragraph (a)(2)(i) of this section, provided that the coveredentity attempts in good faith to obtainsatisfactory assurances as required byparagraph (a)(2)(ii)(A) of this section, and documents the attempt and thereasons that these assurances cannot beobtained. We believe that this situation willaffect 20 entities and that it will take 60 minutes to document attempts to obtainassurances and the reasons they cannotbe obtained for an annual burden of 20 hours. This section further requires that business associate contracts or other arrangements and group health plans must require the business entity and plan sponsor, respectively, to report to the covered entity any security incident of which it becomes aware. We believe that the burden associated with this requirement is not subject tothe PRA. It is good business practice for entities to document their agreements via written contracts, and as such isusual and customary among the entitiessubject to them. A burden associatedwith a requirement conducted in thenormal course of business is exemptfrom the PRA as defined in 5 CFR1320. 3 (b) (2).

Section 164.316 Policies and Procedures and Documentation Requirements

Paragraph (b) (1), Standard:Documentation, of this section requiresa covered entity to— (i) Maintain the policies and procedures implemented to complywith this subpart in written (which maybe electronic) for; and (ii) If an action, activity, assessment, or designation is required by thissubpart to be documented, maintain awritten (which may be electronic) record of the action, activity, assessment, or designation. We estimate that it will take the4, 000, 000 entities covered by this final rule 16 hours to document their policiesand procedures, for a total one-timeburden of 64, 000, 000 hours. The total annual burden of theinformation collection requirementscontained in this final rule is 64, 539, 264hours. These information collectionrequirements will be submitted to OMBfor review under the PRA and will notbecome effective until approved byOMB. If you comment on these informationcollection and recordkeepingrequirements, please mail copiesdirectly to the following:Centers for Medicare and MedicaidServices, Office of StrategicOperations and Regulatory Affairs, Regulations Development and Issuances Group, Attn: Reports Clearance Officer, 7500 SecurityBoulevard, Baltimore, MD 21244–1850, Attn: Julie Brown, CMS–0049–F; and Office of Information and RegulatoryAffairs, Office of Management and Budget, Room 10235, New ExecutiveOffice Building, Washington, DC20503, Attn: Brenda Aguilar, CMSDesk Officer.

Section VI
Regulatory Impact Analysis

A. Overall Impact

We have examined the impacts of this rule as required by Executive Order12866 (September 1993, Regulatory Planning and Review), the Regulatory Flexibility Act (RFA) (September 16, 1980, Pub. L. 96–354), section 1102 (b) ofthe Social Security Act, the Unfunded Mandates Reform Act of 1995 (Pub. L. 104–4), and Executive Order 13132. Executive Order 12866 (as amendedby Executive Order 13258, whichmerely reassigns responsibility ofduties) directs agencies to assess allcosts and benefits of available regulatoryalternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). Although we cannot determine the specific economic impact of the standards in this final rule (and individually each standard may not have a significant impact), the overall impact analysis makes clear that, collectively, all the standards will have a significant impact of over $100 millionon the economy. Because this rule affects over 2 million entities, a requirement as low as $50 per entity would render this rule economically significant. This rule requires each ofthese entities to engage in, for example, at least some risk assessment activity; thus, this rule is almost certainly economically significant even though we do not have an estimate of the marginal impact of the additional security standards. However, the standards adopted in this rule are considerably more flexible than those anticipated in the overall impact analysis. Therefore, their implementation costs should be lower than those assumed in the impact analysis.

The RFA requires agencies to analyze options for regulatory relief of small businesses. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and government agencies. Most hospitals and most other providers and suppliers are small entities, either by non profit status or by having revenues of $6 million to $29 million in any 1 year. While each standard may not have a significant impact on a substantial number of small entities, the combined effects of all the standards are likely to have a significant effect on a substantial number of small entities. Although we have certified this rule as having a significant impact, we have previously discussed the impact of small entities in the RFA published as part of the August 17, 2000 final regulation for the standards for Electronic Transactions (65 FR 50312), on pages 50359 through 50360. That analysis included the impact of the set of HIPAA standards regulations (transactions and code sets, identifiers, and security). Although we discussed the impact on small entities in the previous analysis, we would like to discuss how this final rule has been structured to minimize the impact on small entities, compared to the proposed rule.

The proposed rule mand ated 69implementation features for all entities. A large number of commenters indicated that mandating such a large number would be burden some for all entities. As a result, we have restructured this final rule to permit greater flexibility. While all standards must be met, we are now only requiring 13 implementation specifications. The remainder of the implementation specifications is “addressable”. Foraddressable specifications, an entitydecides whether each specification is areasonable and appropriate securitymeasure to apply within its particularsecurity framework. This decision isbased on a variety of factors, forexample, the entity’s risk analysis, whatmeasures are already in place, theparticular interest to small entities, and the cost of implementation. Based on the decision, an entity can— (1) implement the specification ifreasonable and appropriate; (2) implement an alternative securitymeasure to accomplish the purposes ofthe standard; or (3) not implementanything if the specification is notreasonable and appropriate and thestandard can still be met. This approach will provide flexibilityfor all entities, and especially smallentities that would be most concernedabout the cost and complexity of thesecurity standards. Small entities canlook at the addressable implementation specifications and tailor theircompliance based on their risks and capabilities of addressing those risks. The required risk analysis is also atool to allow flexibility for entities inmeeting the requirements of this final rule. The risk analysis requirement isdesigned to allow entities to look attheir own operations and determine thesecurity risks involved. The degree ofresponse is determined by the risksidentified. We assume that smallerentities, who deal with smaller amountsof information would have smallerphysical facilities, smaller work forces, and therefore, would assume less risk. The smaller amount of risk involvedmeans that the response to that risk canbe developed on a smaller scale thanthat for larger organizations. Individuals and States are notincluded in the definition of a smallentity. However, the security standards will affect small entities, such asproviders and health plans, and vendorsin much the same way as they affect anylarger entities. Small providers whoconduct electronic transactions and small health plans must meet theprovisions of this regulation and implement the security standards. Amore detailed analysis of the impact onsmall entities is part of the impactanalysis published on August 17, 2000 (65 FR 50312), which provided theimpact for all of the HIPAA standards, except privacy. As we discussed above, the scalability factor of the standards means that the requirements placedupon small providers and plans wouldbe consistent with the complexity oftheir operations. Therefore, smallproviders and plans with appropriatesecurity processes in place would needto do relatively little in order to complywith the standards. Moreover, smallplans will have an additional year tocome into compliance. In addition, section 1102 (b) of the Actrequires us to prepare a regulatoryimpact analysis if a rule may have asignificant impact on the operations ofa substantial number of small ruralhospitals. This analysis must conform tothe provisions of section 604 of theRFA. For purposes of section 1102 (b) ofthe Act, we define a small rural hospitalas a hospital that is located outside ofa Metropolitan Statistical Area and hasfewer than 100 beds. While this rulemay have a significant impact on smallrural hospitals, the impact should beminimized by the scalability factors ofthe standards, as discussed above in theimpact on all small entities. In addition, we have previously discussed theimpact of small entities in the RIApublished as part of the August 17, 2000final regulation for the standards forElectronic Transactions. Section 202 of the UnfundedMandates Reform Act (UMRA) of 1995 also requires that agencies assessanticipated costs and benefits beforeissuing any rule that may result inexpenditure in any 1 year by State, local, or tribal governments, in theaggregate, or by the private sector, of$110 million. We estimate thatimplementation of all the standards willrequire the expenditure of more than$110 million by the private sector. Therefore, the rule establishes a Federalprivate sector mand ate and is asignificant regulatory action within themeaning of section 202 of UMRA (2U. S. C. 1532). We have included thestatements to address the anticipatedeffects of these rules under section 202. These standards also apply to Stateand local governments in their roles ashealth plans or health care providers. Because these entities, in their roles ashealth plans or providers, mustimplement the requirements in theserules, the rules impose unfundedMandates on them. Further discussionof this issue can be found in thepreviously published impact analysisfor all standards (65 FR 50360 through50361). The anticipated benefits and costs ofthe security standards, and other issuesraised in section 202 of the UMRA, areaddressed in the analysis below, and inthe combined impact analysis. Inaddition, as required under section 205of the UMRA (2 U. S. C. 1535), havingconsidered a reasonable number ofalternatives as outlined in the preambleto this rule, HHS has concluded thatthis final rule is the most cost-effectivealternative for implementation of HHS’sstatutory objective of administrativesimplification.

Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates aproposed rule (and subsequent final rule) that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has Federalism implications. The proposed rule was published beforethe enactment of Executive Order 13132 of August 4, 1999, Federalism (published in the Federal Register onAugust 10, 1999 (64 FR 43255) ), whichrequired meaningful and timely inputby State and local officials in thedevelopment of rules that haveFederalism implications). However, wereceived and considered comments onthe proposed rule from State agenciesand from entities who conducttransactions with State agencies. Severalof the comments referred to the coststhat will result from implementation ofthe HIPAA standards. As we stated inthe impact analysis, we are unable toestimate the cost of implementingsecurity features as implementationneeds will vary dependent upon a riskassessment and upon what is already inplace. However, the previously referenced impact analysis in theAugust 17, 2000 final rule (65 FR 50312) showed that AdministrativeSimplification costs will be offset byfuture savings. In complying with the requirementsof part C of title XI, the Secretaryestablished interdepartmentalimplementation teams who consultedwith appropriate State and Federalagencies and private organizations. These external groups consisted of the National Committee on Vital and Health Statistics (NCVHS) Subcommittee on standards and Security, the Workgroupfor Electronic Data Interchange (WEDI), the National Uniform Claim Committee (NUCC), the National Uniform Billing Committee (NUBC), and the Americand Dental Association (ADA). The teams also received comments on the proposed regulation from a variety of organizations, including State Medicaid agencies and other Federal agencies.

B. Anticipated Effects

The analysis in the August 2000, Transaction Rule included the expected costs and benefits of the administratives implification regulations related to electronic systems for 10 years. Although only the electronic transaction standards were promulgated in thetransaction rule, HHS expected affected parties to make systems compliance investments collectively because the regulations are so integrated. Moreover, the data available to us were also based on the collective requirements of this regulation. It is not feasible to identify the incremental technological and computer costs for each regulation. Although HHS is issuing rules underHIPAA sequentially, affected entities and vendors are bundling services, that is, they have been anticipating the various needs and are designing relatively comprehensive systems as they develop hardware and software. For example, a vendor developing a system for electronic billing would also anticipate and include security features, even in the absence of any regulation. Moreover, a draft of the security rule was first published in 1998. Even though the final is different (and less burdensome), vendors had a reasonable indication of the direction policy would go. Thus, in preparing the electronic transaction rule, we recognized and included costs that might theoretically be associated with security or other HIPPA rules. Hence, some of the “costs”of security have already been accounted for in the standards for ElectronicTransactions cost estimate (45 CFR parts160 and 162), which was published in the Federal Register on August 17, 2000 (65 FR 50312). This analysis showed that the combined impact of the Administrative Simplification standards is expected to save the industry $29. 9 billion over 10years. We are including in each subsequent rule an impact analysis thatis specific to the standard or standards in that rule, but the impact analysis will assess only the incremental cost of implementing a given standard over another. Thus, the following discussion contains the impact analysis for the marginal costs of the security standards in this final rule. The following describes the specific impacts that relate to the security standards. The security of electronic protected health information is, and has been for some time, a basic business requirement that health care entitiesignore at their peril. Instances of “hacking” and other security violations may be widely publicized, and can seriously damage an institution’s community standing. Appropriate security protections are crucial for encouraging the growth and use of electronic data interchange. The synergistic effect of the employment of the security standards will enhance all aspects of HIPAA’s Administrative Simplification requirements. In addition, it is important to recognize that security is not a one-time project, but rather an on-going, dynamic process.

C. Changes from the 1998 Impact Analysis

The overall impact analysis forAdministrative Simplification was first published on May 7, 1998 (63 FR 25320) in the proposed rule for the National Provider Identifier standard (45 CFR part 142), the first of the proposed Administrative Simplification rules. That impact analysis was based on the industry situation at that time, usedstatistics which were current at that time, and assumed that all of the HIPAA standards would be implemented at roughly the same time, which wouldpermit software changes to be made lessexpensively. While the original impactanalysis represented our bestinformation at that time, we realize thatthe state of the industry, and of securitytechnology, has changed since 1998. We discuss several of those changes and how they affect the impact of this regulation.

Changes in Technology

The state of technology for health care security has changed since 1998. New technologies to protect information have been developed over the past several years. As a result, HHS has consulted with the Gartner Group, a leading technology assessment organization, regarding what impact these changes inthe industry might have on the expected impact of this regulation. The Gartner analysis indicated that the cost of meeting the requirements of a reasonable interpretation of the security rule in 2002 is probably less than 10 percent higher in 2002 than it was in1998. This increase is mainly driven by more active threats and increased personnel costs off setting decreases in technology costs over the past 4 years. However, spending by companies who have anticipated the security rule or who have independently made business decisions to implement security policies and procedures as good business practice (s) has already occurred, and probably will cancel out the increased costs of implementation. Therefore, Gartner expects the cost of complying with the HIPAA security standards to beabout the same now as it was in 1998.

Synchronizing standards

The timelines for the implementationof the initial HIPAA standards (transactions, identifiers, and security) are no longer closely synchronized. However, we do not believe that thislack of synchronization will have asignificant impact on the cost ofimplementing security. The analysisprovided by the Gartner group indicatedthat implementing security standards isbeing viewed by entities as a separatetask from implementing the transaction standards, and that this is not having asignificant impact on costs. As withother HIPAA standards, most currententities will have a 2-yearimplementation period beforecompliance with the standards isrequired. Covered entities will developtheir own implementation schedules, and may phase in various securitymeasures over that time period.

Relationship to Privacy standards

The publication of the final Privacy Rules (45 CFR parts 160 and 164) on December 28, 2000 in the Federal Register (65 FR 82462) and on August14, 2002 (67 FR 53182) has affected the impact of this regulation significantly. Covered entities must implement the privacy standards by April 14, 2003 (April 14, 2004 for small health plans). The implementation of privacy standards reduces the cost ofimplementing the security standards int wo significant areas.

First, we have made substantial effortsto ensure that the many requirements in the security standards parallel those for privacy, and can easily be satisfied using the solutions for privacy. Administrative requirements like the need for written policies, responsibleofficers, and business associate agreements that are already required by the Privacy Rule can also serve to meet the security standards without significant additional cost. The analysisof data flows and data uses that covered entities are doing so as to comply with the Privacy Rule should also serve asthe starting point for parallel analysis required by this final rule.

Second, it is likely that coveredentities will meet a number of therequirements in the security standards through the implementation of theprivacy requirements. For example, in order to comply with the Privacy Rule requirements to make reasonable efforts to limit the access of members of the work force to specified categories of protected health information, covered entities may implement some of the administrative, physical, and technical safeguards that the entity’s risk analysisand assessment would require under theSecurity Rule. E-mail authentication procedures put into place for privacy protection may also meet the security standards, there by eliminating the need for additional investments to meet these standards. As a result, covered entitiesthat have moved forward in implementing the privacy standards are also implementing security measures at the same time. Since the proposed security standards proposed rule represents the most authoritative guidance now available on the nature of these standards, some entities have been using them to develop their securitymeasures. Those entities should face minimal incremental costs inimplementing the final version of these standards. We are unable to quantify theseoverlaps, but we believe they may reduce the cost of implementing these security standards. The analysisprovided to the HHS by the GartnerGroup also stated that compliance with the Privacy Rule will have a moderateeffect on the cost of compliance with theSecurity Rule, reducing it slightly.

Sensitivity to Security Concerns as aResult of September 11, 2001

In our discussions with the GartnerGroup, they indicated that they sawlittle evidence of increased securityawareness in health care organizationsas a result of the events of September11, 2001. However, a survey conductedby Phoenix Health Systems in thewinter of 2002 showed that 65 percentof the respondents to the survey (hospitals, payers, vendors, and clearinghouses) have moderately togreatly increased their attention onoverall security. If these organizationshave already made investments insecurity that meet some of therequirements of this rule, it will reducetheir added costs of compliance. However, HHS can make no clearstatement of the impact of this attention.

D. Guiding Principles for “Standards Selection”

The implementation teams charged with designating standards under the statute have defined, with significant input from the health care industry, a set of common criteria for evaluating potential standards. These criteria are based on direct specifications in the HIPAA, the purpose of the law, and principles that support the regulatory philosophy set forth in the E. O. 12866 of September 30, 1993, and the Paperwork Reduction Act of 1995. In order to be designated as such, a standard should do the following:

1.     Improve the efficiency and effectiveness of the health care systemby leading to cost reductions for or improvements in benefits from electronic health care transactions. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden.

2.     Meet the needs of the health data standards user community, particularly health care providers, health plans, and health care clearinghouses. This principle supports the regulatory goal of cost-effectiveness.

3.     Be consistent and uniform with theother HIPAA standards (that is, their data element definitions and codes, and their privacy and security requirements) and, secondarily, with other private and public sector health data standards. This principle supports the regulatory goals of consistency and avoidance of incompatibility, and it establishes a performance objective for the standard.

4.     Have low additional development and implementation costs relative to the benefits of using the standard. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden.

5.     Be supported by an ANSI accredited standards developing organization or other private or public organization that would ensure continuity and efficient updating of the standard over time. This principle supports the regulatory goal of predictability.

6.     Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster. This principle establishes a performance objective for the standard.

7.     Be technologically independent of the computer platforms and transmission protocols used in health transactions, except when they are explicitly part of the standard. This principle establishes a performance objective for the standard and supports the regulatory goal of flexibility.

8.     Be precise and unambiguous but as simple as possible. This principle supports the regulatory goals of predictability and simplicity.

9.     Keep data collection and paper work burdens on users as low as is feasible. This principle supports the regulatory goals of cost-effectiveness and avoidance of duplication and burden.

10.  Incorporate flexibility to adapt moreeasily to changes in the health careinfrastructure (for example, newservices, organizations, and providertypes) and information technology. This principle supports the regulatory goals of flexibility and encouragement of innovation.

We assessed a wide variety of security standards and guidelines against the principles listed above, with the overall goal of achieving the maximum benefit for the least cost. As we stated in the proposed rule, we found that no single standard for security exists that encompasses all the requirements that were listed in the law. However, we believe that the standards we are adopting in this final rule collectively accomplish these goals.

E.  Affected Entities

1. Health Care Providers

Covered health care providers may incur implementation costs for establishing or updating their security systems. The majority of costs to implement the security standard (purchase and installation of appropriate computer hardware and software, and physical safeguards) would generally be incurred in the initial implementation period for the specific requirements of the security standard. Health care providers that do not conduct electronic transactions for which standards have been adopted are not affected by these regulations.

2. Health Plans

All health plans, as the term is defined in regulation at 45 CFR 160.103, must comply with these security standards. In addition, health plans that engage in electronic health care transactions may have to modify their systems to meet the security standards. Health plans that maintain electronic health information may also have to modify their systems to meet the security standards. This conversion would have a one-time cost impact onFederal, State, and private plans alike. We recognize that this conversionprocess has the potential to causebusiness disruption of some healthplans. However, health plans would beable to schedule their implementation ofthe security standards and other standards in a way that best fits theirneeds, as long as they meet thedeadlines specified in the HIPAA lawand regulations. Moreover, small plans (many of which are employersponsored) will have an additional yearin which to achieve compliance. Smallhealth plans are defined at 45 CFR160.103 as health plans with annualreceipts of $5 million or less.

3. Clearinghouses

All health care clearinghouses mustmeet the requirements of this regulation. Health care clearinghouses would faceeffects similar to those experienced byhealth care providers and health plans. However, because clearinghousesrepresent one way in which providersand plans can achieve compliance, theclearinghouses’ costs of complying with these standards would probably bepassed along to those entities, to beshared over the entire customer base.

4. System Vendors

Systems vendors that provide computer software applications to health care providers and other billersof health care services would likely be affected. These vendors would have to develop software solutions that would allow health plans, providers, and other users of electronic transactions to protect these transactions and the information in their databases from unauthorized access to their systems. Their costs would also probably be passed along to their customer bases.

F.  Factors in Establishing the SecurityStandard

1. General Effect

In assessing the impact of these standards, it is first necessary to focuson the general nature of the standards, their scalability, and the fact that theyare not dependent upon specifictechnologies. These factors will make itpossible for covered entities toimplement them with the least possibleimpact on resources. Because there is nonational security standard inwidespread use throughout theindustry, adopting any of the cand idate standards would require most healthcare providers, health plans, and healthcare clearinghouses to at least conductan assessment of how their currentsecurity measures conform to the new standards. However, we assume thatmost, if not all, covered entities alreadyhave at least some rudimentary securitymeasures in place. Covered entities thatidentify gaps in their current measureswould need to establish or revise theirsecurity precautions. It is also important to note that the standards specify what goals are to beachieved, but give the covered entitysome flexibility to determine how tomeet those goals. This is different fromthe transaction standards, where allcovered entities must use the exact sameimplementation guide. With respect tosecurity, covered entities will be able toblend security processes now in placewith new processes. This shouldsignificantly reduce compliance costs. Based on our analysis and commentsreceived, the security standards adoptedin this rule do not impose a greaterburden on the industry than the optionswe did not select, and they presentsignificant advantages in terms ofuniversality and flexibility. We understand that some large healthplans, health care providers, and healthcare clearinghouses that currentlyexchange health information amongtrading partners may already havesecurity systems and procedures inplace to protect the information fromunauthorized access. These entities maynot incur significant costs to meet thesecurity standards. Large entities thathave sophisticated security systems inplace may only need minor revisions orupdates to their systems to meet thesecurity standards, or indeed, may notneed to make any changes in theirsystems. While small providers are not likelyto have implemented sophisticatedsecurity measures, they are also not aslikely to need them as larger coveredentities. The scalability principle allowsproviders to adopt measures that areappropriate to their own circumstances.

2. Complexity of Conversion

The complexity of the conversion tothe security standards could besignificantly affected by the volume oftransactions that covered entitiestransmit and process electronically and the desire to transmit directly or to usethe services of a Value Added Network (VAN) or a clearinghouse. If a VAN orclearinghouse is used, some of theconversion activities would be carriedout by that organization, rather than bythe covered entity. This would simplifyconversion for the covered entity, butmakes the covered entity dependent onthe success of its business associate. Thearchitecture, and specific technology limitations of existing systems couldalso affect the complexity of theconversion (for example, certainpractice management software that doesnot contain password protection willrequire a greater conversion effort thansoftware that has a password protectionoption already built into it)

3. Cost of Conversion

Virtually all providers, health plans, and clearinghouses that transmit orstore data electronically have alreadyimplemented some security measuresand will need to assess existing security, identify areas of risk, and implementadditional measures in order to comeinto compliance with the standards adopted in this rule. We cannot estimatethe per-entity cost of implementationbecause there is no informationavailable regarding the extent to whichproviders’, plans’, and clearinghouses’current security practices are deficient. Moreover, some security solutions arealmost cost-free to implement (forexample, reminding employees not topost passwords on their monitors), while others are not. Affected entities will have manychoices regarding how they willimplement security. Some may chooseto assess security using in-house staff, while others will use consultants. Practice management software vendorsmay also provide security consultationservices to their customers. Entities mayalso choose to implement securitymeasures that require hardware and /orsoftware purchases at the time they doroutine equipment upgrades. The security standards we adopt inthis rule were developed withconsiderable input from the health careindustry, including providers, healthplans, clearinghouses, vendors, and standards organizations. Industrymembers strongly advocated the flexibleapproach we adopt in this rule, whichpermits each affected entity to developcost-effective security measuresappropriate to their particular needs. We believe that this approach will yieldthe lowest implementation cost toindustry while ensuring that electronicprotected health information issafeguarded. All of the nation’s health plans (over 2 million) and providers (over 600,000) will need to conduct some level of gap analysis to assess current proceduresagainst the standards. However, we cannot estimate the number of covered entities that would have to implement additional security systems and procedures to meet the adopted standards. Also, we are not able to estimate the number of providers that do not conduct electronic transactions today but may choose to do so at some future time (these would be entities that send and receive paper transactions and maintain paper records and thus would not be affected). We believe that the security standards represent the minimum necessary for adequate protection of health information in an electronic format and as such should be implemented by all covered entities. As discussed earlier in this preamble, the security requirements are both scalable and technically flexible; and while the law requires each health plan that is not a small plan to comply with the security and electronic signature requirements no later than 24 months after the effective date of the final rule, small plans will be allowed an additional 12months to comply. Since we are unable to estimate the number of entities that may need to make changes to meet the security standards, we are also unable to estimate the cost for those entities. However, we believe that the cost of establishing security systems and procedures is a portion of the costs associated with converting to the administrative simplification standards that are required under HIPAA, which are estimated in the previously referenced impact analysis. This discussion on conversion costs relates only to health plans, health care providers, and health care clearinghouses that are required to implement the security standards. The cost of implementing security systems and procedures for entities that do not transmit, receive, or maintain health information electronically is not a cost imposed by the rule, and thus, is not included in our estimates. G. Alternatives Considered In developing this final rule, the Department considered some alternatives. One alternative was to no tissue a final rule. However, this would not meet the Department’s obligations under the HIPAA statute. It would also leave the health industry without a set of standards for protecting the security of health information. The vast majority of commenters supported our efforts in developing a set of standards. Thus, we concluded that not publishing a final rule was not in the best interests of the industry and not in the best interests of persons whose medical information will be protected by these measures. A second alternative was to publish the final rule basically unchanged from the proposed rule. Although most commenters supported the approach of the proposed rule, there were significant objections to the number of required specifications, concerns about the scope of certain requirements, duplication and ambiguity of some requirements, and the overall complexity of the approach. Based on those comments, it was clear that revisions had to be made. In addition, the proposed rule was developed before the Privacy Rule requirements were developed. Thus, it did not allow for any alignment of requirements between the Privacy and Security standards. As a result, the Department determined that an approach that modified the proposed rule and aligned the requirements with the Privacy standards was the preferred alternative.

Section VII
Federalism

Executive Order 13132 of August 4, 1999, Federalism, published in the Federal Register on August 10, 1999 (64FR 43255), requires us to ensure meaningful and timely input by State and local officials in the development of rules that have Federalism implications.

Although the proposed rule for security standards was published before the enactment of this Executive Order, the Department consulted with State and local officials as part of an outreach program in the process of developing the proposed regulation. The Department received comments on the proposed rule from State agencies and from entities that conduct transactions with State agencies. Many of these comments were concerned with the burden that the proposed security standards would place on their organizations. In response to those comments, we have modified the security standards to make them more flexible and less burdensome. In complying with the requirements of part C of Title XI, the Secretary established an interdepartmental team who consulted with appropriate State and Federal agencies and private organizations. These external groups included the NCVHS Workgroup on standards and Security, the Workgroup for Electronic Data Interchange, the National Uniform Claim Committee, and the National Uniform Billing Committee. Most of these groups have State officials as members. We also received comments on the proposed regulation from these organizations. In accordance with the provisions of Executive Order 12866, this rule has-been reviewed by the Office of Management and Budget.

List of Subjects 45 CFR Part 160 Electronic transactions, Employer benefit plan, Health, Health care, Health facilities, Health insurance, Health records, Medicaid, Medical research, Medicare, Privacy, Reporting and record keeping requirements.

45 CFR Part 162 Administrative practice and procedure, Health facilities, Health insurance, Hospitals, Medicaid, Medicare, report and record keeping requirement.

45 CFR Part 164 Administrative practice and procedure, Health facilities, Health insurance, Hospitals, Medicaid, Medicare, Electronic Information System, Security, Report and recordkeeping requirement.

For the reasons set forth in the preamble, the Department of Health and Human Services amends title 45, subtitle A, subchapter C, parts 160, 162, and 164 as set forth below:

A. PART 160—GENERAL ADMINISTRATIVE REQUIREMENTS

§160.103 Authority Citation

The authority citation for part 160 continues to read as follows: Authority: Sec. 1171 through 1179 of the Social Security Act, (42 U. S. C. 1320d–1329d–8) as added by sec. 262 of Pub. L. 104–191, 110 Stat. 2021–2031 and sec. 264 of Pub. L. 104–191 (42 U. S. C. 1320d–2 (note))

§160.103 Definitions

In §160.103, the definitions of “disclosure”, “electronic media”, “electronic protected health information, “individual”, “organized health care arrangement”, “protected health information”, and “use” are added in alphabetical order to read as follows:

·        Disclosure means the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.

·        Electronic media means:

1.     Electronic storage media including memory devices in computers (hard drives) and any removable/transportable digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card

2.     Transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the internet (wide-open), extranet (using internet technology to link a business with information accessible only to collaborating parties), leased lines, dialup lines, private networks, and the physical movement of removable/transportable electronic storage media. Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media, because the information being exchanged did not exist in electronic form before the transmission.

·        Electronic protected health information means information that comes within paragraphs (1) (i) or (1) (ii) of the definition of protected health information as specified in this section.

·        Individual means the person who is the subject of protected health information.

·        Organized health care arrangement means:

1.     A clinically integrated care settingin which individuals typically receiv ehealth care from more than one healthcare provider

2.     An organized system of health care in which more than one covered entity participates and in which the participating covered entities:

                                                                             i.     Hold themselves out to the publicas participating in a joint arrangement;and

                                                                            ii.     Participate in joint activities that include at least one of the following:

a)     Utilization review, in whichhealth care decisions by participatingcovered entities are reviewed by otherparticipating covered entities or by athird party on their behalf

b)     Quality assessment and improvement activities, in whichtreatment provided by participatingcovered entities is assessed by otherparticipating covered entities or by athird party on their behalf

c)     Payment activities, if the financial risk for delivering health care is shared, in part or in whole, by participating covered entities through the joint arrangement and if protected health information created or received by acovered entity is reviewed by otherparticipating covered entities or by a third party on their behalf for the purpose of administering the sharing of financial risk.

3.     A group health plan and a health insurance issuer or HMO with respect to such group health plan, but only with respect to protected health information created or received by such healthinsurance issuer or HMO that relates to individuals who are or who have been participants or beneficiaries in such group health plan

4.     A group health plan and one or more other group health plans each of which are maintained by the same plan sponsor

5.     The group health plans describedin paragraph (4) of this definition and health insurance issuers or HMOs with respect to such group health plans, but only with respect to protected health information created or received by such health insurance issuers or HMOs that relates to individuals who are or have been participants or beneficiaries in any of such group health plans.

·        Protected health information means individually identifiable health information:

1.     Except as provided in paragraph (2) of this definition, that is:

                                                    i.     Transmitted by electronic media

                                                   ii.     Maintained in electronic media

                                                  iii.     Transmitted or maintained in anyother form or medium.

(2) Protected health information excludes individually identifiable health information in:

                                                    i.     Education records covered by theFamily Educational Rights and PrivacyAct, as amended, 20 U. S. C. 1232g;

                                                   ii.     Records described at 20 U. S. C. 1232g (a) (4) (B) (iv)

                                                  iii.     Employment records held by acovered entity in its role as employer

·        Use means, with respect to individually identifiable healthinformation, the sharing, employment, application, utilization, examination, or analysis of such information within an entity that maintains such information.

B. PART 162—ADMINISTRATIVE REQUIREMENTS

§162. 103 Authority citation

The authority citation for part 162 is revised to read as follows: Authority: Secs. 1171 through 1179 of the Social Security Act (42 U. S. C. 1320d–1320d–8), as added by sec. 262 of Pub. L. 104–191, 110 Stat. 2021–2031, and sec. 264 of Pub. L. 104–191, 110 Stat. 2033–2034 (42 U. S. C. 1320d–2 (note)) §162. 103 [Amended]

§162. 103 Definitions

In, the definition of “electronic media” is removed.

C. PART 164—SECURITY AND PRIVACY

§164.103 Authority citation

The authority citation for part 164 is revised to read as follows: Authority: Secs. 1171 through 1179 of the Social Security Act (42 U. S. C. 1320d–1320d–8), as added by sec. 262 of Pub. L. 104–191, 110 Stat. 2021–2031, and 42 U. S. C. 1320d–2 and 1320d–4, sec. 264 of Pub. L. 104–191, 110 Stat. 2033–2034 (42 U. S. C. 1320d–2 (note)).

§164.103 Definitions.

A new §164.103 is added. As used in this part, the following terms have the following meanings:

·        Common control exists if an entity has the power, directly or indirectly, significantly to influence or direct the actions or policies of another entity.

·        Common ownership exists if an entity or entities possess an ownership or equity interest of 5 percent or more in another entity.

·        Covered functions means those functions of a covered entity the performance of which makes the entity a health plan, health care provider, or health care clearinghouse.

·        Health care component means acomponent or combination of components of a hybrid entity designated by the hybrid entity in accordance with §164.105 (a) (2) (iii) (C).

·        Hybrid entity means a single legal entity:

1.     That is a covered entity

2.     Whose business activities include both covered and non-covered functions

3.     That designates health care components in accordance with paragraph §164.105(a)(2)(iii)(C).

·        Plan sponsor is defined as defined at section 3 (16) (B) of ERISA, 29 U. S. C. 1002 (16) (B).

·        Required by law means a mandate contained in law that compels an entity to make a use or disclosure of protected health information and that is enforceable in a court of law. Required by law includes, but is not limited to, court orders and court-ordered warrants;subpoenas or summons issued by acourt, grand jury, a governmental or tribal inspector general, or an administrative body authorized to require the production of information; a civil or an authorized investigative demand ; Medicare conditions of participation with respect to health care providers participating in the program;and statutes or regulations that require the production of information, including statutes or regulations that require such information if payment issought under a government program providing public benefits.

§164.104 Applicability

Section 164.104 is revised to read as follows:

o   Except as otherwise provided, the standards, requirements, and implementation specifications adopted under this part apply to the following entities:

§  A health plan

§  A health care clearinghouse

§  A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter.

o   When a health care clearinghousecreates or receives protected healthinformation as a business associate ofanother covered entity, or other than asa business associate of a covered entity, the clearinghouse must comply with§164.105 relating to organizationalrequirements for covered entities, including the designation of health carecomponents of a covered entity.

§164.105 Organizational requirements

A new §164.105 is added to read as follows:

(a)

(1) Standard: Health care component. If a covered entity is a hybrid entity, the requirements of subparts C and E of this part, other than the requirements of this section, §164.314, and §164.504, apply only to the health care component (s) of the entity, as specified in this section.

(2) Implementation specifications:

(i) Application of other provisions. Inapplying a provision of subparts C and E of this part, other than therequirements of this section, §164.314, and §164.504, to a hybrid entity:

(A) A reference in such provision toa “covered entity” refers to a health carecomponent of the covered entity;

(B) A reference in such provision toa “health plan, “ “covered health careprovider, “ or “health careclearinghouse, “ refers to a health carecomponent of the covered entity if suchhealth care component performs thefunctions of a health plan, health careprovider, or health care clearinghouse, as applicable;

(C) A reference in such provision to”protected health information” refers toprotected health information that iscreated or received by or on behalf ofthe health care component of thecovered entity;

(D) A reference in such provision to”electronic protected healthinformation” refers to electronicprotected health information that iscreated, received, maintained, or transmitted by or on behalf of the healthcare component of the covered entity.

(ii) Safeguard requirements. Thecovered entity that is a hybrid entitymust ensure that a health carecomponent of the entity complies with the applicable requirements of thissection and subparts C and E of thispart. In particular, and without limitingthis requirement, such covered entitymust ensure that:

(A) Its health care component doesnot disclose protected healthinformation to another component ofthe covered entity in circumstances inwhich subpart E of this part wouldprohibit such disclosure if the healthcare component and the othercomponent were separate and distinctlegal entities;

(B) Its health care component protectselectronic protected health informationwith respect to another component ofthe covered entity to the same extentthat it would be required under subpartC of this part to protect suchinformation if the health carecomponent and the other componentwere separate and distinct legal entities;

(C) A component that is described by paragraph (a) (2) (iii) (C) (2) of this sectiondoes not use or disclose protectedhealth information that it creates orreceives from or on behalf of the healthcare component in a way prohibited bysubpart E of this part; (D) A component that is described byparagraph (a) (2) (iii) (C) (2) of this sectionthat creates, receives, maintains, ortransmits electronic protected healthinformation on behalf of the health carecomponent is in compliance withsubpart C of this part;

(E) If a person performs duties forboth the health care component in thecapacity of a member of the workforceof such component and for anothercomponent of the entity in the samecapacity with respect to thatcomponent, such workforce membermust not use or disclose protectedhealth information created or receivedin the course of or incident to themember’s work for the health carecomponent in a way prohibited bysubpart E of this part.

(iii) Responsibilities of the coveredentity. A covered entity that is a hybridentity has the following responsibilities:

(A) For purposes of subpart C of part160 of this subchapter, pertaining tocompliance and enforcement, thecovered entity has the responsibility ofcomplying with subpart E of this part.

(B) The covered entity is responsiblefor complying with §164.316 (a) and §164.530 (i), pertaining to theimplementation of policies and procedures to ensure compliance withapplicable requirements of this sectionand subparts C and E of this part, including the safeguard requirements inparagraph (a) (2) (ii) of this section.

(C) The covered entity is responsiblefor designating the components that arepart of one or more health carecomponents of the covered entity and documenting the designation inaccordance with paragraph (c) of thissection, provided that, if the coveredentity designates a health carecomponent or components, it mustinclude any component that would meetthe definition of covered entity if it werea separate legal entity. Health carecomponent (s) also may include acomponent only to the extent that itperforms: (1) Covered functions; or (2) Activities that would make suchcomponent a business associate of a component that performs coveredfunctions if the two components wereseparate legal entities. (b) (1) Standard: Affiliated coveredentities. Legally separate coveredentities that are affiliated may designatethemselves as a single covered entity forpurposes of subparts C and E of thispart. (1) Implementation specifications: (i) Requirements for designation of anaffiliated covered entity. (A) Legally separate covered entitiesmay designate themselves (includingany health care component of suchcovered entity) as a single affiliatedcovered entity, for purposes of subpartsC and E of this part, if all of the coveredentities designated are under commonownership or control. (B) The designation of an affiliatedcovered entity must be documented and the documentation maintained asrequired by paragraph (c) of this section. (ii) Safeguard requirements. Anaffiliated covered entity must ensurethat: (A) The affiliated covered entity’screation, receipt, maintenance, ortransmission of electronic protectedhealth information complies with theapplicable requirements of subpart C ofthis part; (B) The affiliated covered entity’s useand disclosure of protected healthinformation comply with the applicablerequirements of subpart E of this part;and (C) If the affiliated covered entitycombines the functions of a health plan, health care provider, or health careclearinghouse, the affiliated coveredentity complies with§164.308 (a) (4) (ii) (A) and §164.504 (g), as applicable. (c) (1) Standard: Documentation. Acovered entity must maintain a writtenor electronic record of a designation asrequired by paragraphs (a) or (b) of thissection. (2) Implementation specification:Retention period. A covered entity must retain the documentation as required by paragraph (c) (1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later. 5. A new subpart C is added to part164 to read as follows:

Subpart C – Security standards for the Protection of Electronic Protected Health Information

  • 164.302 Applicability
  • 164.304 Definitions
  • 164.306 Security standards: General rules
  • 164.308 Administrative safeguards
  • 164.310 Physical safeguards
  • 164.312 Technical safeguards
  • 164.314 Organizational requirements
  • 164.316 Policies and procedures and documentation requirements
  • 164.318 Compliance dates for the initial implementation of the security standards

Appendix A to Subpart C of Part 164—Security standards : Matrix

Authority: 42 U.S.C. 1320d–2 and 1320d–4.

§164.302 Applicability

A covered entity must comply with the applicable standards, implementation specifications, and requirements of this subpart with respect to electronic protected healthinformation.

§164.304 Definitions

As used in this subpart, the following terms have the following meanings:

Access means the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource. (This definition applies to “access” as used in this subpart, not as used in subpart E of this part).

Administrative safeguards are administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.

Authentication means the corroboration that a person is the one claimed.

Availability means the property that data or information is accessible and useable upon demand by an authorized person.

Confidentiality means the property that data or information is not made available or disclosed to unauthorized persons or processes. Encryption means the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.

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

Information system means 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.

Integrity means the property that data or information have not been altered or destroyed in an unauthorized manner.

Malicious software means software, for example, a virus, designed to damage or disrupt a system.

Password means confidential authentication information composed of a string of characters.

Physical safeguards are physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.

Security or Security measures encompass all of the administrative, physical, and technical safeguards in an information system.

Security incident means the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. Technical safeguards means the technology and the policy and procedures for its use that protect electronic protected health information and control access to it. User means a person or entity with authorized access. Workstation means 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.

§164.306 Security standards: General rules

(a) General requirements. Covered entities must do the following:

(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits.

(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.

(3) Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part.

(4) Ensure compliance with this subpart by its workforce.

(b) Flexibility of approach.

(1) Covered entities may use any security measures that allow the covered entity to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart.

(2) In deciding which security measures to use, a covered entity must take into account the following factors:

(i) The size, complexity, and capabilities of the covered entity.

(ii) The covered entity’s technicalinfrastructure, hardware, and softwaresecurity capabilities.

(iii) The costs of security measures.

(iv) The probability and criticality ofpotential risks to electronic protectedhealth information.

(c) standards. A covered entity must comply with the standards as provided in this section and in §164.308, §164.310, §164.312, §164.314, and §164.316 with respect to all electronic protected health information.

(d) Implementation specifications. In this subpart:

(1) Implementation specifications are required or addressable. If an implementation specification is required, the word “Required” appears in parentheses after the title of the implementation specification. If an implementation specification is addressable, the word “Addressable” appears in parentheses after the title of the implementation specification.

(2) When a standard adopted in §164.308, §164.310, §164.312, §164.314, or §164.316 includes required implementation specifications, a covered entity must implement the implementation specifications. (1) When a standard adopted in§164.308, §164.310, §164.312, §164.314, or §164.316 includes addressable implementation specifications, a covered entity must

(i) Assess whether eachimplementation specification is areasonable and appropriate safeguard inits environment, when analyzed withreference to the likely contribution toprotecting the entity’s electronicprotected health information
(ii) As applicable to the entity

(A) Implement the implementation specification if reasonable and appropriate

(B) If implementing theimplementation specification is notreasonable and appropriate— (1) Document why it would not bereasonable and appropriate toimplement the implementation specification; and (2) Implement an equivalentalternative measure if reasonable and appropriate.

(e) Maintenance. Security measuresimplemented to comply with standards and implementation specificationsadopted under §164.105 and thissubpart must be reviewed and modifiedas needed to continue provision ofreasonable and appropriate protection ofelectronic protected health informationas described at §164.316.

§164.308 Administrative safeguards.

(a) A covered entity must, inaccordance with §164.306:

(1) Standard: Security management process

(i) Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.

(ii) Implementation specifications:

(A) Risk analysis (Required). Conduct an accurate and thorough assessment ofthe potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the coveredentity.

(B) Risk management (Required). Implement security measures sufficientto reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306 (a).

(C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.

(D) Information system activity review (Required). Implement procedures to regularly review records of informationsystem activity, such as audit logs, access reports, and security incidenttracking reports.

(2) Standard: Assigned securityresponsibility. Identify the securityofficial who is responsible for thedevelopment and implementation of thepolicies and procedures required by thissubpart for the entity.

(3)

(i) Standard: Workforce security. Implement policies and procedures toensure that all members of its workforcehave appropriate access to electronicprotected health information, asprovided under paragraph (a) (4) of thissection, and to prevent those workforcemembers who do not have access underparagraph (a) (4) of this section fromobtaining access to electronic protectedhealth information.

(ii) Implementation specifications:

(A) Authorization and /or supervision (Addressable). Implement proceduresfor the authorization and /or supervisionof workforce members who work withelectronic protected health informationor in locations where it might beaccessed.

(B) Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected healthinformation is appropriate.

(C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in paragraph (a) (3) (ii) (B) of this section.

(4)

(i) Standard: Information access management. Implement policies and procedures for authorizing access toelectronic protected health informationthat are consistent with the applicablerequirements of subpart E of this part.

(ii) Implementation specifications:

(A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghousemust implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized accessby the larger organization.

(B) Access authorization (Addressable). Implement policies and procedures for granting access toelectronic protected health information, for example, through access to aworkstation, transaction, program, process, or other mechanism.

(C) Access establishment and modification (Addressable). Implementpolicies and procedures that, basedupon the entity’s access authorizationpolicies, establish, document, review, and modify a user’s right of access to aworkstation, transaction, program, or process.

(5)

(i) Standard: Security awarenessand training. Implement a security awareness and training program for all members of its workforce (including management).

(ii) Implementation specifications. Implement:

(A) Security reminders (Addressable). Periodic security updates.

(B) Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software.

(C) Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies.

(D) Password management (Addressable). Procedures for creating, changing, and safeguarding passwords.

(6)

(i) Standard: Security incident procedures. Implement policies and procedures to address securityincidents.

(ii) Implementation specification: Response and Reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes.

(7)

(i) Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.

(ii) Implementation specifications:

(A) Data backup plan (Required) – Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.

(B) Disaster recovery plan (Required) – Establish (and implement as needed) procedures to restore any loss of data.

(C) Emergency mode operation plan (Required) – Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.

(D) Testing and revision procedures (Addressable) – Implement procedures for periodic testing and revision of contingency plans.

(E) Applications and data criticalityanalysis (Addressable) – Assess the relative criticality of specific applications and data in support of other contingency plan components.

(8) Standard: Evaluation. Perform a periodic technical and non technical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which anentity’s security policies and procedures meet the requirements of this subpart.

(b)

(1) Standard: Business associate contracts and other arrangements. A covered entity, in accordance with §164.306, may permit a business associate to create, receive, maintain, or transmit electronic protected healthinformation on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordancewith §164.314 (a) that the business associate will appropriately safeguard the information.

(2) This standard does not apply with respect to:

(i) The transmission by a covered entity of electronic protected healthinformation to a health care provider concerning the treatment of an individual.

(ii) The transmission of electronic protected health information by a group health plan or an HMO or healthinsurance issuer on behalf of a group health plan to a plan sponsor, to the extent that the requirements of §164.314 (b) and §164.504 (f) apply and are met; or

(iii) The transmission of electronic protected health information from or to other agencies providing the services at §164.502 (e) (1) (ii) (C), when the cover edentity is a health plan that is agovernment program providing public benefits, if the requirements of§164.502 (e) (1) (ii) (C) are met.

(3) A covered entity that violates thesatisfactory assurances it provided as abusiness associate of another coveredentity will be in noncompliance with the standards, implementation specifications, and requirements of thisparagraph and §164.314 (a). (4) Implementation specifications: Written contract or other arrangement (Required). Document the satisfactoryassurances required by paragraph (b) (1) of this section through a writtencontract or other arrangement with thebusiness associate that meets theapplicable requirements of §164.314 (a).

§164.310 Physical safeguards

A covered entity must, in accordance with §164.306:

(a) Standard: Facility access controls

(1) Standard: Facility access controls. Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed.

(2) Implementation specifications

(i) Contingency operations (Addressable). Establish (and implementas needed) procedures that allow facilityaccess in support of restoration of lostdata under the disaster recovery planand emergency mode operations plan inthe event of an emergency.

(ii) Facility security plan (Addressable). Implement policies and procedures to safeguard the facility and the equipment therein fromunauthorized physical access, tampering, and theft.

(iii) Access control and validation procedures (Addressable). Implementprocedures to control and validate aperson’s access to facilities based ontheir role or function, including visitorcontrol, and control of access tosoftware programs for testing and revision.

(iv) Maintenance records (Addressable). Implement policies and procedures to document repairs and modifications to the physicalcomponents of a facility which arerelated to security (for example, hardware, walls, doors, and locks).

(b) Standard: Workstation use. Implement policies and procedures thatspecify the proper functions to beperformed, the manner in which thosefunctions are to be performed, and thephysical attributes of the surroundingsof a specific workstation or class ofworkstation that can access electronicprotected health information.

(c) Standard: Workstation security. Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users.

(d) Standard: Device and media controls

(1) Standard: Device and media controls. Implement policies and procedures that govern the receipt and removal of hardware and electronicmedia that contain electronic protectedhealth information into and out of afacility, and the movement of theseitems within the facility.

(2) Implementation specifications:

(i) Disposal (Required). Implement policies and procedures to address the final disposition of electronic protected health information, and /or the hardware or electronic media on which it is stored.

(ii) Media re-use (Required). Implement procedures for removal of electronic protected health informationfrom electronic media before the media are made available for re-use.

(iii) Accountability (Addressable). Maintain a record of the movements ofhardware and electronic media and anyperson responsible therefore.

(iv) Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.

§164.312 Technical safeguards

A covered entity must, in accordancewith §164.306:

(a) Standard: Access control

(1) Standard: Access control. Implement technical policies and procedures for electronic informationsystems that maintain electronicprotected health information to allowaccess only to those persons or softwareprograms that have been granted accessrights as specified in §164.308 (a) (4).

(2) Implementation specifications:

(i) Unique user identification (Required). Assign a unique name and /or number for identifying and tracking user identity.

(ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.

(iii) Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.

(b) Standard: Audit controls. Implement hardware, software, and /orprocedural mechanisms that record and examine activity in information systemsthat contain or use electronic protectedhealth information.

(c) Standard: Integrity

(1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

(2) Implementation specification: Mechanism to authenticate electronicprotected health information (Addressable). Implement electronicmechanisms to corroborate thatelectronic protected health informationhas not been altered or destroyed in anunauthorized manner.

(d) Standard: Person or entity authentication. Implement proceduresto verify that a person or entity seekingaccess to electronic protected healthinformation is the one claimed.

(e) Standard: Transmissionsecurity

(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

(2) Implementation specifications:

(i) Integrity controls (Addressable). Implement security measures to ensurethat electronically transmittedelectronic protected health informationis not improperly modified withoutdetection until disposed of.

(ii) Encryption (Addressable). Implement a mechanism to encryptelectronic protected health informationwhenever deemed appropriate.

§164.314 Organizational requirements

(a)

(1) Standard: Business associate contracts or other arrangements.

(i) The contract or other arrangement between the covered entity and its business associate required by §164.308 (b) must meet the requirementsof paragraph (a) (2) (i) or (a) (2) (ii) of thissection, as applicable.

(ii) A covered entity is not incompliance with the standards in §164.502 (e) and paragraph (a) of this section if the covered entity knew of a pattern of an activity or practice of the business associate that constituted a material breach or violation of the business associate’s obligation under the contract or other arrangement, unless the covered entity took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful— (A) Terminated the contract orarrangement, if feasible; or (B) If termination is not feasible, reported the problem to the Secretary.

(2) Implementation specifications (Required).

(i) Business associate contracts. Thecontract between a covered entity and abusiness associate must provide that thebusiness associate will

(A) Implement administrative, physical, and technical safeguards thatreasonably and appropriately protect theconfidentiality, integrity, and availability of the electronic protectedhealth information that it creates, receives, maintains, or transmits onbehalf of the covered entity as requiredby this subpart;

(B) Ensure that any agent, including asubcontractor, to whom it provides suchinformation agrees to implementreasonable and appropriate safeguardsto protect it;

(C) Report to the covered entity anysecurity incident of which it becomesaware;

(D) Authorize termination of thecontract by the covered entity, if thecovered entity determines that thebusiness associate has violated amaterial term of the contract.

(ii) Other arrangements.

(A) When a covered entity and its business associate are both governmental entities, the covered entity is in compliance with paragraph (a) (1) of this section, if—

(1) It enters into a memorand um ofunderstand ing with the businessassociate that contains terms thataccomplish the objectives of paragraph (a) (2) (i) of this section;

(2) Other law (including regulationsadopted by the covered entity or itsbusiness associate) containsrequirements applicable to the business associate that accomplish the objectives of paragraph (a) (2) (i) of this section.

(B) If a business associate is requiredby law to perform a function or activityon behalf of a covered entity or toprovide a service described in thedefinition of business associate asspecified in §160.103 of this sub chapter to a covered entity, the covered entity may permit the business associate tocreate, receive, maintain, or transmit electronic protected health informationon its behalf to the extent necessary tocomply with the legal mand ate without meeting the requirements of paragraph (a) (2) (i) of this section, provided that the covered entity attempts in good faith to obtain satisfactory assurances as required by paragraph (a) (2) (ii) (A) ofthis section, and documents the attemptand the reasons that these assurancescannot be obtained.

(C) The covered entity may omit from its other arrangements authorization of the termination of the contract by the covered entity, as required by paragraph (a) (2) (i) (D) of this section if such authorization is inconsistent with the statutory obligations of the covered entity or its business associate.

(b) (1) Standard: Requirements forgroup health plans. Except when theonly electronic protected healthinformation disclosed to a plan sponsoris disclosed pursuant to§164.504 (f) (1) (ii) or (iii), or asauthorized under §164.508, a grouphealth plan must ensure that its pland ocuments provide that the plansponsor will reasonably and appropriately safeguard electronicprotected health information created, received, maintained, or transmitted toor by the plan sponsor on behalf of thegroup health plan. (2) Implementation specifications (Required). The plan documents of thegroup health plan must be amended toincorporate provisions to require theplan sponsor to— (i) Implement administrative, physical, and technical safeguards thatreasonably and appropriately protect theconfidentiality, integrity, and availability of the electronic protectedhealth information that it creates, receives, maintains, or transmits onbehalf of the group health plan; (ii) Ensure that the adequateseparation required by§164.504 (f) (2) (iii) is supported byreasonable and appropriate securitymeasures; (iii) Ensure that any agent, includinga subcontractor, to whom it providesthis information agrees to implementreasonable and appropriate securitymeasures to protect the information; and (iv) Report to the group health planany security incident of which itbecomes aware. §164.316 Policies and procedures and documentation requirements. A covered entity must, in accordancewith §164.306: (a) Standard: Policies and procedures. Implement reasonable and appropriatepolicies and procedures to comply with the standards, implementation specifications, or other requirements ofthis subpart, taking into account thosefactors specified in §164.306 (b) (2) (i), (ii), (iii), and (iv). This standard is notto be construed to permit or excuse anaction that violates any other standard, implementation specification, or otherrequirements of this subpart. A coveredentity may change its policies and procedures at any time, provided thatthe changes are documented and areimplemented in accordance with thissubpart. (b) (1) Standard: Documentation. (i) Maintain the policies and procedures implemented to complywith this subpart in written (which maybe electronic) form; and (ii) If an action, activity or assessmentis required by this subpart to bedocumented, maintain a written (whichmay be electronic) record of the action, activity, or assessment. (2) Implementation specifications:VerDate Jan<31>2003 18:40 Feb 19, 2003 Jkt 200001 PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 E:\FR\FM\20FER2. SGM 20FER2 (i) Time limit (Required). Retain thedocumentation required by paragraph (b) (1) of this section for 6 years from thedate of its creation or the date when itlast was in effect, whichever is later. (ii) Availability (Required). Makedocumentation available to thosepersons responsible for implementingthe procedures to which thedocumentation pertains. (iii) Updates (Required). Reviewdocumentation periodically, and updateas needed, in response to environmentalor operational changes affecting thesecurity of the electronic protectedhealth information.

§164.318 Compliance dates for the initial implementation of the security standards

(a) Health plan.

    (1) A health plan that is not a smallhealth plan must comply with theapplicable requirements of this subpartno later than April 20, 2005.

    (2) A small health plan must comply with the applicable requirements of this subpart no later than April 20, 2006. (b) Health care clearinghouse. A health care clearinghouse must comply with the applicable requirements of thissubpart no later than April 20, 2005. (c) Health care provider. A coveredhealth care provider must comply with the applicable requirements of thissubpart no later than April 20, 2005.

Appendix A to Subpart C of Part 164—Security standards: Matrix

(R) =Required, (A) =Addressable

 

Standards

Sections

Implementation Specifications

Type

Administrative Safeguards

Security Management Process

164.308 (a) (1)

Risk Analysis

R

Risk Management

R

Sanction Policy

R

Information System Activity Review

R

Assigned Security Responsibility

164.308 (a) (2)

 

R

Workforce Security

164.308 (a) (3)

Authorization and /or Supervision

A

Workforce Clearance

?

ProcedureTermination Procedures

A

Information Access Management

164.308 (a) (4)

Isolating Health care Clearinghouse Function

R

Access Authorization

A

Access Establishment and Modification

A

Security Awareness and Training

164.308 (a) (5)

Security Reminders

A

Protection from Malicious Software

A

Log-in Monitoring

A

Password Management

A

Security Incident Procedures

164.308 (a) (6)

Response and Reporting

R

Contingency Plan

164.308 (a) (7)

Data Backup Plan

R

Disaster Recovery Plan

R

Emergency Mode Operation Plan

R

Testing and Revision Procedure

A

Applications and Data Criticality Analysis

A

Evaluation

164.308 (a) (8)

 

R

Business Associate Contracts and OtherArrangement

164.308 (b) (1)

Written Contract or Other Arrangement

R

Physical Safeguards Facility

Access Controls

164.310 (a) (1)

Contingency Operations

A

Facility Security Plan

A

Access Control and Validation Procedures

A

Maintenance Records

A

Workstation Use

164.310 (b)

 

R

Workstation Security

164.310 (c)

 

R

Device and Media Controls

164.310 (d) (1)

Disposal

R

Media Re-use

R

Accountability

A

Data Backup and Storage

A

Technical Safeguards

(see §164.312)

Access Control

164.312 (a) (1)

Unique User Identification

R

Emergency Access Procedure

R

Automatic Logoff

A

Encryption and Decryption

A

Audit Controls

164.312 (b)

 

R

Integrity

164.312 (c) (1)

Mechanism to Authenticate Electronic Protected Health Information

A

Person or Entity Authentication

164.312 (d)

 

R

Transmission Security

164.312 (e) (1)

Integrity Controls

A

Encryption

A

§164.500 [Amended]

6. §In 164.500 (b) (1) (iv), remove the words “including the designation of health care components of a covered entity”.

§165. 501 [Amended]

7. In §164.501, the definitions of the following terms are removed: Covered functions, Disclosure, Individual, Organized health care arrangement, Plan sponsor Protected health information, Required by law, and Use.

§164.504 [Amended]

8. In §164.504, the following changesare made:a. The definitions of the followingterms are removed: Common control, Common ownership, Health carecomponent, and Hybrid entity. b. Paragraphs (b) through (d) areremoved and reserved. Authority: Sections 1173 and 1175 of theSocial Security Act (42 U. S. C. 1329d–2 and 1320–4). Dated: January 13, 2003. Tommy G. Thompson, Secretary. [FR Doc. 03–3877 Filed 2–13–03; 8:45 am]BILLING CODE 4120–01–P