Do I Need a BAA for My Healthcare Startup?

If you're building a healthcare startup, you will probably encounter the term BAA sooner than you expect.

A healthcare provider may ask you to sign one before you use their software. Your cloud provider may require one before you store electronic protected health information (ePHI). An enterprise customer may include BAA requirements in its security questionnaire.

That naturally raises a question:

Does every healthcare startup need a Business Associate Agreement?

No.

But if your startup acts as a business associate under HIPAA and handles PHI on behalf of a covered entity, a BAA is generally both important and often required in that relationship. HHS defines a business associate as an organization or person performing certain functions or services for a covered entity that involve creating, receiving, maintaining, or transmitting PHI.

The distinction matters because being a healthcare startup doesn't trigger the BAA requirement. The nature of the relationship and what your company does with PHI do.

What Is a BAA?

A Business Associate Agreement, or BAA, is a written agreement between a HIPAA-covered entity and its business associate that establishes how PHI may be handled and requires appropriate safeguards.

Think of it as the contractual layer around a PHI-handling relationship.

For example, imagine a healthcare provider launches a patient-management platform your startup developed.

Your application:

• Stores patient information
• Sends messages between patients and providers
• Maintains appointment records
• Connects with an EHR
• Allows providers to review patient information

Your startup isn't simply selling software anymore.

It is performing services for the provider that involve PHI.

That can create a business associate relationship.

HHS specifically identifies healthcare app developers that provide applications to covered entities and create, receive, maintain, or transmit PHI for patient-management services as examples of business associates.

Do All Healthcare Startups Need a BAA?

No.

This is probably the most important thing to understand.

A startup doesn't automatically need a BAA simply because:

• Its product is related to healthcare
• It collects health information
• Its customers are healthcare organizations
• It calls itself a healthcare technology company

HIPAA applies to covered entities and business associates. If an organization doesn't fall into either category, HIPAA's Privacy, Security, and Breach Notification Rules generally don't apply to it as a HIPAA-regulated entity.

The real questions are:

1. Who is your customer?
2. Are they a HIPAA covered entity?
3. Are you providing services on their behalf?
4. Do you create, receive, maintain, or transmit PHI for them?

Those answers determine whether a business associate relationship may exist.

When Your Startup Needs a BAA

Consider a healthcare startup that sells a patient engagement platform to hospitals.

The hospital uses the platform for:

• Patient messaging
• Appointment management
• Care coordination
• Clinical communications
• Patient monitoring

The platform stores patient information in the startup's cloud environment.

In this situation, the startup is likely functioning as a business associate because it is providing services to a covered entity that involve PHI.

HHS lists healthcare application developers among examples of business associates when they create, receive, maintain, or transmit PHI on behalf of covered entities.

The provider and startup would therefore generally need an appropriate BAA before the applicable PHI-handling relationship begins.

What About Your Cloud Provider?

This is where many startup founders overlook the BAA chain.

Your healthcare startup may have a BAA with its hospital customer.

But your application probably doesn't run entirely on your own infrastructure.

You may use a cloud provider to:

• Host your application
• Store your database
• Store patient documents
• Run application services
• Process ePHI
• Maintain backups

If that cloud provider creates, receives, maintains, or transmits ePHI on your behalf, it may itself be a business associate or subcontractor.

HHS states that a cloud service provider that handles ePHI for a covered entity or business associate is a business associate, even if the provider stores only encrypted ePHI and doesn't possess the encryption key. An appropriate BAA is required for that relationship.

So your relationship may look like this:

Healthcare Provider → Your Startup → Cloud Provider

The healthcare provider has a BAA with your startup.

Your startup may need an appropriate BAA with the cloud provider.

This is sometimes described as a BAA chain.

When You May Not Need a BAA

Some situations don't create a business associate relationship.

Consider a consumer health application that an individual chooses to use independently.

The individual downloads the application and decides to connect it to their health information.

If the application isn't provided by or on behalf of a HIPAA-covered entity and isn't handling PHI on that entity's behalf, the app developer may not be a business associate.

HHS specifically explains that an app facilitating an individual's access to ePHI at the individual's request does not, by itself, create a business associate relationship.

