Base44 for Healthcare: HIPAA Gaps, PHI Risk, and What's Actually Possible

Is Base44 right for healthcare?

Not for production apps that handle PHI. This is the most absolute "no" of any vertical we cover. The reasons are structural, not fixable through hardening:

1. No Business Associate Agreement — without a signed BAA, storing PHI on Base44 is a HIPAA violation. The BAA is a legal precondition, not a paperwork formality.
2. Documented vulnerabilities in 2025 — the July 2025 Wiz/Imperva disclosures revealed SSO bypass, stored XSS, and JWT leakage to user apps. Patches deployed in 24 hours, but the architectural choices that allowed those vulnerabilities (token-in-URL, permissive cross-app scripting boundaries) are still partially in effect.
3. No documented technical safeguards — encryption-at-rest, access-control granularity, audit log retention, and key management are not publicly documented at the level a HIPAA risk assessment requires.
4. RLS defaults open — the same row-level security gap that makes multi-tenant SaaS hard makes patient-data access controls essentially impossible to verify.
5. No breach notification SLA — the platform's status page and outage history do not include formal breach notification procedures.

You can use Base44 for healthcare-adjacent apps that do not touch PHI: wellness trackers, marketing sites, internal tools with synthetic data, public-facing information portals. For anything that touches a real patient record, the answer is a different stack.

What you can build

Healthcare-adjacent uses that are fine on Base44:

• Public health information portals — symptom checkers (without storing user input), provider directories, condition explainer libraries. Static-ish content, no PHI ingestion.
• Wellness and fitness apps without clinical PHI — habit tracking, mood journals (non-clinical), exercise logging. The line is whether the data, in combination, could identify a person and reveal a health condition. "I walked 5,000 steps today" is fine. "I took my anxiety medication today" is PHI.
• Provider-facing reference tools — drug interaction lookups (using a public dataset), dosing calculators, ICD-10 code search. No patient data.
• Healthcare marketing and lead capture — clinic landing pages, appointment-request forms (where the form posts to a HIPAA-eligible scheduling service, not stored on Base44).
• Synthetic-data prototypes — build the workflow on Base44 with fake patient names and ages, validate the UX, then rebuild on a HIPAA-eligible stack for clinical launch.
• Internal admin tools at small clinics — staff scheduling, supply tracking, billing reconciliation against an external EHR. PHI stays in the EHR; Base44 sees only IDs and aggregate counts.

What you cannot do:

• Patient portal with chart access — PHI custody, BAA required.
• Telehealth platform — HIPAA + state telehealth licensure + payment regulations.
• EHR replacement or supplement — even a "lightweight notes" tool that stores clinical observations is PHI.
• Insurance claims management — PHI plus PCI for any payment data.
• Mental health support apps — PHI plus state-specific mental health record laws.
• Pediatric anything — PHI plus COPPA plus parental consent.

Critical patterns for healthcare-adjacent apps

If you are building on Base44 in the healthcare space and have decided you can keep PHI out of the platform, the patterns below keep you on the right side of the line.

1. PHI scope statement: write it down

Document, in your project repo, what counts as PHI for your app. The HHS definition is "any information that can be used to identify a patient and that relates to past, present, or future health, healthcare, or payment for healthcare." Apply it to your specific data model. Be explicit:

PHI Scope (this app does NOT store):
- Patient names + diagnosis
- Patient names + medication
- Patient names + procedure history
- Insurance member ID + claim details
- Provider notes about specific patients

PHI-Adjacent (this app DOES store):
- Aggregate step counts (not tied to medical condition)
- Self-reported mood scores (no clinical context)
- Public provider directory entries (publicly available)

Review this document quarterly. Feature creep moves the line.

2. Data minimization: collect less

Every additional field is a future liability. For a wellness app, you do not need real names — usernames work. You do not need date of birth — age range works. You do not need full address — zip code works for any public-health analytic.

// Good — minimal, deidentifiable
users {
  id, username, age_range, zip_code_first_3,
  signed_up_at, last_active_at
}

// Bad — PHI risk
users {
  id, full_name, dob, full_address, ssn_last_4,
  primary_care_physician, current_medications
}

3. Authentication: treat it as if it were healthcare-grade

Even though you are not storing PHI, healthcare users expect security maturity. Lock down auth on day one:

• Require strong passwords (12+ chars, complexity rules).
• Enforce MFA for any account with admin or staff role.
• Session timeout at 15 minutes for staff, 60 for users.
• Audit every authentication event.
• Rotate session tokens on privilege escalation.

The SSO bypass disclosure showed that Base44's auth layer needs reinforcement at the application level.

4. Audit logging: build it because there is none

There is no native audit log on Base44. For any healthcare-adjacent app, build one:

audit_events {
  id, actor_user_id, actor_role,
  event_type: 'login' | 'logout' | 'view_record' | 'export' | 'admin_action',
  entity_type, entity_id,
  before_json, after_json,        // for state changes
  ip_address, user_agent,
  created_at
}

Write to it from every backend function. Retain for at least 6 years to align with HIPAA-equivalent retention even though you are not technically covered.

5. Encryption posture: layer your own

Base44's at-rest encryption is not documented to a level that satisfies a healthcare risk assessment. For sensitive (non-PHI) fields, encrypt client-side before storing:

