These days we deal with resistance and denial towards HIPAA compliance. There are many reasons given for incomplete or ineffective compliance programs. We have heard everything from long rambling rants against the government, claims of not applicable to me and plenty of “we don’t have the _____” (fill in: time, money, resources) to explain away the compliance gaps.
There is, however, one case that concerns me when we find it. A practice or business is given a standard list of HIPAA Security implementation recommendations. The problem is that the list of recommendations doesn’t always include a review of what is reasonable and appropriate for the specific environment. The result is a group frozen by fear, sticker shock or worse paying for services and equipment that may be overkill for them. The Security Rule explains in the General Rules section just what should be considered in determining what is reasonable and appropriate for a specific environment (emphasis added):
HHS recognizes that covered entities range from the smallest provider to the largest, multi-state health plan. Therefore the Security Rule is flexible and scalable to allow covered entities to analyze their own needs and implement solutions appropriate for their specific environments. What is appropriate for a particular covered entity will depend on the nature of the covered entity’s business, as well as the covered entity’s size and resources.
Therefore, when a covered entity is deciding which security measures to use, the Rule does not dictate those measures but requires the covered entity to consider:
Its size, complexity, and capabilities,
Its technical, hardware, and software infrastructure,
The costs of security measures, and
The likelihood and possible impact of potential risks to e-PHI.
No, this doesn’t mean you can decide you are so small and the rules are too complex to follow them at all. That is definitely not what reasonable and appropriate means in this context. What it does mean, though, is that you can determine how to implement the standards, both required and addressable, but apply these considerations to your implementation plans.
Our approach is to always define the environment before defining the plan. The Security Risk Analysis is first in the list of requirements for a reason. But, keep in mind, that even the tasks performed in the Risk Analysis should be confirmed as reasonable and appropriate for your specific environment.
My next post will cover something that we are hearing a lot about lately which often falls into this category – Penetration Testing.