Navigating BAAs for HIPAA Compliance

I went into this thinking a Business Associate Agreement was a form.

You have a healthcare client. They have PHI. You are building software that will eventually touch it. So you sign the BAA, put the PDF in a folder, and move on.

It does not work like that.

A BAA is not the beginning of the process. It is a node in the middle of a dependency graph. Before you can sign it responsibly, you need to know who is allowed to sign, what entity they are signing for, what insurance is in place, what internal controls exist, and which of your own vendors will touch PHI.

That was the part I had wrong. I was treating the signature like a first step. It is closer to a gate.

This is not legal advice. It is field notes from standing up a healthcare platform for a multi-facility outpatient operator and realizing how much has to be true before anyone should be sending real patient data anywhere.

What the BAA actually does

The short version:

A covered entity is the clinic, provider, health plan, or other organization that holds PHI under HIPAA. A business associate is a person or company doing work on behalf of that covered entity where the work involves creating, receiving, maintaining, or transmitting PHI. HHS has a plain-English page on business associate contracts that is worth reading before you touch this stuff.

If you are building software that processes PHI for a healthcare provider, you are probably a business associate.

The BAA is the contract that says what you are allowed to do with that PHI, what safeguards you have to maintain, how you report misuse or breaches, what happens at termination, and how you flow those same obligations down to subcontractors.

That last part matters. If your app stores PHI in AWS, AWS needs a BAA. If your error tracker can receive PHI in stack traces, that vendor needs a BAA or the data needs to be scrubbed before it ever gets there. If your SMS provider sends patient-specific messages, that provider needs a BAA. If your AI provider sees prompts containing PHI, same thing.

You are not just signing one agreement with the customer. You are building a chain.

The clean sequencing looked like this for us:

Bind insurance.
Identify the legal entities and signing authority.
Put the internal controls in place.
Sign the customer BAA.
Sign the subcontractor BAAs.
Allow real PHI into the system.

You can shuffle some of the prep work in parallel, but you cannot ignore the order. A signed customer BAA does not magically make your cloud account, AI provider, SMS gateway, local dev machine, and logging stack safe for PHI.

Insurance comes before the signature

This was one of the first boring things that mattered more than I expected.

Do not sign a BAA and then start looking for insurance. Start the broker conversation early, because binding coverage takes time and the exclusions can make the policy useless.

The two policies that mattered for us were:

Cyber / privacy liability. This needs to explicitly cover HIPAA and ePHI. You are looking for breach counsel, forensics, notification, ransomware, regulatory defense, and the other expensive parts of a privacy incident. The important part is not the headline limit. It is whether healthcare, HIPAA, AI, or professional-services exclusions make the policy useless for the work you are actually doing.

Technology E&O / professional liability. This is the software side: defects, integration failures, billing-workflow errors, subcontractor issues, and the kind of thing where your code causes operational or financial harm.

I am not going to publish the coverage numbers or the cost model from the actual project. The useful part is the sequence: insurance review starts on day one, and coverage should be bound before you sign the customer BAA or receive PHI.

That sounds conservative until you read the BAA language and realize what you are agreeing to. Breach notification, safeguards, subcontractor flow-down, termination handling, cooperation with investigations. This is not an NDA.

The hard part was not the PDF

The hardest blocker was much dumber than I expected:

Who actually signs?

The customer was not one clean legal entity. It was a multi-facility operator with separate facilities, owners, management relationships, vendor accounts, NPIs, tax IDs, and approval paths.

At the product level, everyone can say “the customer” and know what they mean.

At the contract level, “the customer” is not a thing.

We mapped four possible paths:

Each facility signs its own BAA. Most conservative. Most paperwork.
One management or operating entity signs for all facilities. Cleaner, but only if it has documented authority to bind each facility.
The owners sign. Works only where those owners personally have the authority to do that.
A new legal entity signs and contracts into the facilities. Cleaner long-term, slower to stand up.

No one can choose between those paths until the authority map exists.

So the prerequisite was not a contract. It was a spreadsheet.

One row per facility:

legal name
DBA
address
NPI
tax ID
owners and ownership percentages
managing entity
who can sign
who approves vendors
legal contact
compliance contact
per-vendor account IDs
BAA status
authorization-letter status

Ours started blank. That was not a paperwork problem. It was the state of the system.

If you do not know the legal entity, you do not know who the covered entity is. If you do not know who can bind that entity, you do not know who can sign the BAA. If you do not know which vendor accounts belong to which facility, you do not know where PHI will flow.

You can still build software while that is unresolved. You just cannot receive PHI, configure production vendor access, or pretend the brand name of the project has signing authority.

That last bit matters too. The platform name was not a legal entity. So vendor conversations had to be framed as the dev shop supporting a platform initiative on behalf of authorized owners and operators. You cannot sign as a product codename.

You can build almost everything before the BAA is signed

This is the part that kept the project from freezing.

HIPAA gates data flow. It does not gate useful engineering.

We split the work into phases:

