A founder's notes
What I learned making AskFlorence HIPAA-compliant.
One path, not the path. For other founders building healthcare AI with coding agents.
Why this guide exists
Compliance is much easier from day one than to retrofit later.
I have been building software for nearly twenty years. The pattern I keep watching play out: companies that treat HIPAA, SOC 2, and the broader PHI / PII discipline as a day-one architectural decision spend a fraction of the time and money to get there. The ones that bolt it on at year two pay for it in rework, vendor swaps, workflow rebuilds, and audit-prep panic.
The retrofit cost is real. It is not paperwork. It is going back into a working system that was built without the right separation of concerns and untangling it under pressure. The number of decisions that look small at the time and turn into multi-week unwinds later is the part that is hardest to convey to a founder who has not done it.
This matters more in the agent-coding era than it used to. When your job as a founder is the high-leverage upfront decisions and the coding agents (Claude Code, Cursor, take your pick) handle the build, your most expensive mistake is making a bad upfront architectural choice that the agents then encode into a system you have to undo. The agents are fast. They will happily build on the wrong foundation.
A few hours of careful decision-making before the first line of code can save weeks of rework, vendor-swap-out pain, and audit stress months later. This guide is meant to compress that “few hours” for another healthcare-AI founder. Read it, make the decisions, then go let your agents build.
I am a founder, not a lawyer. This is one founder's path, not the path. Your situation will differ. See the disclaimers at the foot of this page.
The shortest honest framing
What HIPAA actually is, in five sentences.
1. HIPAA is the United States health-information privacy law. It defines what counts as Protected Health Information (PHI), who is legally responsible for it, and what happens when it leaks.
2. If you are building healthcare AI that touches PHI, you are almost certainly a Business Associate under HIPAA. Your customers (or the hospitals / insurers / providers your customers serve) are Covered Entities. A Covered Entity that shares PHI with you needs you to sign a Business Associate Agreement (BAA) first.
3. Every vendor in your stack that touches PHI needs a BAA with YOU, for the same reason. You are now the Covered Entity from their point of view. If a vendor cannot or will not sign a BAA, PHI cannot flow through them. Full stop.
4. HIPAA has three rules that show up in practice: the Security Rule (technical and administrative safeguards), the Privacy Rule (what you can and cannot do with PHI), and the Breach Notification Rule (what you have to do when something leaks, and how fast).
5. HIPAA is not the only framework you will meet. You will probably hit SOC 2 (the audit-flavored sibling), possibly ISO 27001, possibly state-specific privacy laws (CCPA, Washington My Health My Data, others), and possibly CMS EDE if you go anywhere near ACA marketplace enrollment. The good news: the same upfront architectural decisions usually serve all of them. The compliance work compounds; it does not fragment.
The first-week decisions that catch you later
The decisions you make before you write any code matter most.
Most of what trips up healthcare-AI founders later is not in the product code at all. It is the operational stack the team gets locked into in week one. Two of our actual stories: one we got right fast, one we over-engineered.
Got it right fast
Internal communications and the Google ecosystem
Slack no longer offers a HIPAA-compliant BAA outside of its Enterprise tier, which lands in the $250K-per-year range and is effectively gated out for early-stage founders. Microsoft Teams is BAA-friendly, but adopting it pulls you into the Microsoft ecosystem and effectively drives you off Google Workspace if that is where you started. The switching cost is real and easy to under-estimate.
We landed on Google Chat under the Google Workspace BAA. Honest acknowledgement: it is worse than Slack as a product. But it sits inside ONE BAA that covers email, Drive, Chat, Calendar, and everything else in Workspace. Our entire operational stack ended up HIPAA-compliant via a single Google BAA signature. The fast decision paid off.
The “risk accept” path - stay on Slack, train the team to never share PHI in messages - works for some companies. The honest framing: it is socially enforceable but very hard to PROVE in an audit, especially if you face a regulator-level audit eventually. For a company headed for that kind of audit, the social-enforcement story is not enough.
Got it wrong (over-engineered)
Internal analytics and error tracking
Our reflex was: “for the CMS EDE audit, an external analytics vendor is risky - better self-host.” The initial direction we wrote down was OpenPanel and GlitchTip, self-hosted, owned end to end, no third party in the data path.
The reality check came when we did the runway math. The CMS EDE audit is a year-plus away for us; we will not even apply for EDE-provider status until next year at the earliest. Building a self-hosted analytics and error-tracking moat to clear an audit that is twelve-plus months out was the wrong trade against demo, build, and shipping velocity.
We reversed to PostHog HIPAA Cloud. Single BAA, single vendor, single SDK family. And we designed the integration for migratability so that when the EDE audit forces a deeper conversation, the swap to a more isolated stack is a config change, not a rebuild.
The lesson: build to the bar that applies TODAY (HIPAA plus standard SOC 2 hygiene), with an architecture that lets you upgrade to the bar that applies LATER (EDE, FedRAMP, whatever audit hits). Do not over-build for an audit that is not in the current quarter.
The trigger question
The compliance question for any operational tool collapses to: “is PHI going to flow through this?”
Not “is it BAA-able” - that is downstream. Ask the flow question first.
Tools where PHI will NOT flow (code repo, issue tracker, planning docs, internal team chat IF you have discipline about it) - pick operationally. GitHub, Linear, Notion. These are normal SaaS decisions. We use Claude Code and Linear with no compliance overhead because no PHI lands in either by design.
Tools where PHI WILL flow even from innocent inputs - BAA tier is mandatory. Customer support is the textbook case. Any healthcare customer can send a support message like “I am looking for this medication for my mother” and you now have identifiable PHI sitting in your support inbox. If you are on Intercom, Front, Zendesk, or anything like them, you need the tier that supports HIPAA and a signed BAA. Period.
Our specific sidestep on customer support is not transferable: we built an AI-native interface (Florence herself) that handles the questions a support tool would handle, so we have no traditional customer support inbox to BAA. That is a Florence-specific architectural answer. Most companies WILL need a support tool, and the Intercom-or-equivalent BAA conversation is unavoidable.
The take: spend a few hours on the flow map before you commit your team or your code to a stack. The decisions that matter are the ones where PHI actually moves; the rest are operational. The coding agents will happily build on whatever foundation you pick, including the wrong one. That distinction has to come from you.
The meta-architectural lesson
Architect for swappability. Vendors change. Audits change.
Our original voice plan was Bedrock for reasoning plus OpenAI Whisper for speech-to-text. The natural AWS-native plus best-known-vendor combo. Made sense on paper.
What actually happened: ElevenLabs ConvAI (their agents platform) turned out to be a meaningfully better product fit for the voice experience we wanted. So we pivoted. But ElevenLabs is a new vendor, which means a new BAA conversation, which means new contract surface area, which means new compliance scope.
The thing that made the pivot survivable: our architecture was designed from the start to make model and provider swaps a config change, not a rewrite. Adapter interfaces around the LLM call, the voice call, the analytics call, the error-tracking call. Vendor-specific code stays behind the adapter. The app code never touches the vendor directly.
The compounding payoff: the same swappability discipline that handles “we found a better vendor” also handles “this vendor's BAA tier just changed” and “we need to migrate to FedRAMP-Moderate before the audit.” All three are vendor swaps; if your architecture handles one, it handles all of them.
The take:when an early-stage healthcare AI founder asks “how do I make compliance easier,” the answer is not a vendor or a tool. It is an architectural posture. Treat every external vendor surface as swappable from day one. Even if you never swap, the discipline buys you breathing room when compliance pressure changes the question.
The classes you will touch
A healthcare AI product touches nine vendor classes. Map yours.
Every healthcare-AI product I have looked at touches some subset of these nine vendor classes: LLM, voice and speech, compute and hosting, database, transactional email, analytics and error tracking, CRM and lifecycle, auth, and identity verification (if you need it). The diagram above sketches the typical entries per class with a BAA-status flag.
A few patterns worth naming directly: AWS-native services (Bedrock, SES, S3, RDS, DynamoDB, Cognito, Transcribe, Polly) all sit under a single AWS Organizations BAA - one signature covers them all. Voice vendors and CRM vendors are the two classes where BAA-tier surprises catch most founders; the BAA often lives only at Enterprise or “contact sales” pricing. Auth and identity verification are usually fine on normal tiers if you pick from the right list.
The companion markdown (see §11) carries the deep table: which specific vendor at which tier signs a BAA, which retired vendors are off the list, what the FedRAMP-Moderate path looks like for each class. The page above is the scannable summary; the companion is the reference.
The highest-leverage architectural decision
AWS umbrella or standalone BAAs? One signature, or N.
Picking AWS-native services means one BAA (the AWS Organizations BAA) covers everything you do on AWS: Bedrock for LLM, SES for email, S3 / RDS / DynamoDB for storage, Cognito for auth, Transcribe for ASR, Polly for TTS. One legal document. One renewal date. One audit story.
Picking best-of-breed multi-vendor means N BAAs to track, each with its own tier gates, its own renewal cycle, its own legal review, and its own audit-evidence collection. The compliance overhead is real and it compounds with team size.
The trade-off is real both directions. AWS-native is the path of least resistance for an early-stage healthcare AI founder. It is also often more expensive per unit AND has developer-experience taxes: model availability gaps on Bedrock, quota friction (see §9), region holes, occasional feature-parity lag versus the best-of-breed vendor in a given class.
Best-of-breed gives better product-fit per surface but multiplies your compliance overhead. We have lived both. We built on Bedrock + AWS SES + S3 + Cognito because the BAA math was clean, and we pivoted to ElevenLabs for voice when the best-of-breed product gap was big enough that the new BAA conversation was worth having.
The take: AWS-native is usually right for early-stage. Outgrow specific surfaces when the product-fit gap is undeniable; do not chase best-of-breed on day one. Voice is the most common surface to outgrow - the AWS voice stack is functional but loses to specialist vendors on quality, latency, voice library, and agents-mode features.
The most important distinction in this guide
EDE is not HIPAA. Use us as a reference. Downgrade to your bar.
HIPAA is the floor for any healthcare-adjacent AI product. CMS Enhanced Direct Enrollment (EDE) is a different, higher bar that applies only to platforms enrolling consumers in ACA marketplace plans on behalf of CMS. We built AskFlorence to the EDE bar from early, which makes our structure a strict superset of pure-HIPAA.
Practically: our whole stack is a useful reference framework, but a pure-HIPAA-obligation startup should consciously OMIT the EDE-driven layers rather than over-build by adopting the whole thing uncritically. The diagram above is the mental model. The inner rectangle is what you have to clear. The outer layers are optional unless you have an EDE-class obligation.
How to know if you have a regulator-audit obligation at all
CMS EDE is a known, written obligation. To get EDE-provider status (which grants you CMS API access for ACA enrollment), you have to PASS a CMS audit first. The audit is the gate; you do not apply for it until you are ready to face it.
Our case: our go-to-market explicitly requires CMS EDE-provider status, so the audit is in the planned path - but not until next year at the earliest. The bar is known, the deadline is known, the work is paced against the application date.
For everyone else: if you are NOT building toward an explicit regulator-API integration (CMS, Medicare, state Medicaid, VA, etc.), you almost certainly do not have an EDE-class audit ahead of you. You would know by now if you did. These obligations come from the API you want access to, and you read about them when you research that API. Absence of evidence is, in this case, pretty good evidence of absence.
How to use our structure if you are pure-HIPAA: treat the AskFlorence vendor stack, BAA inventory, and architectural decisions as a reference checklist that is HIGHER than your bar. The companion markdown (see §11) enumerates the specific layers that are EDE-driven and SAFE TO OMIT for a pure-HIPAA build - append-only audit log enforced at the DB layer vs at the app layer; cross-cluster Atlas PrivateLink and per-env Atlas projects vs one Atlas project with strict roles; three-factor super-admin auth vs magic link plus TOTP; FedRAMP-Moderate-aware vendor selection vs lowest-cost-with-BAA selection.
The take:copy what serves your bar. Omit what does not. Building to a bar you do not have to clear is a tax on velocity that compounds, and “Florence does it” is not, by itself, a reason for you to do it.
The practical posture
MVP until it matters. Two related disciplines.
Discipline 1 - sign BAAs proactively when the cost is low.
We got our MongoDB Atlas BAA in place BEFORE any user data, let alone PHI, entered the system. The Atlas BAA was inexpensive in time and friction; signing it early kept the path clear for the moment user data starts flowing. Today we still have zero PHI in the system - we capture email and plan selections, not medication or anything else that turns into PHI - so we are still pre-PHI, BAA already in hand for when it matters.
The takeaway is not “defer BAAs until you have to.” It is: if the BAA is cheap to sign, sign it. If it is expensive (Enterprise tier, custom legal review, multi-week procurement), defer until you actually need it AND have a plan to migrate off if it does not come together in time.
The honesty test: be clear-eyed about what data is ACTUALLY flowing through which vendor right now. If you cannot say with confidence what is flowing where today, fix that BEFORE worrying about BAAs. You cannot prioritize a list you cannot see.
Discipline 2 - do not over-invest in compliance scaffolding for an audit 12+ months out.
This is the PostHog HIPAA Cloud story from §3. Our reflex was “EDE audit is coming, build a self-hosted analytics moat.” The corrective insight was “the audit is twelve-plus months out; PostHog's HIPAA tier covers the bar I need today; design the integration so the swap to a stricter stack at audit time is a config change, not a rebuild.”
The general rule: build to the bar that applies in your current quarter. Use the swappability pattern from §4 to keep the upgrade path open. Trust that you will do the harder work when the audit pressure actually arrives, because by then you will know more, the vendor landscape will have moved, and your build resources will be much less precious than they are today.
The take:do not fabricate timelines, either way. Auditors and regulators have heard every variant of “we are working on it,” and also every variant of “we built this elaborate thing for an audit we do not actually have to face.” Both reflect poorly.
Specific landmines
Watchouts from our experience.
This section is in progress. Coming next: the Bedrock Claude quota approval saga (the “I thought the BAA was the hard part” moment), our current voice-vendor compliance posture, the Resend-to-AWS-SES migration story, the synthetic- data discipline lesson from our HubSpot incident, and the per- env vs management-account quota fragmentation pattern.
If you want the in-progress version, the Claude prompt and companion markdown in §11 already carry the broader patterns; check back here for the lived-experience vignettes.
Founder-honest retrospective
What I'd do differently if I started over.
In progress. The three to five specific things I would change with hindsight. Coming next.
Take this conversation deeper
A Claude prompt and a companion. For your specific stack.
The page above is the framework. For a tailored conversation, paste the prompt below into a fresh Claude conversation (Claude Code, claude.ai, or the API - any will work). Claude will ask you about your stack and walk through the BAA and architecture decisions specific to your situation.
The companion markdown carries the substance Claude can reference during that conversation: the deep vendor table per class, the EDE-vs-HIPAA layer-by-layer enumeration, the AWS umbrella decision framework, the swappability adapter checklist. Drop it into your Claude project (or attach it to the conversation) so Claude has the full context.
Step 1 - The Claude prompt
Copy this into a fresh Claude conversation. It bootstraps the role, the structure, and the constraints.
Step 2 - The markdown sources (for AI)
Two clean markdown files Claude can ingest directly. Attach them to your Claude project, paste them into the conversation, or let Claude WebFetch them. The first is this whole page as markdown; the second is the deep reference appendix (vendor table, EDE layer-by-layer detail, decision frameworks).
Read this before you act on any of it
Honest disclaimers.
Not legal advice. I am a founder, not a lawyer. Talk to a lawyer with HIPAA experience for anything load-bearing - BAA template language, breach-notification clocks, state- specific privacy laws, vendor-contract review. The cost of one hour of attorney time is much smaller than the cost of one mistake the attorney would have caught.
One founder's path. Your situation will differ. Our stack is shaped by our specific go-to-market (consumer ACA enrollment in 31 US states, with a CMS EDE obligation looming next year). If yours is different, your answers will be different too.
Time-bounded information. This is current as of the date stamped at the foot of this page. The vendor landscape moves: BAA tiers change, providers retire, FedRAMP statuses update, regulations evolve. Check primary sources (the vendor, CMS, HHS) before acting on anything specific.
Open to corrections. If you find an error or something has changed materially, reach me at taha@askflorence.health. I will update the page.
Published 2026-05-28. Stack and vendor references current as of that date.