Breach Notification Planning Tips

All healthcare organizations should create a detailed plan for meeting the requirements of the HITECH breach notification rule, says attorney Gerry Hinkley.

In an interview, Hinkley describes key steps hospitals, clinics and other should take, including:

Designating someone, such as the HIPAA privacy officer, to lead the compliance effort;
Outlining processes for discovering breaches;
Creating a method for determining whether a particular incident poses a significant risk of harm and, thus, should be reported;
Making sure technology is in place to help keep information secure and to detect breaches when they occur;
Making sure state as well as federal notification requirements are met; and
Creating a detailed plan for communicating breach details to the individuals affected, the media and regulators.

Hinkley is co-chair of the healthcare industry team at Pillsbury Winthrop Shaw Pittman in San Francisco, where he advises healthcare organizations on HITECH issues and other legal matters.

HOWARD ANDERSON: This is Howard Anderson, managing editor at Information Security Media Group. We are talking today with attorney Gerry Hinkley who is co-chair of the healthcare industry team at Pillsbury Winthrop Shaw Pittman in San Francisco. Thanks for joining us today Jerry.

GERRY HINKLEY: Glad to be with you.

ANDERSON: Under the HITECH Act's Breach Notification Rule, healthcare organizations must report breaches affecting more than 500 individuals to the media and to federal regulators, in addition to the consumers themselves. Please walk us through step-by-step what should be included in an organization's breach notification plan to comply with the HITECH Act requirement, and who should handle what responsibilities.

HINKLEY: We are advising our clients to have a plan in place because we don't think it is a good idea to start thinking about the steps that need to be taken once you have a breach. The work that we have been doing since the breach notification rules came into effect in February is dealing with companies that haven't given it much of a thought yet. Certainly everybody hasn't jumped on this as job one, which I guess is just understandable.

The major elements of a policy related to breach notification are that you really have to focus on four things. One is technology, to make sure that there are technological measures to ensure that all of the protected health information in your custody is secure, and to the extent that it is not secure, that you have mechanisms to detect when a breach has occurred.

The second big piece is that someone needs to show leadership with respect to the policy development and either take responsibility or establish responsibility. Third, there is a role for your legal counsel in developing these plans to make certain that you are legally compliant and that you have mechanisms in place to take advantage of attorney/client privilege where that is appropriate. And then the fourth element is to reconcile the federal requirements with any state requirements that may be different from the federal requirements. That is certainly the case in California, as we have our own data breach law that is entirely different from what HIPAA requires, and so you have to comply with both. The state law is not pre-empted by the federal law.

And so what are the basic elements for a policy? One is you need processes for discovering breaches. You need to develop procedures and forms for reporting as required. You need mechanisms for determining if the data breach, or the unauthorized release of information rather, poses a risk of "significant harm" to the affected individuals because that is kind of the big question that has to be answered. You need mechanisms for determining if unsecured protected health information was involved, who the individuals were that were affected and what the applicable notification requirements are.

And then you also need processes for determining appropriate mitigation, developing advice to the affected individuals, creating and distributing notices, determining and creating other forms of communication that are or may be required, particularly if you have to notify the press. That typically is not just one communication with the press...there will be follow-up communications, and having a plan for those communications is important.

You also have to have an accounting process for keeping track of how you carried out the notification, particularly the reporting that is required for the Secretary of HHS.

So who should be responsible? Well, in larger settings, HIPAA requires every covered entity to have a privacy officer and it would be logically that individual's responsibility to see that a plan is implemented and then to carry it out. In smaller settings, it tends to fall to the senior administrative person. Somebody needs to be designated as having overall responsibility for carrying this out.

ANDERSON: How should a breach notification plan differ based on the size of the organization? Is the plan is going to have different nature based on the size?

HINKLEY: Absolutely. HIPAA is intended to be scalable. So baked into the law and regulations is the idea that you should do what is appropriate for the size and type of organization that you have. So for example, in a small setting it would be appropriate to have a less formal process. In many cases, particularly in the smaller settings, there is a tendency to utilize a vendor, and there are a number of vendors who run breach notification programs. And that seems to me to make a lot of sense for a smaller setting. We are working with a practice that had a breach of 50,000 records; providing notification to 50,000 individuals is an overwhelming task for this group. So they, on our advice, went to a vendor. In larger settings, they are probably are going to be in a position where they could administer the breach notification themselves, although I think that there is a real niche here for vendors in this regard because having everybody have to figure out all the nuances of the law for something that we are expecting is going to be an isolated incident just may not be a good use of time. So looking to have somebody help you one get policies in place, and two, assist you in implementing if there is a breach notification, probably makes sense, particularly in the smaller settings.

