The Final Frontier: the Health Insurance Portability and Accountability Act (HIPAA) and Security
HIPAA Security Preparedness
Final regulations governing security, the last piece of HIPAA following the privacy and transaction and code set standards, were announced on February 13, 2003 (68 FR 8334). Compliance for all but small health entities is due by April 20, 2005.
The goals of the security rules are to ensure the confidentiality, integrity and availability of all electronic protected health information (ePHI), and to protect against anticipated disclosures and threats to the security of the information.
HHS' approach?
The final security regulations incorporate the concepts of scalability, flexibility and generalization. In other words, the regulations do not expect the same security precautions from small or rural providers as are demanded of large covered entities, such as those in urban centers, with significant resources. Security is recognized as an evolving target, and so the Department of Health and Human Services (HHS) employed generalized security requirements that are not linked to specific technological advances. "[W]e have focused more on what needs to be done and less on how it should be accomplished," states HHS.
The final regulations are divided into "required" and "addressable" standards. While the "required" standards are just that, the "addressable" standards may be mandatory as well. Covered entities must assess how reasonable and appropriate implementing the "addressable" standards would be, and do so where appropriate. Where an "addressable" standard would be inappropriate, a covered entity may instead adopt an alternate means to the same end or possibly forgo the proposal altogether. But HHS has made it clear that cost alone is not a sufficient basis for declining adoption of a standard.
Connection to the Privacy Regulations
The final security regulations recognize an inextricable link with the privacy regulations. HHS notes that compliance with privacy standards will, in many instances, account for a substantial step towards security compliance. To further this linkage, HHS harmonized the terms used in the security standards with those of the privacy standards.
An exception to this overlap is found in the "scope of information" covered by the security regulations compared to privacy, as pertaining to physicians. While the privacy regulations involve all protected health information (PHI) no matter what the form, the security rules covers only providers who transmit electronic PHI, as well as the usual suspects of health plans and health care clearinghouses when handling PHI in any form. Physicians will find, however, that other, non-electronic PHI, may require security protections under the privacy rules. As was the case with the privacy regulations, "business associates" and hybrid entities also have duties under the security rules, although HHS only has the authority to require compliance of the covered entities. Ultimate liability for any regulatory shortcoming of a non-covered entity falls upon the covered entity alone.
Risk Assessment
Covered entities must assess their security risks. This is foundation of compliance. Risk assessment is tailored to the covered entity—its size, complexity and capabilities, in addition to risk and cost, are all taken under consideration when determining whether a "addressable" standard applies or how to best meet a "required" standard. The rules are not prescriptive—a number of different tactics can achieve compliance. These same factors listed above are to be considered when determining an entity's appropriate response.
The Big Three—The Components of the Security Standards
► "Administrative safeguards" focus on workforce training and contingency planning (45 CFR §164.308). The cornerstones, however, are risk analysis and risk management—both "required." Critical and thorough risk analysis must take place before any attempt at regulatory compliance is made. The covered entity's particularized vulnerabilities are the focal considerations for all resultant security policies implemented to reduce detected risks.
Additional "required" administrative safeguards include:
- Sanctions for workforce noncompliance.
- Tracking of security "incidents," and documented policies and procedures for dealing with incidents. Resulting harm must be mitigated.
- Appointment of a single security officer—this person could well be the privacy officer too.
- Allowing workforce access to ePHI only where appropriate, and putting policies in place to prevent unauthorized persons from gaining access.
- Training workforce on security issues, scaled to the organization. Covered entities must train their staffs in security in an ongoing fashion—a single session in 2005 will not be sufficient. "Business Associates" must be aware of security policies, though the covered entity is not under an obligation to train the associates.
- Contingency plans for emergencies that damage systems with ePHI, including provisions for data back up, a recovery plan and a mode for continuing critical business processes for the protection of the security of ePHI during emergency operation.
- Periodic evaluations of security preparedness, conducted either internally or externally.
► "Physical safeguards," are concerned with access both to the physical structures of a covered entity and its electronic equipment (45 CFR §164.310). ePHI and the computer systems upon which it resides must be protected from unauthorized access, in accordance with defined policies and procedures. Some of the requirements under the physical safeguards heading can be accomplished through the use of electronic security systems.
"Required" physical safeguards include:
- Establishing policy for the appropriate use, physical attributes of and security for workstations that access ePHI.
- Establishing policies dictating procedures for the addition, disposal or reuse of hardware or electronic media that contains ePHI.
► "Technical safeguards" may be the most difficult part of the security regulations to comprehend and implement for those lacking technical savvy (45 CFR §164.312).
"Required" technical safeguards include:
- Establishing policies limiting software program access to only those with authorized access. Unique log-ins, either numeric or by name, are required—automatic log-offs are not. Procedures for obtaining necessary ePHI during an emergency are also required.
- Activity logs ("audit logs") of all systems that contain ePHI must be maintained.
- Policies to protect ePHI from alteration and destruction must be maintained must be established.
- Procedures as required to verify the identity of those seeking access to ePHI.
- Transmission of ePHI over a network must be protected by technical security policies. Encryption is an "addressable" standard.
Each of the three categories above contain additional "addressable" safeguards that may or may not be applicable to your organization. A proper risk assessment will inform you of any further obligations.
Document! Document! Document!
Behind every security compliance measure is a documentation requirement (45 CFR §164.316). Practically each facet of compliance requires that policies and procedures be created and implemented. Compliance activities must be documented and retained for six years. Documentation is a major part of the compliance battle.
Policies are amendable at any time, so long as documentation is also updated. The security regulations require periodic review of policies, and appropriate responses to changes in the environmental security of ePHI—as is deemed reasonable for the particular covered entity.
Business Associate Agreements
While only covered entities, not their business associates (BAs), are bound to compliance under the new security regulations, there are nonetheless demands made upon BAs. Written contracts between covered entities and BAs must require, among other things, that the BAs implement safeguards that protect the ePHI used by the BAs, and that BAs ensure the same of any of their subcontractors.
In the Future...
HHS has indicated that it will issue additional guidance on the security standards to help facilitate compliance.
The security issued thus far do indicate how HHS wishes to approach the topics of enforcement or whether the use electronic signatures will be permitted; both will be considered in future proposed rulemakings.
Conclusion
With HIPAA compliance dates having now passed in respect of the privacy regulations and the transaction and code set requirements, physicians now have a notion of what to expect. The thought of security compliance should not be a shock; nonetheless, compliance will not happen overnight. Remember that security is a flexible, scalable concept, and thus inherently manageable—with adequate time and preparation.
Content provided by: Office of the General Counsel