THE ULTIMATE PRIMER FOR HIPAA COMPLIANCE PART III - THE SECURITY RULE

In the first two pieces of this series, we talked heavily about the more general properties of HIPAA. We talked about its history, and the conditions surrounding its creation, in the first piece – in the second, we talked about the Privacy Rule, the chief component that governs health data in a general sense.

We covered these topics for one simple reason – HIPAA is nothing if not a “funnel” of rules and regulations. What it all comes down to, from the nascent days of draft legislation down to the Privacy Rule, is the Security Rule. This is what we’re going to discuss today.

What is the HIPAA Security Rule?

The Security Rule is perhaps the most important element of the HIPAA legislation for data providers. While we gave this moniker to the Privacy Rule as well, this is more indicative of how the rules are integrated than anything else. The Security Rule is necessarily a subset of the Privacy Rule – while the Privacy Rule covers a much broader base of instances and situations, however, the Security Rule is much more focused upon digital data, and the system that processes it.

Fundamentally speaking, the Security Rule should be thought of as a natural extension from the Privacy Rule as applied to electronic data. It covers a broad spectrum of data that it terms “Electronic Protected Health Information”, or “ePHI” (we will refer to it simply as data or information for the rest of this piece in the interest of both clarity and brevity).

While the specific requirements of the Security Rule are complex (and something we will dive into in just a moment), it can best be summarized as this – “the regulations implemented to protect ePHI, spanning creation, storage, and erasure”. As such, the Security Rule is much less concerned about the state of data than in the handling of such data, in contrast to the Privacy Rule, which requires notifications of data activity and usage to the information holders.

Who is Affected by the Security Rule?

While the Security Rule is more concerned with a specific subset of information, the coverage is still the same. Any covered entity (defined in our previous piece as an individual or organization who handles health data of any kind) is beholden to this Security Rule – but more importantly, so too are the “business associates” of these entities. Entities doing business with such entities are required to generate a Business Associate Agreement (BAA), which allows these associates to handle the data in question.

It’s a two-way road though – while the BAA covers the associates as if they were a covered entity, it also extends the punitive measures, regulations, and oversight that would normally be reserved for the covered entity to the business in question. To put it plainly – if a breach is incurred, the business associate will suffer the same penalties as the covered entity, with fines reaching into millions being a distinct possibility.

What is the Security Rule?

With all of that said, what exactly is the Security Rule? There are three chief types of safeguards and a general rule of access.

The Rule of Access

To get started, you must understand the basic concept that we liked to call the “Rule of Access”. Note: this is not a defined “rule”, but one that is derived from the purpose of the Security Rule and its resultant orders. As a general rule, this concept means that the owner of the data should have access to that data – and that only authorized people should have access shared with them.

While this seems a no-brainer, it does have some complex situations. What happens if your data center gets a call, where the caller asks whether or not the data for the cancer ward has been erased? Technically speaking, you are not delivering personal data, so to answer yes might seem fair. However, you’re still revealing information.

While that is a very “gray area” kind of case, what would happen if you got a call from a hospital requesting that a record be returned or excluded from erasure? That is not as gray. You might want to exclude those files and send them on, but then you have to see if you have the right to access that information in the first place. Even if you have trained staff who are allowed to access this data, you must also vett that the request is legitimate. And then even if it is legitimate, you have to establish a strong chain of hand-off to ensure security is met and contained throughout the process.

Obviously, this rule is not as simple as it seems. No matter what, always err on the side of caution – the only people who should have access to the data are the authorized personnel as defined by the data owner.

Administrative Safeguards

In its most simple terms, administrative safeguards are measures that must be undertaken to ensure that a breach does not occur through the implementation of business processes. This includes training, data policies, general security policies, defined roles, chain of custody, and clearly defined roles and responsibilities.

Essentially, this provision demands that business methods be used where appropriate. This makes sense, of course – in a classic business, the power to train and restrict access in terms of work responsibilities falls directly onto the project managers and their superiors. As such, the responsibility for ensuring that no administrative faults lead to breaches are necessarily levied upon the administration.

Technical Safeguards

Technical Safeguards are those methods employed to secure data. This is the chief concern for data providers, as it dictates so much about your administrative safeguards and how you go about your business. As a general rule of thumb, you should ask yourself a few basic questions:

• Is your data encrypted to a government standard for medical and health-related data?

• Do you have authorization and authentication controls to ensure Confidentiality?

• Do you have access controls and record tools to ensure Integrity?

• Do you have load balancing and overflow prevention to ensure Availability?

The Department of Health and Human Services sums this entire section up as thus: “[You must] establish a balance between the identifiable risks and vulnerabilities to ePHI, the cost of various protective measures, and the size, complexity, and capabilities of the entity.”

Physical Safeguards

Finally, Physical Safeguards are the basic methods by which data devices are physically secured. While this obviously includes things like mantraps, window, and door locks, locked server cages, etc., this also includes general mobile data policies concerning mobile devices, thumbsticks, etc. This is much less of an issue with data providers, whose chief concerns are often simply the storage of data to be erased, versus medical facilities that might store this data long-term, but it is still very much a concern.

We’re not going to heavily focus on physical safeguards in this piece for one simple reason – you should, as an IT company, already be employing this at its maximum level. Information technology and security rests heavily on both securing the digital workspace and the physical. If you own a data center and do not have locked cabinets, mantraps, ID readers, cameras, etc., then you have more problems than worrying about HIPAA compliance.

Conclusion

Congratulations – you are at the end of the starter steps to understanding HIPAA. The reason we’ve spent so much time on this early conceptual set of topics, defining HIPAA and its various rules, is to give context for the final piece. In our next and final installment, we will specifically tackle solutions to all of these issues. Not only that – we’ll give you some basic actionable steps to take if a breach does occur in order to mitigate your losses.