HIPAA-Compliant App Development: What AI Tools Miss

What HIPAA actually requires from your software

HIPAA is a federal rule on how Protected Health Information (PHI) (anything that ties a person to a health condition, a diagnosis, a payment, a prescription, or an appointment) moves, gets stored, and gets accessed. As a founder building a clinical product, HIPAA does not give you a checklist that turns green when you are done. It gives you a posture the software has to be configured to meet, and that posture is audited the moment anything goes wrong.

The first requirement is procurement, not code. Before any PHI moves between you and a vendor (your development partner, your database host, your AI model provider, your error monitoring tool), that vendor has to countersign a Business Associate Agreement (BAA). A BAA is a contract that binds the vendor to the same HIPAA controls your covered entity is bound to. No BAA, no PHI. Most consumer-tier AI products do not offer one. We will come back to that in the third section.

After the BAA, the software has to be configured so a specific set of controls is in place from the first day live PHI enters the system:

• Encryption at rest and in transit. The database is encrypted on disk, the connections to it use TLS, and any backup, log file, or export carries the same encryption forward.
• Role-based access control. A clinician sees their patients. An admin sees the audit trail. A billing user sees claims data, not clinical notes. The app enforces this in code, not in a policy document.
• Immutable audit logging. Every PHI read, write, and export gets logged with the user identity, the record touched, and the timestamp, to a log store the application itself cannot edit or delete.
• Breach-notification mechanics. A documented path for detecting unauthorized access, an internal owner, and a runbook covering the 60-day patient notification window the rule requires.
• Data-disposal posture. A documented retention period, a documented way to purge PHI when a patient requests it, and proof that backups age out on the same schedule.

None of those are switches. They are decisions about how the app is built, hosted, and operated, and they have to be made before patient data shows up, not retrofitted under audit pressure. Your covered-entity counsel signs off on the final posture. The software has to give them something defensible to sign off on.

What Lovable, v0, and Bolt get wrong about healthcare apps

Lovable, v0, Bolt, Cursor, and Replit Agent are designed for one job: get from idea to a working app in hours. That job is real and these tools do it well. The problem is the same scaffold that ships a weekend prototype also ships a clinical app, and the model does not know the difference. Audits of vibe-coded apps routinely find significant data-exposure vulnerabilities shipping before any real users sign up — the same RLS-off, secrets-in-client patterns regardless of whether the app holds a hobby list or PHI.

In a consumer app that is a fixable miss. In a clinical app that is a reportable breach.

The failure pattern repeats across the category. Supabase tables get scaffolded with the anon key in the client bundle and Row Level Security off, which means anyone with the public URL can read the patients table. API keys for OpenAI, Stripe, Twilio land in the front-end build because the tool does not separate client and server secrets. Error monitoring gets wired to Sentry with default settings, which logs the full request payload (including whatever PHI was in it) to a vendor that has not signed a BAA. The chat feature routes user messages straight to the OpenAI standard API with no redaction layer, which puts the patient's name, symptoms, and diagnosis in OpenAI's prompt log on the consumer tier.

The Lovable HIPAA gap is the most common one we see in healthcare-adjacent prototypes: Supabase tables scaffolded with RLS off, the anon key public, a working intake form, and patient data open to anyone who finds the URL. The screens look right. The data is open. Nasir wrote the seven-fix version of this for engineers in the Lovable app security checklist. Worth reading before any healthcare data enters a Lovable build.

None of these are tool bugs. They are the default behavior of a system optimizing for time-to-first-screen. For a vibe app with no PHI that posture is acceptable. For an AI app HIPAA posture, it is the gap between a product and a breach.

What can't AI coding tools configure for HIPAA?

Some of what HIPAA requires is technical configuration the tool could plausibly learn to do. Three things are not, and they are the three that decide whether a HIPAA software startup survives its first audit.

