Enterprise Software

Don't gamble with HIPAA security compliance

Ramon Padilla thinks the HIPAA security compliance guidelines left too many loopholes for foot-dragging IT departments. Read his recommendations for becoming compliant and documenting your efforts.

April 21, 2005 has come and gone pretty much without a peep. That date was the deadline for the Health Insurance Portability and Accountability Act (HIPAA) security compliance. Was the lack of hubbub due to all the lead time we had to prepare, or was there some other reason that the deadline became a nonevent?

Unfortunately, I think it was because the current rule gives organizations an "out" in the form of a "good faith" stipulation. The enforcement rule proposed by the Department of Health and Human Services on April 18, 2005 has a provision that allows the Centers for Medicare and Medicaid Services (who enforce the non-privacy rules) and the Office for Civil Rights (who enforces the privacy rules) to "stray from its philosophy of investigating the compliance status of covered entities only upon receipt of a complaint of non-compliance."

In other words, this rule says that (1) the process will remain largely complaint-based and (2) should there be complaints, the above departments will work with non-compliant entities to help them become compliant, reserving civil fines or filing criminal complaints only if an entity does not cooperate. In essence, as long as you can show that you made "good faith" efforts to comply, you won't be penalized—you'll just have to become compliant.

Personally I hate this kind of compliance. The caveat above is full of wiggle room, giving some department heads the license to gamble with the HIPAA law. After all, no one will know until a complaint is made, right?

The language of the final HIPAA security rule doesn't help matters either. While the proposed rule had more specific guidelines for implementing security, the final rule's language is more focused on providing a model for information security, not actual specifications for how to implement it. In fact, there are only 13 required implementation specifications and the rest are "addressable". This means that decisions regarding the reasonableness and appropriateness of implemented security measures are up to the individual entity. In other words, for those specifications that are deemed addressable, it will be up to the entity (knowing its own environment—hopefully) to determine how to or whether to achieve the specification.

This wishy-washy language is unfortunate because to implement the final security rule correctly (even just the 13 required specifications) can be expensive, depending on the size of the organization. If the rule remained as it was in draft form, there would be a greater impetus to make sure that one complied with the letter of the law. However, as it is now, the temptation is there for others to gamble on not getting caught—and, in the process, to gamble with your career. When it comes time to request funding for HIPAA compliance, it might go like this: "Well Bob, I see your budget request for us to comply with the HIPAA security standards is pretty large. I'm afraid we can't handle that. "Do the best that you can."

But whose head will be on the chopping block once a security complaint is filed and it is leaked to the press? You can bet it won't be the person who denied your funding!

What should you do to prepare for this situation?

  1. Determine if you are a covered entity or not. (You should have done this already but late is better than never). If you work in an IT department for Health Departments, EMS, hospitals, or correctional facilities that give medical care, you are covered by HIPAA law.
  2. Get VERY familiar with the final security rule, particularly the security standards matrix: http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf
  3. Develop a plan to achieve ALL the provisions, not just the required 13. However, give priority to the 13 required specifications.
  4. Begin implementing your plan. This is the part where you will "Do the best that you can." Make sure to document that you are making the best effort to implement the rule, and document all of your barriers to doing so. This includes keeping track of your budget requests and any other requests that you make in trying to reach compliance. Yes, your deadline for compliance was April, but if you missed it, you are probably not the Lone Ranger. The key is to be able to show that you have been making a "good faith" effort towards compliance should a complaint be filed.

In summary, don't let the permissiveness and flexibility of the security rule or its enforcement lull you into a sense of complacency. Even if others are inclined to gamble with compliance, and thus deny the resources to accomplish your goals, you must try to reach compliance as soon as possible anyway. Furthermore, you must document your labor in great detail, not just to show your good faith efforts in case of a complaint, but to help insure against the gamblers who would risk your career and reputation.

Keep up with the issues and challenges that uniquely affect public-sector IT with TechRepublic's free Government IT newsletter, delivered each Tuesday. Automatically sign up today!

Editor's Picks

Free Newsletters, In your Inbox