At Last, The Final HIPAA Security Rule Is Released February 24, 2003

Transcription

1 ~ This HIPAA Law Alert is a collaboration of CHC Healthcare Solution and Nixon Peabody LLP ~ At Last, The Final HIPAA Security Rule Is Released February 24, 2003 By all accounts, HIPAA has been one of the most talked about compliance issues of this year and last. With the April deadline for privacy compliance looming, the industry breathed a sigh of relief when on February 20, 2003, the Department of Health and Human Services ( HHS ) finally issued the longawaited final security standards (the Security Rule ). The Security Rule may be downloaded from the CMS website at HHS promised to issue guidance on the Security Rule at some point in the future, although it did not set a date for issuance. Covered entities (except small health plans) must comply with the Security Rule by April 21, Small health plans have an additional year to comply. In short, the Security Rule contain some very significant changes from the proposed rules. The most significant changes include modification of terms to make them consistent with HIPAA s Privacy Rule, a major reorganization and the elimination of many provisions. I. Structure of the HIPAA Security Rule The Final Security Rule is comprised of Standards and Implementation Specifications. There are approximately 20 Standards and 37 Implementation Specifications in the Final Rule, with much of the redundancy in the proposed Regulation Implementation Specifications deleted. The following points should be noted: All Standards must be addressed. Implementation Specifications may be addressable or required. If an Implementation Specification is required, a covered entity must implement it.

2 If an Implementation Specification is addressable, a covered entity must assess whether each implementation specification is a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity's electronic protected health information; And, as applicable to the entity: Implement the implementation specification if reasonable and appropriate; or If implementing the implementation specification is not reasonable and appropriate: Document why it would not be reasonable and appropriate to implement the implementation specification; and Implement an equivalent alternative measure if reasonable and appropriate. II. Addressable Implementation Specifications Based on the stated goal of establishing a scalable standard for all covered entities, the Final Security Rule has placed a greater, clearer emphasis on risk management and analysis as the means achieving compliance. HHS also made a number of the Implementation Specifications addressable to ensure that the Final Rule could be applied fairly to each covered entity. HHS has made it clear that it does not regard the addressable Implementation Specifications as optional. We disagree that covered entities are given complete discretion to determine their security polices under this rule, resulting in effect, in no standards. While cost is one factor a covered identity may consider in determining whether to implement a particular implementation specification, there is nonetheless a clear requirement that adequate security measures be implemented, see 45 CFR (b). Cost is not meant to free covered entities from this responsibility. III. Proposed Requirements Not Included in the Final Rule Several proposed requirements were not included in the Final Rule. These are noted below. A (a)(4) The Requirement for a formal mechanism for processing records is not included in the Final Rule. B (a)(8) Security Configuration Management was removed from the Final Rule except for the Documentation and Testing Requirements. However, the following points should be noted. Hardware and software installation and maintenance review and testing for security features ( (a)(8)(ii)). However, reviewing installation and maintenance of IT assets is a critical component of audit activities and the technical evaluations required by the Final Rule. Inventory ( (a)(8)(iii)). A complete and thorough inventory of IT assets that contain PHI is required to adequately assess the risk to PHI.

3 Virus checking. ( (a)(8)(v)). Although removed, those organizations with Internet connectivity are still at a significant risk from viruses, worms, and Trojans. C (a)(11)(i-iv) Termination Procedure Implementation Features were removed due to being considered too specific. Note, however, that the final Rule still requires termination procedures, and keep in mind that incidents caused by former members of the workforce accessing confidential information or disrupting IT systems are a known high risk. The following baseline policies and procedures may be implemented to reduce these risks: 1. Physical access by former members of the workforce should be removed. 2. Access to information systems should be removed. 3. A checklist should be used to ensure that all required termination procedures have been completed within 24 hours. 4. In the case of hostile terminations, physical and systems access should be removed immediately before or during the termination. D (d)(2) The Network controls standards and all implementation features were removed. The section of the proposed regulation reads as follows: (d)(2) If an entity uses network controls (to protect sensitive communication that is transmitted electronically over open networks so that it cannot be easily intercepted and interpreted by parties other than the intended recipient), its technical security mechanisms must include all of the following implementation features: (d)(2)(i) Alarm. (In communication systems, any device that can sense an abnormal condition within the system and provide, either locally or remotely, a signal indicating the presence of the abnormality. The signal may be in any desired form ranging from a simple contact closure (or opening) to a time-phased automatic shutdown and restart cycle.) (d)(2)(ii) Audit trail (the data collected and potentially used to facilitate a security audit) (d)(2)(iii) Entity authentication (a communications or network mechanism to irrefutably identify authorized users, programs, and processes and to deny access to unauthorized users, programs, and processes) (d)(2)(iv) Event reporting (a network message indicating operational irregularities in physical elements of a network or a response to the occurrence of a significant task, typically the completion of a request for information).

