You have to admit that now is a very interesting time to be in the healthcare field.  This year we saw a $1 Trillion healthcare reform bill get passed.  I don’t believe that anyone has a real understanding of the impact of the bill or its affects on medical practices.  It seems every day more details are revealed of the bill.  It will take years before we see the total impact.

Then you have the ARRA stimulus package which provides $19 Billion in Medicare incentives to doctors that embrace the use of certified EHRs.  This is a huge opportunity for medical practices to implement technology and move from paper charts to EHRs.  But along with the incentives come some significant obstacles.  Medical practices have to use a certified EHR but there is no definition of what that means or who the exact certifying bodies are.  As of today you can not purchase an EHR that is certified and will qualify for the stimulus funds.  Practices not only have to implement certified EHRs but they have to use them in a way that shows “meaningful use”.  Of course the exact rules for meaningful use are not known and many argue that the rules that are being proposed are too rigid and the bar is too high for practices to actually show meaningful use.  Taken altogether, you  have a lot of medical practices that want to cash in on the ARRA stimulus incentives and to implement an EHR but you have uncertainty and obstacles that are keeping them on the sideline.  They are taking the wait and see approach.  Some are even thinking that it may not be worth the effort to attempt to participate in the ARRA stimulus incentives.

One thing for certain is that the medical practices that are moving forward with an EHR implementation are spending a lot of money.  There is no way around it, EHRs are expensive.  The cost of the software, hardware, network, training, staff disruption and all of the other components that go into an EHR implementation all add up.  Of course the hope would be that the costs would be offset by the ARRA stimulus incentives but that is not a guarantee as I mentioned before.

At the same time you have all this uncertainty around healthcare reform and ARRA stimulus, medical practices have to contend with two major economic issues.  The first is the severe recession that we have been in since 2008.  There is no way around it, when the economy is suffering all business including medical practices suffer as well.  I hear from my clients that patient visits are down and that waiting rooms are less filled.  This has a significant and real impact on a medical practice’s cash flow and financial health.  The second economic issue is the proposed cut of 21% in Medicare payments to physicians.  For at least 6 months the looming threat of a 21% cut in Medicare payments have darkened the economic sky for medical practices.  Congress has postponed the cuts several times but have not permanently addressed the situation.  As of today, the 21% cut has been pushed back until November 30, 2010.  Along with postponing the Medicare cut, Congress has given doctors a 2.2% increase until November.  Very few medical practices are rejoicing because in December 2010 they are looking at a 23% cut in Medicare payments followed up by a 30% cut in January 2011.  No one really knows what or when the final outcome will be.

On top of major financial outlays to implement EHRs and the uncertainty surrounding the economy and Medicare reimbursements, medical practices have to deal with many government regulations.  As I have written about often, the looming threat of HIPAA Security Audits are a real concern for medical practices.  Implementing HIPAA Security usually require skill sets that medical practices don’t have.  IT security companies are needed to help with policies and procedures, vulnerability and risk assessments along with implementing new technologies such as email and laptop encryption.  On top of HIPAA Security, medical practices face the “Red Flags Rule”  requiring that certain entities develop and implement written identity theft prevention and detection programs to protect consumers from identity theft.  The Red Flags Rule has been postponed several times and was to go into affect June 1, 2010.  As of now the FTC has agreed to keep physicians exempt from the rule until the outcome of a lawsuit by the American Bar Association.  Once again, the outcome of this regulation is unknown.

When you look at each of the issues a medical practice has to address from healthcare reform to Medicare reimbursement cuts they don’t seem to bad.  Each one taken separately allows a medical practice to address the issue and to make modifications to they way they run their business.  But unfortunately all of the issues are happening at the same time.  A medical practice has to address all of the issues together including major financial outlays, cuts in revenue caused by several factors,  and staying abreast and implementing the latest government regulations.  All the time spent addressing these issues is time not spent on seeing and treating patients.

Have other  industries gone through such dramatic change in such a short period of time?  The changes provide opportunities along with real negative affects.  Medical practices need to be flexible and to adjust to all of these changes.  Some of the changes such as the Red Flags Rule may never occur.  But either way a medical practice needs to be prepared, need to be informed and need to be ready to change their business model to adjust to such dramatic changes.  Strange days indeed.

