After The Deadline, What To Do When You Still Are Not HIPAA Compliant.*
Many home health care providers woke up on April 20, 2005 to the realization they had not successfully completed their HIPAA Security Rule compliance efforts. This resulted in a range of responses from indifference to panic. By now, if you are not compliant, you have probably gotten over your fear that someone will be knocking on your door any minute to investigate your compliance. However, that does not mean you should not be trying to get your organization into compliance as quickly as possible.
Where To Start
If you are not already familiar with the requirements of the security rule, you should do so immediately. The Security Rule contains a number of implementation specifications and standards for the security of Electronic Protected Health Information (“EPHI”). These standards and specifications address not only preventing unauthorized access, but also ensuring the availability and integrity of EPHI. Not all of these standards and specifications are required. Many are “addressable”, which means the covered entity must decide, based on an assessment of the standard, whether the implementation specification is appropriate in its work environment.
You can obtain a copy of the HIPAA security rule from HHS’s website. For an overview of the Security Rule, see Preparing For the Next Phase of HIPAA-The Security Rule, The Remington Report, Vol. 11, Issue 4, July/August 2003, pp. 38-41.
Designating A Security Official
After familiarizing yourself with the requirements of the Security Rule, the next step is to designate a Security Official. The Security Rule requires each covered entity to have a designated Security Official who is responsible for ensuring the covered entity’s compliance with the Security Rule. The Security Official does not need to be an information technology specialist, because your compliance efforts will encompass far more than just technology initiatives.
Once you have designated a Security Official, you may consider instituting a Security Committee. A Security Committee will be appropriate for many providers, because Security Rule compliance will have administrative aspects, physical plant aspects, and technology aspects. For many providers, one person will not be able to adequately oversee each of these.
If you determine a Security Committee is appropriate for your compliance efforts, the committee should include a person from each department, preferably the head of each department or a designated replacement. Additionally, if you do not have a dedicated information technology department, whoever handles information technology issues within your organization should be involved with the committee.
Of course, even if you adopt the committee approach, the Security Officer is still ultimately responsible for your compliance efforts. The Security Officer needs to be in charge of the Security Committee, set deadlines, enforce deadlines, and keep everybody focused on the task at hand. If the committee fails to meet the April 20, 2005 deadline, HHS will want to talk with the Security Officer, not the committee.
Deadlines
Depending upon how far along your compliance efforts are, you may already have a compliance plan with deadlines. If you are still trying to get into compliance, you probably missed many of those same deadlines. Because April 20 is now behind us, many providers will have the instinct to move as quickly as possible to finish their compliance efforts. There are at least two reasons to not follow this instinct. First, HHS is still resolving non-compliance by assisting non-compliant providers, not by fining them or taking other punitive action. It is unlikely that a provider will get penalized for being out of compliance, if the provider is actively moving towards compliance.
Second, such a rush may lead you to cut corners or take other actions that result in a deficient security rule compliance effort. For these reasons, you should still set reasonable deadlines and stick to them, rather than try to finish a crash compliance effort.
Risk Assessment
When you establish your plan, the first specification that you will implement will be the risk assessment required by the Security Rule. As you may recall, the Security Rule does not require you to protect EPHI from every risk, but only from “reasonably anticipated risks.” Therefore, in order to know what efforts you need to take, you need to determine what risks fall into the reasonably anticipated category. This is accomplished through risk analysis.
The Security Rule does not dictate how a risk assessment should be performed, nor does it require a third party assessment. You may perform the assessment in house without violating HIPAA. In fact, many providers will perform their own assessments.
The key to meeting the Risk assessment requirements of the Security Rule is to ensure that you have thoroughly evaluated all potential risks; not just the potential risks for unauthorized access, but the risks to the availability of your information as well as its integrity.
Naturally, your assessment will not be a mathematically precise description of the likelihood of each potential risk, but it should at least categorize potential risks. For example, your risk assessment may have categories of “highly unlikely”, “unlikely”, “likely”, “very likely”. The goal is to evaluate all potential risks in a manner that allows you to make an informed, reasonable decision about which risks need to be addressed and which are not likely to occur.
Risk Management
After you determine what risks you are facing, the Security Rule requires you to take steps to reduce those risks to a “reasonable and appropriate” level. The primary means for reducing these risks will be your Security Rule policies and procedures. In other words, as you move towards Security Rule compliance, you are performing risk management.
Your risk management policy will be a broad statement of the overall all goals of your Security Rule compliance. Your goal in risk management should be to reduce the risks identified in your risk assessment to an appropriate level and, reduce the harm that will result if any particular security incident should come to pass. Finally, your risk management policy will include reviewing and reevaluating to ensure that risks are kept to an appropriate level (evaluation).
As you are implementing Security Rule compliance, keep in mind that you are only required to reduce the risk to a reasonable and appropriate level. You are not expected to eliminate risk. Instead, you can reduce the risk a security breach will occur and you can plan a response in the event it does occur.
When you assess what security measures are reasonable to take, HHS requires you to consider the following four factors:
1) The size, complexity, and capabilities of the covered entity;
2) The covered entity’s technical infrastructure, hardware, and software security capabilities;
3) The costs of the particular security measure; and
4) The probability and criticality of potential risks to EPHI.
Security Measures-Costs
When evaluating the costs of a security measure, keep in mind that there are more than financial costs associated with implementing security measures. An increase in the security of your information will often lead to an added level of complexity and therefore a decrease in usability, of your information systems. For example, a computer that does not require a password to log in is less secure, but easier to use than a computer that requires a password. Thus, as you determine what is a reasonable and appropriate level of risk, you need to evaluate how each added security measure, whether administrative, technological, or physical, affects the day-to-day operations of your entity. At some level, the increase in security may not be worth the additional efforts in training and time lost in using the procedure.
Determine What You Have Already Done
As you have become familiar with the security rule or as you have been working to implement the security rule, you may have discovered that you already have implemented a number of HIPAA Security Rule standards and specifications, including facility security, protection against malicious software and access authorization. To ensure you minimize the amount of duplication involved in your compliance efforts, the Security Officer and/or Committee should review all policies and procedures related to security that your organization currently has in place. By identifying what security measures your organization has already adopted that address a Security Rule specification or standard, the committee may be able to achieve compliance more expeditiously.
Once the security officer or security committee identifies each of the organization’s current policies and procedures, the policies and procedures need to be reviewed to ensure they meet the Security Rule’s requirements for reducing risk to a reasonable and appropriate level. If the policies are outdated, incomplete, or for some other reasons do not reduce the risk sufficiently, they will need to be updated.
If, after evaluating them, the Security Committee determines the current policies and procedures are reasonable and appropriate, the committee may simply adopt them as part of the organization’s HIPAA Security Rule compliance effort.
Evaluating your organization’s current security efforts will also help you to evaluate the reasonableness of implementing the Security Rule’s addressable standards and specifications. If your entity has already implemented procedures that meet an addressable standard, you have a pretty good idea that your organization felt it was reasonable to take that precaution.
The Security Committee should still evaluate the reasonableness of the measures put in place previously, but barring a change in circumstances, the committee will most likely choose to implement the addressable standards.
Required Standards and Specifications
Once you have determined the potential threats to EPHI, and evaluated your current security practices, you can begin to implement the required standards. Obviously, the required standards and specifications must be implemented; the question is simply what is reasonable for a covered entity when it implements them.
Because some required specifications need to be implemented before others, the Security Committee should organize its compliance efforts accordingly. For example, most organizations will determine the data backup plan before determining a disaster recovery plan. By doing it in that order, the disaster recovery planners will be able to refer to the backup plan to determine what information is backed up, on what media it is stored and where that media is stored.
The Security Committee should determine if any required standards are “prerequisites” to other required standards and attempt to implement them in that order. This will ensure that related procedures mesh properly.
Addressable Standards
In contrast to the required standards, the addressable standards require you to perform an assessment to determine whether it is reasonable to implement them.
Based on the assessment, you may determine that a specification is not “reasonable and appropriate” in your environment. If you make that determination, you need to evaluate whether there is an appropriate equivalent alternative measure and, if there is, document the assessment and the decision to implement a reasonable alternative measure and implement the alternative measure. If there is no appropriate equivalent alternative, you should document your assessment and the fact that there was no alternative and implement nothing.
There are three important things to keep in mind when dealing with addressable standards. First, “addressable” does not mean optional. You must perform the assessment and make a determination based on the assessment in order to meet an addressable standard.
Second, as mentioned above, HHS has specifically listed factors to consider when evaluating whether a measure is reasonable. Your assessment should specifically reference how those factors applied in your situation. This means your assessments should clearly and specifically state hour your organizations size, budget, technological infrastructure, the costs of the security measure in question and the particular risks to your organization’s electronic protected health information factored into your decision making.
Finally, addressable standards are not mandatory, unless you determine they are reasonable and appropriate in your environment. Encryption is an addressable standard and, regardless of what some consultants will tell you, HIPAA does not require encryption. It requires you to assess the reasonableness of encryption. After the assessment, you may determine it is a reasonable step to take, but it is not required.
Conclusion
Although the security rule compliance deadline is now behind us, you still have time to complete your security rule compliance plan. Because HHS continues to work with providers to ensure compliance and not fine or otherwise penalize non-compliant providers, you should ignore the impulse to finish your compliance efforts as hastily as possible and move towards compliance in a deliberate manner. The real key at this juncture is to keep moving towards compliance.
*This article is adapted from an article, 12 MONTHS TO COMPLIANCE-START NOW TO AVOID A REPEAT OF THE PRIVACY RULE CRUNCH, which originally appeared in the Remington Report.
© 2005 Gilliland & Markette LLP
