• Search
• Free Magazines
• Newest Links
• Categories
• Register
• Login

Introduction to HIPAA

Added by Papergrl

Written by: Mitchell Rowton

On February 13, 2003, HHS Secretary Tommy Thompson announced the adoption of the HIPAA Security Final Rule. The final standards were published in the February 20 Federal Register with an effective date of April 21, 2003. Most covered entities will have two full years -- until April 21, 2005 -- to comply with the standards. This paper will outline the HIPAA security rules.


General Rule Provisions

Section 164.306, the statement of the general Rule, requires covered entities to:

• Ensure the confidentiality, integrity, and availability of all electronic protected health information (EPHI) the covered entity creates, receives, maintains, or transmits;
• Protect against any reasonably anticipated threats or hazards to the security or integrity of such information;
• Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required by the Privacy Rule; and
• Ensure compliance by its workforce.

The balance of Section 164.306 expands upon the relationships, as summarized above, between these essential standards and addressable and required implementation specifications.

The remainder of the final Security Rule contains the standards and specifications required to implement the general rule.


Administrative Safeguards

Reinforcing the Security Rule's central focus on security management, the detailed sections of the rule begin with Section 164.308, Administrative Safeguards. Section 164.308 focuses on the security management process - the policies and procedures designed to prevent, detect, contain, and correct security violations. This standard contains four required implementation specifications: risk analysis, risk management, sanction policy, and information system activity review. The requirement to assign security responsibility has been moved to this section from Physical Security (where it resided in the draft rule); the preamble now clarifies that a single individual must bear this responsibility. This section also includes:

• Several workforce security provisions, including addressable specifications for authorization and/or supervision, workforce clearance procedures, and termination procedures.
• Clarification of requirements and restrictions on the workforce and other users of EPHI by requiring information access management controls, including addressable standards for access authorization, establishment and modification.
• The required specification that clearinghouses that are part of larger organizations must implement policies and procedures to protect the clearinghouse's EPHI from unauthorized access by the larger organization.
• Security training and awareness requirements for the workforce, including addressable specifications to address security reminders, malicious software procedures, user monitoring of log-in attempts, and password management.
Two additional standards which focus on the organization's planning and response to undesired events. They are:
1. A requirement for policies and procedures that address security incidents, including the required specification, response and reporting. This specification calls for covered entities to 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, and
2. A requirement that covered entities protect the availability of EPHI by establishing a contingency plan. Required implementation specifications for the contingency plan include the presence of a data backup plan, a disaster recovery plan, and an emergency mode operation plan. Testing and revision procedures and applications and data criticality analysis are included as addressable specifications.
• Periodic technical and non-technical evaluation of the organization's compliance with the Security rule. The term "evaluation" in the final rule replaces "certification" required in the draft Security Rule. HHS responded to criticisms of this original requirement by replacing it with a mandate to "periodically conduct an evaluation...to demonstrate and document...compliance with the entity's security policy and the [Security Rule] requirements. Covered entities must assess the need for a new evaluation based on changes to their security environment since their last evaluation."
Language permitting the use of business associates to create, receive, maintain, or transmit EPHI on the covered entity's behalf with the appropriate contractual language described later in the Rule.

Physical Safeguards

Like the draft rule, Section 164.310 of the final Rule requires Physical Safeguards to protect EPHI from unauthorized disclosure, modification, or destruction. This section includes standards for:

• Facility access controls, with addressable specifications that clarify that the standard applies to both normal and contingency operations. They further provide for access control and validation procedures (staff and visitors) and for the collection of appropriate maintenance records for the physical components of a facility that are related to security (such as hardware, walls, doors, and locks).
• Standards for proper workstation use and physical security of workstations that access EPHI.
• Standards for device and media controls -- policies and procedures that control receipt, movement, and removal of hardware and electronic media that contain EPHI. Required elements include disposal policies and procedures to address the final disposition of EPHI, and/or the hardware or electronic media on which it is stored, and media re-use procedures to remove EPHI before the reuse of media. Addressable aspects of this standard include accountability (a record of the movements of hardware and electronic media and any person responsible), and data backup and storage.

Technical Safeguards

Section 164.312, Technical Safeguards, contains provisions extracted from two sections of the proposed rule: Technical Security Services and Technical Security Mechanisms. Covered entities must implement:

