HIPAA Compliance In 30 Days or Less

With the deadline looming, our security manager gives an assist to the fellow in charge of meeting the mandates of the security rule.

HIPAA. We are all sick of the acronym by now, and the April 20 compliance deadline for the Health Insurance Portability and Accountability Act is looming.

At the state agency where I work, the information security officer (ISO), who is responsible for HIPAA security rule compliance, has spent the past seven months or so writing policies and procedures. He divided them into two groups: "required" (stuff we have to do) and "addressable" (stuff we'd better be thinking about doing).

When I came aboard, only one of the policies had been approved by the agency chiefs. Everything is done by consensus here -- if one chief doesn't like a single sentence, the policy is rejected, edited and then resubmitted. I was starting to panic about the approaching deadline. If we can't get the policies approved, we certainly can't implement them.

I did what any respectable security professional would do under the circumstances. First, I asked each chief to support the policy-approval process. Next, wanting to find a template that would be widely accepted but not wanting to reinvent the wheel, I went to the Web site of the National Institute of Standards and Technology (NIST) and downloaded every available document related to security and compliance with the HIPAA security rule.

Special Publication 800-66, titled "An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule," was just what our ISO needed: a step-by-step guide to compliance. A table on page 13 of this handy document defines each standard of the rule, identifies its section number and outlines implementation specifications, noting which ones are required and which are addressable. Even better, pages 16 through 54 describe various "key activities" and provide sample questions. This was the perfect project outline to give to a HIPAA newbie.

I went one step further and took the NIST outline and plunked it into Microsoft Project, defined major milestones, allocated resources and hung the Gantt chart on my wall. I also printed all of the related NIST documents and put them in a big binder.

I wanted to show my ISO how to formulate a project plan. I wanted him to understand what he was going to be held accountable for and how short the time frame for implementation was.

When I showed the plan to my boss, I felt the need to apologize for my micromanagement. "I don't usually go to this length with a direct report, but I need to get through to this guy that this is the quality of work we expect from him. He needs to execute this plan. If he can't, then he shouldn't be the ISO." My boss agreed.

In the Same Boat

I discovered that many state agencies are in the same boat. HIPAA requires them to appoint ISOs. But most agencies don't have much security expertise, and many agency administrators view the ISO role as more of an administrative function than a technical one. They're wrong. The HIPAA security rule is completely different in implementation from the privacy rule in that it requires technical resources.

It's true that the administrative safeguards form the bulk of the ruling, but even with those, you need a technical understanding of how things work.

For instance, you can't conduct a risk assessment without understanding the vulnerabilities of a networked computing environment. And you can't develop security incident-response procedures without understanding what constitutes a true security breach and how to detect one.

And when it comes to contingency planning and disaster recovery, you need a background in things such as conducting an impact analysis and testing a disaster recovery plan.

You can't just write a policy, put it in a binder, label it "HIPAA Security Rule Compliance" and call it a day. And you can't assume that the physical safeguards are administrative in nature. For example, in the area of device and media controls, how do you keep someone from carrying off EPHI (that's electronic protected health information) using one of those little USB flash devices? Do you disable USB ports on all computer systems, or can you disable the use of such devices through Active Directory or third-party software?

When you finally get to the technical safeguards, you have to deal with things like audit controls. Determining what type of audit controls will be deployed and what types of activities will be tracked can be quite a project, depending on the size of the organization. Then you still have to decide where the audit trails will be stored, who can have access to them and how the audit record will be secured from tampering.

Fortunately, my agency has several well-qualified technical people who, even without any direct security experience, have done a fine job of setting up the infrastructure so that the changes that need to be made will be relatively straightforward.

And it helps that the major systems that handle most of our EPHI transactions were outsourced two years ago and are now in the process of becoming certified as HIPAA-compliant. In fact, without that card on the table, the game would be lost.

I'm confident that our ISO and agency will hit the compliance date without a hitch. But I am grateful to NIST for providing the level of documentation that it has and very thankful indeed that my agency made a decision to outsource years before my arrival date.

What do you think?

This week's journal is written by a real security manager, "C.J. Kelly," whose name and employer have been disguised for obvious reasons. Contact her at mscjkelly@yahoo.com, or join the discussion in our forum: QuickLink a1590

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon