The BAA is a contract, not a checkbox

Most practice owners sign Business Associate Agreements the same way they accept terms of service: scroll, initial, done. I understand the impulse. You are trying to launch a new scheduling tool or switch EHRs, and the vendor's legal PDF feels like the last hurdle before you can actually work. But the BAA is one of the few documents that will still matter to you three years from now, when a laptop goes missing at the vendor's data center or a former employee ships a spreadsheet of PHI to a personal Gmail.

A BAA is the contract that lets a HIPAA-covered entity (your practice) share protected health information with a business associate (your vendor) and hold them accountable for handling it correctly. Signing one is required by HIPAA whenever a vendor creates, receives, maintains, or transmits PHI on your behalf. The requirement is easy. The details are where practices get hurt.

Here is what I look at before I sign, based on years of running clinics and reviewing vendor paperwork for compounding and concierge practices.

Confirm the vendor will actually sign one, and who signs it

Start with the obvious: does the vendor sign a BAA at all, and do they sign the version you need signed? Plenty of consumer-grade tools (generic email, general-purpose scheduling apps, common file-sharing services on their basic tiers) either refuse to sign a BAA or only offer one on specific enterprise plans. If a rep tells you "we're HIPAA compliant" but cannot produce a BAA on company letterhead, you do not have a business associate. You have a liability.

Also check who is signing on the vendor side. A BAA signed by a reseller or implementation partner does not bind the underlying software company. If your EHR runs on top of a cloud infrastructure provider, your EHR vendor should have their own BAA with that provider. You should not need to chase the infrastructure company separately, but you should ask your vendor to confirm the chain exists.

Look at the definition of PHI and the permitted uses

Read the section on permitted uses and disclosures carefully. The BAA should limit the vendor's use of PHI to the services they are providing to you, plus narrow exceptions HIPAA allows (their own management, legal obligations, data aggregation on your behalf).

Watch for language that lets the vendor use "de-identified data" for their own purposes. This is not automatically bad. De-identification under HIPAA has a specific technical meaning, and many vendors use aggregated data to improve their products. But you want to know:

  • What de-identification standard do they use (Safe Harbor or Expert Determination)?
  • Who performs the de-identification, and is it audited?
  • Can they sell or license the de-identified data to third parties?

If the answer to that last question is yes and you are not comfortable with it, negotiate it out. In concierge and compounding practices where patient panels are small and specialties are narrow, "de-identified" datasets can be surprisingly re-identifiable. Your counsel should weigh in on the specific language.

Subcontractors and the downstream chain

Every modern clinical software vendor uses subcontractors. Cloud hosting, transactional email, SMS delivery, fax gateways, analytics, error monitoring, AI model providers. Under HIPAA, the vendor must have a BAA with each subcontractor that touches PHI, and those obligations must flow down.

What to look for in the BAA:

  • A clear statement that the vendor will enter into written agreements with subcontractors that impose the same PHI restrictions.
  • A commitment to provide a current list of subprocessors on request, or a public subprocessor page.
  • Notice obligations when subprocessors change, especially for anything involving AI model providers, which are moving quickly.

If your vendor is using large language models for scribing, intake, or messaging, ask specifically whether prompts and responses containing PHI are used to train the model provider's systems. The answer should be no, and it should be in writing somewhere between the BAA and the underlying service order.

Breach notification: timing and cost

HIPAA requires business associates to notify covered entities of a breach without unreasonable delay and no later than 60 days after discovery. Sixty days is the ceiling, not a reasonable target. Push for shorter notification windows, ideally within a few business days of confirmed discovery, with an initial notice within 24 to 72 hours of a suspected incident.

Also look at who pays for what after a breach. Some BAAs are silent, which effectively means you pay for patient notifications, credit monitoring, and regulatory response even if the breach happened entirely inside the vendor. Better BAAs put those costs on the vendor when the breach is caused by their acts or omissions. This is closely tied to the indemnification and limitation of liability sections in the master services agreement, which is why the BAA cannot be read in isolation.

