Do You Need a BAA? When HIPAA Requires One

At a Glance

• • • You need a BAA when a vendor does work for a covered entity or business associate and that work involves protected health information (PHI).
    • Encryption and a contract’s title don’t decide the issue. A cloud vendor storing encrypted ePHI is still a business associate, even without the key.
    • The same company can be a business associate for one service and not another.
      

The two-part test, the exceptions, and why encryption doesn’t settle the question

The BAA discussion often happens too late in a vendor review. Getting the BAA question wrong can create problems for both sides of a contract. Sign one when it isn’t required, and you may take on obligations you didn’t need. Skip one when HIPAA requires it, and you’ve got a different problem. 

The answer starts with three things HIPAA asks. 

What work is the vendor doing? 

Who is it doing that work for? 

Does that work involve protected health information (PHI)?

Then we look at the service and the data flow, and check whether the agreement aligns with them. One company can be a business associate in some instances and not in others. 

When Is a BAA Required Under HIPAA? The Two-Part Test.

Start with understanding the relationship. Is the vendor performing a function on behalf of a covered entity or another business associate? Covered entities include health plans, health care clearinghouses, and health care providers that conduct certain transactions electronically. A business associate can also be a subcontractor that handles PHI for another business associate. For more on that see the HHS Business Associates FAQ and the HIPAA definitions in 45 CFR § 160.103.

We dive deeper now and check if the work involves creating, receiving, maintaining, or transmitting individually identifiable health information on the covered entity’s or business associate’s behalf? If so, the vendor may be a business associate. The answer depends on what the service does, not the vendor’s general privacy policy or name of the agreement.

A BAA is required when a person or company outside not employed by the covered entity performs functions or services that involved PHI for a covered entity or business associate. Keep in mind other privacy laws may still apply even when HIPAA doesn’t require a BAA. 

Can the same vendor need a BAA for one service but not another?

A vendor’s status can change from one product to another. Imagine a technology company that offers a claims platform to health plans and a separate wellness app directly to consumers. When it processes claims for a health plan, it is performing work on the plan’s behalf and handling PHI. The consumer app doesn’t automatically create a business associate relationship just because it collects health information. The question is whether the company is acting on behalf of a covered entity or another business associate.

Professional services need the same analysis. HIPAA identifies as potential business associate work when the service involves PHI. 

For consumer health apps, other rules may apply even when the company isn’t a business associate. The FTC’s Health Breach Notification Rule may apply to vendors of personal health records. State consumer health privacy laws may also apply.

Case Study: Same Software Vendor. Different BAA Answer.

Consider a software company providing the same product to two healthcare customers. In the first arrangement, the customer licensed the software, installed it on its own systems, and managed the data internally. The vendor didn’t host the software, receive patient information, or access PHI through support. We looked at the actual data flow and the vendor’s obligations, not simply the fact that it sold software to a healthcare company. No PHI handled on the customer’s behalf. No BAA required.

In the second arrangement, the vendor hosted the software and provided ongoing technical support that involved accessing patient records. Different facts. Different answer. The vendor was now maintaining and accessing PHI on behalf of a covered entity. A BAA was required. Our approach was to define exactly what the vendor could access, limit how it could use that information, and make sure the BAA and underlying services agreement were consistent. That’s why we follow the data, not the vendor’s label.

Takeaway: Same software company. Same underlying product. Two different uses, two different outcomes.

When does HIPAA not require a BAA?

Not every person or company that encounters PHI is a business associate. The common examples are narrower than they sound.

• Treatment disclosures. A covered entity may disclose PHI to a health care provider for treatment without a BAA. The receiving provider is treating the patient, not performing a service for the referring provider.
• Pure transmission services. A service that only transports PHI, without routine access, may fit HIPAA’s narrow conduit exception.

• Work that doesn’t involve PHI. A vendor whose service doesn’t require the use or disclosure of PHI may not be a business associate just because incidental access is possible. This comes down to having reasonable administrative, physical, and technical safeguards. A person working under a covered entity’s direct control may qualify as part of its workforce rather than as a separate business associate.