4 During the risk analysis process required as a basis for all implementations, network security controls will generally be among the most cost-effective risk mitigation measures that a covered entity can implement. Network controls will broadly protect all PHI stored on information systems. Conversely, failing to implement basic network security controls will leave PHI significantly exposed. In this particular instance, the risk management requirements of the Final Rule will likely lead to considerably more focus on network controls than the proposed regulation indicated. E The Electronic Signature Standard was not included and will be released at a later date. F. Penalties for Non-Compliance To be released at a later date. G. Redundant Proposed Requirements A number of redundant requirements were removed: (a)(7)(v) (a)(7)(vi) (a)(10)(iv) (b)(2)(i) (c)(1)(v)(C) (c)(1)(i)(B) (d)(1)(ii)(A) IV. Business Associate Agreements The Chain of Trust Agreement requirement is not a component of the Final Rule. In its place, HHS has substituted which specifies a number of measures required of Business Associates if electronic PHI is created, received, maintained, or transmitted on behalf of a covered entity. A covered entity is not in compliance 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, either terminate the contract or arrangement, or if termination is not feasible, report the problem to the Secretary. A. Required Implementation Specifications Contracts between a covered entity and a business associate must provide that the business associate will: Require the implementation of 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

5 Ensure that any agent, including a subcontractor, to whom a business associate provides PHI agrees to implement reasonable and appropriate safeguards to protect it; Report to the covered entity any security incident of which it becomes aware; 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. B. When a Covered Entity and its Business Associates Are Governmental Entities The covered entity is in compliance with paragraph (a)(1) of this section, if It enters into a memorandum of understanding with the business associate that contains terms that accomplish the objectives of paragraph (a)(2)(i) of this section; or Other law (including regulations adopted by the covered entity or its business associate) contains requirements applicable to the business associate that accomplish the objectives of paragraph (a)(2)(i) of this section. C. Business Associates Required By Law To Perform An Activity or Function 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: The covered entity may permit the business associate to create, receive, maintain, or transmit electronic protected health information on its behalf to the extent necessary to comply with the legal mandate without meeting the requirements this section, provided that: The covered entity attempts in good faith to obtain satisfactory assurances as required by this section, and Documents the attempt and the reasons that these assurances cannot be obtained. The covered entity may omit from its other arrangements authorization of the termination of the contract if such authorization is inconsistent with the statutory obligations of the covered entity or its business associate. D. Requirements for Group Health Plans Except when the only electronic protected health information disclosed to a plan sponsor is disclosed pursuant to (f)(1)(ii) or (iii), or as authorized under , 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.

6 The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to: 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; Ensure that the adequate separation required by (f)(2)(iii) is supported by reasonable and appropriate security measures; 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 Report to the group health plan any security incident of which it becomes aware. V. Documentation A covered entity must, in accordance with implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in (b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. 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. Documentation must include: Policies and procedures implemented to comply with this subpart in written (which may be electronic) form. 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. Documentation must be: Retained for 6 years from the date of its creation or the date when it last was in effect, whichever is later. Made available to those persons responsible for implementing and complying with the policies and procedures to which the documentation pertains. Reviewed periodically and updated as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.

7 VI. Conclusion Overall, the consensus of the health care industry appears to be that the final Security Rule appropriately meshed the security standards with the privacy standards, eliminated some redundancy and made many other significant and welcomed changes. Despite easing some of the uncertainty inherent in the proposed rules, significant compliance challenges remain for covered entities and business associates. Nixon Peabody attorneys continue to be on the cutting edge of these and other HIPAA issues. If you have any questions about the Final Security Rule or HIPAA compliance, please contact any of the members of our Nixon Peabody HIPAA Task Force or your regular contact at the firm. Nixon Peabody HIPAA Task Force Members Albany, NY Peter Millock Boston, MA Alan Einhorn Thomas McCord Leigh-Ann Patterson Garden City, NY Claudia Hinrichsen Loren Ratner Orange County, CA Dale Hudson Providence, RI Stephen Zubiago Rochester, NY Brian Kopp Regina MacAdam Richard Yarmel Washington DC Ray Gustini Philadelphia, PA John Whitman jw