Claude and HIPAA: what a BAA covers (and what it doesn't)

Note: this article explains the general HIPAA framework as it applies to building with Claude. It is not legal advice and does not assess whether your specific application or configuration is compliant. Any determination about your organization’s HIPAA obligations should be made by your compliance and legal counsel.

According to Anthropic’s published documentation, a Business Associate Agreement is available for the Claude API under HIPAA-ready configurations. For healthcare teams evaluating Claude for clinical AI, this is meaningful — and it’s easy to misread what it actually means for compliance.

The short version: a BAA is necessary, and it’s not sufficient. Here’s the distinction that matters.

What Anthropic’s documentation says the BAA covers

When you sign a BAA with Anthropic and access Claude through a HIPAA-ready configuration, Anthropic becomes your business associate under HIPAA. This creates contractual obligations: they must handle PHI in accordance with the regulation, report breaches, and restrict use to the purposes specified in the agreement.

According to Anthropic’s guidance, covered models are retained for a defined period on the platform, historically described as around 30 days — this kind of detail changes over time and should be reverified rather than assumed. Whatever the current figure, the point is the same: the BAA governs what the provider can do with that data, but the data is present on their systems for that window.

One detail worth reading carefully: according to Anthropic’s published documentation, zero data retention (ZDR) and BAA coverage pull against each other — and the constraint runs in both directions depending on the product.

Covered Models require a retention window and are not available with ZDR enabled. But some services work the opposite way: Claude Code is covered under the BAA only when ZDR is enabled, which in turn rules out using Covered Models under that BAA.

So it is not simply “ZDR or BAA, pick one”. It is a per-product constraint, and getting it backwards means assuming coverage you do not have. Check which side of it your specific configuration falls on.

What a BAA does not cover

A BAA is a contract between you and the provider. It does not:

• Prevent PHI from being transmitted — patient names, diagnoses, and identifiers in your prompts travel to the provider’s infrastructure, BAA or not
• Implement technical safeguards for you — HIPAA’s Security Rule requires access controls, audit logs, and transmission security. These are your responsibility
• Apply to your application’s logic — if your code logs prompts, stores them in a database, or forwards them to another service, the BAA is irrelevant to those flows
• Cover subprocessors automatically — most providers use infrastructure vendors of their own, and a BAA does not automatically extend to every system in that stack — verify this specifically rather than assuming coverage

The minimum necessary standard still applies. Even with a BAA, HIPAA requires you to think carefully about what PHI actually needs to be in the prompt, and whether you have legal standing to transmit each piece of it.

The ZDR tension

If that ZDR/BAA incompatibility is accurate for your configuration, here’s the tension it creates for security-conscious teams: the strongest data minimization posture (ZDR) may be incompatible with BAA coverage. You could effectively have one or the other, not both.

This isn’t necessarily a criticism of any one provider — it can reflect a genuine architectural constraint, since providing BAA-backed breach reporting typically requires retaining data long enough to investigate an incident. But it means that teams who want both maximum privacy and BAA coverage may need a different architectural approach.

The alternative: prevent before transmit

The most robust approach doesn’t depend on which provider you use or whether they have a BAA. It operates at the architecture layer: PHI is tokenized before the prompt leaves your network.

When your application routes through an inference proxy that applies reversible pseudonymization at the edge:

• Names become [PERSON_1]
• Medical record numbers become [MRN_1]
• SSNs become [SSN_1]
• Diagnoses tied to individuals become [CONDITION_1]

The model — Claude, GPT, or any other — receives anonymized tokens. It reasons over the structure. Your system rehydrates the response with real values on the return path, in your infrastructure, before the user sees it.

The result: Anthropic (or any provider) never receives identifiable PHI. Whatever the retention window that applies, it retains tokens, not patient data. The ZDR/BAA tension disappears, because there’s no PHI to retain in the first place.

The BAA still matters — it’s a legal requirement and provides breach notification coverage. But it becomes a secondary safeguard over a system where PHI leakage is architecturally prevented, not a primary compliance mechanism.

---

This is the principle behind Privedge: a single-line drop-in for any LLM SDK that tokenizes PHI at the Cloudflare edge before any external API call. Claude, OpenAI, Gemini — the provider’s BAA status becomes less critical when identifiable data never reaches them.

// Before — PHI reaches Claude verbatim
import Anthropic from '@anthropic-ai/sdk'
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_KEY })

// After — PHI anonymized at the edge before transmission
import Privedge from '@privedge/sdk'
const ai = new Privedge({
  apiKey:    process.env.PRIVEDGE_KEY,
  workerUrl: 'https://edge.privedge.io',
})

const res = await ai.chat.completions.create({
  model:        'claude-sonnet-4-6',
  messages:     [{ role: 'user', content: prompt }],
  pii_strategy: 'anonymize',
})

Your existing code doesn’t change. What changes is that "Summarize treatment plan for John Smith (SSN 123-45-6789)" becomes "Summarize treatment plan for [PERSON_1] (SSN [SSN_1])" before it reaches any provider — BAA or not.

---

What this means in practice

If you’re evaluating Claude for healthcare AI, the right framing isn’t “does Anthropic have a BAA?” It’s:

1. What PHI actually needs to reach the model? In most clinical AI use cases, the model needs clinical context — not patient identifiers. These are separable.
2. What happens to the data that does reach the model? Under a BAA, the provider retains it for whatever window their current terms specify. Under ZDR, BAA-covered models may not be available. Under an architectural proxy, there’s no identifiable data to retain.
3. What are your audit trail obligations? HIPAA requires you to demonstrate what PHI was accessed and by whom. An inference proxy that logs metadata (not prompt content) provides this without retaining clinical data.

A BAA from any provider, Anthropic included, is a step in the right direction for the healthcare AI ecosystem. It’s also a reminder that the hard part of HIPAA compliance isn’t finding a provider who will sign a BAA — it’s building an application where the right data reaches the right system, and nothing more.

If you want an architectural approach to HIPAA that works with Claude, GPT, or any future model — without your compliance posture depending on any single vendor’s current BAA terms — Privedge is the starting point.