Google Apps

Google agrees to sign BAA as means to HIPAA compliance

Google removes a barrier to Google Apps adoption by offering to sign BAA for organizations that need to comply with HIPAA.

HIPAA.gif
In September 2013, Google offered for the first time to sign a HIPAA Business Associate Agreement (BAA) available for Google Apps. That's good news for organizations unwilling to deploy Google Apps without such an agreement. It is also a smart competitive move, as it matches Microsoft, which offers to sign a BAA for Office365.

HIPAA: The basics

For those who may be unfamiliar, HIPAA (Health Insurance Portability and Accountability Act), refers to a set of laws passed in the United States in 1996. The laws seek to limit access to individually identifiable healthcare information to those that "need to know". HIPAA holds healthcare industry professionals accountable for the privacy of patient information.

Effective HIPAA compliance implementations resemble effective security systems: they're designed with the aim of protecting individually identifiable health information (IIHI). Such information is broadly referred to as "protected health information", or PHI. This information includes an individual's name, address, and any information related to the individual's health or payment records. A Business Associate Agreement (BAA) provides written assurances that an organization's partners will also seek to secure an individual's PHI.

Google Apps BAA

Google's BAA agreement covers three Google Apps services (Gmail, Calendar, and Drive), along with the Google Apps Vault service, which archives user data from the other three services. To sign up, an Administrator for the Google Apps domain must answer three questions online. From the website:

  1. Are you a Covered Entity (or Business Associate of a Covered Entity) under HIPAA?
  2. Will you be using Google Apps in connection with Protect Health Information?
  3. Are you authorized to request and agree to a Business Associate Agreement with Google for your Google Apps domain?

After responding, the Administrator will be taken to the BAA document for signature. As of September 27, 2013, Google is using Adobe's Echosign to obtain digital signatures.

Read before signing

The BAA terms state "...other Google services or third party Marketplace Apps should not be used in connections with PHI. This agreement requires that you disable all Additional services in the Admin console." (Emphasis is mine.)

An organization signing the BAA would not be able to use the domain covered by this agreement for additional useful Google services, such as Google+, Google Groups, or Google Sites. As the terms state, you must disable all Additional services: you may use Gmail, Calendar, Drive and Google Vault. The terms also appear to prohibit the use of Marketplace Apps in conjunction with PHI. (It is unclear whether the terms also prohibit the use of apps intended to secure and protect PHI, such as zSentry. zSentry offers to sign a BAA, and is a third-party app, which may be connected through the Marketplace.)

Implement thoughtfully

If your organization needs HIPAA compliant email, calendars and document storage, then sign the BAA and move forward with the migration. Your organization can adopt Gmail, Calendar, and Drive, confident that IIHI and PHI in those apps will be protected by the BAA.

If your organization is already using Google Apps, review your usage carefully before signing the BAA. If you've already implemented measures to ensure HIPAA compliance, the availability of a BAA may not change anything for your organization. For example, you might already prohibit the use of PHI in Gmail, Calendar and Drive. You might already use tools to audit and verify compliance, such as CloudLock.

Documents don't ensure security

Google-Apps-logo.png
Google's willingness to sign a BAA for organizations that need to comply with HIPAA is helpful and certainly welcomed. It may remove a barrier to adoption for some organizations. But healthcare professionals need to remember that HIPAA compliance, like all IT security, involves complex systems comprised of people, policies, and practices. (For example, you still need effective password policies, security measures such as 2-step authentication, and appropriate user permission settings.)

Signing a BAA doesn't ensure your entire organization is HIPAA compliant: the BAA is just one piece of a complex system needed to protect IIHI and PHI.

Also read:

About

Andy Wolber helps people understand and leverage technology for social impact. He resides in Ann Arbor, MI with his wife, Liz, and daughter, Katie.

12 comments
warrenbullock3
warrenbullock3