Termination and return of PHI

Every BAA should describe what happens to your PHI when the relationship ends. You want two things clearly spelled out: your right to retrieve your data in a usable format, and the vendor's obligation to return or destroy PHI within a defined window after termination.

Practices get burned here more than anywhere else. If you switch EHRs and your outgoing vendor takes 90 days to export your data (or charges a five-figure fee for a "data extract"), you have a real operational problem. The BAA itself may not spell out the export mechanics, but it should reference your right to receive PHI in electronic form, and the master agreement should describe the format and any fees. If it does not, ask for language before you sign.

Security representations that actually mean something

Marketing pages love the phrase "HIPAA compliant." The BAA should back that up with concrete commitments. Look for references to:

  • Encryption of PHI at rest and in transit, with specific standards named or referenced in a security exhibit.
  • Access controls, including role-based access and audit logging on the vendor side.
  • A named security contact or incident response process.
  • An annual third-party audit or attestation (SOC 2 Type II, HITRUST) the vendor will share under NDA.

If the vendor cannot show you a recent SOC 2 report or equivalent, that does not automatically disqualify them, especially for smaller specialty tools. But you should understand why, and you should document that decision internally.

Practical process for your clinic

The BAA workflow I recommend for practices:

  • Keep a single inventory of every vendor that touches PHI, with the signed BAA attached and the effective date noted.
  • Review the inventory annually. Vendors change ownership, get acquired, and update their BAAs. You want to know before an auditor does.
  • When evaluating new software, request the BAA and security documentation during the demo phase, not after you have signed a purchase order. If a vendor stalls in sales, they will stall in incident response.
  • Have your healthcare counsel review the first BAA you sign with any material vendor. After that, you will start recognizing the patterns yourself.

None of this is legal advice, and your attorney should confirm the specifics for your state and specialty. But the shape of the review is the same across practices: understand what data the vendor gets, what they can do with it, who else touches it, how fast you hear about problems, and what happens when you leave.

If you want to see how we handle BAAs, subprocessor transparency, and PHI handling for compounding and concierge practices, talk to our team. We are happy to walk through our paperwork before you ever sign anything.

Frequently Asked Questions

Do I need a BAA with every software vendor my practice uses?

You need a BAA with any vendor that creates, receives, maintains, or transmits PHI on your behalf. That covers EHRs, patient communication tools, billing platforms, scheduling systems, cloud storage that holds clinical documents, and AI tools that process patient data. It generally does not cover pure infrastructure like a website builder that never sees PHI, or an accounting platform that only handles vendor invoices. When in doubt, ask your counsel.

Is a signed BAA enough to make my practice HIPAA compliant?

No. A BAA shifts specific obligations onto the vendor, but your practice remains responsible for its own Security Rule and Privacy Rule compliance: policies, workforce training, risk analyses, physical safeguards, and access controls. The BAA is one piece of a larger compliance program.

What if a vendor sends their standard BAA and refuses to negotiate?

Larger vendors often present take-it-or-leave-it BAAs. You still have leverage in three places: the master services agreement (indemnification, liability caps, data export), the security exhibit, and your choice to walk away. Read the standard BAA carefully and price the risk of the terms you cannot change. Sometimes the answer is to accept the language; sometimes it is to choose a different vendor.

How often should we review our existing BAAs?

At least annually, and whenever a vendor announces a material change (acquisition, new subprocessors, significant product changes involving AI). Put the review on the same calendar as your annual HIPAA risk analysis so it does not slip.

Does a BAA cover AI features like ambient scribing or intake bots?

It should, but only if the BAA and underlying agreements specifically address how PHI is used with AI models. Ask whether patient data is used for model training, whether it is retained by the model provider, and whether the AI subprocessor is listed. If those questions are not answered in writing, the BAA alone is not enough.