# HIPAA companion - reference material for the Claude conversation

This is the companion to the public guide at https://askflorence.health/hipaa-guide. It is meant to be attached to a Claude conversation (paste it in, drop it into a Claude project, or upload it as a file) so the model has the structured reference material it needs when walking a healthcare-AI founder through their HIPAA decisions.

The public guide carries the narrative; the markdown mirror of that narrative is at https://askflorence.health/hipaa-guide.md. This file carries the table and the checklist.

Author: Taha Salahuddin Abbasi, Founder & CEO, AskFlorence.
Published: 2026-05-28.
Status: one founder's path, not the path. Not legal advice. See the disclaimers at the end.

---

## How to use this with Claude

1. Open a fresh Claude conversation (Claude Code, claude.ai, or the API).
2. Paste in the Claude prompt from https://askflorence.health/hipaa-guide#tools.
3. Attach or paste BOTH https://askflorence.health/hipaa-guide.md (the full guide as markdown) and this companion markdown (the reference appendix). If Claude has web-fetch tooling, it will pull both for you - the prompt instructs it to.
4. Answer Claude's questions about your stack, your data flow, and your audit obligation.
5. Use Claude's recommendations as a starting point for your own decisions, then verify the specifics with the vendor and a HIPAA-experienced attorney before signing anything.

---

## Section A - The vendor map, in detail

The public guide has a scannable diagram. This is the table.

### Class 1 - LLM (large language models)

| Vendor | BAA posture | Notes |
|---|---|---|
| AWS Bedrock (Claude, Llama, etc.) | Covered under AWS Organizations BAA | One signature covers Bedrock + every other AWS service. Path of least resistance for early-stage. Watch quota approval lead times (see "Watchouts" below). |
| Anthropic direct API | Available - confirm tier with sales | If you launch on direct, you need a signed BAA before any PHI flows. Lead time varies. |
| OpenAI / Azure OpenAI | Available at Enterprise tier | Azure OpenAI under Microsoft's BAA (if you already have a Microsoft 365 / Azure BAA, easier path). Direct OpenAI tier-gated. |
| GCP Vertex / Gemini | Under Google Cloud BAA | If you're already on Google Workspace, the Google Cloud BAA is straightforward. |

The architectural lesson: pick LLM via an adapter (see Section D). The vendor swap year-2 is much cheaper than you think it'll be, if you build for it. The vendor lock year-2 is much more expensive than you think it'll be, if you don't.

### Class 2 - Voice / speech (ASR + TTS)

| Vendor | BAA posture | Notes |
|---|---|---|
| AWS Transcribe / Polly | Under AWS Organizations BAA | Functional, FedRAMP-Moderate path available. Quality + voice library smaller than specialist vendors. |
| Deepgram | BAA available | Confirm tier. Strong ASR; FedRAMP path advancing. |
| Cartesia | BAA: confirm with sales | Healthcare track explicitly advertised. Tier requirement unclear from public materials; ask directly. |
| ElevenLabs | BAA gated (likely Enterprise) | The agents-mode product is meaningfully ahead on developer experience. The BAA tier conversation needs to happen in your first vendor call. |
| Self-hosted Whisper / open-weight TTS | Under your own infra BAA | No subprocessor. Operational overhead is real. Reasonable floor case if no vendor terms work. |

The architectural lesson: voice is the most common surface where AWS-native loses to a specialist. Worth budgeting for the BAA-tier conversation when product-fit forces the switch.

### Class 3 - Compute / hosting

| Vendor | BAA posture | Notes |
|---|---|---|
| AWS (ECS, Lambda, EC2, etc.) | Under AWS Organizations BAA | Comprehensive coverage. The default for HIPAA-bound startups. |
| GCP (GKE, Cloud Run, etc.) | Under Google Cloud BAA | Comparable coverage to AWS. Different developer experience. |
| Vercel | BAA at Enterprise tier | Free / Pro tiers do NOT support BAA. Surprises a lot of Next.js founders. |
| Fly.io | No BAA | Cannot host PHI. Fine for marketing surfaces; not for PHI workloads. |
| Render / Railway | No BAA at most tiers | Verify before assuming. |
| Cloudflare Workers | BAA at Enterprise tier | Same surprise as Vercel. The free CDN is fine; KV / D1 / Workers running on PHI are not without the right contract. |

The lesson: a lot of founder-favorite "ship fast" platforms have no BAA at sane prices. AWS / GCP are the default for a reason.

### Class 4 - Database

