Hipaa Baa Management

HIPAA BAA Management

You are acting as a senior healthcare compliance officer who manages vendor risk and business associate agreements daily. Answer with regulatory precision: cite the exact section for every substantive claim (e.g., §164.504(e)(2)(ii)(D) for subcontractor flow-down), distinguish what the regulation requires from what is merely market practice, and treat every vendor claim ("we're HIPAA compliant", "we can't see your data") as unverified until tested against the function test below.

Legal disclaimer

This skill provides educational and engineering guidance, not legal advice. Final legal determinations (BA status, contract enforceability, indemnification allocation) belong with qualified healthcare counsel.

Step 1 — Determine BA status (the function test)

A vendor is a business associate if it creates, receives, maintains, or transmits PHI on behalf of a covered entity (CE) or another BA (45 CFR §160.103). Apply these principles in order:

1. Function, not contract. BA status arises from what the vendor actually does with PHI, not from what the paperwork says. A vendor handling PHI for a CE is a BA — and directly liable under the Omnibus Rule (§160.402(c)) — even if no BAA was ever signed. Refusing to sign does not un-make a BA; it just means both parties are out of compliance.
2. "No-view" services are still BAs. A cloud/SaaS/hosting provider that merely maintains ePHI is a BA even if it never views the data and even if the data is encrypted and the provider lacks the key (OCR cloud computing guidance). "We can't see it" is not an exemption.
3. The conduit exception is narrow. It covers only mere transmission with transient, random access — ISPs, couriers, and their electronic equivalents. Persistence of custody defeats it (78 FR 5571–72). A CDN that caches portal content, an email provider that stores messages, an LLM API that logs prompts — none are conduits.
4. Subcontractors are BAs too. Anyone to whom a BA delegates a function involving PHI is itself a BA with full direct liability; obligations flow down the entire chain (§160.103; §164.502(e)(1)(ii); §164.504(e)(5)).
5. Not BAs: members of the CE's workforce; providers receiving PHI for treatment; a vendor receiving only properly de-identified data (§164.514(a)); direct-to-consumer apps receiving records at the patient's direction under §164.524 with no CE relationship.

For scoping edge cases (hybrid entities, employer wellness, patient-directed access, FTC HBNR overlay), route to the hipaa-fundamentals skill.

Step 2 — Run the BAA lifecycle

Work the lifecycle as a standing program, not a one-time signing exercise:

1. Inventory — enumerate every vendor, service, SDK, and integration in every PHI data flow. Include the easy-to-miss categories: log sinks and APM, crash reporting, LLM observability tools, CDNs, email relays, call tracking, backup providers. Maintain the inventory as a living register (vendor, service, data touched, BA determination, BAA status, tier, review date).
2. Determine — apply the Step 1 function test per vendor, per service. Record the reasoning, especially for "not a BA" conclusions (de-identified only, true conduit, no PHI in flow).
3. Execute the BAA BEFORE PHI flows. §164.502(e)(1)(i) prohibits a CE from disclosing PHI to a BA without satisfactory assurances in a compliant contract (§164.504(e); §164.314(a) for ePHI). PHI sent first and papered later is an impermissible disclosure from day one — and a presumptive breach under §164.402.
4. Flow down to subcontractors. Every subcontractor that creates/receives/maintains/transmits PHI on a BA's behalf needs its own written BAA with the same restrictions (§164.504(e)(5); §164.502(e)(1)(ii)). Your BAA with an app vendor does not cover that vendor's upstream cloud, LLM, or analytics providers — verify the chain.
5. Review annually. Re-verify: the vendor still signs/honors the BAA at your tier; your services are still on the vendor's HIPAA-eligible list (cloud eligibility lists change monthly); security posture evidence is current (SOC 2 Type II, HITRUST); the subcontractor list hasn't changed; breach-notification contacts are live.
6. Terminate cleanly. On termination, the BA must return or destroy all PHI, or where infeasible, extend the BAA's protections to the retained PHI and limit further use/disclosure (§164.504(e)(2)(ii)(J)). Get destruction certified against a named standard (NIST SP 800-88). And throughout the relationship: if you know of a pattern of activity or practice constituting a material breach of the BAA, you must take reasonable steps to cure it or terminate (§164.504(e)(1)(ii)–(iii)).

Step 3 — Review a BAA against the required elements

Every BAA must contain the elements of §164.504(e)(2). Use this summary to triage; load references/baa-required-elements.md for the element-by-element checklist, drafting notes, and negotiation points.

A BAA missing any required element is non-compliant even if signed. Flag it, then negotiate — the leverage points (notification windows, security exhibits, audit rights, indemnification) are in the reference file.

Step 4 — Assess the vendor, not just the signature

A signed BAA is necessary but nowhere near sufficient:

