Michael R. Costa is a senior associate in the Health Business Practice Group of Greenberg, Traurig, LLP in Boston. He also is chair of the Health Law Section Council of the Massachusetts Bar Association.
On Feb. 20, 2003, more than four years after first being proposed, Department of Health and Human Services ("HHS") Secretary Tommy G. Thompson announced the adoption of final security rules for protecting individually identifiable health information when it is maintained or transmitted electronically.1 The 289-page final regulations are required as part of the administrative simplification provisions included in the Health Insurance Portability and Accountability Act of 1996 (HIPAA)2 and were designed to help safeguard confidential health information as the health-care industry increasingly relies on computers for processing health-care transactions.
Prior to the adoption of the final Security Rule, there was no recognized single standard that integrated all the components of security (administrative procedures, physical safeguards, technical security services and technical mechanisms) in order to preserve health information confidentiality and privacy as defined in the law. Therefore, the Security Rule was proposed as a set of requirements with implementation features that providers, plans and clearinghouses would be required to include in their operations to assure that electronic health information pertaining to an individual remains secure. Under the final Security Rule, health insurers, certain health-care providers and health-care clearinghouses must establish procedures and mechanisms to protect the confidentiality, integrity and availability of electronic protected health information. The Security Rule requires covered entities to implement administrative, physical and technical safeguards to protect electronic protected health information in their care. Such safeguards include risk analyses; sanction policies for noncompliance; information access management; access authorizations such as passwords and log-ins; contingency planning; disaster recovery plans; and testing and revisions procedures, to name but a few. The Security Rule works in concert with the final privacy standards adopted by HHS last year and scheduled to take effect for most covered entities on April 14, 2003. The two sets of standards use many of the same terms and definitions in order to make it easier for covered entities to comply.
The final Security Rule does not reference or advocate specific technology. This would allow the security standards to be stable, yet flexible enough to take advantage of state-of-the-art technology. The Security Rule also does not address the extent to which a particular entity should implement the specific features. Instead, the Security Rule requires that each affected entity assess its own security needs and risks and devise, implement and maintain appropriate security to address its business requirements. How individual security requirements would be satisfied and which technology to use would be business decisions that each organization would have to make. Nevertheless, affected entities will be required to:
• Conduct a thorough risk analysis of their organizations and review electronic information handling procedures, information system activities and policies to develop measures that ensure the integrity of patient health information;
• Develop clear policies for detecting and reporting security violations, as well as contingency and disaster recovery plans to guard against patient data loss; and
• Make business associates and partner companies aware of security policies and procedures, either through written contracts or other less-formal means.
Based upon the risk assessment mentioned above, the covered entity must implement a risk-management plan addressing each standard. For most standards, the Security Rule sets forth a "specification" - an action or process that is a safeguard against risks identified under the given standard. Some specifications are "required," meaning that the action or process must be implemented. Some specifications are "addressable," meaning that the action or process is not mandatory, but must be implemented unless it is "reasonable and appropriate" to implement an alternative that addresses the same risks.
An "addressable" specification is not wholly discretionary. Rather, a covered entity may choose to implement an alternative if it determines (1) that the addressable specification is not a reasonable and appropriate response to the risks under the standard, but that (2) the alternative is a reasonable and appropriate response. If it then elects the alternative, the decision and its basis must be documented in writing, which is retained for at least six years from the last date on which the decision was the effective policy. In determining what is reasonable and appropriate for an addressable specification (and in making detailed decisions under all standards), covered entities make "scalable" choices; that is, as under the privacy rule, the specific details may appropriately vary depending on the size, operational needs and resources of the covered entity.
The publication of the "final rule" will likely be met with mixed reaction from health-care experts, given the lack of specific requirements that may create confusion in the health-care industry. However, it is equally likely that others will applaud the government's hands-off approach. Most covered entities will have two full years - until April 21, 2005 - to comply with the standards, while small health plans (those with under $5 million in annual receipts) will have an additional year to comply as HIPAA requires. Commencing compliance activities sooner rather than later is a prudent idea, as the processes it requires may take some time depending on the size of the covered entity.
1. The security standards were published as a final rule in the Feb. 20, 2003, Federal Register with an effective date of April 21, 2003. They can be found at: http://www.cms.hhs.gov/regulations/hipaa/cms0003-5/0049f-econ-ofr-2-12-03.pdf[back]
2. 65 Fed. Reg. 82461 (Dec. 28, 2000).[back]