Healthcare Information Security

Latest Health Data Breaches News

OHSU breach triggers sufficient risk assessment questions

By Patrick Ouellette

- Oregon Health and Science University (OHSU) made news last week when it explained to 3,044 patients that it had been lacking a business associate agreement (BAA) with Internet-based service provider Google and their data may have been potentially exposed as a result of its oversight.

This wasn’t a breach where any sort of malicious activity is believed to have occurred, but serves as an interesting topic for debate because OHSU couldn’t point to an external review that vetted for this security gap and since Google was the vendor involved. Beyond the fact that OHSU didn’t seem to have its staff unified in understanding what types of contracts and agreements need to be in place regarding protecting patient data until recently, the story raised additional questions.

When incidents such as this arise, industry experts often call for either more extensive external assessment or better employee training. James Burgess, Executive Director at Principled Data Governance, for example, said in a LinkedIn comment that he is among those who believe in independent assessments to help avoid breaches, even if it’s a smaller healthcare organization.

If these were my clients I would have suggested a full risk assessment that not only addressed the issue specifically but the issue of data storage, and transmission generally. Additionally, these guys should have emphasized this point when they provided training.

Typically, if you have one issue occur others are brewing. This group definitely needs to have an outside assessment immediately. Also, if resources are an issue they don’t need a huge Accounting Firm or Law firm to provide the assessment. There are many small to medium sized firm that can perform these services with superior talent, and at a much more reasonable price.  I wonder if they had such an assessment and if so there consultant missed the issue or if they ignored advice. At the end of the day, you wonder who’s running the shop.

Additionally, this case was a reminder that cloud vendor liability isn’t a factor once the decision is made on the part of the covered entity not to enter into a BAA with the vendor. Carlos Leyva, Attorney, Digital Business Law Group and manager of the LinkedIn group “HIPAA Survival Guide”, added that Google not signing a BAA is nothing new and a cloud vendor entering into a BAA with a healthcare organization is rare.

The only cloud vendor that I know for sure is willing to sign a BA agreement is Microsoft (e.g. for their Office 365 Product Suite). I hear that Amazon has announced publicly that it will also enter into BA agreements for its S3 storage offering (although I have not seen the announcement but was informed by a client).

From a liability perspective it’s unlikely that a breach actually occurred because I would tend to think that this fact pattern falls under the “low probability that the PHI in question was compromised.” Obviously, unless HHS and/or a state AG brings an action there won’t be any liability found. As aggressive as the “class action” law firms are, I don’t think this is a case they would pursue (famous last words) under state law.

Just because no BA agreement is in place does NOT make it automatically a breach under the HITECH/Omnibus Rule test. To James’ point however, any minimalist Risk Assessment would have identified this as a problem and one that could easily corrected.

As both Burgess and Levya opined, even a low-level risk assessment could have made a significant difference in avoiding OHSU having to tell patients that their data was potentially compromised in Google’s cloud. It’s hard not to include training in this topic either, because with cloud technology so prominent these days, you would assume that knowledge of BAAs would be fundamental to a healthcare organization.


SIGN UP and gain free access to articles, white papers, webcasts and exclusive interviews on

HIPAA Compliance
Data Breaches

Our privacy policy

no, thanks

Continue to site...