Claude in Healthcare: What the BAA Actually Covers
Claude can support healthcare workflows involving PHI, but Anthropic’s BAA only applies to specific HIPAA-ready services, features and configurations. This article explains what is covered, what falls outside the BAA, and what healthcare teams should verify before using Claude with protected health information.
Anthropic provides a Business Associate Agreement for eligible HIPAA-ready Claude services, but the agreement does not automatically cover every Claude product, feature or integration.
For Claude Enterprise, Anthropic currently says the organisation’s Primary Owner must activate HIPAA compliance in the HIPAA-ready organisation settings and accept the BAA. A standard Enterprise plan does not receive BAA coverage automatically.
For Anthropic’s first-party API, the organisation must also have the appropriate BAA and have HIPAA-ready use enabled before processing protected health information.
Therefore, the useful question for a healthcare team is not:
“Does Claude have a BAA?”
It is:
“Does our BAA cover the exact Claude service, feature and data flow that will process PHI?”
That distinction is where most of the practical work begins.
What a BAA actually does
A Business Associate Agreement is not a general healthcare certification for an AI product.
Under HIPAA, a business associate can include an organisation that creates, receives, maintains or transmits protected health information on behalf of a covered entity or another business associate.
The BAA establishes what the business associate may do with PHI and requires appropriate safeguards around that information. HHS also requires relevant business-associate relationships to address subcontractors that handle PHI.
For cloud services specifically, HHS says a healthcare organisation may use a cloud provider to process ePHI when the appropriate BAA is in place and the organisation otherwise complies with HIPAA.
Additionally, HHS makes clear that the customer still needs to understand the environment, conduct its own risk analysis and establish appropriate risk-management measures.
So the BAA answers an important contractual question.
It does not answer every compliance question around the healthcare application.
What Anthropic’s BAA currently covers
Anthropic currently describes its BAA as covering its HIPAA-ready services, including eligible Claude Enterprise use and eligible use of its first-party API.
However, coverage starts at the organisation level.
For Claude Enterprise, Anthropic says:
- a Primary Owner must activate HIPAA compliance;
- the BAA must be accepted;
- coverage applies only to the organisation that accepted it;
- configuration requirements and feature limitations still apply.
In other words, buying an Enterprise plan is not, by itself, the compliance event.
The BAA and HIPAA-ready configuration are.
Claude Enterprise: the covered core features
Anthropic currently lists several Claude Enterprise capabilities as eligible under its BAA.
| Claude Enterprise feature | Published BAA status |
| Chat | Eligible |
| Projects | Eligible |
| Artifacts | Eligible |
| File creation and code execution | Eligible, excluding network access and external websites |
| Voice | Eligible |
| Web Search | Eligible |
| Research | Eligible |
| Skills | Eligible |
Anthropic also notes that coverage can depend on which version of the BAA the organisation accepted.
This detail matters.
A healthcare organisation should not rely solely on the feature currently appearing in a public eligibility table. It should compare that feature with its own executed BAA and organisation configuration.
Where the boundary becomes more complicated
The important distinction appears when Claude sends information outside the Anthropic-controlled feature.
For example, Anthropic currently marks MCPs and connectors as available, but says data sent to third parties through those features is not covered by Anthropic’s BAA.
The same warning applies to certain third-party data flows through Enterprise Search and Claude in Chrome.
Therefore, a workflow such as:
Patient information → Claude → external connector → another system
contains more than one compliance boundary.
The fact that the first step occurs inside an eligible Claude environment does not mean Anthropic’s BAA extends to the external destination.
The point often overlooked
Healthcare teams naturally evaluate the application they can see.
HIPAA analysis needs to follow the information that moves underneath it.
So, if a clinician uses a covered Claude feature but that feature passes PHI to another service, the team needs to establish what happens at that next boundary.
The BAA should follow the data path.
What about the Claude API?
Anthropic also provides a path for processing PHI through its first-party API.
However, Anthropic states that the organisation’s Primary Owner must sign the BAA and then work with Anthropic to have HIPAA-ready API use enabled.
Therefore:
An API key alone is not evidence that PHI may be processed.
The organisation and service need the appropriate healthcare configuration.
Which Claude API capabilities are covered?
Anthropic currently lists the following API services as eligible within a HIPAA-ready API organisation:
- Messages API;
- Token Counting API;
- Models API;
- Organisation Management API;
- Compliance API.
Within the Messages API, Anthropic currently identifies these capabilities as eligible:
- prompt caching;
- structured outputs;
- memory;
- web search;
- Bash tool;
- text editor tool.
Again, the key point is feature-level eligibility.
The phrase:
“We use Claude’s API.”
does not tell a compliance reviewer enough.
A more useful statement is:
“We use this API endpoint, with these features enabled, inside this HIPAA-ready organisation under this BAA.”
Some Claude API capabilities are not covered
Anthropic currently identifies several API capabilities as not covered under its BAA and not accessible to HIPAA-ready API users.
These currently include:
- Batch API;
- Files API;
- Skills API;
- Code Execution;
- Computer Use;
- Web Fetch.
External MCP is treated differently: it can be available, but Anthropic says third-party data flows through it are not covered by Anthropic’s BAA.
This is precisely why healthcare teams should review the architecture at feature level.
A BAA covering one API does not imply that every related API capability receives the same treatment.
Data retention changes the picture again
Data retention introduces another layer.
Anthropic currently states that its Covered Models require 30-day data retention and are not available with zero data retention enabled.
At the same time, some services are only eligible under the BAA when zero data retention, or ZDR, is enabled.
For example, Anthropic currently lists certain Claude Code configurations as eligible only when ZDR is enabled.
Consequently, healthcare teams may need to consider several variables together:
**Model
- feature
- product surface
- retention configuration
- executed BAA**
That is more precise than asking whether the vendor generally “supports HIPAA.”
Why the data path matters more than the model name
Consider a clinical documentation workflow:
Consultation
→ transcription
→ application backend
→ Claude
→ structured clinical note
→ database
→ EHR
Claude is only one component.
PHI may also appear in:
- application logs;
- temporary files;
- monitoring systems;
- backups;
- error reports;
- analytics;
- connectors;
- support tools.
HHS states that organisations using cloud services for ePHI still need to understand the environment and perform their own risk analysis.
Therefore, obtaining a BAA for Claude does not remove the need to map the wider PHI flow.
A BAA-covered AI endpoint cannot make an otherwise uncontrolled data path compliant.
The BAA does not establish clinical safety
Another distinction matters in healthcare.
HIPAA and the BAA primarily concern the handling and protection of health information.
They do not demonstrate that an AI-generated clinical output is accurate or clinically appropriate.
For example, a Claude-based workflow could operate within an appropriately contracted PHI environment and still require separate controls for:
- hallucinations;
- incorrect summarisation;
- omitted clinical information;
- human review;
- workflow suitability;
- validation;
- intended use.
In other words:
Privacy assurance and clinical assurance answer different questions.
A healthcare AI deployment may need both.
What a healthcare team should verify before using Claude with PHI
There are eight questions worth answering before deployment.
1. Which Claude product will receive PHI?
Enterprise chat and the first-party API do not have identical feature boundaries.
2. Has the correct organisation accepted the BAA?
Anthropic says coverage applies to the organisation that accepted it.
3. Has HIPAA-ready functionality actually been activated?
Standard Enterprise access alone does not automatically create BAA coverage.
4. Is the exact feature eligible?
Check individual features rather than assuming eligibility based on the Claude product name.
5. Does PHI move through a connector or external integration?
Third-party data flows may sit outside Anthropic’s BAA.
6. Which retention configuration applies?
Covered Models and ZDR-dependent services can have different requirements.
7. Where else is the information stored?
Logs, databases, monitoring systems and backups should form part of the PHI map.
8. Has the organisation completed its own HIPAA risk analysis?
HHS makes clear that using a cloud service with a BAA does not remove this responsibility.
What the BAA supports, and what it does not
Supported
Anthropic’s current documentation supports the following conclusions:
- qualifying Claude Enterprise organisations can activate HIPAA-ready functionality and accept Anthropic’s BAA;
- qualifying first-party API organisations can also use eligible services under a BAA;
- multiple core Enterprise features are currently listed as eligible;
- several API services and Messages API capabilities are eligible;
- some features require specific retention configurations.
Not supported
The documentation does not support these broader statements:
- “Every Claude product is HIPAA compliant.”
- “Every Claude Enterprise feature is covered by the BAA.”
- “Every Claude API capability can process PHI.”
- “A BAA makes the complete healthcare application HIPAA compliant.”
- “A BAA establishes that Claude is clinically safe.”
Those statements collapse different contractual, technical and clinical questions into one.
Where this leaves Claude in healthcare
Claude can form part of a healthcare workflow involving PHI when the appropriate BAA, eligible service and required configuration are in place.
However, the BAA applies to defined services and data paths rather than to the Claude name in general.
That leads to a practical rule:
Treat BAA coverage as a property of the workflow, not a property of the logo.
Firstly, identify where PHI enters.
Then identify which Claude service receives it.
Additionally, verify the exact features and retention settings being used.
Finally, follow the information when it leaves Claude.
If every part of that path cannot be explained, the BAA question is not finished.
KastHunt’s Approach to Using Claude in Healthcare
At KastHunt, Claude supports the healthcare workflow rather than replacing clinical judgement or governance. We treat the BAA as an important contractual safeguard, but not as the complete compliance solution. The wider architecture still needs clear controls around PHI, retention, integrations, data storage and access.
In practice, this means using Claude as an assistive language-processing layer while keeping clinicians responsible for reviewing and approving outputs. Our focus is on designing the surrounding workflow so that every data movement, system dependency and AI interaction can be understood, governed and traced.
Planning to Use Claude in a Healthcare Workflow?
Claude can support documentation and language-processing tasks, but the surrounding workflow still determines how safely and responsibly PHI is handled. Before deployment, teams should understand the BAA boundary, data flows, retention, integrations and where clinician review remains essential.
Frequently asked questions
Does Claude have a BAA for healthcare?
Anthropic provides a BAA for eligible HIPAA-ready services, including qualifying Claude Enterprise and first-party API use. The required organisation-level activation and configuration must be completed before relying on that coverage.
Is Claude Enterprise automatically covered by a BAA?
No. Anthropic says a Primary Owner must activate HIPAA compliance in the HIPAA-ready organisation and accept the BAA. Standard Enterprise plans do not automatically include BAA coverage.
Can Claude process PHI?
Eligible Claude services can process PHI when the appropriate BAA and required HIPAA-ready configuration are in place. However, the healthcare organisation retains its own HIPAA responsibilities.
Does the BAA cover Claude Web Search?
Anthropic currently lists Web Search as an eligible Claude Enterprise feature and as an eligible Messages API feature under applicable BAA versions. Organisations should still confirm their own executed BAA.
Are Claude connectors covered?
The distinction is important. MCPs and connectors may be available, but Anthropic says data sent to third parties through them is not covered by its BAA. Those external data flows therefore need separate assessment.
Is the Claude Files API covered?
No. Anthropic currently lists the Files API as not covered under its BAA and unavailable to HIPAA-ready API users. This shows why coverage should be checked at feature level.
Is the Messages API covered?
Yes. Anthropic lists the Messages API as an eligible service, but only specified capabilities within it are covered. Teams should verify the exact features used in their workflow.
Does zero data retention automatically make Claude HIPAA compliant?
No. ZDR is required for some BAA-eligible configurations, but it does not replace the BAA or the healthcare organisation’s own HIPAA safeguards and risk-management responsibilities.
Does signing Anthropic’s BAA make our application HIPAA compliant?
No. The BAA covers the relationship with Anthropic for eligible services. The healthcare organisation must still conduct risk analysis, implement safeguards and assess the complete PHI data flow.
Does the BAA mean Claude outputs are clinically safe?
No. The BAA concerns PHI handling and contractual obligations. Clinical accuracy, validation, hallucination risk, human oversight and patient safety require separate evaluation.
About the author
Kamna Singh Thakur is CEO and Founder of KastHunt, an AI-native healthcare technology firm serving clinics, healthtech founders and health systems across the UK, US, CA, AU, UAE and Australia. She has spent nine years in healthcare technology across business development, account management and digital transformation, and grew up in a clinical household — her mother, Leela Verma, spent 40 years in frontline nursing, medicine and behavioural health, including NHS service.
She writes about clinical AI governance, healthcare product delivery, and what actually survives deployment in a real clinical environment.
Questions or corrections: info@kasthunt.com
Sources
- Anthropic — Business Associate Agreements for Commercial Customers — current Claude Enterprise, API, feature and BAA coverage requirements.
- US Department of Health and Human Services — Guidance on HIPAA & Cloud Computing — cloud-provider business-associate status, BAA requirements and customer risk-analysis responsibilities.
- US Department of Health and Human Services — Business Associates — current requirements for BAAs and business-associate subcontractors.
- US Department of Health and Human Services — Business Associate Contracts — required concepts and sample BAA provisions.
