HIPAA & Patient Privacy

Detail

Do not rule yourself out — on either path.

The API path is self-serve too. “There are two ways to set up HIPAA-ready API access. Most organizations can enable it directly in the Claude Console with Anthropic’s standard BAA; organizations that require a negotiated BAA should work with their account team.” The mechanics: “In Claude Console > Settings > Privacy, organization admins with the HIPAA management permission see a HIPAA compliance card.” For a small technical team — plausibly the cheapest compliant route for a registry project — this matters as much as the Enterprise correction below.

Two API-path facts worth deciding on early:

• You do not need ZDR as well. “Do I still need ZDR if I have HIPAA readiness? No.” HIPAA readiness “applies a broader set of privacy and security safeguards than ZDR … rather than requiring immediate deletion.”
• HIPAA is enforced org-wide, so mixed workloads need two orgs. “HIPAA readiness is enforced at the organization level. If you need both HIPAA-ready and general-purpose API access, use separate organizations for each.” Decide this before you build, not after.

Now the Enterprise path. The source’s own eligibility banner reads: “This feature is available for Enterprise plans only (both self-serve and sales-assisted).” And on getting started: “Eligible Enterprise organizations can enable HIPAA-ready configuration directly from organization settings—no sales or legal cycle required. The Business Associate Agreement (BAA) is included in the flow as click-to-accept, so there’s no separate document to sign and return.”

Who can do it. “Only the Primary Owner of the organization can accept the BAA and enable HIPAA. Other Owners or Admins can’t complete this flow on the org’s behalf.” If you are an admin but not the Primary Owner, the source’s instruction is to ask your Primary Owner to sign in and complete enablement.

Who cannot. “You can enable the HIPAA configuration from organization settings if your organization is on an Enterprise plan. Team plans and individual plans (Free, Pro, and Max) can’t enable HIPAA.” See Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call.

Two things to know before you click — both are one-way.

• “Enabling HIPAA resets certain settings across your organization. Some configurations return to defaults as part of the transition to a HIPAA-ready state.” The onboarding modal and the Implementation Guide detail what changes.
• “This is a one-way decision. Once HIPAA is enabled and the BAA is accepted, the change can’t be reversed from organization settings.” The source requires reviewing the BAA and the Implementation Guide before accepting, “as this is an irreversible organization transition.” Note also: “The BAA offered through the self-serve flow is a standard agreement and can’t be modified.”

If you already have an API BAA — check the date. “If your organization signed a BAA for Claude API usage before December 2, 2025, that agreement only covers API usage—it does not extend to the HIPAA-ready Enterprise plan. To add this Enterprise plan access, you’ll need to sign a new BAA with your account team.” And: “BAAs signed after December 2, 2025 can cover both API usage and the Enterprise plan under a single agreement.” An org that signed early and assumes it is covered on both surfaces is not.

Coverage is still not automatic on the right plan — the enablement path must be walked (HIPAA coverage must be actively enabled — an Enterprise contract alone is not a BAA) — and enabling HIPAA does not sweep every feature under the BAA (Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered, Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call). Which configuration fits an advocacy nonprofit’s needs and budget is the group’s first question in this domain: Which BAA configuration fits an advocacy nonprofit's needs. (Scoped at CG4. This read “the group’s first question for the contact” — as did the retention module’s pointer to a different question. Two nodes each claiming the register’s top slot cannot both be right. The register now carries an explicit per-module order: this question leads the HIPAA list, and the plan-and-terms question leads retention’s. Neither claims to outrank the other across the whole register, because the register groups by module and nothing in it can make that claim true.)

Source & currency

• Source: HIPAA-ready Enterprise plans — Claude Help Center (Enterprise path) · API and data retention — Claude Docs (API path, ZDR-not-also-needed, org-level enforcement).
• Status: CONFIRMED — re-verified 2026-08-03 (receipts R62, R63) — every quoted passage on both pages verified verbatim on the live sources 2026-08-03, in the mandated currency re-check before the wording fix recorded next. Hedge restored 2026-08-03 (CG7): the plain-language takeaway (and the HIPAA domain page’s one-pager gloss, corrected in the same act) had flattened the API path’s own hedge — “Most organizations can enable it directly … organizations that require a negotiated BAA should work with their account team” — into “no sales call needed,” an error in the permissive direction: it invites an organization that does need its account team to rely on self-serve. The source sentence was unchanged on the 2026-08-03 fetch; only our summary had drifted. This is the mirror image of the 2026-07-25 corrections below, which erred restrictive. Previously re-verified 2026-07-28 (receipts R11, R12, R36, R37) — every quoted passage verified on the live pages 2026-07-25 and re-verified 2026-07-28, when the API docs page joined the chip list (the API-path claims — the two-ways setup, the Console mechanics, the ZDR-not-also-needed answer, the org-level enforcement — live there, and the chip previously named only the Enterprise article); the Enterprise page itself showed “Updated this week.” Second-pass correction, same day, after independent review: the first rewrite fixed the restrictive error on the Enterprise path but still described the API path without saying it is also self-serve — leaving an API-only organization to infer that a sales cycle was required for theirs. Same error class, smaller blast radius; now stated for both paths. Corrected 2026-07-25 — this was the most consequential error found on this site. The prior version said a BAA required a “sales-assisted Claude Enterprise plan,” which would lead a self-serve Enterprise organization to conclude it was categorically ineligible and stop pursuing a BAA it in fact qualifies for. That is an error in the restrictive direction: it stops care. The self-serve enablement path, the Primary-Owner restriction, the settings-reset, the irreversibility, and the December 2, 2025 BAA cutover were all absent and are now stated.
• ⚑ Compliance-critical: BAA eligibility moves — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — the complement: what is never BAA-eligible
• HIPAA coverage must be actively enabled — an Enterprise contract alone is not a BAA — coverage must be switched on, even on the right plan
• Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered — enabling HIPAA alone does not bring Claude Code under the BAA
• Which BAA configuration fits an advocacy nonprofit's needs — which of the two fits an advocacy nonprofit
• BAA — Business Associate Agreement — the term, plainly
• Primary Owner — the role that accepts the BAA

(1) Do not put PHI through these — Claude Free, Pro, Max, or Team; Console and Workbench; Cowork; Claude Code on the API path; beta features; third-party integrations. And Claude Platform on AWS and Microsoft Foundry, where the documentation says HIPAA readiness “is not available.”

(2) These are governed by your cloud provider, not by Anthropic — Amazon Bedrock and Google Cloud’s Agent Platform. There, the cloud provider is the data processor, so its BAA and compliance documentation decide what you may do. Anthropic’s HIPAA readiness does not extend to them — but that is a handoff, not a prohibition. If your organization already has a BAA with AWS or Google covering that service, check it. Do not conclude you must stop.

Detail

Plans that cannot enable HIPAA at all: “Team plans and individual plans (Free, Pro, and Max) can’t enable HIPAA.”

Surfaces the API documentation lists as not covered under HIPAA readiness:

• Console and Workbench — “enabling HIPAA readiness from Console settings is supported; processing PHI through the Console is not covered.”
• Partner-operated platforms: Amazon Bedrock and Google Cloud’s Agent Platform. The documentation’s instruction is a referral, not a bar: “Refer to those platforms’ compliance documentation.” Read the force of that sentence carefully — it is different from the next bullet’s.
• Claude Platform on AWS and Microsoft Foundry: “HIPAA readiness is not available on these platforms.” This one is a bar.
• Third-party integrations — “Data processed by external tools or services connected to your application.”
• Claude Code — “Claude Code is not covered under HIPAA readiness” on the API path; see Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered for the Enterprise-with-ZDR exception.
• Beta features — “Features in beta are generally not covered under the BAA unless explicitly listed as eligible in the feature eligibility table.” Note the force of that sentence: it is a default, with a documented exception path, not an absolute.
• Flagged content and legal holds — retained regardless of arrangement.
• Cowork — “not yet covered under Anthropic’s BAA.”

The cloud-partner rule, stated plainly — this is the one most likely to be missed, and most likely to be over-read. “This page covers the Claude API (api.anthropic.com), Claude Platform on AWS, and Claude in Microsoft Foundry, where Anthropic is the data processor. On Amazon Bedrock and Google Cloud’s Agent Platform, the cloud provider is the data processor; refer to those platforms’ data retention and compliance documentation for their equivalent controls.” Restated in the source’s own FAQ: the ZDR and HIPAA arrangements described there “apply to the Claude API, where Anthropic is the data processor. On Bedrock and Google Cloud, the cloud provider is the data processor.”

