Cursor, Lovable, Replit, Bolt, and Claude Code have made it genuinely possible for a doctor or a small team to build a working app in a weekend. Then someone asks "is it HIPAA compliant?" — and the honest answer is "the UI is fine; the part that matters isn't." Here's why, and what to actually do.
What HIPAA actually requires (the short version)
HIPAA isn't a checkbox in your frontend. It governs protected health information (PHI) and the vendors that touch it. The parts that bite a builder:
- Business Associate Agreements (BAAs). If a vendor acts as your business associate and stores, processes, or transmits PHI, get written assurances in a BAA before sending PHI.
- Encryption at rest and in transit (formally an "addressable" specification — in practice, implement it or document a defensible reason you didn't).
- Access control + audit. Minimum-necessary access, and a tamper-evident record of who saw or changed what.
- Breach notification obligations if it goes wrong.
Notice what these have in common: they live in the data layer and the vendor relationships — not the UI an AI tool is great at generating. (And the obligatory line, meant sincerely: this is a builder's orientation, not legal advice — compliance still needs your own risk analysis and counsel.)
What AI coding tools do well
A lot, honestly. They scaffold the project, build the screens and forms, wire up state, and can even emit FHIR-shaped data models. For the workflow — the part a clinician actually pictures — vibe-coding is a real superpower. Keep doing it.
What they can't do — and quietly get wrong
- A BAA on the coding tool isn't a BAA for your app. Even when a coding tool offers a BAA on a specific plan, it covers that tool handling your code — not your running app's data. Every vendor your deployed app sends PHI to (your database, the model API, logging, analytics) needs its own agreement if it acts as a business associate. A code generator can't produce that for you.
- They generate compliant-looking code. An AI will happily write a function named
encryptPHI()that base64-encodes a string, skip the audit log entirely, drop secrets into client-side code, or log PHI to the console. It looks done. It isn't. - They don't enforce access control. "Only a patient's own clinician can read their notes" is an authorization model someone has to design and enforce server-side. Scaffolded CRUD doesn't do it.
- They leak PHI to non-BAA services. Piping records into a model API, an analytics tool, or a logging service that hasn't signed a BAA is a violation — and it's the default in most generated code.
Does your coding tool sign a BAA?
This question only covers the tool processing your code — not your running app's data. Vendor terms and plan names change, so do not rely on a blog table. Verify the current legal terms for the exact plan and data path before sending anything resembling PHI through a tool.
| Question to verify | Why it matters |
|---|---|
| Does this exact plan offer a signed BAA? | Enterprise and default tiers often have different legal terms. |
| Will prompts, files, logs, traces, or support tickets contain PHI? | A tool can touch PHI outside the code editor path you were thinking about. |
| Is data used for training, retained, or routed to subprocessors? | The BAA and privacy terms need to cover the real processing path. |
| Does the BAA cover the deployed app's model, database, logs, and storage? | A coding-tool BAA does not cover separate vendors your running app calls. |
And again: a BAA on the tool that writes your code is not a BAA for the database, model API, or logging service your deployed app sends PHI to. Those are separate vendors with separate agreements.
Five compliant-looking-but-wrong patterns AI emits
These show up constantly in generated healthcare code. Each one passes a casual read and fails an audit:
- A fake
encryptPHI()that base64-encodes (or just hashes) a string and calls it encryption. - No audit log — reads and writes to PHI happen with no tamper-evident record of who did what.
- Secrets client-side — API keys or DB credentials shipped in the browser bundle where anyone can read them.
- PHI in
console.log— patient data dumped to logs that flow to a non-BAA log sink. - No server-side authorization — access checks live in the UI, so any caller hitting the API directly reads every patient.
Where does PHI actually go?
Trace one record through a typical vibe-coded app. Every hop that stores, processes, or transmits PHI needs its own BAA:
- Browser (your UI) — captures the data. Needs a BAA? No (it's the user's own device), but it must not persist or leak PHI.
- Your API server — receives and routes the data. Needs a BAA? Yes — the hosting/compute vendor.
- Your database — stores the record. Needs a BAA? Yes.
- Model API — summarizes or drafts from the record. Needs a BAA? Yes.
- Logs & analytics — anything PHI lands in. Needs a BAA? Yes if PHI reaches it — so keep PHI out, or use a BAA-covered sink.
So where's the line?
Vibe-code the workflow. Don't vibe-code the clinical data layer. The data layer is where PHI lives, where the BAA applies, where encryption and audit and access control have to be real and enforced — and where "generate me something" is exactly the wrong move.
The practical pattern: build your UI and workflow with whatever AI tool you love, on top of a clinical backend that handles the hard, regulated parts for you — runs in your cloud, where we're not a Business Associate (you operate under your own AWS BAA), or as a managed option designed to sign a BAA (early access today), with encryption, automatic audit + provenance, and per-patient authorization built in, and FHIR underneath for portability.
That's the gap bonfireDB is built for (open source, early access): the safe clinical data layer beneath the app you vibe-code. See the security & HIPAA model for how the BAA and data-residency story works, or FHIR explained for the data side.
Keep reading
- The backend an AI scribe actually needs
- Building an AI scribe in a weekend (the honest version)
- Clinical authorization and audit — the part a prompt cannot enforce for you.
- Clinical context engineering for FHIR agents — why the agent read path is part of the safety boundary.
TL;DR
- You can vibe-code the app. You cannot vibe-code HIPAA compliance.
- A BAA on your coding tool ≠ a compliant app — your app's data-layer vendors each need their own BAA, and the AI emits compliant-looking code that isn't (fake encryption, no audit, PHI in logs/prompts, no real access control).
- Compliance lives in the data layer + vendor relationships — keep those real.
- You build the app. Bonfire keeps the clinical data layer on infrastructure built for PHI.