Security

How Business Associate Agreement Terms Apply to Google’s Generative AI

The HIPAA Security Rule outlines how a BAA defines permissible use of protected health information. These regulations are flexible enough to ensure AI tools don’t pose a security risk.

Brian Eastwood

Brian Eastwood is a freelance writer with more than 15 years of experience covering healthcare IT, healthcare delivery, enterprise IT, consumer technology, IT leadership and higher education.

Business associate agreements between technology vendors and their payer, provider and clearinghouse partners establish how a BAA works with these HIPAA-regulated entities. The contract also underscores how a BAA can — and cannot — use an entity’s protected health information (PHI) through the course of their work.

As a frequent business associate of covered entities, Google is bound by the terms of the BAA for its Google Cloud Platform. “The BAA says Google is held to the same level of accountability that I am as a covered entity and healthcare provider when it comes to managing PHI,” says Spencer Cuffe, a chief architect at CDW who defined the company’s Google Cloud strategy. “It also says that anyone brought on to handle that information is held to the same accountability.”

As is the case with other enterprises, the terms of Google’s BAA apply to any products, services or features considered a “covered service” under the agreement. Increasingly, that includes the use of generative artificial intelligence (AI) tools.

DISCOVER: CDW and Google bridge the gap from AI hype to ROI.

A BAA Spells Out Permitted Use, “Appropriate Safeguards”

The HIPAA Privacy Rule of 2003 first defined covered entities and business associates, describing the latter as those that do work on behalf of a covered entity that involves the use or disclosure of PHI. The 2013 HIPAA Omnibus Rule offered additional clarification, generally defining business associates as those that create, receive, maintain, transmit or store PHI on behalf of a covered entity.

The Department of Health and Human Services has indicated that a BAA must describe permitted and required uses of PHI, prohibit further disclosure beyond those use cases, require “appropriate safeguards” to prevent use or disclosure beyond what the BAA specifies and require reporting of any disclosure of PHI the contract doesn’t account for.

What those “appropriate safeguards” should be often remains in the eye of the beholder. HIPAA itself is meant to be technology-neutral and doesn’t explicitly spell them out. (This is understandable in part because the authors of HIPAA had no way to anticipate how technology would evolve in the decades that followed the law’s signing.)

The HIPAA Security Rule offers some clues, indicating that covered entities and business associates must “implement a series of administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability” of electronic PHI. According to HHS, this means ensuring data confidentiality, integrity and availability while protecting against data security threats, “reasonably anticipated” impermissible data disclosure, and noncompliant employee behavior.

Cuffe says proper data classification and data lifecycle management are an important part of this process. Along with outlining what safeguards a business partner puts in place at each stage of this lifecycle, it’s important for covered entities to define who, when and why users and systems get to use the data.

“Organizations need to set boundaries about who can access what,” he says. “You need to establish clear guidelines for technical and employee enablement. Whether it’s PHI or important corporate data, you need to make sure it’s not leaked.”

Click the banner below to power employee productivity with AI.

A Foundation for Working With AI Safely

AI tools introduce an additional element of data risk in a few ways. Large language models depend on centralized data sets for accuracy, reliability and equity in training. Those large data sets are an attractive target for cybercriminals, especially compared with the siloed systems of yesteryear.

The tools themselves can be a threat. If individuals disclose PHI to a publicly available chatbot (intentionally or otherwise), then PHI is no longer subject to a BAA or regulated under HIPAA. This is also true if an individual transfers PHI from a platform developed by a business associate to another system (such as a wellness application or personal health device) that’s similarly not subject to HIPAA.

“Every AI conversation we have focuses on this question: If we put our proprietary information into this tool, is it safe?” Cuffe notes. “If you use the consumer-grade tools, especially if they’re free, then your information is eligible to be trained back into the AI model. If you use the enterprise-grade tools, it’s clearly stated that your information isn’t being trained back in.”

That underscores the benefit of making AI tools available that have been developed by business associates and are covered by a BAA, Cuffe says. Along with indicating specific authorized use cases for PHI, business associates will likely take action, such as erecting firewalls or censoring, redacting or otherwise anonymizing PHI before it’s injected into AI models for training purposes.

Cuffe adds that these conversations between the covered entity and business associate come up among platform owners, vendor relationship managers and legal departments. When it comes to frontline employees in clinical and administrative roles, the nuances of the BAA shouldn’t come up.

“Focus on the fact that you know they’re dealing with sensitive information, and you’ve given them the foundation to work with it in a safe way,” Cuffe says. “Everything is safe and secure because the right people have put the BAA in place, and partners are being held accountable.”

Brought to you by: