← All posts

The backend for healthcare apps: what you keep, what 1health runs

You build the app. 1health runs the plumbing. Three layers: your app on top, which you keep; 1health in the middle; a server and database at the bottom, where AWS and Supabase stop.

You build the app. 1health runs the healthcare plumbing.

AWS and Supabase give you a server and a database. 1health gives you what sits on top of them — the part that takes a year to build: patient identity, reusable connections to labs, health plans, providers, and fax, workflows that cross organizations, and the compliance to prove it. Build your product with Lovable, Vercel, Cursor, Claude, or whatever you like.

Your app, your brand, your customers.

What you keep, what we run

Think of 1health the way you think of Supabase, built for healthcare. You build and own the app. We run the healthcare layer underneath it.

You keep1health runs
Your product, interface, and brandPatient identity and records
Your business rules and clinical logicReusable connections to labs, health plans, providers, and fax
Your care modelWorkflows that cross organizations
Your customers and the patient and provider relationshipWorkflow monitoring and analytics
Your pricing and your businessCompliance: SOC 2 Type II, BAAs, audit logs, access rules

The left column is where your company's value lives. The right column is what every healthcare app needs and no healthcare app is valued for.

HIPAA-eligible is not the same as built on 1health

AWS and Supabase are HIPAA-eligible: on the right plan, with a signed Business Associate Agreement, their infrastructure is allowed to hold protected health information. That is a real and useful thing. It is also where their part ends. Everything your app does with that data — who can see it, how access is logged, how it moves to another organization — is yours to build and prove.

On 1health, your app starts on controls that are already built and independently audited.

HIPAA-eligible (AWS, Supabase)Built on 1health
Protected health informationInfrastructure can legally hold itYour app starts on audited controls
CertificationsTheir SOC 2 covers their infrastructure, not your appSOC 2 Type II platform
BAAsYou sign and track one with every vendor in your stackHandled through the platform's BAA framework
Audit logsYou design and build the loggingAccess logged by the platform
Access controlsGeneral-purpose auth; you write the healthcare rulesHealthcare permission rules built in
Data flow between organizationsNothing; you build it from scratchNative
Ongoing burdenAll of it is yours, continuouslyWe carry the platform controls; you keep your app's policies and training

What the rows mean, in plain English

BAA (Business Associate Agreement). The contract that lets a vendor touch protected health information. With AWS or Supabase you sign one with them, then one with every other vendor in your stack that touches patient data. On 1health, the platform's BAA framework covers the layer we run.

Audit logs. A tamper-evident record of who looked at which patient's data, and when. Eligible infrastructure gives you a place to store logs; you build the logging. On 1health, the platform records every read and write.

Access controls. Each person sees only the patient data they're allowed to see. Eligible infrastructure gives you general-purpose authentication. 1health ships the healthcare permission rules.

Data flow between organizations. Moving patient data safely between a provider, a lab, and a health plan — three separate legal entities, each with its own obligations. Eligible infrastructure gives you nothing here. On 1health it's native. This is where the real value in healthcare lives, and it's the part that takes longest to build alone.

Certifications. Independent proof that the controls work. An infrastructure vendor's certification covers its infrastructure; Supabase's own documentation says its SOC 2 is not a substitute for HIPAA compliance. Your app on top starts at zero. 1health's platform holds SOC 2 Type II today.

What stays yours

A head start isn't a hand-off. On 1health you still own your risk assessment, your team's policies and training, and how your app uses the data it touches. We run the platform controls; you run your business responsibly on top of them.

What this does to your timeline

About 80% of a healthcare app's surface area is the layer in the right-hand column. When it's already there, you build the other 20%.

Transitions of Care is the clearest example: one engineer, 30 days, and the app now serves 40,000–50,000 patients a month across a national payer network. Muse Bio, a regenerative medicine startup, swapped the plumbing behind its early in-house MVP for 1health's and kept building its own product — and expanded nationwide in about a month.

Muse Bio didn't hand over its product to get there. That's the point.

Common questions

Is Supabase HIPAA compliant? No platform is "HIPAA compliant" on its own — compliance belongs to the organization handling the data. Supabase will sign a BAA and allow protected health information on its hosted platform on qualifying paid plans with its HIPAA add-on enabled. Your application's access rules, logging, and data flows remain yours to build and prove.

Does 1health replace AWS or Supabase? No. They provide a server and a database. 1health provides the healthcare layer above that: identity, records, connections to other healthcare organizations, cross-organization workflows, and compliance controls.

Who owns an app built on 1health? You do — the product, the interface, the business rules, the customers, and the pricing. 1health is the layer underneath it.

Which tools can I build with? Whatever you already use. 1health connects through its MCP from Cursor, Claude Code, V0, Replit, and Codex.

Read the docs · See how to get started


Al Hariri, with research and drafting assistance from Claude (Anthropic)