An organization running Claude through Bedrock and reading Anthropic’s HIPAA page is reading the wrong document — that is the finding. It is not a finding that the organization must stop. The source explicitly points to the provider’s “equivalent controls,” which implies they exist. A health system with an existing AWS BAA covering Bedrock may well be on solid ground; what it cannot do is cite Anthropic’s HIPAA readiness as its basis. Go read your cloud provider’s BAA and its compliance documentation for that service, and confirm the coverage there. Ruling yourself out on the strength of this page would be its own error — the mirror of the one this module corrected on 2026-07-25 (see A BAA is available in two configurations — and Enterprise self-serve orgs qualify).

The practical trap for a working group: members’ personal Pro/Max accounts and the Cowork surface both feel private, and neither is BAA-eligible — Cowork’s session isolation (Isolation protects your computer from Claude's code — it does not limit what Claude reads or does) is a security property, not HIPAA coverage. For members not on a covered plan, the de-identification questions (De-identification practices for members without a BAA) are where safe use begins.

Source & currency

• Source: API and data retention — Claude Docs (the not-covered list + the data-processor rule) + HIPAA-ready Enterprise plans — Claude Help Center (plan eligibility, Cowork).
• Status: CONFIRMED — re-verified 2026-07-28 (receipts R11, R12, R36, R37) — every quoted passage verified 2026-07-25 and re-verified 2026-07-28, when the Help Center article joined the chip list: the title’s own plan-eligibility claim (“Team plans and individual plans (Free, Pro, and Max) can’t enable HIPAA”) and the Cowork “not yet” sentence live there, not on the page the chip previously pointed to. Corrected 2026-07-25: the prior version’s list omitted every cloud-partner path (Bedrock, Google Cloud’s Agent Platform, Claude Platform on AWS, Microsoft Foundry), third-party integrations, and Claude Code — a reader deploying through Bedrock found nothing here and could reasonably conclude the question did not apply. Two register corrections also landed: the blanket “never … under any circumstances … Full stop” now tracks each item’s actual force (betas are a default-with-exceptions; Cowork is “not yet”), and the beta examples “Claude in Office and Claude Design” — which appear on neither fetched primary source — are now attributed to the working-group document rather than presented as Anthropic’s list.
• Second correction, same day, after independent review: the first pass swept Bedrock and Google Cloud into a single “do not put PHI through any of these” imperative. The source defers on those two (“refer to those platforms’ compliance documentation”) while it bars Claude Platform on AWS and Microsoft Foundry (“HIPAA readiness is not available”). Collapsing a deferral into a prohibition would have told an organization with a valid AWS BAA to stop work it may lawfully do — a restrictive error of exactly the kind this round was convened to remove. The two situations are now separated in the plain-language line, which is where a phone reader stops.
• ⚑ Compliance-critical: the covered/uncovered lists move with the product — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• A BAA is available in two configurations — and Enterprise self-serve orgs qualify — the configurations that ARE eligible, including self-serve Enterprise
• Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered — the two-path Claude Code answer, in full
• Isolation protects your computer from Claude's code — it does not limit what Claude reads or does — isolation ≠ coverage
• De-identification practices for members without a BAA — what members off covered plans should do instead
• PHI — Protected Health Information — what counts as PHI, plainly
• BAA — Business Associate Agreement — the agreement itself, plainly
• Cowork — what Cowork is, plainly

Detail

Even on a HIPAA-ready Enterprise plan, coverage is not automatic: the Primary Owner must navigate to Organization Settings → Data and Privacy → HIPAA Compliance and accept the BAA. A standard Enterprise contract by itself does not include BAA coverage. This is the “someone assumed we were covered” failure mode, named: eligibility (A BAA is available in two configurations — and Enterprise self-serve orgs qualify), activation (this node), and per-feature coverage (Enabling HIPAA does not cover every feature — coverage is decided feature by feature) are three separate hurdles, and all three must clear. Process, timeline, and cost are the group’s question: Process, timeline, and cost to activate HIPAA readiness.

Source & currency

• Source: HIPAA-ready Enterprise plans — Claude Help Center (cited by the source doc).
• Status: CONFIRMED — re-verified 2026-07-27 (receipts R3, R7, R23): “Sign in to Claude as the Primary Owner and go to Organization settings > Data and privacy… Click ‘Accept and enable HIPAA.’” New fact since the doc: on the API side, once enabled, HIPAA readiness “is permanent and cannot be disabled by an administrator” — activation is a one-way door. ⚑ Compliance-critical: settings paths and activation mechanics move — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• A BAA is available in two configurations — and Enterprise self-serve orgs qualify — hurdle one: being in an eligible configuration
• Enabling HIPAA does not cover every feature — coverage is decided feature by feature — hurdle three: the feature is on the covered list
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — what no amount of activation reaches
• Process, timeline, and cost to activate HIPAA readiness — process / timeline / cost for the contact
• Primary Owner — the one role that can do this step

Detail

On the API path, read the table. Anthropic’s API documentation publishes a “table [that] lists which Claude API features are eligible for ZDR and HIPAA readiness arrangements” — roughly thirty-five features, each with an endpoint and a rating. It is public: it can be fetched anonymously. The ratings are three-valued, not yes-or-no, and the middle value is the one worth reading slowly: “Yes (qualified): Your prompts and Claude’s outputs are not stored, but a bounded technical artifact (named in the Details column) is retained briefly for the feature to function.” A feature can be eligible and still leave something behind.

The API enforces this, and only for HIPAA. “When a HIPAA-enabled organization sends a request that includes a non-eligible feature, the API returns a 400 error to prevent accidental use of features not covered by your BAA.” The documentation is explicit that the same is not true of zero-data-retention: “Under ZDR, the API does not block these features; using one is a choice to step outside your ZDR arrangement for that specific data, and the feature’s own documented retention policy applies.” So a 400 is a guard-rail you get under HIPAA and do not get under ZDR alone — and note the closing clause: stepping outside ZDR does not mean stepping outside retention governance altogether, it means falling back to that feature’s own policy.

On the Enterprise path, the authoritative list is gated. The Help Center states plainly that “enabling HIPAA doesn’t bring every feature under your BAA” and that “Features fall into three categories: covered by your BAA, available but not covered, and disabled” — but it does not publish the per-feature list. It defers: “The Implementation Guide for HIPAA Entities on the Anthropic Trust Center lists every feature’s status and is the authoritative source,” and “You’ll need to request access to view the Implementation Guide. Requests from domains matching existing customer accounts are approved automatically.”

Read that second sentence — it matters, and an earlier draft of this node cut the quotation just before it. The gate is real but it is not a wall, and it opens automatically for exactly the population that would be asking: any organization for whom this question is live is already an Enterprise customer, since the same page restricts HIPAA enablement to “Enterprise plans only”. The honest statement is therefore narrower than “a barrier”: the per-feature truth is not publicly readable, so you cannot check it before you are a customer, and you cannot cite it to someone who is not. That is why the group’s per-feature question stays on the register: Which day-to-day features are covered once HIPAA is active.

Two things routinely fall outside coverage. Beta features — “Features in beta are generally not covered under the BAA unless explicitly listed as eligible in the feature eligibility table” — and Covered Models, which “require 30-day data retention; ZDR is therefore not available for either model.” A zero-retention posture and the newest models are, today, mutually exclusive.

So the practical question is never “are we HIPAA-covered?” but “is this feature, on our surface, with our retention setup, covered right now?”

Source & currency

• Source: API and data retention — Claude Docs (the public per-feature table, the 400-error enforcement, beta features, Covered Models) · HIPAA-ready Enterprise plans — Claude Help Center (the three-category framing, the gated Implementation Guide). The claim spans both pages, and until CG4 the chip named only the second.
• Status: CONFIRMED 2026-07-27 (receipts R23, R24) — every passage above re-fetched and quoted verbatim this date. Corrected at CG4, and the correction is the reason this node was rewritten: the previous title, heading and body put “Eligible Services” in quotation marks and attributed it to Anthropic. An enumerated search of both primary sources (§4.4) found the phrase on neither. It was our coinage, rendered as theirs, on a compliance-critical node — the same defect class an independent review caught in the receipts log at CG2. Three further corrections came out of the same re-fetch: the eligibility table is three-valued, not Yes/No; it is public, so it and not the gated guide is the reader’s first stop on the API path; and the 400 enforcement is HIPAA-only, which the earlier text did not say. ⚑ Compliance-critical: feature eligibility is exactly the kind of fact that moves — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• HIPAA coverage must be actively enabled — an Enterprise contract alone is not a BAA — the activation hurdle before this one
• Claude Code: not covered on the API path at all; on Enterprise only with ZDR. Cowork: not yet covered — the two named per-surface rulings (Code, Cowork)
• Never put PHI in a JSON schema — cached schemas are not protected like message content — the PHI-handling rule attached to the structured-outputs row of this same table
• Which day-to-day features are covered once HIPAA is active — the feature-by-feature ask for the contact
• ZDR — Zero Data Retention — why retention arrangements interact with coverage

Detail

Path 1 — the API. The API documentation’s not-covered list is unqualified: “Claude Code: Claude Code is not covered under HIPAA readiness.”

Our reading, not the source’s words: we take that as covering the API path regardless of ZDR. Note the tension you may hit if you go looking — the same page’s FAQ says “Claude Code is eligible for ZDR through two paths,” including “API keys: Claude Code used with pay-as-you-go API keys from a Commercial organization.” ZDR eligibility and HIPAA coverage are different arrangements, and the page states the HIPAA answer plainly while never saying ZDR rescues it. We read the conservative way; if this decides something for you, ask your contact rather than relying on our inference.

Path 2 — Enterprise. “Important: Enabling HIPAA readiness alone doesn’t bring Claude Code under your BAA. Claude Code is covered under your BAA only with zero data retention (ZDR) enabled, and only on qualified accounts.” And the trap most likely to catch a real organization: “Without ZDR, Claude Code remains available to use but isn’t covered—including when Claude Code access is bundled into your Enterprise seats.” Bundled access is not coverage. The tool keeps working; the BAA does not follow it.

The source directs organizations exploring Claude Code coverage to “contact your Anthropic account team or our Sales team.”

The ZDR trade-off is real. Enabling ZDR blocks access to some newer models — Claude Fable 5 and Claude Mythos 5 “require 30-day data retention and are not available under ZDR.” Coverage versus capability is a decision an organization makes consciously. The ZDR mechanics live in the retention domain: API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable.

Cowork. “Additionally, Cowork is not yet covered under Anthropic’s BAA.” Treat Cowork as uncovered today and re-check — “not yet” is the source’s own word, and it describes a roadmap position rather than a permanent exclusion. The operational bright line is unchanged: no PHI through Cowork today. Cowork’s session isolation (Isolation protects your computer from Claude's code — it does not limit what Claude reads or does) is a security property, not coverage.

So: confirm your path first. “API or Enterprise?” changes the Claude Code answer from no to conditionally yes. Anyone quoting one rule for both is quoting the wrong one half the time.

Source & currency

• Source: HIPAA-ready Enterprise plans — Claude Help Center (Enterprise path) + API and data retention — Claude Docs (API path).
• Status: CONFIRMED — re-verified 2026-07-28 (receipts R11, R12, R36, R37) — every quoted passage verified on the live pages 2026-07-25 and re-verified 2026-07-28, when the API docs page joined the chip list (both documents carried the claim all along; the chip under-reported). Corrected 2026-07-25: the prior headline stated one rule (“covered only when ZDR is enabled”) and left the API path’s flat no buried in collapsed detail — on a phone, the headline is what gets acted on. The bundled-seats trap was also absent. Separately, the Cowork wording was softened from “never … in any configuration today” to the source’s actual “not yet” (the prior phrasing asserted permanence the source does not claim), without loosening the operational rule.
• ⚑ Compliance-critical: per-surface coverage and the ZDR-model interaction are volatile — confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• A BAA is available in two configurations — and Enterprise self-serve orgs qualify — which plan configurations can hold a BAA at all
• Enabling HIPAA does not cover every feature — coverage is decided feature by feature — the per-feature coverage frame these rulings instantiate
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — the full not-covered picture, including the cloud-partner platforms
• API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable — what ZDR is and where it’s negotiated
• Isolation protects your computer from Claude's code — it does not limit what Claude reads or does — isolation ≠ eligibility, stated from the other side
• ZDR — Zero Data Retention — the term, plainly

Detail

The rule, verbatim: “When using structured outputs or tools with strict: true, the API compiles JSON schemas into grammars that are cached separately from message content. These cached schemas do not receive the same PHI protections as prompts and responses. Do not include PHI in JSON schema definitions.”

Where the trap actually is — the restriction “applies to schema property names, enum values, const values, and pattern regular expressions.” Those are exactly the places a well-meaning builder puts real detail: a property named for a specific patient or family, an enum listing actual patient identifiers, a pattern encoding a real MRN format. The instruction is unambiguous: “Patient-specific information should appear only in message content, where it is protected under HIPAA safeguards.”

How long the cache lives: the feature-eligibility table notes that for structured outputs, “Your prompts and Claude’s outputs are not stored. Only the JSON schema is cached, for up to 24 hours since last use.” The same grammar pipeline covers strict tool use (strict: true on tools), so the rule applies there too.

What PHI means here. The source defines it as “any individually identifiable health information,” typically appearing “in message content (prompts and Claude’s responses), attached files (images, PDFs), and file names or metadata associated with message content.” It also names fields not expected to contain PHI under the BAA: “workspace names, user information (name, email, phone number), billing data, and support tickets.” See PHI — Protected Health Information.

This is a narrow, technical rule with a wide blast radius — it applies to anyone building a registry extractor, an intake form parser, or any tool that asks Claude to return structured data about real people.

Source & currency

• Source: API and data retention — Claude Docs (§PHI handling guidelines, §feature eligibility).
• Status: CONFIRMED 2026-07-25 (receipt R12) — every quoted passage verified on the live page this date. Node created 2026-07-25: the rule was absent from this curriculum entirely, despite being one of the few places the documentation gives an explicit never about where PHI may be written.
• ⚑ Compliance-critical: confirm current specifics with your Anthropic contact before relying on this for a compliance decision. This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — the surface-level not-covered picture; this is the field-level one
• Enabling HIPAA does not cover every feature — coverage is decided feature by feature — the feature-eligibility table this rule sits inside
• API: content not retained by default; inputs/outputs deleted within 30 days; ZDR negotiable — why “not stored” for prompts does not mean “not stored” for everything
• PHI — Protected Health Information — what counts as PHI, plainly

Detail

Why an ordinary redaction habit is not enough in rare disease. Most de-identification advice is field-by-field: remove the name, remove the date of birth, remove the address. That instinct is right and insufficient here, for the reason De-identification and PHI — Protected Health Information both make: rare conditions are quasi-identifying. When the population with a diagnosis is small, the diagnosis is doing the work an identifier normally does, and the remaining details only have to narrow the field a little further. The unit of risk is therefore the combination of what survives redaction, not any single field in it. A clinician who has read one paragraph and thought I think I know who that is has just failed the only test that counts.

The pre-flight. ✎ Our practice. It is meant to be run in order, quickly, on the actual text you are about to send.

1. Ask whether it has to go in at all. The cheapest de-identification is the detail you never include. Rewrite the request as the smallest question that still gets you the answer — very often the clinical question survives intact with no case attached. Whether and when sensitive material should be entered is itself on the group’s register: How to increase security and when sensitive input is safe.
2. Know what you are typing into. Most everyday ways of using Claude are not BAA-covered, which is exactly why this checklist exists — see Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call. On an uncovered surface there is no safety net behind the redaction, so the redaction has to hold on its own.
3. Remove the direct identifiers. Names — the patient’s, family members’, the referring clinician’s; contact details; medical record, insurance and account numbers; photographs and images; and the names of the treating institution, clinic, school or employer. An institution name in a rare-disease context is frequently as narrowing as a postcode.
4. Coarsen every date. Birth, onset, admission, procedure, death. Convert to intervals or age bands: “onset at around age four, investigated over about three years” rather than a dated timeline. A sequence of exact dates is a fingerprint even with no name attached.
5. Coarsen geography. Country, or a broad region, rather than city, hospital catchment, or named centre. The rarer the condition, the coarser this has to be — with a small enough patient population, “in Europe” can still be too specific, and that is a signal to go to step 7 rather than to keep trimming.
6. Strip the memorable detail out of the free text. Direct quotes from a parent, an unusual clinical course, the striking incidental finding, the phrase you would use to remind a colleague which case you mean — the detail that makes a case memorable is, almost by definition, the detail that re-identifies it. Keep the clinical fact; drop the anecdote that carries it.
7. Now read the residue as a set and ask the counting question. If I knew this patient community, how many people could this be? If the honest answer is “a handful”, or “I would know”, it is not de-identified yet. Three moves, in preference order: generalize the diagnosis (to the phenotype group or gene family rather than the specific variant), widen the age band, drop the geography entirely. If none of those leaves a useful question, that is the answer — do not send it.
8. De-identify the file, not the paragraph. An attachment carries more than the passage you meant to share: the filename itself, document properties and author fields, tracked changes and comments, hidden rows, filtered-out ranges, extra worksheets, and the rest of a table you only meant to show one row of. Open it and look, or paste the extract as plain text instead.
9. Have a second person read it cold. Hand the de-identified text to a colleague who does not know the case and ask them to guess. Two minutes, and it catches what the author cannot see — the writer knows who the patient is and therefore cannot read the text as a stranger would.
10. Write down what you removed. One line, kept with the request: what was stripped, what was generalized, and how coarse you went. It costs nothing, it makes the practice reviewable by someone qualified to review it, and without it the review in the next paragraph has nothing to inspect.

What this checklist does not claim — read this part. It is not a determination that the result meets HIPAA’s Safe Harbor or Expert Determination standard. Those are defined things: Safe Harbor is the removal of a specified list of identifier types, and Expert Determination is a certification by a qualified statistical expert that the re-identification risk is very small (De-identification). Whether the practice above reaches either bar — and for which kinds of rare-disease material — is a question we have not answered and are not competent to answer here. It is logged for real clinician and counsel review — a review that has not yet happened — and the standard question stays open on the group’s register: Anthropic's safe de-identification threshold before data is PHI.

Why we draft it rather than wait for it. The group’s register already asks Anthropic both halves of this — what threshold counts as de-identified (Anthropic's safe de-identification threshold before data is PHI) and what practices to follow without a BAA (De-identification practices for members without a BAA). Arriving with a draft turns an open-ended request into a review: here is what we do — where is it wrong? That is a shorter conversation, it is a better one, and it means the group is not sitting on its hands in the meantime. Bring this to the contact; do not wait for it to come back.

Source & currency

• Source: this curriculum’s own synthesis — the working-group document §4 — the two open de-identification questions, drafted forward into a practice by us. No product behaviour is asserted here; every factual statement about Claude on this node lives on a linked node with its own provenance.
• Status: DOCUMENTED · register: recommendation — ✎ our practice, not an Anthropic product fact and not a legal standard.
• compliance: false is deliberate. The ⚑ compliance flag on this graph marks patient-safety-critical product claims that must be confirmed with the Anthropic contact before a compliance decision rests on them. This node is a practice we authored; flagging it ⚑ would dress our own recommendation in the authority of a documented fact, which is the exact conflation the register/fact distinction exists to prevent. The compliance-critical facts this checklist sits on top of carry their own ⚑ — start at Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call and HIPAA & Patient Privacy.
• This is a teaching aid, not compliance or legal advice.

Related

• HIPAA & Patient Privacy — parent domain
• De-identification — the two recognized standards, and why rare disease strains the field-by-field instinct
• PHI — Protected Health Information — what makes information identifying in the first place
• Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call — the plans and surfaces with no BAA behind them, which is where this checklist earns its keep
• Anthropic's safe de-identification threshold before data is PHI — the open question this draft is written for: where the safe threshold actually sits
• De-identification practices for members without a BAA — the open question this draft answers provisionally, pending the contact’s review
• How to increase security and when sensitive input is safe — step 1’s question: whether sensitive material should be entered at all
• Your first week: the shortest safe path, in five days — Day 4 runs this checklist on a deliberately low-stakes task, so the habit is formed before it is needed
• HIPAA — connections (the compliance spine anchors here) — the compliance spine this node hangs from