This is why you shouldn't use a simple rule such as:

"If an app handles health data, it needs a BAA."

That's too broad.

The relationship and role matter.

A consumer wellness startup and a patient-management platform contracted by a hospital can both handle health information, yet have very different HIPAA obligations.

What If You Just Sell Software?

Another common misconception is that every software vendor selling to a healthcare organization automatically needs a BAA.

That's not necessarily true.

HHS explains that merely selling or providing software to a covered entity does not create a business associate relationship if the vendor doesn't have access to the covered entity's PHI.

However, if the vendor needs access to PHI to provide its services, for example, hosting patient information or accessing it while troubleshooting, the relationship can become one involving a business associate.

So there's an important difference between:

Selling software

and

Operating a service that handles the customer's PHI.

That difference can completely change your contractual requirements.

What Does a BAA Actually Cover?

A BAA isn't just a document that says:

"We promise to be HIPAA compliant."

It establishes specific responsibilities between the parties.

HHS's sample BAA provisions address areas including:

• Permitted uses and disclosures of PHI
• Safeguarding PHI
• Reporting certain unauthorized uses or disclosures
• Reporting security incidents and breaches
• Requirements for subcontractors
• Access to PHI
• Amendments to PHI
• Accounting-related obligations where applicable
• Return or destruction of PHI
• Termination of the relationship

The exact provisions should fit the relationship and applicable HIPAA requirements.

For a startup, this means you shouldn't treat a BAA as a generic legal template you sign and forget.

It should reflect how your product actually handles PHI.

A BAA Does Not Make Your Startup HIPAA Compliant

This is another distinction founders need to understand.

Signing a BAA does not magically make your application HIPAA compliant.

The agreement is one component of the relationship.

If your startup is a business associate, it can also have direct obligations under HIPAA. HHS states that business associates are directly liable for certain provisions of the HIPAA Rules.

Your technology may still need appropriate controls around:

Access Control

Users should access only the PHI they are authorized to view.

Authentication

Your application needs appropriate mechanisms to verify user identities.

Audit Controls

Important activity involving ePHI needs appropriate monitoring and logging.

Encryption

PHI should be appropriately protected during transmission and storage.

Risk Management

You need to identify and address security risks affecting ePHI.

Incident Response

Your organization needs processes for responding to security incidents.

Workforce Controls

Employees and contractors need appropriate access, training, and procedures.

A BAA establishes contractual responsibilities.

It doesn't replace the security architecture behind your application.

What Happens If You Store PHI Without a BAA?

This is where the issue becomes more serious.

Suppose your healthcare startup chooses a cloud provider and immediately starts storing ePHI.

You plan to sort out the BAA later.

That's a risky approach.

HHS states that when a covered entity or business associate uses a cloud service provider to maintain ePHI without first entering into the required BAA, it violates the HIPAA Rules.

The safer approach is to establish the appropriate contractual relationship before placing applicable PHI into the service.

Don't make your first real patient record the test case for your compliance architecture.

What If a Vendor Says "We're HIPAA Compliant"?

Don't stop there.

A vendor's marketing statement isn't enough to determine whether the service fits your particular HIPAA obligations.

Ask the vendor:

1. Do you sign a BAA?

Then ask:

1. Which products and services are covered?
2. Does the BAA apply to the plan we're purchasing?
3. Which subprocessors are involved?
4. Will they handle PHI?
5. Where is ePHI stored and processed?
6. What security controls are included?
7. What happens to PHI when the relationship ends?

HHS explains that organizations using cloud services should understand the cloud environment, conduct their own risk analysis and establish appropriate risk-management policies, and enter into appropriate BAAs.

In other words:

"The vendor says they're HIPAA compliant" isn't the end of your due diligence.

A BAA Checklist for Healthcare Startups

Before your application handles PHI, work through these questions:

☐ Is our company a covered entity or business associate?

☐ Who are we providing the service for?

☐ Is our customer a HIPAA covered entity?

☐ Are we creating, receiving, maintaining, or transmitting PHI?

☐ Do we need a BAA with our customer?

☐ Which vendors can access PHI?

☐ Do those vendors provide appropriate BAAs?