1. The BAA itself.A tool cannot sign a Business Associate Agreement. The founder needs a development partner that countersigns one, and every downstream vendor that touches PHI needs to do the same. This is where most healthcare prototypes hit the first wall. OpenAI's standard API does not include a BAA; moving to the enterprise tier with a signed BAA is a procurement decision and a different billing relationship. Anthropic offers HIPAA-eligible access on a separate track. Azure OpenAI offers a BAA through the Microsoft enterprise agreement. Picking the right tier, getting the BAA countersigned, and wiring the application to that endpoint and only that endpoint is work no scaffolder does for you. Cardinal countersigns a BAA before any PHI moves and verifies the same is in place with every model and infrastructure vendor the build depends on.

2. PHI redaction before any external LLM call. Even with a BAA in place with your model vendor, the cleanest posture is to keep PHI out of the prompt entirely whenever the feature does not require it. The reason is simple: the fewer places PHI lives, the smaller the breach surface, and the easier the audit. Cardinal uses Redactor, an in-house privacy guard that sits between the app and any LLM call, tokenizing PHI before the prompt leaves your perimeter and rehydrating the response on the way back. Until you have something playing that role, every LLM call is leaking PHI in the prompt body and in the prompt log of whatever model you used. No AI coding tool scaffolds this for you because it requires reasoning about which fields are PHI, which calls touch them, and what the substitution policy is: context the tool does not have.

3. Audit posture configured before the first patient signs up. Encryption at rest and in transit, role-based access control, immutable audit logging, retention policy, breach-response runbook: these are not switches you flip after launch. They are decisions baked into the database schema, the deployment, the logging pipeline, and the operational docs from day one. Lovable, v0, and Bolt cannot do this for the same reason they cannot pick a BAA tier: the tools do not know what production posture means in a regulated context. They generate a working screen. The posture has to be wired in by someone who has shipped under HIPAA before and knows what an auditor will ask to see.

What a BAA-grade build looks like in practice

BAA-grade means the technical posture HIPAA requires is configured from day one of production, not retrofitted before an audit. On a Cardinal healthcare engagement that posture ships as a concrete set of artifacts.

The database lives on a HIPAA-grade Supabase or AWS deployment with a countersigned BAA on the hosting side. Every table that touches PHI has Row Level Security on, with policies tied to the user identity in the JWT, not to a flag in application code. Encryption at rest is on at the disk level; TLS is enforced for every connection; backups inherit the same encryption and the same retention rules. An immutable audit log records every PHI read, write, and export, keyed to the authenticated user. Role-based access control is enforced in the database, not just in the UI, so a stolen admin token cannot pull patient records the role should not see.

Every endpoint that calls an external LLM passes through Redactor, so PHI tokenizes before it leaves the perimeter and the model never sees a patient name, an MRN, or a free- text note that has not been scrubbed. Redactor is part of Cardinal's operating stack and runs on every healthcare engagement that includes AI features. A written runbook ships with the build, covering breach response, log retention, audit posture, and the path for a patient data deletion request: the artifact your covered- entity counsel reads when they sign off.

This is the posture Cardinal shipped on Theryo, a mental- health platform running PHI in production traffic, and on AIMS Clinical, an anesthesia information management system used inside operating rooms. Both run on live patient data today. The posture has held through real-world conditions (staff turnover, vendor migration, security questionnaires from enterprise customers) because it was wired in on day one rather than bolted on under pressure.

One framing worth being explicit about: Cardinal builds the technical posture HIPAA-grade software requires. Final compliance certification is a covered-entity decision made in consultation with your counsel. The software gives them something defensible to sign off on. The sign-off itself is theirs.

If you are a founder with a healthcare prototype already built in Lovable, v0, Bolt, or Cursor and PHI is about to flow through it, Vibe Rescue is the 14-day, $4,800 hardening path that adds the BAA-grade layer underneath without rewriting the app on top. If you are starting from a sketch or a memo, Cardinal's HIPAA software development engagement is the from-$28,000 Flagship Build tier that ships the full posture from the first commit. Send your healthcare project for a free written audit and a flat-fee quote comes back within two business days. Mutual NDA countersigned the same day, no discovery call, no obligation if the audit shows the project is in better shape than expected.