HIPAA in a Nutshell

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) places a large regulatory burden on organizations that deal with certain types of health-related information. Now, if you’re about to stop reading this and say to yourself “I don’t work for a health-related organization,” stick with me for at least one more paragraph. As HIPAA deals with the security and privacy of health information, it’s of direct importance to database administrators.

There are a number of ways you may qualify as a “Covered Entity” that is required to comply with the terms of HIPAA. Some of these are obvious – health care providers come immediately to mind. However, some require a little more thought. If your organization qualifies as a “health plan,” you are considered a Covered Entity. What’s a health plan? It’s any organization that “provides medical care, including items and services paid for as medical care, to employees or their dependents directly or through insurance.” If you offer employees medical care through a self-insured plan, chances are that you’re covered under HIPAA. Other organizations may fall under the “health care clearinghouse” provision based upon their responsibilities for processing health care data.

If you have any doubt about whether you’re covered by HIPAA, you may wish to consult the Center for Medicare & Medicaid Services Covered Entity Decision Tool. Of course, direct any specific questions to your attorney if you require legal advice.

So, you’re covered by HIPAA. What does that mean? There are two specific regulations of interest to database professionals: the HIPAA Privacy Rule and the HIPAA Security Rule.

The Privacy Rule protects all individually identifiable protected health information (PHI) maintained by the Covered Entity. It is not specific to electronic information and applies equally to written records, telephone conversations, etc. According to the Department of Health and Human Services, PHI includes data that relates to:

• the individual’s past, present or future physical or mental health or condition or
• the provision of health care to the individual or
• the past, present, or future payment for the provision of health care to the individual

The Privacy Rule’s basic mandate is that organizations may only release PHI as explicitly permitted by the Privacy Rule or with the prior written consent of the individual who is the subject of the records. The Privacy Rule also contains a number of notification requirements and administrative requirements designed to ensure proper records are maintained and that individuals are aware of their rights under HIPAA.

The Security Rule covers the security of electronic protected health information (ePHI). It prescribes a number of required policies, procedures and reporting mechanisms that must be in place for all information systems that process ePHI within the Covered Entity. It also prescribes a number of required and addressable implementation specifications designed to protect the confidentiality, integrity and availability of ePHI within the enterprise. These specifications fall into five categories:

• Administrative Safeguards
• Physical Safeguards
• Technical Safeguards
• Organizational Requirements
• Policies and Procedures

The key to compliance with the Security Rule lies in the language of the law: implementing “reasonable and appropriate” measures. You should carefully evaluate each of the items your risk assessment identifies as possible security actions against this principle. If you (and your attorney) feel that the measure isn’t reasonable and appropriate when viewed in light of the type of data in question, the size of the business, the potential risk and other circumstances, it’s only necessary to document that rationale.

It’s certainly true that HIPAA has caused database professionals a number of headaches while striving to come into compliance with the law. You should, however, view this as an opportunity to focus on the security of your databases. The procedural requirements of HIPAA only apply to specific PHI/ePHI data, but they’re reliable best practices for all of your data. When you’re working through the implementation exercises, ask yourself how much added effort would be required to apply the HIPAA standards to other, non-healthcare aspects of your organization.

This article is meant to serve as an educational introduction to HIPAA for database professionals and in no way constitutes legal advice. If you require legal advice, please consult a qualified attorney.