Phase A: synthetic or de-identified data only. Build the schema, RBAC, audit-log tables, API skeleton, TypeScript types, UI, integration adapter interfaces, and mock connectors. No PHI. No production vendor data. No excuses.

Phase B: vendor sandboxes. Once the authorization path is chosen, start working against sandbox environments where possible. Still no live PHI.

Phase C: staging with real PHI. This is where the gates become real: cloud BAA accepted, encryption on, centralized audit logging live, error tracking on a HIPAA-eligible plan with scrubbing configured, AI provider BAA active, SMS provider BAA active, and redaction tests passing.

Phase D: production. Pen test done, policies approved, access roster locked, incident contacts known, and production data flows documented.

That gave us a useful mental model: PHI is a feature flag you turn on late.

Not literally one boolean in the codebase. More like a system boundary. Until Phase C, every workflow runs on fake data, sandbox data, or de-identified data. The app can be real. The auth model can be real. The database can be real. The integrations can be shaped like the real integrations. But the records are not real patient records yet.

This changed how we designed the app.

Every PHI-touching record needed facility scope from day one. Not bolted onto the UI later. Enforced at the query layer.

Every meaningful action needed an audit entry. User, role, facility, action, record type, record ID, timestamp. Not note bodies. Not SMS bodies. Not raw AI prompts. The audit log needs to prove what happened without becoming a second PHI landfill.

Every record needed enough classification to drive log scrubbing, trace scrubbing, retention, and export rules.

Consent and opt-out tracking needed to exist before outreach automation became real. Especially for SMS. “STOP” is not a UX detail.

The vendor registry also became part of the data model. For each integration, we needed to know whether it was sandbox or production, whether a BAA existed, whether PHI was allowed, who owned the account, and what scope the integration had.

This is the part I underestimated. Compliance requirements do not stay in policy docs. They turn into columns, tables, tests, and deploy gates.

The vendors are their own project

Subcontractor BAAs have lead time.

The cloud BAA may be straightforward. AWS has a standard path through Artifact, assuming you are using covered services and configuring them correctly. That still has to happen before PHI lands there.

The AI provider might take weeks. That lead time can block the workflows stakeholders ask about first.

The SMS provider brings BAA questions, 10DLC registration, opt-out handling, quiet hours, inbound webhooks, and the rule that message bodies should not contain PHI unless you have designed for that very explicitly.

The error tracker needs a HIPAA-eligible plan or aggressive scrubbing, and probably both. You do not want patient names, DOBs, phone numbers, insurance IDs, note text, SMS bodies, or prompts showing up in exception payloads.

Marketing tools are worse in a different way. Google Ads and analytics pixels should not receive PHI. They are useful for aggregate attribution, not patient-level tracking. If a design requires PHI to leave the healthcare boundary and land in ad tech, that design is broken.

The boring vendor tracker became one of the most important documents:

vendor
data touched
PHI allowed or not
BAA status
sandbox status
production status
account owner
admin contact
incident contact
auth model
webhook security
retention behavior

That tracker tells engineering what can be built, legal what needs review, and operations what still blocks launch.

Behavioral health adds another layer

The platform was for substance-use treatment.

That means HIPAA is not the whole story.

SUD records can also be subject to 42 CFR Part 2, which has its own confidentiality rules for substance-use disorder treatment records. HHS describes Part 2 as protecting records for people receiving SUD services, with special limits around disclosure, consent, redisclosure, and use of records against a patient.

The exact implementation needs counsel. The important product point is simpler: a normal HIPAA BAA does not mean you are done thinking about SUD-specific confidentiality.

That affects the data model.

You may need consent-to-disclose records. You may need redisclosure tracking. You may need stricter rules around what flows to Salesforce, SMS, AI systems, call recordings, exports, support tickets, and screenshots.

The mistake would be treating Part 2 as a legal footnote. It is not. If your product handles SUD treatment records, it can change what you store, what you send, what you log, and what you let staff do in the UI.

In our docs, HIPAA was everywhere. Part 2 was missing until we raised it.

What I would do first next time

I would start with the entity map.

Not the app architecture. Not the vendor demos. Not the AI workflows. The entity map.

Who are the covered entities? What are their legal names? Who owns them? Who can sign? Who approves vendors? Which facility maps to which EMR account, billing account, CRM account, call tracking account, ad account, and SMS account?

While that is happening, I would start insurance and subcontractor BAA conversations immediately. Those have lead time, and no amount of code makes them go faster.

Then I would build aggressively on synthetic data.

The useful engineering work does not have to wait for signatures:

schema
RBAC
audit logging
integration boundaries
mock connectors
PHI classification
tenant and facility scoping
redaction tests
vendor registry
internal admin screens

Just keep real PHI out until the gates are actually cleared.

The BAA is not a checkbox at the start. It is what you sign after the shape of the legal, operational, and technical system is clear enough that the signature means something.

That is less convenient than “send me your BAA and I’ll sign it.”

It is also a lot closer to what the work actually is.