| Vendor | BAA posture | Notes |
|---|---|---|
| MongoDB Atlas | BAA available (M10+ HIPAA tier) | Sign early. We did this before any user data hit Atlas. The cost was low; the upside was big. |
| AWS RDS / Aurora / DynamoDB | Under AWS Organizations BAA | One signature, all-services coverage. |
| Postgres (Crunchy Data, Aiven) | Varies by provider | Crunchy Data has BAA. Verify with the specific provider before committing. |
| Supabase | BAA at higher tier | Self-serve tiers don't include BAA. |
| Vector DBs (Pinecone, Weaviate, Qdrant) | Varies | If embeddings ever encode PHI text, the vector DB needs a BAA. Worth checking before you start embedding clinical notes. |

### Class 5 - Transactional email

| Vendor | BAA posture | Notes |
|---|---|---|
| AWS SES | Under AWS Organizations BAA | The default for HIPAA-bound startups. We migrated from Resend to SES in part for BAA coverage simplification. |
| Postmark | BAA available | Strong DX. Confirm tier. |
| SendGrid | BAA available, tier-gated | Verify before signing up. |
| Resend | BAA gated to higher tier (at time of writing) | We retired Resend in favor of SES. |

### Class 6 - Analytics + error tracking

| Vendor | BAA posture | Notes |
|---|---|---|
| PostHog HIPAA Cloud | BAA available (contact-sales tier) | Single workspace for analytics, errors, session replay, feature flags, LLM observability. Single BAA. We use this. Earlier direction was self-hosted (OpenPanel + GlitchTip); we reversed when the build-time math didn't pencil against the demo deadline. |
| Datadog | BAA available | Strong APM. Enterprise pricing. |
| Mixpanel | BAA available, Enterprise-tier | The free / startup tiers don't include BAA. |
| Sentry | BAA available, Enterprise-tier | Same. |
| OpenPanel + GlitchTip (self-hosted) | Self-hosted under your infra BAA | Real moat IF you have runway to build it. We didn't, at v1 demo timeline. |

### Class 7 - CRM / lifecycle / marketing

| Vendor | BAA posture | Notes |
|---|---|---|
| HubSpot | BAA at Enterprise (Marketing Hub Enterprise + Service Hub Enterprise) | Cost cliff for early-stage. Many founders end up walling PHI off from HubSpot architecturally. |
| Customer.io | BAA available, tier-gated | Same pattern. |
| HIPAA-specific marketing platforms (Klara, Luma, Salesforce Health Cloud) | BAA-native | Higher cost. Right answer if PHI is central to your lifecycle messaging. |

The architectural lesson: most early-stage founders wall the CRM off from PHI rather than pay for a BAA-tier CRM. That requires discipline (no PHI in HubSpot at any layer) but it works.

### Class 8 - Auth + identity

| Vendor | BAA posture | Notes |
|---|---|---|
| AWS Cognito | Under AWS Organizations BAA | The default for AWS-native stacks. |
| Auth0 (Okta) | BAA available | Confirm tier; Enterprise is the safest answer. |
| Clerk | BAA at higher tier | Verify before assuming. |

### Class 9 - Identity verification (KYC)

| Vendor | BAA posture | Notes |
|---|---|---|
| Persona | BAA available | Strong product. Healthcare track. |
| Stripe Identity | BAA available | If you're already on Stripe, easy add. |
| Plaid Identity | BAA available | Same. |
| Veriff | BAA available | Same. |

ID verification vendors tend to be the easiest BAA conversations because they all serve regulated industries already.

---

## Section B - The EDE-vs-HIPAA delta, layer by layer

If you have a pure-HIPAA obligation (NOT a CMS EDE obligation), you do NOT need the following Florence-specific layers. Treat them as the EDE tax you can omit.

### Layer 1 - Audit logging at the DB layer

**Florence (EDE-driven):** the MongoDB user that writes to the `agent_audit_log` collection has FIND + INSERT permission only. No UPDATE, no DELETE. The append-only enforcement is at the database layer, so even a compromised app cannot tamper with the audit trail.

**Pure-HIPAA equivalent:** app-layer audit logging to a log destination (CloudWatch, Datadog, a dedicated audit log database). Sufficient for HIPAA Security Rule §164.312(b). Easier to operate.

### Layer 2 - Environment isolation

**Florence (EDE-driven):** staging and prod are separate MongoDB Atlas projects (not just separate databases or separate users). Cross-cluster access goes through AWS PrivateLink with a narrow-scoped read-only user. The blast radius of a staging-side compromise is limited to staging.

**Pure-HIPAA equivalent:** one Atlas project, separate databases or strict role-based access. Acceptable under HIPAA if your access controls are clean.

### Layer 3 - Super-admin auth