This is the third part in an on-going series about the HIPAA Security Rule. So far I have discussed the following:

• Security Rule Overview
• Security Rule Principles

As I mentioned previously, the Security Rule is broken into three main parts; the administrative, physical and technical safeguards. We will now dive into the administrative safeguards.

The administrative safeguards make up 50% of the Security Rule. So if you implement the administrative safeguards you are half way done! Below is a list of the Standards, Sections and Implementation specifications.

I am going to take the rest of this article to discuss just the Security Management Process and more specifically the Risk Analysis and Risk Management implementation specifications. I believe the whole foundation of the HIPAA Security Rule is based on the Risk Analysis and Risk Management implementation specifics.

Keeping in mind that the principle behind HIPAA is protecting patient information, it is important to determine where patient information resides and determine what risks could potentially prevent you from protecting the information. Once you determine where the patient information resides and what the risks to protecting it are, you can then put in place procedures that will reduce these risks and strengthen your ability to protect the information.

To further illustrate the point, let’s apply the Security Management process to your house. Your house protects you and your family as well as your possessions; let’s call all of these your valuables. In order to protect your valuables you need to know the inventory of your valuables. While you probably won’t forget your spouse and kids, you may not remember the gold watch tucked away in your dresser drawer. So the first step should be to write down all of your valuables. Once you have a complete inventory of your valuables you need to determine the importance of them to you. Let’s break the importance into three categories; high, medium and low. Most likely your family ranks at the top of your importance list and would fall into the high importance category. The gold watch may have a significant financial value or may be a gift from someone making it important but not nearly as important as your family. Let’s put the gold watch into the medium category. Your mailbox may be on the list but of very little importance. If anything were to happen to your mailbox you can easily replace it with minimal financial impact so we will put that in the low category. So now you have a complete list of all your valuables and you have assigned an importance category to each of them. The next step is to determine the potential threats to your valuables.

No matter where you live the threat of crime always exists. If you live in a low crime area the threat may be lower but conversely if you live in a high crime area the threat could be very real. Once again we will break each threat into a category of high, medium or low. A flood is another threat to your valuables. If you live by a river or lake the threat of a flood could be high. A hurricane could be another threat but if you live in Kansas the threat is probably very low. At the end of this process you have a list of all potential threats to your valuables as well as the likeliness of the threat occurring.

Now you take the list of your valuables that are categorized by their value to you and you take the threats and their likeliness of occurring and you have identified where you need to focus your attention. If your family is of high value and the threat of crime is high, you will spend a lot of attention on securing your house. This could entail adding additional locks to your doors or installing a security system. On the other hand, your mailbox is of low value so you may choose not to worry about adding any addition security other than securing it to a mailbox post. Your home security management process is complete when you go through the list of your valuables and have implemented steps to protect them from the potential medium and high threats.

The process of protecting your valuables is the exact process that the Security Rule calls for in regard to protecting EPHI. Determine where your EPHI resides. Like the home illustration, you probably won’t forget your EMR (i.e. family) but EPHI may reside in email or digital x-rays on a network share (i.e. the gold watch). Make sure you have a complete list of all your EPHI and write it down. Categorize the importance of the EPHI. As a rule of thumb I like to say that the more EPHI you have in a system and the more people that access the EPHI, the higher the importance of the system (high category). The lower the EPHI and the less amount of people accessing the system the lower the importance of the system (low category). Another rule of thumb, if the system contains very important or highly confidential information then the system would fall into the high category. Conversely, if the system is encrypted or requires special software to access the EPHI then this would lower the category of the system. Next step is to identify the threats to your EPHI and categorize the likeliness of the threat occurring.

The loss of EPHI is always something to be concerned about (high category). In addition fire, flood or a natural disaster are other threats to consider. Once again each of these threats need to be categorized with the likeliness of the threat occurring.

The final Security Management step is to implement procedures to protect your EPHI against the medium or high potential threats. Let’s look at a few threats and some steps to strengthen your ability to protect your EPHI:

