What Is a BAA? Business Associate Agreements for Engineers

Most engineers meet the BAA at an awkward moment: late in a procurement review, as a document to be signed before launch. It is easier to reason about earlier, as an interface contract with regulatory penalties attached.

Here is the mental model, the definitions, and the parts that actually matter when you are the one sending the data.

Who counts as a business associate

HIPAA defines a business associate in 45 CFR 160.103. Stripped of the statutory language, it is a person or entity that creates, receives, maintains, or transmits protected health information to perform a function on a covered entity's behalf.

The definition names the functions explicitly, and "data analysis, processing or administration" is in the list. An inference provider is plainly a business associate. So is a transcription vendor, a billing service, and a data pipeline that handles PHI.

Two extensions catch people out:

• Subcontractors are business associates too. A vendor that engages another company to handle PHI on its behalf creates a business-associate relationship with that subcontractor. The chain extends.
• A covered entity can be a business associate of another covered entity. The roles are defined by the relationship, not by the organization type.

When you actually need one

The rule is at 45 CFR 164.502(e). A covered entity may disclose PHI to a business associate only if it "obtains satisfactory assurance that the business associate will appropriately safeguard the information." That assurance must be documented in writing.

So the trigger is not "we signed a contract with a vendor." The trigger is "this vendor will touch PHI." A vendor that never sees PHI needs no BAA. A vendor that sees it needs one before the first request, not after the pilot.

The same logic flows down: a business associate may disclose PHI to a subcontractor only if it obtains the same assurances, with the same requirements applied.

What the agreement actually obliges

The regulation sets out the required terms at 45 CFR 164.504(e)(2). The shape of it is worth internalizing:

• Permitted uses and disclosures are enumerated. The vendor may use PHI for what the contract says and nothing else.
• Safeguards are required, including Security Rule compliance for electronic PHI.
• Breach reporting is required - the vendor must tell you about unauthorized uses and disclosures it becomes aware of.
• Individual rights are supported - access, amendment, and an accounting of disclosures.
• Subcontractors must be bound to the same terms.
• Records must be available to HHS for compliance review.
• PHI must be returned or destroyed at termination, or the protections extended and further use limited if destruction is not feasible.
• You can terminate if the vendor violates a material term.

For the procurement version of this list, including the questions to ask a vendor, see What to Demand From a Vendor.

The question to ask yourself early

Before you evaluate any vendor, answer one thing: will this system ever process information about a real patient - including in a pilot, and including in a test environment that had production data copied into it?

Test environments are where agreements are most often found to be missing, because the data came from production and nobody revisited the vendor list when the environment was stood up. A staging database with real records and a third-party logging tool is an unauthorized disclosure, regardless of intent.

The liability model, which is the point

Here is why the BAA is not a formality. HHS states that a business associate "is directly liable under the HIPAA Rules and subject to civil and, in some cases, criminal penalties for making uses and disclosures of protected health information that are not authorized by its contract or required by law."

Directly liable. Not liable only through your contract with them.

That changes the engineering conversation in two ways. First, the vendor has its own regulatory exposure and therefore its own reason to enforce the constraints - which is a better guarantee than goodwill. Second, your exposure does not disappear because a vendor promised something; you still have obligations around the safeguards you control.

What happens without one

Without a documented agreement, the disclosure is not permitted in the first place. Period. Sending PHI to a vendor that has not signed a BAA is not a paperwork gap you can close retroactively; it is an unauthorized disclosure during the timeframe it occurred.

This is the practical reason the phrase "we're HIPAA compliant" on a marketing page is not an answer. The question is whether an executed agreement exists, what it covers, and which endpoints and subprocessors are inside its scope.

The engineering summary

• A BAA is a precondition, not an optimization. You need it before PHI flows, not after.
• Scope is the thing to verify. Which products, which endpoints, which subprocessors, which retention posture.
• It does not make you compliant. It makes the disclosure permitted. Your safeguards, access controls, and audit trail are the rest.
• It binds both directions. The vendor takes on real obligations, and so do you.

The HIPAA compliance guide walks through the broader control set, and Zero Data Retention covers the retention question that sits alongside it.

OpenMed Router signs a BAA covering inference across the open-weight model catalog, with zero-retention isolated inference and AES-256 encryption in transit and at rest. Proprietary models are coming soon.

Need the agreement in place before you build? Join the waitlist.