• Each party acting on its own behalf. A covered provider and a health plan processing its claim are each acting on their own behalf as covered entities. That exchange alone doesn’t necessarily create a business associate relationship.

HIPAA has other specific rules, including for certain organized health care arrangements and group health plan disclosures. Don’t stretch the conduit or incidental-access examples to cover a vendor whose service depends on handling PHI.

A BAA Is a Contract, Not a Box to Check

If a BAA isn’t required, document why, including what the vendor does, what data it accesses, and why the relationship doesn’t meet HIPAA’s business associate test. That doesn’t mean the vendor gets a free pass on confidentiality, security, or data use. Those provisions still belong in the MSA or license subscription agreement. Don’t incorporate a BAA just to get through procurement. It’s a contract that can impose obligations the parties didn’t need to take on and create conflicts with the rest of the agreements. 

If the data is encrypted, do you still need a BAA?

“The data is encrypted, so the vendor can’t read it. We don’t need a BAA.” I hear versions of this argument regularly. It confuses two different questions. One is whether the vendor is a business associate. The other is whether particular information triggers notice under the rules for a breach of unsecured PHI.

Under HHS’s cloud computing guidance, a cloud provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is a business associate. Yes, even if the data is encrypted and the provider doesn’t have the key. It doesn’t remove the BAA obligation.

How this played out for one client. A healthcare client was onboarding an AI vendor that would process patient communications. The vendor said a BAA wasn’t needed because the data was encrypted.

That didn’t hold up. Encryption doesn’t take PHI outside HIPAA. And this vendor held the decryption keys. Its AI addendum also let it use customer data for model training and product improvement. That ran straight into the limits a BAA places on permitted uses and disclosures of PHI.

Under the proposed terms, the vendor could have trained its models on PHI and relied on the AI addendum as its contractual permission to do so. 

We prohibited training on PHI and limited data use to providing the service. Then we required the same limits for subcontractors. The approach was to make the BAA control over any conflicting terms. The deal closed without the vendor getting broader rights to its patient data.

In roughly one out of three AI vendor reviews involving health data, we find provisions that give vendors broader rights to use customer data than the BAA allows. Getting the BAA signed isn’t enough if the MSA or AI addendum gives the vendor rights the BAA is supposed to restrict. You have to read the agreements together and resolve those conflicts before signing. 

Can a DPA or MSA serve as the BAA?

Yes, but only if agreement includes the HIPAA terms that apply to the relationship and covers the right parties and service. A standard DPA may cover security incident and breach notice terms but still miss HIPAA-specific terms like an accounting of disclosures.

Back to the problem of conflict between the contracts. A BAA, an MSA, and an AI addendum can each look reasonable and still contradict each other on how the vendor may use PHI. Our BAA review checklist discusses how to read them together.

Build the BAA question into vendor intake

The BAA question shouldn’t first appear the week before launch. Ask the business sponsor to describe the service, who receives it, and what information the vendor is doing with the information. Then ask whether the vendor is doing that work for a covered entity or business associate.

Frequently asked questions about BAAs

Does encrypted ePHI still require a BAA? Yes. A cloud provider handling ePHI on behalf of a covered entity or business associate is a business associate even if it lacks the encryption key.

Does every subcontractor need a BAA? A subcontractor that handles PHI on behalf of a business associate needs a written agreement with the business associate before receiving PHI. The covered entity doesn’t usually sign directly with each downstream subcontractor.

Is every health app a business associate? No. A consumer app isn’t automatically a business associate when it provides its own service directly to individuals. The FTC Health Breach Notification Rule and state laws may still apply.

BAA questions go faster when they start with the service, the data flow, and the contracts around it. Gouchev Law’s healthcare regulatory practice advises health care and technology companies on BAAs, DPAs, and vendor agreements. We’re ready when you are.

This article is for general informational purposes and doesn’t constitute legal advice or create an attorney-client relationship.

About the Author

More Resources For You