PwCs Iinterpretation of Final HIPAA Security Rule...

PricewaterhouseCoopers Interpretationof the Final HIPAA Security Rule

April 15, 2003

PricewaterhouseCoopers

Interpretation of the Final HIPAA Security Rule

HOW TO USE THIS DOCUMENT...................................................................................................1 BACKGROUND...............................................................................................................................1 MODIFICATIONS ............................................................................................................................1 §164.308(A)(1)(I) ADMINISTRATIVE SAFEGUARDS: SECURITY MANAGEMENT PROCESS.3

STANDARD: SECURITY MANAGEMENT PROCESS..............................................................................3 MODIFICATIONS .............................................................................................................................3

1. Renamed to �Information System Activity Review�............................................................................ 3 2. Removed �Security Policy� ................................................................................................................ 3

IMPLEMENTATION NOTES................................................................................................................3 1. Risk Analysis (Required) ................................................................................................................... 3 2. Risk Management (Required)............................................................................................................ 4 3. Sanction Policy (Required) ................................................................................................................ 4 4. Information System Activity Review (Required)................................................................................. 4

§164.308(A)(2) ADMINISTRATIVE SAFEGUARDS: ASSIGNED SECURITY RESPONSIBILITY5 STANDARD: ASSIGNED SECURITY RESPONSIBILITY ..........................................................................5 MODIFICATIONS .............................................................................................................................5

1. Required security responsibility assignment...................................................................................... 5 IMPLEMENTATION NOTES................................................................................................................5

1. Assigned Security Responsibility (Required) ..................................................................................... 5 §164.308(A)(3)(I) ADMINISTRATIVE SAFEGUARDS: ASSIGNED WORKFORCE SECURITY..6

STANDARD: ASSIGNED WORKFORCE SECURITY...............................................................................6 MODIFICATIONS .............................................................................................................................6

1. Combined items to form �Authorization and/or Supervision�.............................................................. 6 2. Renamed to �Workforce Clearance Procedure�................................................................................. 6 3. Moved �Termination Procedures� ...................................................................................................... 7 4. Moved �Security Awareness Training� ............................................................................................... 7 5. Removed "Personnel Security Policies and Procedures� ................................................................. 7

IMPLEMENTATION NOTES................................................................................................................7 1. Authorization and/or Supervision (Addressable)................................................................................ 7 2. Workforce Clearance Procedures (Addressable) .............................................................................. 7 3. Termination Procedures (Addressable) ............................................................................................. 8

§164.308(A)(4)(I) ADMINISTRATIVE SAFEGUARDS: INFORMATION ACCESS MANAGEMENT.........................................................................................................................................................8

STANDARD: INFORMATION ACCESS MANAGEMENT...........................................................................8 MODIFICATIONS .............................................................................................................................8

1. Added �Isolation of Health Care Clearinghouse Functions� ............................................................... 8 IMPLEMENTATION NOTES................................................................................................................8

1. Isolating Healthcare Clearinghouse Function (Required) .................................................................. 8 2. Access Authorization (Addressable) .................................................................................................. 8 3. Access Establishment and Modification (Addressable) ..................................................................... 9

§164.308(A)(5)(I) ADMINISTRATIVE SAFEGUARDS: SECURITY AWARENESS AND TRAINING.........................................................................................................................................................9

STANDARD: SECURITY AWARENESS AND TRAINING..........................................................................9 MODIFICATIONS .............................................................................................................................9

1. Combined all security awareness training ......................................................................................... 9 2. Renamed to �Protection from Malicious Software� ............................................................................ 9

IMPLEMENTATION NOTES..............................................................................................................10 1. Security Reminders (Addressable) .................................................................................................. 10 2. Protection from Malicious Software (Addressable) .......................................................................... 10 3. Log-in Monitoring (Addressable)...................................................................................................... 10 4. Password Management (Addressable)............................................................................................ 10

ii

§164.308(A)(6)(I) ADMINISTRATIVE SAFEGUARDS: SECURITY INCIDENT PROCEDURES 11 STANDARD: SECURITY INCIDENT PROCEDURES .............................................................................11 MODIFICATIONS ...........................................................................................................................11

1. Combined �Response� and �Reporting� ........................................................................................... 11 IMPLEMENTATION NOTES..............................................................................................................11

1. Response and Reporting (Required) ............................................................................................... 11 §164.308(A)(7)(I) ADMINISTRATIVE SAFEGUARDS: CONTINGENCY PLAN .........................12

STANDARD: CONTINGENCY PLAN..................................................................................................12 MODIFICATIONS ...........................................................................................................................12

1. Clarified the term �Emergency Mode�.............................................................................................. 12 IMPLEMENTATION NOTES..............................................................................................................12

1. Data Backup Plan (Required) .......................................................................................................... 12 2. Disaster Recovery Plan (Required) ................................................................................................. 12 3. Emergency Mode Operation Plan (Required).................................................................................. 12 4. Testing and Revision Procedures (Addressable)............................................................................. 13 5. Applications and Data Criticality Analysis (Addressable)................................................................. 13

§164.308(A)(8) ADMINISTRATIVE SAFEGUARDS: EVALUATION...........................................13 STANDARD: EVALUATION..............................................................................................................13 MODIFICATIONS ...........................................................................................................................14 IMPLEMENTATION NOTES..............................................................................................................14

1. Evaluation (Required) ...................................................................................................................... 14 164.308(B)(1) ADMINISTRATIVE SAFEGUARDS: BUSINESS ASSOCIATE CONTRACTS AND OTHER ARRANGEMENTS...........................................................................................................14

STANDARD: ADMINISTRATIVE SAFEGUARDS: BUSINESS ASSOCIATE CONTRACTS AND OTHER ARRANGEMENTS...................................................................................................................................................14 MODIFICATIONS ...........................................................................................................................15

1. Replaced �Chain of Trust Agreements� ........................................................................................... 15 IMPLEMENTATION NOTES..............................................................................................................15

1. Written Contract or Other Arrangement (Required) ......................................................................... 15 §164.310(A)(1) PHYSICAL SAFEGUARDS: FACILITY ACCESS CONTROLS .........................15

STANDARD: FACILITY ACCESS CONTROLS.....................................................................................15 MODIFICATIONS ...........................................................................................................................15

1. Combined items into �Access Control and Validation Procedures�.................................................. 16 2. Moved �Disaster Recovery� and �Emergency Mode Operations� .................................................... 16 3. Moved �Equipment Control�............................................................................................................. 16

IMPLEMENTATION NOTES..............................................................................................................16 1. Contingency Operations (Addressable) ........................................................................................... 16 2. Facility Security Plan (Addressable) ................................................................................................ 16 3. Access Control and Validation Procedures (Addressable) .............................................................. 16 4. Maintenance Records (Addressable) .............................................................................................. 17

§164.310(B) PHYSICAL SAFEGUARDS: WORKSTATION USE................................................17 STANDARD: WORKSTATION USE ...................................................................................................17 MODIFICATIONS ...........................................................................................................................17 IMPLEMENTATION NOTES..............................................................................................................17

1. Workstation Use (Required) ............................................................................................................ 17 §164.310(C) PHYSICAL SAFEGUARDS: WORKSTATION SECURITY.....................................18

STANDARD: WORKSTATION SECURITY ..........................................................................................18 MODIFICATIONS ...........................................................................................................................18 IMPLEMENTATION NOTES..............................................................................................................18

1. Workstation Security (Required)...................................................................................................... 18 §164.310(D)(1) PHYSICAL SAFEGUARDS: DEVICE AND MEDIA CONTROLS.......................18

iii

STANDARD: DEVICE AND MEDIA CONTROLS ..................................................................................18 MODIFICATIONS ...........................................................................................................................18

1. Removed �Access Control�.............................................................................................................. 18 2. Added �Media Re-Use� .................................................................................................................... 18

IMPLEMENTATION NOTES..............................................................................................................19 1. Disposal (Required) ......................................................................................................................... 19 2. Media re-use (Required).................................................................................................................. 19 3. Accountability (Addressable) ........................................................................................................... 19 4. Data backup and storage (Addressable) ......................................................................................... 19

§164.312(A)(1) TECHNICAL SAFEGUARDS: ACCESS CONTROL ..........................................19 STANDARD: ACCESS CONTROL.....................................................................................................19 MODIFICATIONS ...........................................................................................................................20

1. Expanded the access control options .............................................................................................. 20 2. Renamed �Encryption and Decryption�............................................................................................ 20 3. Moved �Audit Controls� .................................................................................................................... 20 4. Moved �Authorization Controls� ....................................................................................................... 20 5. Moved �Data Authentication� ........................................................................................................... 20 6. Moved �Entity Authentication�.......................................................................................................... 20