• Technical policies and procedures for access control on systems that maintain EPHI. These systems must allow for unique user identification and include an emergency access procedure for obtaining necessary EPHI during an emergency. Addressable specifications include automatic logoff and encryption and decryption, which is defined as a mechanism to encrypt and decrypt EPHI.
• Transmission security, including two addressable specifications:
  1. Integrity controls -- security measures to ensure that electronically-transmitted PHI is not improperly modified without detection until disposed of, and
  2. Encryption. Designation of encryption as an addressable specification is a key departure from the proposed rule, which explicitly required encryption when using open networks. Covered entities now must determine how to protect EPHI "in a manner commensurate with the associated risk." Covered entities are encouraged in the Rule's preamble to consider use of encryption technology for transmitting EPHI, particularly over the Internet. The key reasons cited by HHS for this change are the cost burden for small providers and the current lack of a simple and interoperable solution for email encryption.
• Hardware, software, and/or procedural methods for providing audit controls.
• Policies and procedures to protect EPHI from improper alteration or destruction to ensure data integrity. This integrity standard is coupled with one addressable implementation specification for a mechanism to corroborate that EPHI has not been altered or destroyed in an unauthorized manner.
• Person or entity authentication, which requires the covered entity to implement procedures that verify that a person or entity seeking access to EPHI is the one claimed to be doing so.

Business Associate Contracts

The proposed Security Rule required a "chain of trust partner agreement" between parties exchanging data electronically. In keeping with the goal of aligning Privacy and Security requirements, Section 164.314 of the final Security Rule requires a Business Associate agreement, which is already required by the Privacy Rule. For relationships where a third party is used to create, receive, maintain or transmit EPHI on the covered entity's behalf, the Security Rule requires the business associate to:

• Implement administrative, physical and technical safeguards that reasonably and appropriately protect the confidentiality, integrity and availability of the covered entity's EPHI;
• Ensure that its agents and subcontractors to whom it provides EPHI meet the same standard;
• Report to the covered entity any security incident of which it becomes aware; and
• Ensure that the contract authorizes termination if the business associate has violated a material term.

The Security Rule adopts the Privacy Rule's exceptions to the agreement requirement for disclosures to providers for treatment, exchanges of information between government entities, and exchanges between group health plans and their sponsors. However, it does not adopt the Privacy Rule's exception for covered entities participating in an organized health care arrangement (OHCA). It is not clear if this is a deliberate or inadvertent omission.

This section also applies the Security Rule provisions to affiliated entities, hybrid entities and group health plans, again increasing the new Rule's compatibility with Privacy Rule provisions for these entities.


Policies, Procedures and Documentation

• Section 164.316 requires covered entities to implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of the Security Rule. A covered entity may change its policies and procedures at any time. The section also requires covered entities to maintain the policies and procedures and any other required action, activity or assessment in written form (which may be electronic). Three required implementation specifications complete this standard, requiring that the covered entity must:
  1. Maintain the documentation for six years from the date of its creation or the date when it last was in effect, whichever is later;
  2. Make the documentation available to those persons responsible for implementing the procedures to which the documentation pertains; and
  3. Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.

The Bottom Line

The final Security Rule is, overall, a welcome revision to the proposed provisions. It clearly outlines a realistic model for security management that is broadly flexible across the healthcare industry. However, covered entities should not take the flexibility provisions of the rule as a reason to ignore the technological side of security. HHS has clearly stated its position that this flexibility does not extend to non-compliance; appropriate technical measures will be needed to implement many of the Rule's provisions. The standard requiring periodic evaluation stresses that technical measures must be included part of the mandated evaluation.

• A further caution: covered entities would be wise not to underestimate the effort involved in complying with the improved Security requirements, or their liability for security results or lack thereof. The new Rule replaces a relatively "black and white" menu of specified actions with results-based expectations requiring enterprise-wide vigilance and judicious decisions about security through constantly changing circumstances. Implementation of a security management methodology where none has previously existed is a significant process that may require a period of one to two years to conceptualize and implement, followed by continuous monitoring and indefinite updating. Further, each covered entity's security program will be subject to federal scrutiny of the entity's well-documented rationale.

You don't have permission to post replies.

Please login or register.