HIPAA Compliance for AI-Built Apps

A hipaa supabase configuration starts on the Team plan or higher. The Pro plan does not sign a BAA and does not expose the full audit logging features the framework expects. On the Team plan, the first step is to enable at-rest encryption with a customer key, turn on the Postgres audit extension, and raise log retention to at least 90 days. The database optimization expert engagement handles the database-layer posture end-to-end.

RLS is the single highest-impact control. Every PHI-bearing table gets a policy that checks auth.uid() against a provider-to-patient assignment table, and every admin query runs through a server-side service role with its own row of the audit log. The CI pipeline includes a test that enumerates tables and fails if any table reachable from a PHI join graph lacks RLS. This single test catches more future regressions than any other control in the stack.

Audit logging at the database level is necessary but not sufficient. A hipaa audit log ai app also needs application-level middleware that captures the business-level event — "provider X viewed patient Y at time T for reason R" — because raw SQL logs cannot answer that question. We install the middleware, the hash-chained table, and the nightly verifier together.

A baa-ready ai app has a BAA executed with every vendor in the PHI path. The review starts by enumerating that path: the frontend host, the backend host, the database, the email provider, the SMS provider, the analytics vendor, the error tracker, any AI model provider, any video vendor. Each one either signs a BAA or is removed from the path. Most AI-built healthtech apps start with five or six vendors that do not sign a BAA; we finish with one or two and a documented legal posture for each.

The common traps: OpenAI signs a BAA on its Enterprise API tier, not the standard API. Anthropic signs a BAA on a per-customer basis. Resend and Postmark sign BAAs on enterprise plans. Twilio signs for voice and SMS but only with explicit configuration. Sentry signs on its Business tier. If the AI generator wired any of these on their free or standard tiers, you either upgrade or replace them. We handle both paths in a healthtech AI app rescue engagement.

A hipaa telemedicine app or patient portal demands stronger auth than a consumer app. Provider accounts require TOTP MFA, session rotation on sign-in and on privilege elevation, and a short idle timeout. Patient accounts require at minimum email-based magic links with short TTLs, forced password reset on first login if a password is used, and lockout after repeated failed attempts. The auth specialist engagement ships all of this in a single week.

Session management is where AI-generated code most often fails. The generator wires a long-lived JWT in localStorage and never rotates it. For HIPAA, the session token must rotate on every privilege change and on a configurable idle window, and it must never live in a place a cross-site script could read. We move sessions to httpOnly cookies, add a rotation middleware, and instrument every auth event into the audit log.

Retention rules are often the most surprising part of a HIPAA rescue. A patient cannot ask to have their clinical record deleted. They can ask for it to be amended, and they can ask for an accounting of disclosures. The AI-generated scaffold ships a hard DELETE on the patient row because the generator learned from consumer apps where hard delete is the right default. We swap to a soft-delete pattern: a tombstone flag, a retention timer keyed on matter close, and a scheduled purge job that runs after the retention window expires.

The accounting-of-disclosures requirement is best handled by the same audit log that satisfies §164.312(b). A query against the audit table by patient ID returns every disclosure to every provider, admin, or integration, which is exactly what the regulation asks for. We ship the query as a canned report the compliance officer can run on demand. Related reading: our healthtech Cursor case study documents the full playbook.

A HIPAA compliance consultant writes the Security Risk Assessment, the policies, and the training program. A HIPAA-aware developer writes the code that implements the controls those documents describe. You need both, but in different phases. Before a pilot with a clinic, the developer work dominates: RLS, audit logs, BAAs, encryption, MFA. Before a SOC 2 audit overlay or a larger health system contract, the consultant work dominates: the written risk assessment, the policies, the annual review cycle.

Afterbuild Labs is the developer half. We do not write the Security Risk Assessment and we do not sign attestations. What we do is make sure that when a consultant or auditor walks in, the code and the infrastructure already satisfy the controls they are measuring. Pair us with a HIPAA consultant for the full posture. Related services: security audit, emergency triage. Platform-specific rescues: Lovable developer, Bolt developer. Case studies: Cursor healthtech rescue, fintech Lovable rescue.