IMPLEMENTATION NOTES..............................................................................................................20 1. Unique User Identification (Required).............................................................................................. 20 2. Emergency Access Procedure (Required)....................................................................................... 21 3. Automatic Logoff (Addressable) ...................................................................................................... 21 4. Encryption and Decryption (Addressable) ....................................................................................... 21

§164.312(B) TECHNICAL SAFEGUARDS: AUDIT CONTROLS ................................................22 STANDARD: AUDIT CONTROLS ......................................................................................................22 MODIFICATIONS ...........................................................................................................................22 IMPLEMENTATION NOTES..............................................................................................................22

1. Audit Controls (Required) ................................................................................................................ 22 §164.312(C)(1) TECHNICAL SAFEGUARDS: INTEGRITY.........................................................22

STANDARD: INTEGRITY .................................................................................................................22 MODIFICATIONS ...........................................................................................................................23

1. Removed �Double Keying�............................................................................................................... 23 IMPLEMENTATION NOTES..............................................................................................................23

1. Mechanism to Authenticate Electronic Protected Health Information (Addressable) ....................... 23 §164.312(D) TECHNICAL SAFEGUARDS: PERSON OR ENTITY AUTHENTICATION............23

STANDARD: PERSON OR ENTITY AUTHENTICATION ........................................................................23 MODIFICATIONS ...........................................................................................................................23

1. Removed authentication examples.................................................................................................. 23 IMPLEMENTATION NOTES..............................................................................................................24

1. Person or Entity Authentication (Required)...................................................................................... 24 §164.312(E)(1) TECHNICAL SAFEGUARDS: TRANSMISSION SECURITY .............................24

STANDARD: TRANSMISSION SECURITY ..........................................................................................24 MODIFICATIONS ...........................................................................................................................24

1. Removed "Message Authentication"................................................................................................ 24 2. Removed "Network Controls� .......................................................................................................... 24 3. Removed "Access Controls� ............................................................................................................ 24

IMPLEMENTATION NOTES..............................................................................................................24 1. Integrity Controls (Addressable) ...................................................................................................... 24 2. Encryption (Addressable) ................................................................................................................ 25

§164.314 (A)(1) ORGANIZATIONAL REQUIREMENTS: BUSINESS ASSOCIATE CONTRACTS OR OTHER ARRANGEMENTS...........................................................................................................25

STANDARD: BUSINESS ASSOCIATE CONTRACTS OR OTHER ARRANGEMENTS..................................25

iv

MODIFICATIONS ...........................................................................................................................26 1. Added unique situations .................................................................................................................. 26

IMPLEMENTATION NOTES..............................................................................................................26 1. Business Associate Contracts (Required) ....................................................................................... 26

§164.314 (B)(1) STANDARD REQUIREMENTS FOR GROUP HEALTH PLANS ......................26 STANDARD: STANDARD REQUIREMENTS FOR GROUP HEALTH PLANS .............................................26 MODIFICATIONS ...........................................................................................................................26 IMPLEMENTATION NOTES..............................................................................................................27

1. Document amendment provisions (Required) ................................................................................. 27 §164.316 (A) POLICIES AND PROCEDURES.............................................................................27

STANDARD: POLICIES AND PROCEDURES ......................................................................................27 MODIFICATIONS ...........................................................................................................................27 IMPLEMENTATION NOTES..............................................................................................................28

1. Policies and Procedures (Required) ................................................................................................ 28 §164.316(B)(1) DOCUMENTATION..............................................................................................28

STANDARD: DOCUMENTATION.......................................................................................................28 MODIFICATIONS ...........................................................................................................................28 IMPLEMENTATION NOTES..............................................................................................................28

1. Time limit (Required) ....................................................................................................................... 28 2. Availability (Required)...................................................................................................................... 28 3. Updates (Required) ......................................................................................................................... 28

FOR MORE INFORMATION .........................................................................................................29

v

How to Use This Document Assuming that you have implemented HIPAA privacy within your organization, your organization ideally addressed security and has implemented the safeguards required in the Privacy rule. However, many organizations may be just beginning to focus on security, or you may be wondering if your privacy implementation is sufficiently supported by your security infrastructure. This document is designed to help you develop or refine your security program by providing a practical analysis and guide for applying the final HIPAA Security Rule to a your compliance efforts. We invite you to return to our website (http//www.pwchealth.com) periodically, as this document will be frequently updated with lessons learned and industry practices over time. We intended this document to be used as you, the reader, needs. Therefore, for those of you who were familiar with the proposed HIPAA security regulations, we have provided the new Standards and Modifications from the proposed for each standard. However, for those that are familiar with the final HIPAA Security Rule, we have provided Implementation Notes for each standard. We encourage you to read the details for only those areas of interest to you, rather than reading this document from beginning to end. NOTE: This is not intended to be legal advice, but rather our interpretation and understanding. You should consult your attorneys for legal advice. Background On August 12, 1998, the Department of Health and Human Services (HHS) published a proposed rule to establish a minimum standard for the security of electronic health information used by covered entities. HHS received approximately 2,350 public comments about the rule over the past five years. On February 20, 2003, after taking into consideration the public comments, HHS published the final Security Rule. The rule becomes effective on April 21, 2003, with compliance dates of April 21, 2005 for covered entities, with the exception that small health plans must comply with the requirements by April 21, 2006. It should be noted that covered entities were required to comply with the privacy regulations by April 14, 2003, and with the transaction and code set regulations by October 16, 2003. The final security regulations contain requirements for safeguarding the privacy of protected health care information and security is integral to privacy compliance, and so must be implemented by the April 2003 privacy compliance date. Other security standards must be met to protect transactions data by October 2003; the remaining standards must be met by April 2005. In addition to covered entities (i.e., health plans, health care clearinghouses, and certain health care providers), various business partners of HIPAA covered entities will be required to provide assurance to their respective covered entities that they are in compliance with certain privacy and security practices. The final Security Rule adopts standards for the security of electronic protected health information (PHI) to be implemented by HIPAA covered entities. The hope in creating a minimum security standard for electronic PHI is to improve the Medicare and Medicaid programs, other Federal 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. Modifications To establish a minimum baseline of security standards for electronic PHI, the final Security Rule includes security standard and implementation specifications grouped under one of three categories: Administrative Safeguards, Physical Safeguards, and Technical Safeguards. These specifications have been designed to be comprehensive, technology-neutral, and scalable, which will allow covered entities the flexibility they will need to meet the standards as technology changes and improves. The rule is composed of 18 standards, each of which may have required and addressable implementation specifications. All covered entities must comply with all the standards with respect to electronic protected health information and they must review and modify their security measures as needed to continue

PricewaterhouseCoopers Interpretation of the Final HIPAA Security Rule

1

http://www.pwchealth.com/

reasonable and appropriate protection of electronic PHI. A covered entity must: ensure the confidentiality, integrity, and availability of all electronic PHI it creates, receives, maintains, or transmits; protect against any reasonably anticipated threats or hazards to the security or integrity of electronic PHI; protect against any reasonably anticipated uses or disclosures of PHI that are not permitted or required under the privacy rules; and ensure compliance by its workforce. Although some lawyers will interpret that word, �ensure�, in the most strict way by saying that it means to make inevitable, a reasonable person would put it in the context of the flexibility specified in the rules. The rules say that a covered entity may use any security measures that allow it to reasonably and appropriately implement the standards and implementation specifications, taking into account: The size, complexity, and capabilities of the covered entity; The covered entity's technical infrastructure, hardware, and software security capabilities; The costs of security measures; and The probability and criticality of potential risks to electronic protected health information.

Although covered entities must implement all 18 of the Standards and the Required Implementation Specifications, they must only �assess� the Addressable Implementation Specifications to see if they are reasonable and appropriate in their environment. When analyzed as to their contribution to protecting electronic PHI, covered entities must implement them if reasonable and appropriate. If implementing an Addressable Implementation Specification is not reasonable and appropriate, the covered entity must document why it would not be reasonable and appropriate to implement, and implement an equivalent alternative measure if that is reasonable and appropriate. Many of the comments from the public requested that the standards within the final rule be prioritized. While the rule does not go so far as to provide a detailed roadmap for implementation, the alphabetical ordering of the proposed rule has been replaced with an order that HHS believes to be more appropriate to the order in which a covered entity might consider implementing the standards, emphasizing the importance of risk analysis and risk management. For example, �Security Management Process�, which includes the requirement for risk analysis, is listed first under the �Administrative Safeguards� section, as HHS believes that this forms the foundation upon which the implementation of all the other standards depends. Because covered entities must have become compliant with the Privacy Rule by April 14, 2003, many entities incorporated elements of security into their privacy preparation. While inextricably linked, the scope of the final Privacy and Security Rules differ significantly. The Privacy Rule applies to protected health information in any form, whereas the Security Rule applies only to protected health information in electronic form. In other words, health information in non-electronic form is covered under the Privacy rule but not covered under the Security Rule. The intent and overall concept of the final Security Rule is materially the same as the proposed Security Rule and does not contradict the safeguard requirements in the Privacy Rule. In fact, the language and content within the Security Rule has been made consistent with the Privacy Rule throughout. While there have been a large number of changes to the final Security Rule, the vast majority of those changes have been made to align with the Privacy Rule, clarify many misunderstandings, and reorganize the content to make it more understandable. These changes are explained in more detail in the body of this paper. To summarize the changes in general, HHS has:

Reorganized the final rule to make it more readable, eliminating redundancies, consolidating categories, expanding the administrative category, clarifying a number of concepts, limiting the rule�s scope, and generally making it more �user friendly.�

o

o

o

Eliminated the electronic signature requirement.

Added the concept of �addressable� specifications to clarify the intent of scalability and maintain flexibility in covered entities� ability to implement security safeguards that are appropriate for the entities� specific environment.


2

Clarified that a covered entity is not responsible for the security of a transmission it receives (an email from a patient, for example), but that it is responsible for PHI once received.

o

o

o

o

Drawn no distinction between internal and external data movement, therefore covering electronic health information at rest as well as during transmission.

Emphasized that ensuring availability of ePHI is a critical component to security. In health care, making sure ePHI is available may take a higher priority than securing the ePHI. This is especially true in provider entities where denial of access to ePHI needed to make patient care decisions (intended or unintended) could create negative outcomes.

We present our analysis within the sections provided by the final Security Rule: Administrative Safeguards, Physical Safeguards, and Technical Safeguards. Within each section, we include a summary of our interpretation and implementation of the new rule. §164.308(a)(1)(i) Administrative Safeguards: Security Management Process

Standard: Security Management Process �Implement policies and procedures to prevent, detect, contain and correct security violations.� Modifications There are few differences between the proposed Security Rule and the final Security Rule regarding the Security Management Process except for the importance placed on this standard. The standard calls for the establishment of a security management process to involve the creation, administration, and oversight of policies to address the full range of security issues and to ensure the prevention, detection, containment, and correction of security violations. In the proposed rule, standards were ordered alphabetically. Within the final rule, standards have been placed in an order for which it would make sense that covered entities implement the standards. Thus, Security Management Process was placed first within Administrative Safeguards because HHS believes this to be the foundation upon which the implementation of all the other standards will be based. In fact, all four implementation specifications under this standard are considered important enough to be required.

1. Renamed to �Information System Activity Review� In the proposed rule, there was a separate standard for Internal Audit. Within the final rule, Internal Audit has been renamed to Information System Activity Review and moved to the Security Management Process. It has been made a required specification.

2. Removed �Security Policy� The requirement for a Security Policy was removed as it was determined to be redundant. Implementation Notes

1. Risk Analysis (Required) �Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.� The analysis can be carried out either by the entity�s workforce (security organization or internal audit) or by an external agency. The depth and scope of risk analysis should be consistent with the type and size of the entity. The following areas should be considered for inclusion:

Systems housing PHI, based on the security concepts of confidentiality, integrity and availability.


3

Security processes (security administration, security monitoring, incident response, forensic procedures, and virus detection).

o

o o o o o o

o

o

o o o o

o

Physical access to the data center and other critical operations areas. Contingency planning. Operating system and/or platform configurations. Network (LAN, WAN, VAN) configurations. Data repositories (e.g., Oracle, SQL). Portal/web architecture.

Threat assessment should be an integral part of the risk analysis. Depending on the type and size of the entity, a threat assessment might include internal and external penetration testing, as well as controls around the network and servers/systems that house PHI. The Evaluation process (§164.308(a)(8)) should then be used to periodically re-evaluate the entity�s risk stance.

2. Risk Management (Required) �Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.� The security measures and implementations performed by a covered entity, whether �required� or �addressable�, will be the result of decisions made in its risk management process. The results of the risk analysis provide the information on which to base those decisions. The risk management process will include those actions taken to document and mitigate the risks identified in the analysis to a reasonable and appropriate level. The definition of a reasonable and appropriate level will be left to the discretion of each covered entity, and will be dependent upon size of the entity, level of risk, and cost of safeguard implementation, among other factors. Again, the degree of risk management activities will depend on the size and type of entity. A comprehensive risk management process should include the development of the following:

Processes to track industry-posted vulnerabilities, either devising corrective actions in order to remediate the risks, or making conscious decisions to accept the risks posed by the vulnerabilities. Processes to perform security assessments periodically as vulnerabilities are continuously being identified with the industry. Documentation of the threats and vulnerabilities to the systems and network. Presentation of the issues identified during the security assessments to management. Identification of options and associated costs for remediation. Processes to make necessary changes to the continuity plan based on the results of the risk assessment. Documentation of security implementation decisions. This should include the information used to make those decisions (usually based on the risk analysis) and the supporting rationale.

3. Sanction Policy (Required) �Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.� Covered entities must implement sanction policies for security violations around electronic PHI. The decision as to the type and severity of the sanction imposed will be left to the discretion of each covered entity. The policy should be published as part of the covered entity�s security policy, and all employees, vendors, and contractors should be made aware of ramifications of violating the security policies. The policy should make it clear that the sanctions will be applied uniformly across the workforce.

4. Information System Activity Review (Required) �Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.�


4

The intent of this implementation specification is to monitor information system activity through the periodic review of audit logs, access reports, and security incident reports. The degree and scope of implementation will vary widely. For example, smaller entities could use paper reports to track some activities. The activity review will also depend on the choices a covered entity makes to enforce its policies. For example, each entity should strike a balance between proactive controls (e.g. tight access control policy and enforcement) and the retroactive controls provided by audit trails and activity review. To coordinate this effort, we suggest the following:

Develop a process for the review of exception reports and/or logs (who reviews, how often, what is the anomaly process).

o

o

o

o

o

o o

o o

Determine the types of audit trail data and monitoring procedures that would be needed to drive the exception reports. Develop a strategy for implementing monitoring procedures for systems with no current monitoring capability. Develop procedures to ensure that Information Systems administrative personnel are following corporate policies and procedures (i.e., who monitors the police). Install appropriate monitoring tools (third party, freeware, or OS-provided) to log activity and security violations against PHI. Develop processes for retention of monitoring data appropriate for the policies being enforced. Establish a process to periodically review compliance to security policies and procedures.

§164.308(a)(2) Administrative Safeguards: Assigned Security Responsibility Standard: Assigned Security Responsibility �Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the entity.� Modifications The proposed rule allowed security responsibility to be assigned to an individual or an organization. The final Security Rule requires that one security official be responsible for the development and implementation of the policies and procedures as listed in the final Security Rule. This is consistent with the Privacy�s Rule requirement for a Privacy Official.

1. Required security responsibility assignment In the final Security Rule, it is clarified that the responsibility for a covered entity�s security must be assigned to one official. Responsibilities would include the management and supervision of the following:

The use of security measures to protect data The conduct of personnel in relation to the protection of data

Several commenters expressed concern about the responsibility lying with only one person. However, this was done to ensure accountability for the overall security environment. Security responsibilities can be delegated to appropriate personnel and in fact, security is really the responsibility of all staff. Implementation Notes

1. Assigned Security Responsibility (Required) The standard serves as the sole implementation specification. Security work and responsibility should be delegated to an individual to be responsible for security at the organization. In fact, while responsibility will ultimately lie with one individual, a sound security management structure will ensure sound security practice. As much as possible, the security official


5

should report progress and/or status reporting on a regular basis to a senior executive who can act as a champion for information security in the organization. The level of authority of the security official should be commensurate with the responsibility. We recommend the following:

Identify a senior executive that will act as the champion for information security. o o

o o o o o

o

Ensure that the information security official reports to upper management so that he or she will have organizational authority and political leverage. Develop and document specific roles and responsibilities for each member of the Security Team. Develop a security strategy that aligns with business and technology objectives. Develop working relationships with operating and business units. Create and formalize a program for implementing the security policies. Develop a process to keep the program and the policies current as changes to technology and the business occur. Develop metrics to measure the success of the security program.

§164.308(a)(3)(i) Administrative Safeguards: Assigned Workforce Security

Standard: Assigned Workforce Security �Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, and to prevent those workforce members who are not authorized to have access under the Information Access Management standard from obtaining access to electronic protected health information.�

Modifications The overall purpose of this standard remains nearly identical to that in the proposed Security Rule, though it has been renamed from Personnel Security. The impetus of the standard is still to implement policies and procedures to ensure that all members of a covered entity�s workforce have appropriate access to electronic protected health information, and to prevent those workforce members who should not have access from obtaining access to electronic protected health information. All specifications within the standard have been made addressable. In addition, the definition of �workforce� was intended to coincide with that definition as used in the Privacy Rule.

1. Combined items to form �Authorization and/or Supervision� In the proposed rule, there were two standards: �Assuring supervision of maintenance personnel by an authorized, knowledgeable person" and "Assuring that operations and maintenance personnel have proper access authorization." In the final Security Rule, these two standards have been combined to form the �Authorization and/or Supervision� implementation specification. Because it may not be feasible for smaller organizations to identify a �knowledgeable person�, that implementation specification has been made addressable and modified to state that workforce members, such as operations or maintenance personnel that work with or around electronic PHI must be either authorized to do such work or supervised while performing the work.

2. Renamed to �Workforce Clearance Procedure� �Personnel clearance procedure� was renamed to �Workforce clearance procedure� and made an addressable implementation specification in response to a number of comments inquiring whether or not a clearance procedure included background checks. The inclusion of background checks was never intended to be part of this standard; rather the intent was to ensure that a screening process be in place before granting a member of the workforce access to electronic PHI to ensure that access was appropriate. In addition, several commenters requested that details be provided on restrictions to be placed on the workforce. In order to maintain flexibility, this was not incorporated into the final standard. Restrictions


6

will depend upon job responsibility, level of risk, the amount and type of supervision required, as well as other factors that should be determined by each covered entity.

3. Moved �Termination Procedures� Termination procedures have been made a part of the "Workforce Security" standard as an addressable implementation specification. In addition, all of the following features from the proposed standard were removed:

changing locks, o o o o

o

o

removal from access lists, removal of user accounts, turning in of keys, tokens, or cards.

The standard states that procedures need to be in place to terminate all access to electronic PHI when an employee leaves. Policies and procedures should be updated accordingly, and should detail steps that will need to be taken, such as revoking passwords and retrieving keys when a termination occurs.

4. Moved �Security Awareness Training� �Security Awareness Training� was removed from �Workforce Security Training� and included as part of the separate �Security Awareness and Training� standard.

5. Removed "Personnel Security Policies and Procedures� �Personnel Security Policies and Procedures� were removed as a separate implementation specification as it was considered to require redundant effort. Implementation Notes

1. Authorization and/or Supervision (Addressable) �Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.� Each entity should assess its need to establish procedures to authorize access to all personnel who work in areas where PHI might be available. The authorization process should be owned and by management who understand the access requirements of the personnel, based upon the job role and associated responsibilities, as well as the risk of exposure of the available data. This may require supervision of systems and maintenance personnel if they are not part of the workforce. If this is the case, consider the following control measures for access authorization:

Custodians should undergo a more stringent access authorization process if working in areas containing PHI and perhaps be limited to accessing the floors that they are responsible for cleaning. Access authorization procedures should be developed for HVAC and computer maintenance personnel when in areas containing PHI and information processing or related equipment.

2. Workforce Clearance Procedures (Addressable) �Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.� This implementation specification requires entities to assess their need for a procedure to determine that all workforce access to PHI is appropriate based on their need-to-know and job function. Each organization should determine if background employment checks are appropriate prior to allowing an individual access to PHI.


7

3. 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.� An entity should assess its need to develop formal termination procedures so that when an employee or contractor is terminated, the following items are addressed:

Changing of locks/combinations if necessary. o o o o o

Removal from logical and physical access lists in a timely manner. Account removal/disablement. Deletion of personal files. Return of physical security items (e.g. keys, access card, laptops).

Procedures to establish closed loop feedback controls for terminations should be considered. These procedures would ensure the assignment of each portion of the termination procedures and accountability for completing and reporting terminations to Human Resources (HR) and/or Information Systems Security. An automated transmission from the HR and/or contracts system may also be appropriate. §164.308(a)(4)(i) Administrative Safeguards: Information Access Management

Standard: Information Access Management �Implement policies and procedures for authorizing access to electronic protected health information.� Modifications The majority of the information contained within the proposed �Information Access Control� standard has been maintained within the renamed �Information Access Management� standard in the final rule; however, there has been some minor restructuring; e.g., �Access authorization� and �Access establishment and modification� have been made addressable implementation specifications. The intent of the standard is still to ensure that there are defined and implemented policies and procedures for authorizing access to electronic PHI, and restricting access to those who need it.

1. Added �Isolation of Health Care Clearinghouse Functions� A required specification has been added to require that health care clearinghouses that are owned by larger companies ensure that electronic PHI is protected from unauthorized access by personnel within the larger company. Implementation Notes

1. Isolating Healthcare Clearinghouse Function (Required) �If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.� This will mean determining which departments or individuals have access to PHI and developing procedures to remove that access if it is not appropriate. Affected covered entities must implement separation procedures to ensure appropriate access based on business functions of the clearinghouse and the individuals in those areas.

2. Access Authorization (Addressable) �Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.�


8

Each entity should gather information about current levels of access to corporate applications and applications containing protected health information. Then the appropriate department managers should be consulted to identify job functions that can be accommodated with role-based access. If possible, user access to systems should be granted through groups in order to provide the highest level of security. This information gathering process may be used to isolate the health care clearinghouse function mentioned above.

3. Access Establishment and Modification (Addressable) �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.� A covered entity must assess its need for a process to create or modify a user�s system and/or application access must be developed. This process should establish access guidelines that are standardized for all existing applications and systems where possible. This would include items such as:

Unique identification/authentication with appropriate formats (i.e., not SSN). o o o o

o o o o

Password management. Required authorization. Privileged users (e.g. system administrators and hospital administrators typically require higher levels of access to electronic PHI).

§164.308(a)(5)(i) Administrative Safeguards: Security Awareness and Training Standard: Security Awareness and Training �Implement a security awareness and training program for all members of its workforce (including management).�

Modifications HHS believes that security awareness training is an important aspect of an organization�s training program and its security program. While several commenters requested that the standard be removed, made optional or made to serve as a guideline, it remains part of the rule due to its criticality. Specifically, the following items fall into the category of �Security awareness and training:�

periodic security reminders and updates. procedures for guarding against, detecting, and reporting malicious software. procedures for monitoring log-in attempts and reporting discrepancies. procedures for creating, changing, and safeguarding passwords.

All specifications for the standard have been made addressable and must be assessed by each covered entity for implementation if reasonable and appropriate.

1. Combined all security awareness training All proposed references to security awareness and training were incorporated under this one standard for consistency.

2. Renamed to �Protection from Malicious Software� This addressable implementation specification was changed from �Virus protection� to ensure the inclusion of malicious programs besides viruses, such as worms.


9

Implementation Notes Security awareness training should include overall security awareness, periodic reminders, malicious software protection, and password management. However, a comprehensive security awareness program would also include such topics as security incident identification and reporting procedures, and user-specific topics necessary for individual workstation security. We provide implementation features as they are listed under HIPAA.

1. Security Reminders (Addressable) �Periodic security updates.� Security advisories or reminders should be periodically distributed to all affected users, including contractors. Suggested delivery methods are e-mail, flyers and an intranet site. Security reminders should include warnings on current risks such as latest viruses, social engineering, new technical vulnerabilities, and risks and countermeasures specific to the covered entity. The definition of �periodic� is left up to each covered entity, but we recommend at least twice per year.

2. Protection from Malicious Software (Addressable) �Procedures for guarding against, detecting, and reporting malicious software.� The existence of virus scanning software and virus procedures within an incident response plan will be part of the overall solution to guard against malicious software. The intent of the implementation specification is to ensure that there are procedures in place so that all users know how to respond to viruses. This might include guidelines such as the following:

o Contacting a system administrator or help desk if there is an unidentified or strange file received through email.

o Upon identification of a virus, quarantining systems for proper remediation. o Listing both appropriate and inappropriate actions in the event of a virus.

3. Log-in Monitoring (Addressable) �Procedures for monitoring log-in attempts and reporting discrepancies.� Administrators should be on the look out for log-in attempts from unauthorized users through the examination of audit and log files. Users should be made aware of steps to be taken and who to contact in the event of suspicious scenarios that may include the following:

User leaves his/her desk and returns to find that he/she has been locked out or cannot login in the morning.

o

o

o o

o

User notices that a different username has been entered into the log-in box.

4. Password Management (Addressable) �Procedures for creating, changing, and safeguarding passwords.� All users should be aware of the importance of selecting strong passwords. Some example elements of strong passwords might include:

The password is at least 8 characters long A varied set of characters, including lowercase and uppercase letters, numerals, and symbols (like spaces, dots, colons, quote marks, dollar signs) are used. It does not use palindromes (�abba�, �oininio�, �14541�) or sequences (�12345�, �abcd�).

Lastly, users should be made aware of the covered entity�s policy for safeguarding passwords. We suggest the following:


10

Passwords may not be shared o o o o

o

o

Passwords should not be written down Passwords should not use any word found in any dictionary or proper names Passwords must be changed periodically, and must be changed immediately if compromised

§164.308(a)(6)(i) Administrative Safeguards: Security Incident Procedures Standard: Security Incident Procedures �Implement policies and procedures to address security incidents.�

Modifications HHS has removed the term �security breach� and replaced it with the term �security incident�. They then redefined it to mean the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. The intent of this standard is to implement policies and procedures to address security incidents, including network activity and misuse of data.

1. Combined �Response� and �Reporting� Realizing that responding to a security event and proper reporting of that event go hand in hand, the proposed specifications �Report Procedures� and �Response Procedures� were combined into one required specification, entitled �Response and Reporting.� Implementation Notes

1. 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.� In the event of a security incident, a covered entity must be able to follow defined policy and procedures for reporting and responding to that incident. These procedures should include escalation procedures based on the criticality of incident. Some of the tasks related to security incident response and reporting procedures might include the following:

A crisis management plan to manage the release of information about security and privacy breaches to the media and public. Forensic procedures to capture evidence of security breaches for prosecution.

As part of a comprehensive security awareness and training program, all users should know who to call if they suspect a security incident. In addition, information technology personnel should be made aware of these procedures and certain parties should be trained in the proper handling of electronic evidence. Incident procedure and reporting forms a keystone for enforcement of policies that are impractical or inefficient to enforce using technology. For example:

° Developing a procedure for safely reporting password sharing violations. ° Procedure for challenging and/or reporting unauthorized personnel in a computer room.

Note: Incident reporting procedures are a key component of protecting PHI and enforcing physical security measures such as name badge requirements and physical access control for non-electronic related areas of the facility such as medical records.


11

§164.308(a)(7)(i) Administrative Safeguards: Contingency Plan 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.�

Modifications The same features of the proposed rule have been adopted for the final Security Rule. Some were made addressable and some are required as follows: �Data Backup Plan,� �Disaster Recovery Plan,� and �Emergency Mode Operation Plan� have been made required specifications, while �Testing and revision procedures� and �Applications and Data Criticality Analysis� specifications have been made addressable.

1. Clarified the term �Emergency Mode� The final rule clarifies the �Emergency mode operations plan� to state that it only involves those critical business processes that must occur to provide availability and protect the security of electronic PHI during and immediately after a crisis. It has been made a required specification. Implementation Notes

1. Data Backup Plan (Required) �Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.� The implementation specification requires that there be retrievable exact copies of electronic PHI in the event of an emergency or loss of data. To that end, each covered entity should perform backups of all systems and information that are required to meet obligations and function successfully; at the very least, those that house PHI. The frequency of system and data backups should be determined based on the level of risk of loss of that data. The backup media should then be stored at a secure, preferably offsite, location. Finally, the backups should be tested periodically (we recommend at least twice a year) to ensure the systems and data can be recovered within anticipated timeframes.

2. Disaster Recovery Plan (Required) �Establish (and implement as needed) procedures to restore any loss of data.� This implementation specification specifically requires that covered entities be able to restore any data that has been lost through a disaster. Backups of all data will have been made, per the above recommendation. However during a disaster, servers and systems may be lost and data will need to be recovered to new systems. Therefore, a disaster recovery plan should be developed for all critical, server-based systems, communications, and infrastructure items (i.e., e-mail, voice-mail, fax server). The plan should be periodically reviewed and tested to ensure that it:

is appropriate in scope, o o o o

includes recent system updates, includes crisis management team changes, and includes latest testing results.

3. Emergency Mode Operation Plan (Required) �Establish (and implement as needed) procedures to enable continuation of critical business processes to assure access to ePHI and provide for adequate protection of the security of electronic protected health information while operating in emergency mode.�


12

PHI will need to be protected, even during a disaster or crisis. For this reason, a crisis management team should be identified that will be responsible for activating the contingency and recovery plans during the emergency mode, coordinating activities and implementing the required tasks. They should be aware of all HIPAA requirements and the location of all PHI. The crisis management team should include appropriate representation from executive management, information technology personnel, and business operations, especially those knowledgeable about electronic PHI. A contingency plan should be developed for all systems that incorporate critical items as determined through the risk analysis (at the least those servers housing PHI). This plan will enable the continuation of the business processes (and the protection of electronic PHI) in the event of an emergency. The plan should consider:

Business Drivers. o o o o o o

Patient Safety Performance Obligations. Business Processes. Process Dependencies. Service Management.

Lastly, a strategy for the recovery of business operations should be developed. Options include maintaining leases for office space, entering into reciprocal agreements with nearby organizations, or contracting services from a third party service provider. A process should be established for determining metrics and criteria that identify when a business should close down operations and redirect its operations to other facilities.

4. Testing and Revision Procedures (Addressable) �Implement procedures for periodic testing and revision of contingency plans. � Covered entities must assess the need to have contingency and recovery plans reviewed and tested on a regular basis and following significant changes to the business or system/network environment. We recommend that testing and/or revision occur at least on an annual basis. During testing, it will be important to ensure that appropriate security measures are in place to prevent unauthorized disclosure of electronic PHI. A process should be in place to review the results of the testing and revise the plan to adjust to deficiencies found during testing.

5. Applications and Data Criticality Analysis (Addressable) �Assess the relative criticality of specific applications and data in support of other contingency plan components.� Covered entities must assess the need to classify information systems, applications, and data groups according to their criticality and sensitivity (specific to HIPAA, this will at least include those that house or touch PHI). Business units and information owners should lend their assistance to this effort. The information systems classification should include infrastructure and personal items as well, such as e-mail, fax, voicemail, laptops and personal digital assistants. The systems, applications, and data deemed critical should be emphasized during recovery and contingency efforts, as PHI will need to be protected, even during a disaster. §164.308(a)(8) Administrative Safeguards: Evaluation 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


13

affecting the security of electronic protected health information, that establishes the extent to which an entity's security policies and procedures meet the requirements.�

Modifications As defined in the proposed rule, �Certification� was �the technical evaluation performed as part of, and in support of, the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a pre-specified set of security requirements. This evaluation may be performed internally or by an external accrediting agency.� In the final Security Rule, the specification has been renamed to �Evaluation.� In addition, language within the rule has been modified to indicate that the evaluation should cover the entire rule, both technical and non-technical elements. 1. Required the entire program be evaluated The certification in the proposed rule implied a security certification of a computer system or network design and its respective implementation. The final rule calls for an evaluation of the security around an entity�s electronic PHI, both technical and non-technical elements as defined in this rule. The final rule also requires a covered entity to evaluate the extent to which its policies and procedures meet the requirements of the rule.

Implementation Notes

1. Evaluation (Required) The standard serves as the sole implementation specification. An entity's risk analysis and risk management measures must be designed to lead to the implementation of security measures that will comply with the Security Rule. Each covered entity will be measured not only against its own policies, which presumably have been created to suitably address security risks within the entity�s environment, but also against compliance to the HIPAA security standards. This standard is a requirement for each entity to see how it measures up against its own security program. Each covered entity may elect to perform the evaluation on its own or through an external agency or some combination of both. A comprehensive evaluation should at least include the following items:

Risk analysis. o o o o o o o o o o o o o

Threat assessment. Operating system and network device security configurations. Workforce security. Access controls and authorization to PHI. Security awareness. Security incident response. Physical security. Transmission security. Security model (i.e., data classification/ownership). Security organizational structure. Security policies/procedures. Security architecture and design.

164.308(b)(1) Administrative Safeguards: Business Associate Contracts and Other Arrangements

Standard: Administrative Safeguards: Business Associate Contracts and Other Arrangements �A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances that the business associate will appropriately safeguard the information.�


14

Modifications In the proposed rule, chain of trust agreements were required with all entities with whom electronic PHI was shared. Agreements are still required under the new rule; however, to ensure consistency with the Privacy Rule and using the same structure, agreements are only required with business associates.

1. Replaced �Chain of Trust Agreements� In the proposed rule, it was required that covered entities enter into a chain of trust partner agreement with all entities with which they shared health information, in which the partners agree to electronically exchange data and protect the integrity, confidentiality, and availability of the data exchanged. This standard has been renamed to �Business associate contracts and other arrangements� to reflect the business associate structure defined in the Privacy Rule. Language was also revised to define who must enter into a contract under this rule. As part of the final rule, a covered entity is required to document through a written contract or other arrangement with the business associate the satisfactory assurances that the business associate will take the necessary steps to protect electronic PHI. Each company will decide for itself the meaning of �satisfactory assurances� as well the �necessary steps� to ensure the protection of electronic PHI. Implementation Notes

1. Written Contract or Other Arrangement (Required) �Document the satisfactory assurances required through a written contract or other arrangement with the business associate that meets the applicable requirements.� Each covered entity should have a clear understanding of what data is being exchanged with its various business associates. Each covered entity should clearly document and communicate objectives and responsibilities with regards to protecting electronic PHI to each business associate. In particular, the covered entity should:

Develop language requirements for business associate contracts based upon HIPAA regulations. o o

o

Review current contracts to assess the need for amendment or re-contracting and ensure the inclusion of HIPAA verbiage where appropriate. Negotiate with business associates to implement amendments or new agreements as necessary.

The business associate should be able to provide satisfactory assurances that it can and will safeguard all protected health information connected with the covered entity. If it cannot do so, the covered entity may put itself at risk of non-compliance with the HIPAA standard. §164.310(a)(1) Physical Safeguards: Facility Access Controls

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.� Modifications In the final Security Rule, �Physical Access Controls� has been renamed to "Facility Access Controls", as there was much discussion as to what physical boundaries should be included in the organization�s controls. Thus �facility� was defined as the physical premises and interior and exterior of a building. Other changes simply moved some of the original items to other standards. All four remaining implementation specifications are addressable.


15

1. Combined items into �Access Control and Validation Procedures� The following four procedures were combined into one addressable implementation specification, allowing each covered entity to determine what visitor and workforce authorization procedures:

- "Procedures for Verifying Access Authorizations" - "Need to Know Procedures for Personnel Access" - "Procedures to Sign In Visitors and Provide Escort, If Appropriate" - "Testing and Revision�

2. Moved �Disaster Recovery� and �Emergency Mode Operations� These two items were moved to Contingency Plan, as they require processes to be used during recovery from a disaster; thus leaving this standard to address facility security.

3. Moved �Equipment Control� This item is now covered under "Device and Media Controls�, again realizing that this standard addresses facility access.


1. Contingency Operations (Addressable) �Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.� In this implementation specification, the covered entity must assess the need to include procedures (e.g., Disaster Recovery Plans (DRPs) and Business Continuity Plans (BCPs)) that provide guidelines for accessing facilities in the event of an emergency. The procedures should address how access to electronic PHI will be restricted to only authorized individuals during restoration operations. For example, the plan should state that, where feasible, only recovery team leaders or designated individuals for a particular system should gain entry into a computer room to restore a system from backup tapes.

2. Facility Security Plan (Addressable) �Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.� Each covered entity must assess the need to adopt policies and procedures that should include activities that are related to the securing of a covered entity�s physical facility, such as:

Perform a walk-through of the building perimeter, interior and any computer room or data center to assess physical security controls and identify control weaknesses. For example, building construction that would allow unauthorized access through windows, doors, loading docks, vents, air shafts, roof or basement entry.

o

o Develop a facility security plan that includes physical access procedures during emergency mode operations, periodic testing of the security of the computer room and sensitive areas, and periodic review of the physical access lists. This plan should include monitoring (surveillance cameras, motion and door sensors; environmental equipment monitoring; computer operations center controls); environmental controls (air conditioning; smoke detection and fire suppression systems); and entrance/exit controls (visitor sign-in log, picture identification and/or card access badges, security guards).

3. Access Control and Validation Procedures (Addressable) �Implement procedures to control and validate a person's access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision.�


16

Each covered entity must assess the need for procedures related to controlling and validating appropriate access to a physical facility and/or area where PHI is contained. Each covered entity must establish physical security control standards according to the risk in each area and estimated cost for implementing the control. The following items should be considered:

Procedures for vendor/contractor/visitor access and/or escort o o

o

o

o

o o

Procedures to verify access authorization before granting physical access to a restricted area (computer/telecommunications room) Procedures for security services personnel that include operating procedures during normal business hours, off-hours, and emergency situations Procedures to ensure users only have physical access to those areas and systems/data required by their jobs (�need to know�) Procedures to restrict access to systems and software to authorized personnel for purposes of testing and revision

Note: See Security Incident Procedures

4. Maintenance Records (Addressable) “Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks).” Each covered entity must assess the need to have policies and procedure to ensure that facility repairs and modifications are documented and those records are maintained. This may or may not be possible by the covered entity if it resides in a leased facility, but the covered entity could require the building owner to maintain such records. In either case, the records that should be kept and available are of all building and system maintenance, documenting who performs the maintenance, who authorizes the maintenance, and the details of the maintenance activities. §164.310(b) Physical Safeguards: Workstation Use

Standard: Workstation Use �Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information.�

Modifications In the final Security Rule, �Policy and guidelines on work station use� has been renamed to simply "Workstation Use" as the policies and guidelines are part of the standard. Otherwise, this standard is similar to the proposed requirement. Implementation Notes

1. Workstation Use (Required) The standard serves as the implementation specification. This implementation specification calls for the proper use of workstations that contain or have access to PHI. Each covered entity must establish a policy for secure workstation use that includes specific guidelines for both laptop and home system usage. The policy might cover the following topics:

Encryption of laptops or desktops that contain PHI if physical controls cannot be implemented. Usage guidelines for covered entity-owned vs. personally-owned home systems.


17

Virus software protection guidelines. o o o

Email/Internet/instant messaging use guidelines (e.g., �business use only�). Software licensing guidelines.

§164.310(c) Physical Safeguards: Workstation Security

Standard: Workstation Security �Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users.

Modifications In the final Security Rule, this standard was renamed "Workstation Security" from �Secure Workstation Location�. Otherwise, the standard is similar to the proposed requirement. Implementation Notes

1. Workstation Security (Required) The standard serves as the sole implementation specification. In conjunction with the standard for workstation use, the following topics for workstation security should be considered: ° Require cable locks for all laptops. ° Position the screen away from unauthorized users. ° Secure in protected areas if possible. ° Implement password-protected screen-savers that are evoked after a specified period of inactivity. §164.310(d)(1) Physical Safeguards: Device and Media Controls

