Do I need a HIPAA Business Associate Agreement for my health app?

Building an AI tool for therapists or small clinics looks like an ordinary SaaS, and the thing most builders miss is that if your customers are HIPAA-covered providers and your tool touches their patients' data, HIPAA reaches you too, as a Business Associate. The wall here is not the scheduling feature or the chatbot. It is that handling protected health information on a covered provider's behalf pulls you into HIPAA directly, with a required contract and real security duties. A version of the same tool sold to providers who are not covered entities lands under a different set of rules, but not under none.

The card above is a real result from a compliance check. The idea tested was a synthetic example: an AI assistant that books appointments for small health and wellness providers, chats with the client to learn what they need help with, and books into the provider's calendar, aimed at solo therapists, counselors, and wellness coaches. The profile was a solo founder based in the US. The result was a needs review signal, not a blocked one, because handling health data is lawful with the right safeguards. The condition is the set of duties explained below, and which set you owe depends on who your customer is.

What a HIPAA business associate is

A business associate is anyone outside a covered entity's own workforce who performs a function or service for that entity that involves access to protected health information. A vendor that schedules appointments and runs intake for a therapist, and in doing so can see who the patient is and why they are seeking care, fits that definition. HIPAA does not bind only hospitals and doctors. It follows the data to the vendors who handle it.

When you are a business associate, two things become true. The covered entity must have a signed Business Associate Agreement with you before you handle protected health information, and you take on direct HIPAA duties of your own: implement the HIPAA Security Rule safeguards for electronic protected health information, limit use and disclosure to what the contract allows, and report breaches. The contract requirements sit at 45 CFR 164.504(e), and your subcontractors need their own agreements down the chain.

Sources: HHS, Business Associates and HHS, Business Associate Contracts.

When does a provider count as a covered entity?

Not every health and wellness provider is a covered entity, and this is the line that decides which rulebook you are under. A health care provider becomes a HIPAA covered entity when it transmits health information electronically in connection with certain standard transactions, the most common being billing a health plan.

A licensed therapist or counselor who bills insurance is almost always a covered entity. A wellness coach who takes cash and bills no insurance often is not. The same product, sold to those two customers, can land on opposite sides of HIPAA. That is why a tool aimed at "solo therapists, counselors, and wellness coaches" cannot answer the BAA question with a single yes or no until you know who is actually buying.

Source: HHS, Covered Entities and Business Associates.

The same tool, two different rulebooks

The compliance check flagged this idea for consumer health data rather than blocking it, because the answer genuinely depends on the customer. The engine separates the activity from the obligation, and so should you.

If the provider is a covered entity, you are a HIPAA business associate. You need a signed Business Associate Agreement and you must build to the HIPAA Security Rule. If the provider is not a covered entity, for example a cash-only wellness coach, HIPAA may not apply, but you are not off the hook. A non-HIPAA app that handles health information can fall under the FTC Health Breach Notification Rule and a growing set of state consumer-health-data laws, none of which have a small-founder or no-revenue exemption.

Either way there is a duty. What changes is which regime you are in, and that turns on a fact about your buyer, not on how you describe your feature.

The myth versus what the law does

	The common assumption	What the law actually does
"I just schedule, I don't treat"	Scheduling is not health care, so HIPAA does not apply	Handling protected health information for a covered provider makes you a business associate regardless of the feature
"HIPAA is the provider's problem"	The clinic deals with HIPAA, not my SaaS	A Business Associate Agreement pushes direct HIPAA duties onto the vendor
"A good privacy policy covers me"	One privacy policy is enough	A BAA and Security Rule safeguards are separate, specific, and required
"We serve wellness coaches, not doctors"	Wellness is outside health regulation	Even outside HIPAA, the FTC Health Breach Notification Rule and state health-data laws can apply

What you take on as a business associate

The duties are concrete, and they are engineering and process work, not a checkbox. A signed Business Associate Agreement before you touch any protected health information. HIPAA Security Rule safeguards for electronic protected health information, which in practice means access controls, encryption, and audit logging. Use limited to the minimum necessary and to what the contract permits. Breach reporting to the covered entity. And if you use subcontractors, such as a cloud host or a model provider, they need their own agreements with you.

This is workable for a solo founder, but it has to be designed in. Pick infrastructure that will sign a BAA with you, because not every vendor will, and keep protected health information out of any system you cannot bring under the Security Rule.

Source: FTC Health Breach Notification Rule, for the non-HIPAA side of the line.

If you are a solo founder on a small budget

The cost here is not the build. It is the contract plus the safeguards that come with holding protected health information, and they grow with the data you keep. That is why a compliance check returns this kind of idea as needs review rather than a clean pass.

If that is too heavy for your stage, these are not workarounds. They are different products that change the duty:

• If you target covered providers, sign Business Associate Agreements and build to the Security Rule from day one. Treat it as a core requirement, not a later add-on.
• Or scope to providers who are not covered entities and design for the FTC Health Breach Notification Rule and state consumer-health-data laws instead. Lighter, but still real.
• Or avoid holding protected health information at all: keep identifiable patient data on the provider's side and have your tool operate on minimal or de-identified data.

Each of these changes what data you hold and on whose behalf, which is what changes the duty.

How to validate before you build

The result shown above came from Tovrio, a compliance check that runs an idea against country specific rules before you write code. The idea tested was a synthetic case, not a real user. The result was a needs review signal with the reasons named here.

This is a validate before you build signal, not legal advice. A flag means "go confirm this with a healthcare privacy professional before you commit," not "your specific plan is definitely unlawful." You can run your own idea through it.