Match PHI flows to covered services

Learning objective

Map HIPAA protected-health-information flows to contractually covered, eligible services and configurations.

Core idea

A signed business associate agreement (BAA) is necessary for an applicable business-associate relationship, but it does not make every product, feature, or connected tool eligible for protected health information (PHI). Trace each disclosure to the service and configuration that actually receives it, then confirm the contract covers that use.

The U.S. Department of Health and Human Services (HHS) explains that a cloud provider creating, receiving, maintaining, or transmitting electronic PHI on behalf of a covered entity or business associate is itself a business associate. This includes a provider storing encrypted information without the decryption key. Encryption does not remove the relationship or replace the BAA. The organization’s compliance and legal owners determine HIPAA applicability and approve contractual coverage; the architect makes the approved flow enforceable.

How it works

Inventory recipients, including operational systems

Follow clinical information through transcription, prompt assembly, inference, returned drafts, clinician review, and storage. Add observability vendors, support tickets, evaluation datasets, and tool backends. For each recipient, record the operator, exact service, data received, BAA or other applicable contractual basis, approved configuration, retention, and owner.

A log containing a patient’s condition and identifier remains a PHI flow even if the application calls it telemetry. Removing a name does not establish that a clinical narrative is de-identified. If the team cannot establish that a recipient is permitted to receive the remaining data, exclude that recipient from the flow rather than asking the model to conceal the disclosure in its answer.

HHS cloud guidance calls for risk analysis and risk management alongside a BAA. The service inventory supports that analysis; it is not an attestation of compliance by itself. Keep the data-flow inventory and approved service/configuration list as controlled team artifacts, using the ownership method in 5.4.1.

Enable the Claude API arrangement that covers PHI

Anthropic documents HIPAA readiness for eligible Claude API features at api.anthropic.com. Eligible organizations can enable it through the HIPAA compliance card on the Claude Console Data retention page (platform.claude.com/settings/privacy); organization admins need the HIPAA management permission. An authorized legal representative reviews and executes the standard BAA; organizations needing negotiated terms or lacking self-service eligibility contact sales. Enablement is bound to the downloaded BAA version and is permanent at the organization level.

Keep the executed BAA version and organization identity in the approved service record. Use separate organizations for HIPAA-ready and general-purpose API access where both are needed. Do not route an ineligible request through another organization’s credentials to make an error disappear.

HIPAA readiness and zero data retention (ZDR) answer different questions. Anthropic states that HIPAA-ready access supplies safeguards across the PHI lifecycle and does not also require ZDR. ZDR concerns retention after the API response and has its own eligibility conditions. Neither arrangement removes the need to govern copies in your systems.

Review features, not only the endpoint

The feature-eligibility table documents these relevant distinctions:

Most noneligible requests return HTTP 400 with error.type: "invalid_request_error". The error identifies the unavailable features; remove them and retry an eligible design. The browser-use exception demonstrates why successful API acceptance is insufficient: the documented client-side tool remains outside HIPAA readiness. External tools and services also remain outside Anthropic’s arrangement and need their own assessment.

Most noneligible requests fail with an error, but a browser-use request is not automatically blocked, so acceptance is not coverage.

For structured outputs, the API compiles schemas into separately cached grammars. Anthropic explicitly prohibits PHI in property names, enum, const, and pattern values. Use generic schema vocabulary and put patient-specific values in message content. A patient name used as an enum value creates a distinct disclosure even when the surrounding Messages call is eligible.

Match the contract to the deployment platform

The Claude API arrangement does not cover partner-operated Amazon Bedrock or Google Cloud’s Agent Platform; those platforms require their own compliance documentation and terms. Anthropic also states that HIPAA readiness is unavailable on Claude Platform on AWS and Microsoft Foundry. Purchasing through AWS is therefore insufficient to establish the arrangement described here.

The same documentation excludes Claude Code, consumer plans, PHI processing through the Console interface, and third-party integrations from this Claude API coverage. Enabling the organization through Console settings is supported; entering PHI into the Console interface is a different activity. Beta features are generally excluded unless explicitly listed as eligible. Recheck the chosen feature and contract before enabling it in a PHI workload.

Apply minimization with the correct qualification

HHS describes the minimum necessary standard under 45 CFR §§ 164.502(b) and 164.514(d): generally limit uses, disclosures, and requests to what the purpose requires. It also lists exceptions, including disclosures to or requests by a healthcare provider for treatment. Do not teach “minimum necessary applies to every disclosure” as an unconditional rule.

Have the privacy owner determine the applicable rule for the flow. Where minimization is required or adopted as a design safeguard, implement field selection and free-text screening before transmission. Clinical usefulness and contractual eligibility remain separate checks: removing unnecessary identifiers does not permit an otherwise ineligible service to receive the remaining PHI.

Key distinctions and trade-offs

Contract versus configuration: The BAA defines coverage; organization enablement and feature restrictions help enforce it. Keep both in the service record.

Eligibility versus availability: A feature can exist and accept a request while remaining outside HIPAA readiness. The browser-use exception makes application enforcement necessary.

Synchronous cost versus batch savings: A cheaper or operationally convenient API is unsuitable if the PHI flow is outside its documented eligibility. Redesign the scheduling around an eligible inference path instead of changing credentials.

Architecture / decision scenario

A healthcare network needs 12,000 overnight care-management draft summaries by 06. A team proposes Message Batches and a browser tool that reads patient portals. The organization has executed Anthropic’s BAA and enabled HIPAA readiness, but the two proposed features are not eligible.

The architect selects a customer-operated scheduler making eligible /v1/messages calls, with capacity and deadline testing before launch. The application blocks the browser tool and uses the network’s approved clinical-data integration. The privacy officer approves recipient coverage and the minimization rule; the platform owner verifies the enabled organization and allowed features. If capacity cannot meet the deadline, the team reduces the initial cohort rather than moving PHI to the Batch API.

Generic output schemas contain no patient names in enum values. Protected message content carries the necessary clinical facts. The service inventory includes the scheduler, integration, model route, summary store, and observability system; each recipient has a documented contractual decision and configuration. The BAA for inference cannot cover an unrelated telemetry vendor.

Common exam traps

• Treating encryption or ZDR as a substitute for a BAA.
• Assuming all features of an enabled organization are covered because a request succeeds.
• Putting PHI in schema definitions or support tickets.
• Assuming Anthropic’s arrangement transfers to every platform selling Claude.
• Stating minimum necessary without its treatment and other exceptions.

What to remember

Map each PHI recipient to an approved contract, service, feature, and configuration. For the Claude API, use a HIPAA-enabled organization and eligible features, keeping PHI outside schemas and uncovered tools. Coverage and minimization need separate decisions, and the compliance determination belongs to the organization’s compliance and legal owners.

Knowledge check

References

• U.S. Department of Health and Human Services, Guidance on HIPAA & Cloud Computing
• U.S. Department of Health and Human Services, Minimum Necessary Requirement
• Anthropic, API and data retention