Thanks for the great article.  I'm the CIO of a non-profit healthcare organization so obviously there's a lot of stock in this discussion for me as well.  I've written blog post about my take on this subject based on actually referencing the HIPAA regulations.  Take a look if you like.  Post comments as well if you think I'm way off on my take: http://www.warrenbullock.me/article/hipaa-compliance-google-apps

DigDug63
DigDug63

The problem with this...

The BAA terms state "...other Google services or third party Marketplace Apps should not be used in connections with PHI. This agreement requires that you disable all Additional services in the Admin console."

... is that you can never turn off Google Search in Google Apps. Search needs to be unlinked from Google Apps if you want to protect your data.

GSG
GSG

This is all backwards.  It's not the client that should be signing the BAA, it's Google, because Google is providing the service.  While the BAA is standard, and the coverend entity is required to use the standard BAA, then you can specify what applications it covers.  I'd do this with a separate contract.

Google is then held to a higher level of privacy.  They have to train any employees responsible for the covered applications in HIPAA, and with the new Omnibus rules that went into affect a couple of days ago, they then become a covered entity.  The hospital, or covered entity then has the right to inspect Googles facilities and ask for their security audits, HIPAA training info, etc...  If Google fails to comply, then the entity using their services is obligated to report them to CMS for HIPAA violations.  I believe fines are now at $1.5 million per incident, which is a drop in the bucket for Google, but if they are investigated, I'm sure they could find lots of incidents.

Dave Lalande
Dave Lalande

Here comes healthcare.  Thank you Google.

wizard57m-cnet
wizard57m-cnet moderator

We don't use any online "cloud" storage for HIPPA or PHI at my company.  Everything is encrypted and stored on premise.  I can't take the chance that some server somewhere in the "cloud" will be down for repair, update, upgrade, etc. at some critical point. 

sandyshoes
sandyshoes

So, is zsentry, cloud lock etc allowed or not? Seems too restrictive to disallow firms enhancing security and willing to sign BAAs. 

Mark W. Kaelin
Mark W. Kaelin moderator

Has the lack of a BAA from Google been a stumbling block when it comes to using Google Apps in your organization?

trey_swann
trey_swann

@wizard57m-cnetRespectfully, I hope that that starts to change. Patients are demanding healthcare to become more transparent and interactive. The “cloud” can be used to facilitate a more effective dialogue between patients and doctors. With the rise of mobile health tech the amount of consumer generated health information is growing at a geometric rate. But, consumers don’t want data, they want information. Developers of new healthcare apps can use the “cloud” to increase collaboration and to transfer data to healthcare providers.

I agree with you, five 9s is critical when it comes to PHI. I share your concerns. But, it wasn’t that long ago where many had the same concerns about credit card data. Now, using companies like Stripe and Authorize.Net is a part of best practices. Plus, on-premise solutions are not inherently more secure than off-premise. Most breaches are the result of human error (e.g. lost or stolen devices, etc.). 

My company, TrueVault, is helping developers store PHI off-premise. TrueVault is a HIPAA compliant data backend for healthcare apps, devices, and sites. Developers build their solutions on top of TrueVault, and TrueVault handles the Technical and Physical Safeguards outlined in the HIPAA Security Rule. TrueVault will sign a BAA, and provides a comprehensive Privacy-Data Breach Insurance policy.

https://www.truevault.com/

The administrative components are also really important when implementing a HIPAA compliance program. I think that Accountable does a great job automating this process.

http://www.accountablehq.com

123pete
123pete

@sandyshoes I really want to understand this too. Surely it can't be Google's intention to preclude all marketplace apps regardless of whether they offer a BAA. If all parties have a BAA in-place I'd have thought there wouldn't be a problem from a HIPPA point of view.

roaringfork25
roaringfork25

@123pete @sandyshoes From Google "The BAA is specific only to disabling the Non-Google Apps Products and doesn't restrict the use of other third party apps."

Editor's Picks