Standard: Device and Media Controls �Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility, and the movement of these items within the facility.�

Modifications In the final Security Rule, the standard was renamed from �Media Controls� to �Device and Media Controls� to include systems (i.e., devices) in addition to simply media. �Data Backup and Data Storage� were combined into one addressable implementation specification. �Disposal� and "Media Re-use" are required implementation specifications, and �Accountability� remains essentially the same, but is addressable.

1. Removed �Access Control� Access Control was removed as it was considered redundant.

2. Added �Media Re-Use� Realizing that media is oftentimes reused instead of being disposed, Media Re-Use was added.


18


1. 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.� The secure disposal of electronic PHI depends upon properly designed policies for disposal. Within this implementation specification, the covered entity must create a policy and process that includes the following components that address the secure disposal of media and assets that contain electronic PHI: ° Measures to sufficiently erase or overwrite media before disposal. ° Additional actions to destroy media (e.g., cutting up floppy disks, where appropriate). ° Measures to appropriately discard media according to the classification level of the data. ° Procedures for disposal � including sale or donation - of intact workstations and PDAs.

2. Media re-use (Required) �Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use.� Similar to disposal, the covered entity must ensure that there are policies in place to address the secure re-use of media and assets that contain electronic PHI. To that end, the covered entity should take the necessary measures to sufficiently erase or overwrite media before re-use (i.e., simply deleting the data is not sufficient).

