Claude Team and HIPAA: What to Check Before Use

Claude Team is not the HIPAA-ready Claude offering: Anthropic says Team plans cannot enable HIPAA↗ (opens in a new tab). Before using Claude with protected health information (PHI), meaning identifiable health information protected by HIPAA, your organization needs to verify the eligible service, applicable agreement, configuration and approved workflow.

You can use fenbs to record nonclinical policy decisions and follow-up review tasks, keeping patient information out of that record. The useful starting point is a clear question: what exact work is approved, with which data, in which account?

Does a team subscription authorize patient-data use?

No. A shared subscription is not evidence of HIPAA approval. Anthropic distinguishes Team from its HIPAA-ready Enterprise offering, and even an Enterprise subscription needs the required agreement and activation. Do not enter PHI while those checks are unresolved, or assume that a colleague using the same model has the same coverage.

Ask your administrator to identify the actual organization and service you would use. Keep ordinary purchasing questions in the Claude Team plan guide and the Enterprise versus Team comparison; this review concerns permission to handle specific information.

What must the agreement cover?

A business associate agreement (BAA) sets contractual responsibilities for a service handling PHI on an organization’s behalf. HHS cloud guidance↗ (opens in a new tab) explains that covered entities and business associates need an appropriate BAA with a cloud provider processing electronic PHI for them, alongside compliance with the other HIPAA requirements. A contract alone does not complete that work.

• Match the agreement to your legal entity, account and intended service. Ask the contract reviewer to confirm that it is in effect.
• Check the permitted uses, required safeguards, retention terms and incident-reporting responsibilities against the proposed workflow.
• Identify the features and configurations included in coverage. Keep unresolved exclusions visible rather than treating silence as approval.
• Ask who can approve changes if the team adds another service or changes the information it sends.

Treat these as questions for your privacy, security and contract reviewers. A model-training setting or an encryption control cannot replace this contract-and-workflow review. Keep the agreement itself in your organization’s approved contract repository.

Which information belongs in the proposed workflow?

Define the inputs before testing. “Healthcare work” is too broad: drafting a public hiring notice is different from summarizing an identifiable patient’s appointment. Administrative information can contain PHI too, so calling work nonclinical does not settle the data question.

Removing a name is not enough to establish de-identification. HHS describes two methods↗ (opens in a new tab): Expert Determination, involving a qualified expert’s assessment, and Safe Harbor, requiring removal of specified identifiers and no actual knowledge that the remaining information can identify someone. Do not upload PHI to an unapproved service just to ask it to anonymize the data.

What should your organization approve before a pilot?

Give reviewers a narrow proposal they can accept, reject or return with questions. For example, propose drafting a staff training outline from public guidance using an empty template. State explicitly that patient examples, screenshots and production exports are excluded from that pilot.

• Purpose: the specific task and why an AI assistant is useful.
• Data: allowed sources, prohibited information and who checks inputs.
• Access: the approved account, participating staff and enabled connections.
• Review: who checks outputs before anyone relies on or distributes them.
• Operations: retention expectations, staff instructions and the route for reporting an accidental disclosure.

Keep the pilot’s approval separate from permission for future clinical work. For shared project setup, see Claude Projects for teams. Record the human-approved boundaries in fenbs Decisions and rules, using only nonclinical policy information.

What changes when Claude connects to another tool?

A connection creates another place to examine. Anthropic’s BAA guidance↗ (opens in a new tab) says coverage applies to the organization that accepted the agreement and has feature-specific exclusions. Sending data to third parties through connectors is not covered by Anthropic’s BAA. Do not transfer approval from one account, service or feature to another.

Sketch the route before enabling a connection: where information starts, what Claude receives, what the outside service receives and where outputs go. Ask the reviewers to assess each destination and any required agreements. Include exports and copied responses, since a staff member can move sensitive information without enabling a connector.

Keep team collaboration procedures separate from this approval: a convenient way to share work does not establish permission to share patient information.

What should the policy record say?

Write the outcome so another staff member can tell what remains prohibited. A hypothetical decision could approve only a public-source training pilot, name the approved account and require another review before introducing internal data. Include who decided, the reason, the review date and the questions still open.

In fenbs, people make decisions; assistants can record what those people chose. History records changes and who made them, which helps explain why a policy changed. It does not establish HIPAA compliance or prove that staff followed the policy. Keep patient details and clinical incident evidence in your approved healthcare systems, outside fenbs.

How to do this with fenbs

1. Create a free account. Use your personal kanban board to try a review using only public or invented policy examples; one person is free, with no credit card.
2. Add a project for the AI-use policy review. Describe the proposed nonclinical workflow without patient details, clinical files or sensitive account information.
3. Add tasks for the outstanding plan, agreement, configuration and organizational checks. Write what evidence the responsible reviewer still needs.
4. Record the person’s actual approval or refusal in Decisions and rules. Leave unanswered questions open, and save Where we left off so the next session knows what is waiting on a person.

fenbs is not the right fit for storing patient records or processing PHI. Use it for the nonclinical work of keeping decisions and review tasks clear, subject to your organization’s approval of that use.

When should you reopen the review?

HHS risk-analysis guidance↗ (opens in a new tab) describes risk analysis as an ongoing process that considers where electronic PHI is created, received, maintained or transmitted. Set review triggers for a changed service, feature, connection, data source or purpose. A previous approval should not silently expand when a pilot grows.

Before that change, return to the exact account, agreement and workflow. If coverage is uncertain, pause PHI use and ask the responsible reviewer. The AI governance hub covers the wider work of keeping AI use accountable; start here with one explicit, documented boundary.