HIPAA-covered entities' first step should be a quality assurance plan

Keep your friends close and your auditors closer

As a management consultant who deals with compliance, I think you can imagine what was going through my mind as I was driving away. Of course, this was just one office so I couldn't draw any conclusions based on that one visit; however, a fire-engine red banner went straight up, so I started inconspicuously asking other covered entities (the HIPAA term used to indicate a company responsible for complying with HIPAA regulations) that I knew or did business with. Surprisingly, I started seeing an alarming trend.

As frightening and painful as audits may be, they're a vital component of the feedback necessary for the proper compliance of anything. I was recently watching the telecast of a well-known and respected singer, who went way off key on a song this person had probably been performing for decades. Later in an interview, the singer said the earpiece had malfunctioned for about 30 seconds of the song: I know exactly which 30 seconds the singer was referring to. Even if you feel like you have things under control, you need the feedback of an audit to keep you on track.

I won't bore you with the details of what HIPAA is, as there's a plethora of information available at this point. Even if you don't work for a HIPAA-covered entity, I'm sure you've been to the doctor or dentist, where you had to read through and sign a privacy statement. This privacy component is the piece we're interested in today, but interestingly enough it's a side effect of what the real intent of HIPAA was -- the simplification and streamlining of medical information exchange.

Proactive auditing with quality assurance

In the absence of audits, the IT function that supports a HIPAA-covered entity must be extra diligent to protect the organization. This can usually be accomplished by leveraging (or installing) a good quality assurance (QA) team. This should be driven from the top down and installed in the strategic plan of the technology organization (or whatever organization the QA team reports up to), with a dotted-line relationship to the privacy officer. If you already have an internal audit team under the privacy officer, that's good -- but not good enough. You must be fully engaged with a team that understands the actual technology of the systems holding the sensitive data, referred to as protected health information (PHI).

Every covered entity should have a privacy officer, or some other title that's responsible for ensuring compliance with HIPAA and other standards and regulations. As with all compliance-related IT architecture, the privacy officer and/or his team of professionals will be the key drivers of your compliance implementations, as they are the ones responsible for creating policy.

If you haven't started addressing HIPAA compliance from a technical standpoint yet, I would actually advise you to start designing your audit plan with your QA function before designing a compliance architecture with your development team. Although probably counterculture and counterintuitive, this is a best practice adopted from the world of agile software development that I find to be remarkably effective.

Testing for HIPAA compliance

At the core of your implementation will be the tagging of PHI in your data, so good data governance is a must. In the best scenario, your QA team will actually build audit infrastructure that will comb through your solution to see if there's any untagged data in the system. The team members will also want to randomly audit data that's tagged as PHI, as well as data that's not tagged as PHI, to see if there are any gaps in your classifications.

Secondly, they'll want to focus on disclosures. Once PHI is accurately tracked in your system, you're in a position to track where it goes and why. I recommend either setting up a gated publish-subscribe model and/or a request-response system for transferring PHI anywhere. Anytime PHI moves from one place to another record it's called a disclosure, which should be carefully recorded in a disclosure tracker. Every disclosure should be classified as required, permitted, authorized or unauthorized.

A required disclosure is one that is specifically requested by an individual or one of his agents, or a specific request by the Department of Health and Human Services to aid in a compliance investigation. A permitted disclosure is covered by the HIPAA Privacy Rule and does not require an authorization. An authorized disclosure specifically requires authorization by an individual, and an unauthorized disclosure is a violation. To validate authorized disclosures, your QA team should ensure that it is accompanied by a physical record of authorization.

The success of your HIPAA compliance is surprisingly related to how well your QA function is engaged. Make sure you have strong guidance from your privacy officer, and strong test cases in place for the identification of PHI in your data and disclosure tracking. Find out where you stand today by building a simple set of PHI test cases.

John Weathington is President and CEO of Excellent Management Systems Inc., a San Francisco-based management consultancy. For more information, please visit: www.excellentmanagementsystems.com.