3. Accountability (Addressable) �Maintain a record of the movements of hardware and electronic media and any person responsible therefore.� Each covered entity must assess the need to identify owners for all assets that contain electronic PHI. An inventory of those assets should be maintained, and records of any movement of those assets within or external to the facility should be kept. Procedures should address �permanent� movement, such as laptops or PDAs that come and go continuously. A barcode system may help with this effort for a large organization, and may be combined with any Fixed Assets controls the organization may already have in place.

4. Data backup and storage (Addressable) �Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.� As part of the Data Backup Plan required under the Contingency Plan, the organization should already be backing up electronic PHI on a routine basis. This item requires each covered entity to consider the need for an additional safety precaution for the entity to ensure that retrievable, exact copies of electronic PHI are created before movement of any equipment that might cause loss or destruction of data or systems software. §164.312(a)(1) Technical Safeguards: Access Control

Standard: Access Control �Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified.�


19

Modifications The intent of the access control standard is to provide a guideline for implementing technical policies and procedures for systems that house electronic PHI to allow access only to those persons or software programs that require it. In addition, the language of the new rule has been modified to allow for flexibility with equivalent access controls. Some specifications that were mandatory within the proposed standard (e.g., automatic logoff and encryption) have been made addressable in the new rule. Despite one commenter suggesting that emergency access procedures should be made a separate requirement because such a procedure is not really access, the standard has been retained because it is considered a necessary part of access controls, because access controls are still necessary, even under emergency conditions. Therefore, the emergency access procedures remain a required implementation specification of the �Access Control� standard. The �Automatic logoff� standard has been modified to be an addressable access control implementation specification in response to numerous objections stating that mandatory �Automatic logoff� was too specific and limiting. The language of the final rule permits the use of other equivalent measures for inactivity lockout, based on particular configurations in use and the risk assessment/analysis.

1. Expanded the access control options HHS has removed the terms �Context-based access,� �Role-based access,� and �User-based access� in response to comments that these features were too specific and were perceived as the only options permissible, and thus other types of access controls should be allowed. The final rule has been reworded to clarify that use of any appropriate access control mechanism be allowed.

2. Renamed �Encryption and Decryption� Although some commenters requested that encryption be removed as an implementation feature because encryption is not required for �data at rest,� encryption remains a part of the rule as an addressable implementation specification. This will enable covered entities to utilize encryption as a method for denying access to information as it resides on electronic media or systems that may be more exposed to potential incidents, such as in portable devices.

3. Moved �Audit Controls� Realizing that access and audit are two completely separate security controls, audit controls were moved to its own required standard.

4. Moved �Authorization Controls� Authorization controls were incorporated under Information Access Management.

5. Moved �Data Authentication� Retitled "Data Authentication" to "Mechanism to Authenticate Data" and moved it under a new standard entitled "Integrity".

6. Moved �Entity Authentication� Moved "Entity Authentication" to a new standard entitled "Person or Entity Authentication". Implementation Notes

1. Unique User Identification (Required) �Assign a unique name and/or number for identifying and tracking user identity.� To ensure that users are uniquely identified in an appropriate and controlled manner, the covered entity must develop a framework for completing user profiles or roles for access to existing applications and


20

systems, especially those with PHI. Profiles should be developed for at least the following classes of users to enforce segregation of duties:

Application users. o o o o o o o

o o o

o o o

Application supervisors and managers. Executive management. Application security administrator. Network/operating system administrator. Help desk. End user.

Once profiles and roles have been developed, the entity should create a process for identifying, reviewing and authorizing access to applications or systems that cannot conform to role-based access profiles. The systems/network should then support the appropriate access profiles through a unique user ID that can be used to identify each user and track each user�s activity.

2. Emergency Access Procedure (Required) �Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.� As part of the access control procedures, there must be a process to handle logical access to systems and data in emergency situations. The process should include details around the granting emergency access, logging activity during the emergency, return to normal operations (i.e., revocation), and review of emergency access activities. Any emergency access accounts should not be used for routine activities and when in use, should be monitored, and immediately revoked upon completion of the required tasks.

3. Automatic Logoff (Addressable) �Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.� For systems that contain PHI, the covered entity must evaluate the need to ensure that mechanisms are in place to terminate sessions after a period of idle time or at the end of the session. Such mechanisms might include:

A password-protected screen-saver after a period of idle time. Locking the system when leaving the workstation. Automatic logoff of the application or network session after a period of idle time.

4. Encryption and Decryption (Addressable) �Implement a mechanism to encrypt and decrypt electronic protected health information.� Based upon the risk analysis, a covered entity should determine if it is necessary to encrypt PHI at rest. The use of encryption is a technical and business decision that should be made based on risk. Should the covered entity choose to utilize encryption, encryption and decryption policies and procedures should be developed. Procedures for encryption and decryption should consider:

Web-based applications (i.e., enduser use of encryption). Media on portable devices Key and certificate management (including issuance, expiration, and revocation).


21

§164.312(b) Technical Safeguards: Audit Controls Standard: Audit Controls �Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.� Modifications HHS has modified the proposed rule to make �Audit Controls� a separate required implementation standard. However, the intent of the Audit Control standard is similar to the original intent. Implementation Notes

1. Audit Controls (Required) The standard serves as the sole implementation specification. A covered entity must implement auditing, logging, and monitoring controls to allow it to examine system activity, both routinely and as result of a possible security incident. Auditing controls may be manual, automatic, or a combination of both. Logs should be reviewed as part of the Information System Activity Review requirement under the Security Management Process standard. Examples of audit controls might include:

User access and account activity o o o o o o

o o o o o o o

Exception reports Dormant account reports System resource monitoring Data integrity controls Failed log-in reports

This standard should address the development of monitoring procedures for systems without any current monitoring capability. Monitoring tools (third party, freeware, or OS-provided) can be deployed to log activity and security violations against PHI. Examples of security relevant events to monitor might include:

Users switching user IDs during an on-line session Attempts to guess passwords Attempts to use privileges that have not been authorized Modifications to production application software Modifications to system software Changes to user privileges Changes to logging subsystems

Logging controls should include the development of processes for the review of logs as well as standards for log retention and management. The data collected and the amount of time dedicated to log review should be managed according to the criticality and classification level of the system. §164.312(c)(1) Technical Safeguards: Integrity Standard: Integrity �Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.�


22

Modifications The goal of the proposed data authentication feature was to ensure that data was not altered or destroyed in an unauthorized manner. The goal is similar with the final Security Rule. HHS used the term �integrity� because it more clearly described the intention of the standard. However, the writers still felt that �data authentication� was an important piece of the standard and incorporated its meaning into the now addressable implementation specification, �Mechanism to Authenticate Electronic Protected Health Information.� The core elements from the proposed rule remain in this new standard.

1. Removed �Double Keying� Realizing that in today�s economy and with existing systems, double keying is not a practical control, it was removed as an implementation feature. Implementation Notes

1. Mechanism to Authenticate Electronic Protected Health Information (Addressable) �Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.� Each covered entity must assess the need in its environment for these mechanisms. The integrity standard states that mechanisms of the covered entity�s choice should be implemented to ensure that PHI has not been altered or destroyed in any way while at rest. (Integrity of transmitted information is included in a separate standard). There are a number of ways to accomplish this, the most appropriate and practical of which should be determined by the covered entity based on its environment. Some examples include the following:

Error-correcting memory, o o o o

Magnetic disk storage with built-in error detection and correction, Checksums, and Encryption.

In addition, policies and procedures should be developed to ensure that PHI is handled appropriately; i.e., that it has not been improperly altered or modified through perhaps manual review of file sizes/dates before and after key data transmissions. §164.312(d) Technical Safeguards: Person or Entity Authentication Standard: Person or Entity Authentication �Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.�

Modifications The final Security Rule states that access to PHI should only be granted to those who require it for their jobs. The �Person or Entity Authentication� standard mandates that controls be in place to verify that someone seeking access to electronic PHI is the one they claim to be. The final rule provides a more general requirement for person or entity authentication; users may be entities (e.g., service IDs) and not people. Otherwise, the intent of the proposed rule remains the same.

1. Removed authentication examples Although a Unique User Identification is now a required specification under Access Control, all references to "Password", "PIN", "Telephone Callback", and �Token� as authentication mechanisms have been removed as too specific.


23


1. Person or Entity Authentication (Required) The standard serves as the sole implementation specification. Before granting access to electronic PHI, a process to ensure that a person or entity is who they claim to be must be in place. Authentication is defined as a process utilized by a system to confirm the identity of a user by means of account validation and/or password verification scheme. Each covered entity must develop a mechanism to support and enforce corresponding policies and procedures developed for authentication to PHI. Although no specific implementation is required, examples of procedures for implementing person or entity authentication include the following:

Username and password, o o o o

Token based authentication, Biometrics, and Challenge and response mechanisms.

§164.312(e)(1) Technical Safeguards: Transmission Security 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.�

Modifications This standard was renamed in the final rule from �Communications or network controls�. Several items were moved to other standards, leaving �Integrity Controls� and �Encryption� as addressable implementation specifications. Encryption was reworded to enhance flexibility and scalability. The term �open network� was removed from the definition because its meaning was too broad.

1. Removed "Message Authentication" Message authentication was removed because the use of data authentication codes (called for in the "Integrity Controls") satisfies its intent.

2. Removed "Network Controls� Network controls have been removed, as well as all of the proposed implementation features ("Alarm," "Audit Trail," "Entity Authentication," "Event Reporting"). These features were deleted since they are normally incorporated by telecommunications providers as part of network management and control functions that are included with the provision of network services; i.e., a covered entity would not normally expect to be responsible for these technical telecommunications features.

3. Removed "Access Controls� Access controls have been removed since the consideration of the use of encryption will satisfy the intent of this feature. Implementation Notes

1. Integrity Controls (Addressable) �Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. � Each covered entity must assess the need for controls to ensure that PHI has not been altered during transmission. The scope of data communications should at least include files transmitted to/from


24

business associates/external entities by FTP, e-mail, dial-up, direct connection, or web access. The covered entity should establish measures for data communications depending on the level of risk based on the method of transmission. Examples of standards for integrity controls might include switched networks, point-to-point connections, digital signatures, SSH, SSL, or other forms of encryption (discussed below).