What you will notice is that after the Security Management process, the rest of the Security Rule is all about minimizing the potential risks to your EPHI. Each of the Steps to prevent threat listed in the above table is a specific Standards and/or Implementation Specifics in either the Administrative, Physical or Technical safeguards of the Security Rule.

In future posts, I will go over the rest of the administrative safeguards as well as discuss the physical and technical safeguards.

In this article, I gave an overview of the HIPAA Security Rule.  Let’s drill down a little further and go over the principles of the Security Rule.

There are two very good papers published by CMS that give an overview of the Security Rule.  The papers include Security 101 for Covered Entities and Security Standards: Implementation for the Small Provider.  In an ideal world, the Security Rule would sound like a cooking recipe that tells you the exact ingredients you need, how to mix the ingredients and how long you should cook everything to have the final product.  However, reading the papers, you’ll immediately notice they are very vague, giving you what is required to comply with the Security Rule, but they don’t tell you how or what you need to do to comply.  No recipe here – which brings me to my first point; the Security Rule is not a detailed step by step process that tells you how to implement the rule.

Take this line from the Security Standards:

“The Security Rule provides a flexible, scalable and technology neutral framework to allow all covered entities to comply in a manor that is consistent with the unique circumstances of their size and environment.”

Wow, that seems to say a lot but when you finish reading it you realize that it doesn’t say that much at all.  My take on it is that there are a set of rules you need to follow which include procedures and technologies you need to implement but specific procedures and technologies will not be defined.  Furthermore, based on the size of your organization you may or may not implement the same procedures and technologies and you may choose not to implement some of the procedures and technologies at all.  To clarify, if you are a large hospital with a full-time IT staff you will have the ability to implement different procedures and technologies then a small practice that has no full-time IT staff. 

The Security Rule is composed of a series of Standards.  A good description of a Standard can be found in the  Security Standards:

“Each Security Rule standard is a requirement: a covered entity must comply with all of the standards of the Security Rule with respect to the EPHI it creates, transmits or maintains.”

So no matter your organization size or level of IT ability, a Standard has to be implemented.

Within some Standards are Implementation Specifications:

“An implementation specification is a more detailed description of the method or approach covered entities can use to meet a particular standard. Implementation specifications are either required or addressable.”

 • A required implementation specification is similar to a standard, in that a covered entity must comply with it.

• For addressable implementation specifications, covered entities must perform an assessment to determine whether the specification is a reasonable and appropriate safeguard in the covered entity’s environment. After performing the assessment, a covered entity decides if it will implement the addressable implementation specification; implement an equivalent alternative measure that allows the entity to comply with the standard; or not implement the addressable specification or any alternative measures, if equivalent measures are not reasonable and appropriate within its environment. Covered entities are required to document these assessments and all decisions.

• Factors that determine what is “reasonable” and “appropriate” include cost, size, technical infrastructure and resources. While cost is one factor entities must consider in determining whether to implement a particular security measure, some appropriate measure must be implemented. An addressable implementation specification is not optional, and the potential cost of implementing a particular security measure does not free covered entities from meeting the requirements identified in the rule.

 Required implementation specifications have to be implemented no matter what your size or ability.  Addressable implementation specifications are not optional but you have to determine if your ability to implement the specification is reasonable and appropriate.  A good example of this is email encryption.  A large hospital has the ability and resources to ensure that all emails that contain electronic patient information have to be sent via secure encrypted email.  A smaller practice may decide that email encryption is too complicated or expensive to implement.  Instead the smaller practice may decide that they will not send electronic patient information via email at all, thus removing the need for email encryption.  Both organizations have addressed the implementation specific but did it in different ways that make sense to each of them.

If you determine that an addressable implementation specification is not reasonable or appropriate for your organization, you need to document the rationale for your decision.  Make sure you can defend the decision in the future which could be years from when you actually made the decision.

If you are a small,  midsize or large medical practice, the take away from this article should be that the Security Rule is not a specific list of things you have to do or a defined list of technologies you have to implement.  The Security Rule is a set of guidelines that give you some flexibility and take into account a practice’s size and resources. 

In future posts, I will dive into each of the Security Rule Standards and try to help you make sense of them.