// Backend function: encrypt-sensitive.ts
import { encrypt, decrypt } from '@/lib/crypto'; // your crypto layer

const encryptedValue = encrypt(plaintext, perUserKey);
await db.from('records').insert({ user_id, encrypted_value: encryptedValue });

Per-user keys derived from a master key + user salt give you the option to "shred" a user's data by deleting their key, useful for right-to-be-forgotten requests.

Limitations and gotchas

Limitation	Healthcare impact	Mitigation
No BAA	Cannot legally store PHI	Do not store PHI; migrate for production
RLS defaults open	Patient data isolation impossible to verify	Lock down explicitly; do not store PHI anyway
No audit log	HIPAA technical safeguard gap	Build audit_events collection
No documented encryption	Risk assessment gap	Client-side encrypt sensitive fields
July 2025 vulnerabilities	Demonstrated security maturity gap	SSO bypass fix, token theft fix
No breach notification SLA	HIPAA breach notification rule gap	Cannot meet 60-day rule reliably
No SOC 2 Type II at customer-app layer	Vendor risk assessment fails	Document compensating controls or migrate
Webhooks need active users	Patient appointment reminders unreliable	External webhook proxy
No native MFA enforcement	Cannot meet enterprise auth expectations	App-layer MFA + session timeout
AI agent sees your data during generation	Provider note flows risk leakage to LLM	Do not put PHI in prompts

The non-negotiable: no BAA means no PHI. Every other limitation is a hardening problem; this one is a legal problem.

Real-world example architecture

A wellness-tracking app on Base44 that explicitly does not store PHI:

Collections:
- users               (username, age_range, zip3, no real name)
- daily_logs          (user_id, date, steps, sleep_hours, mood_score 1-5)
- challenges          (public group challenges, leaderboards by username)
- challenge_entries   (user_id, challenge_id, score, completed_at)
- audit_events        (every staff/admin action)

External services:
- Auth0 or Clerk      -> robust auth + MFA enforcement
- Postmark            -> transactional email
- Sentry              -> error tracking (configure to scrub PII)
- Cloudflare Worker   -> Stripe webhook reliability if subscription-based

Explicit out-of-scope:
- No medication tracking
- No clinical condition self-reporting
- No provider relationships
- No insurance information
- No real names anywhere in the data model

Compare with the wrong shape — a "lightweight EHR" attempt on Base44, which we have audited and recommended migration in every case:

Collections (DO NOT BUILD ON BASE44):
- patients            (full name, DOB, address, MRN, insurance)
- visits              (provider notes, vitals, diagnosis codes)
- prescriptions       (drug name, dose, prescriber, dispense history)

The second model is a HIPAA covered-entity dataset. It belongs on a HIPAA-eligible stack with a BAA.

Cost to ship

For a wellness app on Base44 (no PHI, 5,000 active users):

Line item	Monthly	One-time
Base44 Pro plan	$80–200	—
Auth0 / Clerk for stronger auth	$25–100	—
Postmark	$30	—
Sentry	$26	—
Cloudflare Worker	$5	—
Build (auth hardening, audit log, encryption layer)	—	$9,000–15,000
Total	~$165–360/mo	~$9,000–15,000

For a HIPAA-eligible healthcare app on AWS or equivalent:

Line item	Monthly	One-time
AWS infrastructure under BAA	$200–800	—
HIPAA-eligible auth (Auth0 with BAA, Cognito)	$100–300	—
Specialized HIPAA tools (Datica, Particle)	$500–2,000	—
Compliance and audit consulting	—	$15,000–40,000
Build (full HIPAA-eligible architecture)	—	$60,000–250,000
Total	$800–3,100/mo	$75,000–290,000

The cost gap is real. Base44 saves money only when you are explicitly not in the HIPAA domain.

Migration off-ramp

If your healthcare app outgrows the no-PHI scope (you sign a clinical partner, you decide to store provider notes, you accept an investor who demands HIPAA-eligibility), migrate before you ingest your first PHI record. Migration target: AWS App Runner + AWS RDS PostgreSQL + Auth0 Enterprise (all under BAAs), or Azure Health Data Services for FHIR-native workflows. Document the migration in your audit trail; the HIPAA Security Rule Risk Assessment will ask.

Migration playbook for Base44 → AWS HIPAA stack covers the architecture and the timeline (usually 12–20 weeks for a small clinical app).

Get this scoped

If you are building anything in the healthcare space on Base44, our $497 production audit is the right first step. We deliver a written assessment of your PHI exposure, a HIPAA-readiness gap analysis (even if you are not yet a covered entity), and a recommendation on whether to harden, migrate, or scope down. Five business days, fixed price.

If your app is pre-PHI and you want it built on Base44 with explicit non-PHI scoping and the audit logging / encryption hardening done correctly, our standard build engagement handles it. We will turn down PHI-touching projects on Base44; the legal exposure is too high for both of us.

Book a 15-minute call to scope your healthcare project

Related

• Base44 for fintech: PCI and SDK lock-in
• Base44 for SaaS: multi-tenancy and security defaults
• SSO bypass and authentication vulnerabilities
• Stored XSS and token theft on Base44
• Migrate Base44 to a self-hosted HIPAA-eligible stack
• Is Base44 production ready?
• Base44 security hardening checklist