2. Encryption (Addressable) �Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.� As part of the risk analysis, areas of high transmission risk should be identified based on the type and format of the data being transmitted using electronic media, including wireless transmission, email, and network communications. Encryption should be considered for all of the above with respect to the associated risk, cost, and benefit. For email, the preamble of the Security rule suggests an organization may want to pay special attention to email encryption, especially with regard to provider communications. In particular, an organization may want to consider if the benefit of providers using email to communicate with other providers, patients, and health plans may outweigh the risks associated with unencrypted email. While there is no shortage of email encryption software and methodologies, there is a shortage of interoperability between email encryption software. Each email user would have to be using the same email encryption software or using the same secure email web site. There are a number of cost and usability factors of deploying email encryption that could dissuade users from adoption of email communications and result in the loss of email benefit, including potential improvements in patient care. Some of those include:

1. Cost of the encryption software and support of end users � both providers and individuals. This includes establishing distribution schemes, supporting multiple operating systems and multiple email clients (e.g. Outlook, Notes, and Eudora).

2. Hassle of provider end users having to support multiple encryption software clients and understand which client works for which email target. A physician could wind up having to use separate encryption software for each physician, hospital, or payer he/she communicates with.

3. For web-based secure email, the hassle of provider or individual end users having to log into a different web site to check or send mail. Like email encryption clients, they would conceivably need to log into a different web site for each entity they needed to communicate with.

Prior to implementing encryption technology, the covered entity should address the following issues to assess the risk and feasibility of using encryption as a viable method for transmission security:

The need for encryption licensees. o o o

Local and international (if applicable) encryption laws. Agreements and proper communication with business associates who may or may not be able to receive encrypted transmissions based upon budgetary/technology constraints.

§164.314 (a)(1) Organizational Requirements: Business Associate Contracts or other Arrangements

Standard: Business Associate Contracts or Other Arrangements �The contract or other arrangement between the covered entity and its business associate must meet the requirements, as applicable.

(ii) A covered entity is not in compliance with the standards 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 or arrangement, if feasible; or


25

(B) If termination is not feasible, reported the problem to the Secretary.�

Modifications In the final rule, the proposed chain of trust partner agreement has been replaced by the standards for business associate contracts or other arrangements and the standards for group health plans. A contract between a covered entity and a business associate must require the business associate to implement safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the covered entity.

1. Added unique situations Language was added in the final rule to address three situations: 1) when a covered entity and its business associate are both governmental agencies; 2) if a business associate is required by law to perform a function or activity on behalf of a covered entity or to provide a service described in the definition of business associate; and 3) when authorization of the termination of the contract by the covered entity is inconsistent with the statutory obligations of the covered entity or its business associate.


1. Business Associate Contracts (Required) �The contract between a covered entity and a business associate must provide that the business associate will--

(A) Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the covered entity as required by this subpart; (B) Ensure that any agent, including a subcontractor, to whom it provides such information agrees to implement reasonable and appropriate safeguards to protect it; (C) Report to the covered entity any security incident of which it becomes aware; (D) Authorize termination of the contract by the covered entity, if the covered entity determines that the business associate has violated a material term of the contract.�

The business associate should consider implementation of the administrative, physical, and technical safeguards of the final HIPAA Security Rule as if they were a covered entity. The implementation should be conducted in a manner that is reasonable and appropriate for securing the covered entity�s PHI while in the business associate�s possession. The covered entity should regularly review current contracts to assess the need for amendment or re-contracting to ensure the implementation of HIPAA-compliant security practices. As necessary, the covered entity should negotiate with business associates to implement amendments or new agreements to contracts to ensure the inclusion of proper security implementation requirements. §164.314 (b)(1) Standard Requirements for Group Health Plans

Standard: Standard Requirements for Group Health Plans �A group health plan must ensure that its plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan.�

Modifications To address the overly broad scope and inability to address appropriately the circumstances of certain covered entities, particularly the ERISA group health plans, the proposed rule has been modified to include a standard for group health plans. The language of the new rule has been modified to ensure that


26

the plan documents of the group health plan must be amended to incorporate provisions that require the plan sponsor to implement reasonable and appropriate safeguards to protect the confidentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the group health plan.


1. Document amendment provisions (Required) �The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to--

(i) Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the group health plan; (ii) Ensure that the adequate separation is supported by reasonable and appropriate security measures; (iii) Ensure that any agent, including a subcontractor, to whom it provides this information agrees to implement reasonable and appropriate security measures to protect the information; and (iv) Report to the group health plan any security incident of which it becomes aware.�

The plan sponsor is not a covered entity. However, the Privacy Rule recognizes that plan sponsors should have access to certain PHI for the governance of the Group Health Plan, which is a covered entity. However, before the Group Health Plan can release PHI to the plan sponsor, the Privacy rule requires that the Group Health Plan require the plan sponsor to certify that it has modified the plan documents to conform to the requirements for plan documents in the Privacy rule. The Security rule expands the requirements of the plan sponsor�s certification to the Group Health Plan to include that the plan documents include specific statements that ensure appropriate security measures are used to protect the PHI. The result, of course, is that the plan sponsor needs to take many, if not all, of the same steps as a covered entity with regards to security implementation. Note: As with Business Associates, there is no requirement for the Group Health Plan to audit the plan sponsor. However, the plan sponsor must provide adequate assurances, which would be equivalent to the Group Health Plan�s requirement for the plan sponsor to certify that its plan documents conform. §164.316 (a) Policies and Procedures

Standard: Policies and Procedures �Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements. This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements. A covered entity may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart.�

Modifications The new rule emphasizes the scalability of solutions allowed under the security standards, and requires covered entities to implement policies and procedures that are reasonably designed, taking into account the size and type of activities of the covered entity, and documented in written (which may be in electronic) form. The new rule emphasizes the flexible nature of the policies and procedures, stating that a covered entity may modify its policies and procedures at any time, given the dynamic nature of regulatory and organizational changes. Covered entities must also document relationships between covered entities.


27


1. Policies and Procedures (Required) The standard serves as the sole implementation specification. The writers expected that many of the standards of the final rule were already being met in one form or another by covered entities. While revisions to an organization�s policies and procedures were expected, the development of entirely new procedures was not. Therefore, the covered entity should first look at what policies and procedures already exist within the organization that could be used or modified before developing new policies and procedures to comply with the security standards. §164.316(b)(1) Documentation

Standard: Documentation �(i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) If an action, activity, or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.�

Modifications Much of the required documentation under the proposed rule appeared in �Security Configuration Management�. This documentation was expected to include written security plans, rules, procedures, and instructions concerning all components of an entity's security. No significant modifications have been made in regards to these expectations. The new rule still requires the covered entity to make the documentation available to those who need it and to periodically review/update it as necessary; in addition, a retention time was added.


1. Time limit (Required) �Retain the documentation required by paragraph (b)(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.� The covered entity must retain the system/network configuration documentation, as well as any surrounding policies, procedures and training material, for six years from the date of its creation or the date when it last was in effect, whichever is later. This requirement is consistent with similar retention requirements in the privacy rule.

2. Availability (Required) �Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.� The covered entity must make any documentation available to those persons responsible for implementing the procedures. Not only would this include network and systems administrators, but perhaps Human Resources, Contracts, Facilities, Legal, Compliance, Training, and Security personnel. In addition, this should include emergency personnel listed in the emergency mode operations procedures.

3. Updates (Required) �Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.�


28


29

The covered entity must update and review the documentation periodically. These updates could be as a result of a security incident, new vulnerability, updated systems, changes in personnel, or organizational changes that may affect the security of the electronic PHI in a covered entity�s possession. For More Information For questions on the final HIPAA security regulations, or for information on HIPAA advisory services, assessment, planning and implementation services from PwC in the areas of security, privacy, or standard transactions and code sets, please contact one of the following members of the PwC HIPAA practice: Jeff Fusile 678-419-1558 [email protected]

Bill Braithwaite, MD, PhD 202-414-1534 [email protected]

Tom Hanks 312-298-4228 [email protected]

Cindy Smith 412-355-8054 [email protected]

TR Kane 614-629-5366 [email protected]

Cliff Baker 678-419-1151 [email protected]

Thomas Phelps 213-236-3577 [email protected]

Greg Smith 617-478-5946 [email protected]

Julie Shin 617-478-5858 [email protected] © 2003 PricewaterhouseCoopers LLP. "PricewaterhouseCoopers" refers to PricewaterhouseCoopers LLP a Delaware limited liability partnership or, as the context requires, the network of member firms of PricewaterhouseCoopers International Limited, each of which is a separate and independent legal entity.

mailto:[email protected]









PwCs Iinterpretation of Final HIPAA Security Rule...

Documents

Transcript of PwCs Iinterpretation of Final HIPAA Security Rule...