ANDERSON: The Breach Notification Rule allows healthcare organizations to determine whether a particular data security breach presents "significant risk" and thus needs to be reported. As a result of this harm threshold provision, should healthcare organizations create a risk analysis process to help them determine what breaches to report?

HINKLEY: Absolutely. We have worked with a number of organizations to develop an algorithm, and there are some that you can get to for free on the web. The definition of breach in the law and in the regulations requires a determination of whether there is a significant risk of harm to the affected individuals. Now this is a controversial part of the regulation. A number of people have predicted that it is not going to stay. I know Congressman Waxman, for example, was quite upset that this was included in the regulation and felt that HHS had gone way beyond the authority that was given to it for rulemaking in Hitches. So I personally think that if you have an unauthorized disclosure of protected health information, the consumer should be making the decision whether there is a substantial risk of harm, and not the breaching party, because there is already a built-in prejudice to find no significant harm. So I think, from the standpoint of consumers, I am not a big fan of that requirement and I am actually hopeful that it does go....

ANDERSON: How should an organization go about analyzing why a breach occurred, and what steps should be taken to prevent further incidents?

HINKLEY: A really key part of any kind of compliance effort is learning from past experiences and training with respect to them. So this is really a cornerstone of any compliance plan. And certainly in the breach notification area, if you had a situation where information has been disclosed that is not authorized, putting a finger in that dike is really a critical step, but more important than that is then learning from it and raising your consciousness about how breaches can occur. If you have one incident, it is a good opportunity to rethink your policy and your operational plan and determine if you are doing what you need to do in order to prevent these kinds of things from happening in the future. So of all of the elements in the plan, learning from your mistakes is really key.

ANDERSON: The Breach Notification Rule includes a safe harbor, which exempts organizations from reporting breaches if the information was encrypted in a specific way. So how should hospitals, clinics and others apply encryption? For example, should organizations be applying encryption to mobile devices and email?

HINKLEY: HIPAA does not require that per se. You don't have to have an encrypted communication between doctor and patient. However, if there is an unauthorized disclosure, then you are going to have a breach that could give rise to reporting requirements. So we are advising clients generally to do whatever they can to create secure messaging. For example, a lot of banks do this: You have a private message and you need to log on and then you go to a secure site and you get to read the message. That tends not to be too cumbersome and is a good way to just protect that kind of messaging.

A goal is to try, in any context where you are storing or transmitting protected health information, to do it in a secure way, which means in an encrypted way...for mobile devices or any way that you communicate....Advances in cloud computing actually are going to make it easier because the individual molecules, if you will, of information will have that level of protection....

ANDERSON: Because business associates now must report breaches to their healthcare partners, who are called covered entities, should business associate contracts be updated to add HITECH compliance details?

HINKLEY: If I were a covered entity, I would want to do that. HITECH...states business associates have 60 days to report to the covered entity. Well that creates something of a Catch 22. The 60-day period applies both to the covered entity and the business associate, so if a business associate uses the whole 60 days to get back to the covered entity, they are going to be forcing the covered entity to violate the law.

I also think that the covered entities need to know if there are security incidents related to their business associates, not just that there are breaches of information. Because a breach by definition means, one, that it was unprotected health information and, two, that it poses a significant risk of harm to the individual. As a covered entity, I really don't want my business associated making that determination.

Now...some covered entities say, "What I don't know won't hurt me, so if a business associate makes a decision that a breach didn't occur and on the basis of that they don't notify me, then I don't have to do anything." That is kind of putting you head in the sand and ultimately is contrary to the intent of HITECH. So what I am advising people to do with their business associate agreements is to add provisions that require notification of security incidents as soon as practicable, which is really consistent with the HIPAA Security Rule that was adopted in 2002. It really contains that same kind of obligation, although, frankly, I think it is probably ignored more than followed. At least in my practice, the business associates are not routinely monitoring data breaches and security incidents and reporting them to their covered entities. So you need to put expectations in your business associate agreement so that you have that level of protection.

ANDERSON: Thanks Gerry. We have been talking today with attorney Gerry Hinkley. This is Howard Anderson of Information Security Media Group.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing, you agree to our use of cookies.