☐ Are relevant subcontractors covered?

☐ Where is ePHI stored?

☐ Who can access it?

☐ Do we have appropriate authentication and authorization?

☐ Do we maintain appropriate audit controls?

☐ Have we conducted a risk analysis?

☐ Do we have security and incident-response procedures?

☐ Do our contracts accurately reflect our PHI workflows?

This checklist doesn't replace legal or compliance advice, but it gives a startup a much better starting point.

Build the Architecture Before You Sign the BAA

Another reason founders should think about BAAs early:

Your contracts should match your technology.

If your BAA says your startup protects PHI, but your application sends patient information to an unreviewed third-party service, you've created a problem.

If your cloud provider stores ePHI but you haven't established a contractual relationship, you've created another problem.

If your application gives every employee unrestricted access to patient records, the BAA won't fix the underlying security issue.

That's why you should consider compliance during architecture planning, not after development is finished.

• Map the PHI.
• Identify the systems touching it.
• Evaluate vendors.
• Define roles.
• Design access controls.
• Determine your infrastructure.

Then establish the necessary contractual relationships.

Where Does DrapCode Fit?

For a healthcare startup, a BAA is only one piece of the production puzzle.

You also need an application architecture designed around healthcare workflows, security, interoperability, and PHI.

DrapCode is a healthcare application development company focused specifically on building software for healthcare organizations, providers, and digital health businesses.

That includes applications such as:

• Patient portals
• EMRs
• Care management platforms
• Telehealth applications
• Healthcare marketplaces
• Remote patient monitoring platforms
• FHIR-enabled applications
• Healthcare integrations

The objective isn't simply to add a BAA to an existing application.

It's to build the application, infrastructure, integrations, and security controls around the requirements of a real healthcare product.

The Bottom Line

So, do you need a BAA for your healthcare startup?

Maybe, but being a healthcare startup alone doesn't determine the answer.

If your startup acts as a business associate and handles PHI on behalf of a HIPAA-covered entity, you'll generally need an appropriate BAA.

If you're operating a consumer health application independently of a covered entity, you may not need a BAA simply because your product handles health information.

And if you do need one, remember:

A BAA is not the same thing as HIPAA compliance.

It's part of the contractual framework governing a PHI-handling relationship.

Your startup still needs appropriate security, risk management, policies, technical safeguards, and operational processes.

For healthcare founders, the best time to figure this out isn't after the first customer asks for a BAA.

It's before your application starts handling real PHI.

Frequently Asked Questions

Q1. Does every healthcare startup need a BAA?

No. Whether a startup needs a BAA depends on its role, its relationship with a HIPAA-covered entity or business associate, and whether it creates, receives, maintains, or transmits PHI on behalf of a HIPAA-covered entity or business associate.

Q2. Does a healthcare app developer need a BAA?

A healthcare app developer can be a business associate when it provides an app to a covered entity and handles PHI on that entity's behalf. HHS specifically includes healthcare app developers among its examples of business associates.

Q3. Do I need a BAA with my cloud provider?

If your cloud service provider creates, receives, maintains, or transmits ePHI on behalf of your startup or a covered entity, HIPAA generally requires an appropriate BAA with the provider.

Q4. Does signing a BAA make my app HIPAA compliant?

No. A BAA establishes contractual responsibilities for handling PHI, but your organization still needs appropriate safeguards, risk management, policies, and technical controls.

Q5. Can I launch first and sign the BAA later?

If the relationship requires a BAA, you shouldn't wait until after PHI is already being handled. HHS states that using a cloud service to maintain ePHI without first executing the required BAA can violate the HIPAA Rules.

Q6. Can a consumer health app need a BAA?

Not necessarily. If an individual independently chooses an app to receive their health information and the app isn't acting on behalf of a covered entity, a business associate relationship may not exist.

Build Your Healthcare Startup on the Right Foundation

A BAA answers a contractual question:

How will the parties handle PHI?

Your application architecture needs to answer another:

How will the technology actually protect it?

DrapCode helps healthcare startups and organizations build production healthcare applications with healthcare-focused development, security, and interoperability considerations built into the product architecture.

Build your healthcare application with DrapCode.