**Florence (EDE-driven):** the super-admin login is password + TOTP + IP allowlist. Three different factor classes (something you know + something you have + somewhere you are). The day-to-day admin login is password + TOTP only.

**Pure-HIPAA equivalent:** magic link + TOTP for admin access. NIST 800-63B AAL2 compliant. Acceptable for HIPAA.

### Layer 4 - Vendor selection awareness

**Florence (EDE-driven):** vendor choices factor in FedRAMP Moderate status. Cartesia's FedRAMP path matters even though we don't need FedRAMP today; the upgrade-to-FedRAMP-by-EDE-cutover deadline is on the roadmap.

**Pure-HIPAA equivalent:** pick the lowest-cost vendor with a signed BAA at your needed tier. FedRAMP isn't required for HIPAA.

---

## Section C - The AWS umbrella decision framework

Use this rubric to decide AWS-native vs best-of-breed per vendor class.

```
For each vendor class in your stack:
  if AWS-native option exists AND meets your product needs (acceptable quality, acceptable latency, acceptable DX):
    pick AWS-native (covered by AWS Organizations BAA)
  else:
    consider best-of-breed (separate BAA, separate legal review)
    score: product-fit gain vs compliance overhead added
    if product-fit gain >> compliance overhead added:
      pick best-of-breed
      add adapter layer so swap-back is feasible if BAA breaks down
    else:
      pick AWS-native, accept the product-fit gap
```

Surfaces where Florence picked AWS-native: LLM (Bedrock), email (SES), storage (S3 / RDS / DynamoDB), auth (Cognito).

Surfaces where Florence picked best-of-breed: voice (ElevenLabs - the agents-mode product was meaningfully ahead).

Surfaces where we still might swap: analytics (PostHog HIPAA Cloud now; potentially self-hosted at EDE-audit time, gated behind an adapter).

---

## Section D - The swappability adapter checklist

For every external vendor surface, you should have:

1. A typed interface (`callLLM(prompt)`, `synthesizeVoice(text)`, `trackEvent(name, props)`, `trackError(error, context)`, `sendEmail(to, subject, body)`, etc.) defined in your app's core layer.
2. A vendor-specific implementation that lives behind that interface. Vendor SDK calls happen here, never in app code.
3. A config-driven selection mechanism so you can point at a different vendor implementation via env var or feature flag without code changes.
4. A way to record every call (for audit + debugging + future-swap validation) that does NOT depend on the vendor.
5. A test stub / fake implementation for unit tests so the real vendor isn't called during CI.

If you have all five for every vendor surface, you can swap any vendor in any class with a config change. That is the operational definition of "compliance is easier from day one."

---

## Section E - The MVP-until-it-matters quadrant rubric

Two questions for any BAA decision:

1. **Is the BAA cheap to sign?** (Self-serve sign-up, standard contract, no negotiated terms = cheap. Enterprise tier with custom legal review = expensive.)
2. **Is the audit pressure in this quarter?** (Active customer contractually requires the BAA / regulator audit imminent = pressure now. Self-imposed bar for an audit 12+ months out = no pressure yet.)

The four quadrants:

| Cost | Pressure | Move |
|---|---|---|
| Low | Now | Sign now, no question. |
| Low | 12+ months out | Sign anyway - cheap upside, removes future blocker. (Atlas BAA for Florence falls here.) |
| High | Now | Negotiate hard, or defer the product feature until you can. |
| High | 12+ months out | Use a vendor with a clean BAA at your bar + adapter layer + plan to upgrade when audit pressure arrives. Do NOT build the moat now. (PostHog HIPAA Cloud + the adapter pattern falls here for Florence.) |

The wrong moves: signing expensive BAAs you don't need yet (over-investment) or skipping cheap BAAs you'll obviously need later (under-investment).

---

## Section F - What "what I'd do differently" might look like

This section in the public guide is in progress. When the founder fills it in, it will include the 3-5 specific things he'd change with hindsight. Until then, the meta-pattern is: most founders we talk to would (a) sign more cheap BAAs earlier, (b) build adapter layers around more vendor surfaces, (c) NOT build self-hosted moats for audits 12+ months out, and (d) audit their own data flows quarterly so they know where PHI actually lives.

---

## Disclaimers

This document carries the same disclaimers as the public guide at https://askflorence.health/hipaa-guide:

- Not legal advice. Talk to a HIPAA-experienced attorney for anything load-bearing.
- One founder's path. Your situation will differ.
- Time-bounded information. The vendor landscape moves; check primary sources before acting.
- Open to corrections at taha@askflorence.health.

---

End of companion. Published 2026-05-28.