For most healthtech founders, the Business Associate Agreement is a document they need to sign before a hospital will work with them. That’s a reasonable way to understand it. What’s less understood is what the BAA actually means legally, what hospitals are specifically looking for when they review it, and what the common friction points are that delay deals by months.
Understanding the BAA changes how you sell into healthcare. It’s not a formality to push through legal. It’s the document that defines your liability exposure with PHI, and the way you approach it signals to the hospital whether you understand what you’re getting into.
What a BAA actually is
Under HIPAA, covered entities — hospitals, health plans, and healthcare providers — can only share Protected Health Information with Business Associates who have signed a compliant BAA. If your healthtech product creates, receives, maintains, or transmits PHI on behalf of a covered entity, you are a Business Associate. The BAA is mandatory, not optional.
The BAA specifies: what PHI you can use and for what purposes, your obligation to implement safeguards, your responsibility to report breaches to the covered entity and their timeline expectations for that notification, your obligation to pass down equivalent protections to any subprocessors who touch PHI, and what happens to PHI when the relationship ends.
Signing a BAA creates real legal accountability. If you experience a breach of PHI traceable to your failure to implement the safeguards described in the BAA, you face direct exposure under HIPAA. Penalties up to $1.9 million per violation category per year, plus civil litigation from affected patients.
This is why the hospital’s legal team reads it carefully. And why you should too.
What hospitals focus on when they review your BAA
HIPAA requires Business Associates to notify covered entities ‘without unreasonable delay and in no case later than 60 calendar days after discovery.’ Most hospitals want a much shorter commitment in the contract — 24 to 48 hours for initial notification of a suspected breach. This is where the most negotiation happens. The hospital wants fast notification because they have their own HIPAA obligations to patients and potential HHS reporting requirements. If you notify them on day 58, they have two days to notify potentially thousands of patients.
Hospitals are specific about what you can do with their patients’ PHI. Using it to provide the contracted service: permitted. Using it to improve your AI model, train on patient cohorts, or aggregate for research: requires explicit permission in the BAA or a separate data use agreement. Several healthtech companies have run into significant problems by training AI models on patient data under BAAs that didn’t explicitly permit it.
Hospitals want to know who else touches their patients’ data. Your AWS environment, your database, your monitoring platform, your analytics service. Each one is a subprocessor. Hospitals increasingly require disclosure of key subprocessors by name, especially cloud providers.
When the relationship ends, what happens to PHI? ‘Within 30 days of termination’ is a common commitment. If you’re operating a platform where PHI destruction would affect the service for other covered entities, this section gets complicated and needs careful drafting.
Your BAA or theirs
Most hospitals have their own BAA templates and prefer to use them. Their lawyers drafted their template with their specific obligations and preferences in mind. The problem for an early-stage healthtech company is that hospitals’ templates often include indemnification and liability terms that are heavily weighted toward the hospital.
Having your own BAA template, pre-approved by healthcare counsel, creates a different dynamic. It signals that you’ve done this before. It gives legal teams something to compare against. And your template likely has more balanced indemnification and liability terms.
The three things BAA negotiations almost always come down to:
- Breach notification timelines
- Indemnification scope
- Permitted use of PHI for product improvement
Know where you’re flexible and where you’re not before the negotiation starts.
The subprocessor BAA chain
Every service that touches PHI in your stack needs to sign a BAA with you.
AWS, GCP, and Azure all offer HIPAA BAAs and will sign them, but you have to request them and actively enable HIPAA-eligible services. The default configuration of most cloud accounts is not HIPAA-eligible. If you’re storing patient data in an S3 bucket on a standard AWS account without a signed BAA with AWS, you’re operating without a required Business Associate Agreement.
-
!
Your cloud provider (AWS, GCP, Azure): BAA required, HIPAA-eligible services must be explicitly enabled -
!
Your database-as-a-service: BAA required if PHI flows through it -
!
Your logging platform: BAA required if logs contain PHI -
!
Your support ticketing system: BAA required if support staff can access patient records -
!
Your analytics and monitoring tools: BAA required if PHI passes through them
If they handle PHI and won’t sign a BAA, they can’t be in your stack.
Before the hospital sends their questionnaire
The fastest way to compress the BAA process is to arrive at the first conversation already prepared. Have your own BAA template ready. Have your subprocessor list documented. Have your breach notification procedure, with specific timelines, written and tested.
When the hospital’s legal team receives a BAA from a healthtech vendor that’s clearly drafted by someone who understands HIPAA, with reasonable terms and a clear subprocessor disclosure, it moves faster through review. When they receive an obvious template with blank fields and vague language about ‘appropriate notification,’ it goes back to the vendor with a long list of questions.
Your BAA is one of the first signals hospitals receive about whether working with you will be straightforward or complicated. Make it a good signal.
Getting your BAA, subprocessor chain, breach notification procedure, and security posture in order before the first hospital conversation is exactly the kind of work Osto helps healthtech teams do, so the deal does not stall at the security and compliance gate.