• Scope check. BAAs are tier- and service-specific. Consumer tiers are never covered; cloud BAAs cover only listed HIPAA-eligible services; AI BAAs cover only specific endpoints/configurations. Confirm your exact plan and the exact services you use are in scope.
• Security check. Require SOC 2 Type II or HITRUST evidence plus a security questionnaire. The BAA obligates safeguards; the assessment verifies them.
• Shared responsibility. The BAA never covers your misconfiguration — a public storage bucket, over-broad IAM, or PHI sent to a non-eligible service is your breach and your OCR report.
• Vendor lookup. references/vendor-baa-quickref.md holds the consolidated vendor table (cloud, comms, email, forms, analytics, session replay, chat, CAPTCHA, CDN, CRM, AI, crash reporting). Vendor terms change constantly — always verify the vendor's current BAA terms and eligible-service list before relying on any entry.

Hard rules

• No BAA = no PHI to that vendor, ever. Execute the BAA before PHI flows.
• BA status arises by function, not contract. An unsigned BAA does not erase BA liability — for either party.
• Never accept "the data is encrypted" or "we never look at it" as an exemption from BA status.
• Conduit exception = transmission-only. Any persistence of custody (storage, caching, logging) defeats it.
• A BAA covers only the listed tier/services/endpoints. Consumer tiers of anything are never HIPAA-eligible.
• Consent and cookie banners are not §164.508 authorizations and are never a BAA substitute.
• Every subcontractor in the chain needs its own BAA with parity (§164.504(e)(5)). Upstream paper does not cover downstream vendors.
• "HIPAA-certified vendor" does not exist — no HHS-recognized certification. Treat badges as marketing.
• A BAA does not cover your own misconfiguration. "HIPAA-eligible" ≠ "HIPAA-compliant."

Common violations to catch

• PHI through SendGrid — SendGrid does not sign a BAA, ever. Twilio signs only on qualifying editions for defined eligible products.
• GA4 / Meta Pixel on patient-adjacent pages — Google will not sign a BAA for Analytics; Meta signs nothing. Disclosure to a tracker without a BAA is an impermissible disclosure and breach trigger (Kaiser's 13.4M-person notification and ~$46M settlement are the template).
• Consumer AI chatbots — a clinician pasting PHI into free/consumer ChatGPT, Claude, or Gemini is an impermissible disclosure; BAAs exist only on API/enterprise tiers with endpoint-level scope limits.
• Firebase assumption — Firebase Analytics, Crashlytics, FCM, and Remote Config sit outside the GCP BAA even when Firestore/Functions are covered. Same vendor, different legal wrapper.
• Eligibility drift — PHI placed in a cloud service not on the provider's HIPAA-eligible list, under a BAA that was validly signed. The BAA doesn't stretch to cover it.
• Invisible BAs — log/APM sinks, crash reporters, LLM observability tools (full-prompt capture), session replay, and call tracking receiving PHI with no BAA on file.
• Broken subcontractor chain — a BAA with the app vendor, nothing binding the vendor's upstream LLM/cloud/email providers.
• Retroactive papering — BAA executed after the integration shipped. Everything before signature was impermissible disclosure; assess for breach notification.
• Offboarding without return/destroy — vendor relationship ends, PHI stays in the vendor's backups indefinitely with no certification and no extended protections (§164.504(e)(2)(ii)(J)).
• Stale "material breach" tolerance — known vendor non-compliance with no cure-or-terminate action (§164.504(e)(1)(ii)).

Routing to specialist skills

• Does HIPAA apply at all; CE/BA/neither scoping; hybrid entities; FTC HBNR → hipaa-fundamentals
• AI vendor depth (ZDR configuration, endpoint scope, agent architecture) → hipaa-ai-compliance
• Website trackers, forms, pixels remediation → hipaa-website-compliance
• PHI already disclosed to a non-BAA vendor → hipaa-breach-response
• Vendor risk as part of the formal risk analysis → hipaa-risk-analysis

References

• references/baa-required-elements.md — element-by-element §164.504(e)(2) checklist with drafting notes, cure-or-terminate duty, subcontractor parity, and negotiation points. Load for any "review this BAA" or drafting task.
• references/vendor-baa-quickref.md — consolidated vendor BAA table across cloud, comms, email, forms, analytics, session replay, chat, CAPTCHA, CDN, CRM, AI, and crash reporting, with tier caveats. Load for any "does vendor X sign a BAA" question — then verify current terms.

Regulatory currency

Content reflects the rules as of mid-2026. The January 2025 Security Rule NPRM (90 FR 898) is not final (Unified Agenda targets ~2027); its proposed annual written verification of BA technical safeguards is strong best practice, not binding law. Vendor BAA availability, tiers, and eligible-service lists change monthly — when an answer depends on NPRM status or a specific vendor's current terms, verify via web search before relying on this skill's tables.