Best Boilerplates for Healthcare & Telehealth Apps 2026

TL;DR

Supastarter + AWS is the most practical foundation for HIPAA-compliant SaaS — replace Supabase with AWS RDS, add field-level encryption, audit logs, and sign BAAs with every vendor.
No boilerplate ships HIPAA-ready out of the box. HIPAA is a configuration and legal layer you add on top, not a checkbox a template can tick for you.
MedusaJS works for pharmacy e-commerce (medication subscriptions, OTC retail) but lacks clinical data handling — do not use for PHI-heavy workflows.
For full telehealth products, Daily.co gives you BAA-eligible video infrastructure in under an hour; the bigger challenge is intake forms, patient portals, and appointment reminders.
If EHR integration is a core requirement, plan for 3–6 months of implementation time regardless of boilerplate — FHIR and HL7 integration complexity dwarfs the boilerplate choice.

Building healthcare software in the United States means operating inside HIPAA's regulatory perimeter whether you like it or not. The moment your application stores, processes, or transmits Protected Health Information — names combined with diagnosis codes, prescription details, appointment records, lab results — you're a Covered Entity or Business Associate and HIPAA applies. This is not a suggestion.

What that means technically: you need BAAs with every cloud vendor touching PHI, encryption at rest and in transit for all PHI, audit logs for every access to protected data, access controls enforced at the application layer, and a breach notification process. Most popular SaaS-friendly platforms (Vercel, Supabase free/pro tier, Cloudinary, Resend) either don't offer BAAs or bury the BAA option behind enterprise plans.

The right framing is not "which boilerplate is HIPAA compliant?" — none of them are, and that's the wrong question. The right question is "which boilerplate gives me the cleanest foundation to build HIPAA compliance on top of?" That answer is usually a well-structured Next.js or Node.js boilerplate deployed to AWS with specific service choices substituted in.

Why HIPAA Changes Everything

Most SaaS infrastructure decisions are driven by developer experience: pick the fastest database to provision, the auth platform with the best docs, the hosting provider with the simplest CI/CD. HIPAA turns this upside down. Infrastructure choices are now driven by compliance eligibility first, everything else second.

What a BAA Actually Means

A Business Associate Agreement is a legal contract, required under HIPAA, that a cloud vendor signs to confirm they will handle PHI appropriately, implement safeguards, report breaches, and accept liability for their handling of your patients' data. Without a BAA, you cannot legally store PHI on that vendor's infrastructure, full stop.

The catch: BAAs are typically only available on paid enterprise tiers. AWS will sign a BAA at any paid tier (BAA is in their AWS Service Terms by default). Google Cloud and Azure are similar. But smaller SaaS vendors — Vercel, Supabase, Resend, Cloudinary — require you to investigate each one individually. Some have BAAs on Business plans, some only at Enterprise, some not at all. Your HIPAA compliance posture is only as strong as your weakest vendor.

What gets flagged in a HIPAA audit: any data transmission over unencrypted channels, PHI stored in log files (a common mistake when you log request bodies for debugging), PHI accessible to employees who don't need it, and any vendor relationship without a signed BAA. Audit logs without tamper protection are also a red flag — a log someone can delete is not a compliant audit log.

Technical Requirements That Shape Architecture

HIPAA's Security Rule specifies administrative, physical, and technical safeguards. The technical safeguards that directly shape your architecture are:

Access controls: Every PHI access must be authorized. This means role-based access control at the application layer, not just authentication. A doctor should not be able to read another doctor's patients' records. A billing staff member should not see clinical notes. This level of row-level authorization needs to be intentionally designed.

Audit controls: Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing PHI. This means logging who accessed what PHI and when, not just application-level error logs. These audit logs must be retained for 6 years.

Transmission security: PHI must be encrypted in transit. TLS 1.2+ everywhere. No email transmission of PHI unless encrypted (most email is not HIPAA-safe without a BAA with the email provider and end-to-end encryption).

Encryption at rest: Not explicitly required by HIPAA (it's an "addressable" implementation specification, meaning you must implement it or document why you haven't), but any serious healthcare application treats it as mandatory.

HIPAA-Eligible Services (2026)

Before choosing a boilerplate, choose a HIPAA-compliant infrastructure stack:

Category	HIPAA-Eligible Options	Not HIPAA-Eligible
Database	AWS RDS (with BAA), Google Cloud SQL, Azure SQL	Supabase Free/Pro, PlanetScale Free
Auth	AWS Cognito, Auth0 (with BAA)	Most free tiers
File storage	AWS S3 (with BAA), Google Cloud Storage	Cloudinary, Uploadthing (check BAA)
Email	AWS SES, SendGrid (with BAA)	Resend (check BAA status)
Video	Daily.co, Twilio Video (with BAA)	Zoom (check BAA), standard WebRTC
Hosting	AWS, GCP, Azure (with BAA)	Vercel (check BAA), Netlify

A Business Associate Agreement (BAA) is the legal contract with each vendor confirming they'll handle PHI appropriately. Sign BAAs with every vendor touching PHI.

Healthcare Boilerplate Roundup

No boilerplate ships pre-configured for HIPAA out of the box. You'll configure compliance on top of a standard foundation. Here is an honest assessment of each option.

Supastarter — Best Foundation for HIPAA SaaS

Supastarter is a Next.js + Supabase boilerplate with multi-tenancy, auth, billing, and team management pre-built. For healthcare SaaS, the irony is that you immediately swap out Supabase (their namesake infrastructure component) in favor of AWS RDS. What you keep from Supastarter is the application architecture: the multi-tenant data model, the billing integration patterns, the auth scaffolding, and the Next.js structure.

The migration path looks like this:

Supastarter (foundation) →
  Replace Supabase DB with AWS RDS (PostgreSQL)
  Replace Vercel with AWS or self-hosted
  Add encryption at rest for PHI fields
  Add audit logging for all PHI access
  Add BAAs with all vendors

This is not a clean off-the-shelf solution — it requires real engineering work to make the substitution, add the compliance layer, and validate that no PHI leaks into logs or non-compliant services. Budget 2–4 weeks of infrastructure work before you touch product features. But the alternative — building multi-tenancy and billing from scratch — takes far longer. Read the full Supastarter review to understand what you're working with before committing to this approach.

MedusaJS — For Pharmacy and Health Commerce

MedusaJS is an open source headless commerce platform built for complex e-commerce. For healthcare applications that look more like e-commerce — medication subscriptions, OTC health product stores, nutraceutical subscriptions, compounding pharmacy ordering — MedusaJS provides a solid foundation.

The gotcha: MedusaJS has no native support for PHI handling, HIPAA audit trails, or clinical data structures. If your pharmacy app stores prescription information, patient medication histories, or anything that qualifies as PHI, MedusaJS is the wrong base. Use it only for the commerce layer, and design the clinical layer separately with appropriate compliance controls.

Where MedusaJS shines is in the order management, inventory, fulfillment, and subscription billing logic that health commerce products need. These are genuinely hard to build well, and MedusaJS's modular architecture lets you swap in AWS storage and databases without restructuring the whole application.

Bento / Custom Health Tech Starters

A handful of GitHub repositories market themselves as "health tech boilerplates" or "telehealth starters." Most of these are undergraduate projects or prototypes that have not been vetted for production HIPAA use. Treat any health-specific boilerplate on GitHub with extreme skepticism — "HIPAA compliant" in a README is a marketing claim, not a legal certification.

The better approach is to use a proven, actively maintained general SaaS boilerplate and apply the HIPAA configuration layer yourself, guided by a healthcare compliance consultant. The boilerplate gives you application structure; the compliance work is yours to do regardless of what template you start with.

Custom Next.js Stack

For teams with significant healthcare domain expertise, building on a minimal Next.js foundation with careful infrastructure selection is a viable approach. You get full control over the data model, no legacy decisions to work around, and can design the compliance architecture from the ground up.

The downside is the time cost. Auth, multi-tenancy, billing, email infrastructure, role-based access control — all of this needs to be built. If you can afford the engineering time and your team understands HIPAA's technical requirements, a custom stack is often more maintainable in the long run than a boilerplate with significant modifications. See our comparison of open source SaaS boilerplates to understand the full landscape before deciding.

Healthcare-Specific Libraries

// Encrypt PHI before storing
import { createCipheriv, createDecipheriv, randomBytes } from 'crypto';

const ENCRYPTION_KEY = Buffer.from(process.env.PHI_ENCRYPTION_KEY!, 'hex');
const ALGORITHM = 'aes-256-gcm';

function encryptPHI(data: string): string {
  const iv = randomBytes(12);
  const cipher = createCipheriv(ALGORITHM, ENCRYPTION_KEY, iv);
  const encrypted = Buffer.concat([cipher.update(data, 'utf8'), cipher.final()]);
  const tag = cipher.getAuthTag();

  return JSON.stringify({
    iv: iv.toString('hex'),
    tag: tag.toString('hex'),
    data: encrypted.toString('hex'),
  });
}

// Always audit PHI access
async function getPatientRecord(patientId: string, requestorId: string) {
  await auditLog({
    action: 'PHI_ACCESS',
    resourceType: 'patient_record',
    resourceId: patientId,
    actorId: requestorId,
    timestamp: new Date(),
    ipAddress: getClientIP(),
  });

  return db.patient.findUnique({ where: { id: patientId } });
}

HIPAA Technical Checklist

The following technical controls are not optional for a production healthcare application. Work through each one before launch.

Audit Logs

Every access to PHI must be logged with: who accessed it (authenticated user ID), when, what they accessed (resource type and ID), from where (IP address and user agent), and what action they took (read, write, delete, export). These logs must be tamper-resistant — stored separately from application logs, ideally in a write-once storage system like AWS CloudWatch Logs with log retention settings that prevent deletion.

Retention: HIPAA requires audit logs to be retained for 6 years from creation or last effective date, whichever is later. Design your log storage with this retention window in mind from day one — retrofitting 6-year retention onto a system that was purging logs monthly is a significant and expensive migration.

Encryption at Rest and in Transit

All PHI fields in your database should use field-level encryption with AES-256-GCM (as shown in the code example above), not just database-level encryption. Database-level encryption protects against disk theft but not against a misconfigured API endpoint serving data to unauthorized users. Field-level encryption means even a SQL injection attack that reads raw rows returns encrypted ciphertext without the application-layer decryption key.

In transit: enforce TLS 1.2 minimum, TLS 1.3 preferred. Disable older cipher suites. For internal service-to-service communication inside a VPC, TLS is still required for HIPAA — not just for external traffic.

Access Controls

Implement role-based access control at the row level. A patient should only be able to read their own records. A provider should only see patients assigned to their practice. An administrator should have audit access but not clinical access. These access rules must be enforced server-side, not just in the UI. Row Level Security in PostgreSQL (or equivalent in your database) is your enforcement mechanism at the data layer.

Breach Notification

HIPAA requires breach notifications to affected individuals within 60 days of discovering a breach, to HHS, and for breaches affecting 500+ individuals in a state, to prominent media outlets in that state. Your application should have an incident response runbook that specifies who is responsible for breach detection, assessment, and notification.

Technically: set up anomalous access alerting. Unusual spikes in PHI access, access outside business hours, bulk exports, or access from unexpected IP addresses should trigger alerts. AWS GuardDuty and CloudWatch Alarms can handle much of this automatically.

Data Retention and Deletion

Medical records retention requirements vary by state (typically 7–10 years for adults, longer for minors). Your application needs a data lifecycle policy and the technical capability to delete or de-identify records when retention periods expire. Soft deletes are not sufficient for HIPAA compliance — you need genuine deletion or cryptographic de-identification when the retention period ends.

Telehealth Product Features

Telehealth is not just video calls. The video connection is usually the smallest engineering challenge. Here's what a complete telehealth product actually requires.

Video Infrastructure

HIPAA-eligible video for telehealth:

// Daily.co — HIPAA-eligible WebRTC
import Daily from '@daily-co/daily-js';

const callFrame = DailyIframe.createFrame({
  showLeaveButton: true,
  iframeStyle: {
    position: 'fixed',
    border: '0',
    width: '100%',
    height: '100%',
  },
});

await callFrame.join({ url: roomUrl, token: meetingToken });

Daily.co provides BAA-eligible video infrastructure designed for telehealth. It handles end-to-end encryption, recording with HIPAA-compliant storage, and waiting rooms.

Twilio Video is the other serious option. More complex API, but deeper programmability — custom recording workflows, real-time participant monitoring, and carrier-grade reliability. Twilio also provides HIPAA BAAs. Avoid Zoom's developer platform for HIPAA unless you've verified your Zoom account has a signed BAA; Zoom's standard developer API does not include a BAA.

Intake Forms and Symptom Capture

Before the video call, patients need structured intake. This means forms with branching logic (if the patient reports chest pain, ask follow-up questions), medical history collection, medication lists, and consent forms. These forms generate PHI immediately, so every form submission response must go through your PHI handling pipeline with encryption and audit logging.

Tools that work well here: Typeform (check BAA), Google Forms (not HIPAA-eligible without Workspace HIPAA configuration), or custom-built forms stored to your compliant backend. For anything capturing clinical data, custom forms with server-side validation stored to your encrypted database is safest.

Patient Portal

A patient-facing portal needs: appointment history, upcoming appointments with the ability to reschedule or cancel, messages from their provider, access to visit summaries and care instructions, and prescription/lab result viewing if applicable. This is a significant surface area — plan for it as a distinct module with its own access control layer.

Appointment Reminders

SMS and email reminders are standard expectations. The HIPAA gotcha: appointment reminder content must be minimal. An SMS saying "You have an appointment tomorrow at 2pm" is generally acceptable. An SMS saying "Reminder: your therapy appointment for depression treatment is tomorrow at 2pm" includes a PHI disclosure (mental health treatment). Design reminder content to confirm the appointment without disclosing the nature of care.

For SMS: Twilio (with BAA) is the standard choice. Configure reminders as a background job that triggers 24 hours and 2 hours before each appointment.

E-Prescribing

E-prescribing is a separate regulatory layer on top of HIPAA. Prescriptions for controlled substances (Schedule II–V) require DEA Electronic Prescriptions for Controlled Substances (EPCS) compliance, which adds identity proofing and two-factor authentication requirements beyond standard HIPAA. For non-controlled medications, e-prescribing services like DoseSpot, Surescripts, or DrFirst provide the pharmacy routing infrastructure — you do not build prescription routing yourself.

EHR Integration Strategy

Healthcare apps frequently need to integrate with existing Electronic Health Record systems. The integration landscape is fragmented, expensive, and time-consuming. Here's what you're actually dealing with.

When to Use an Existing EMR

Building an EHR/EMR from scratch is one of the highest-complexity software projects. Consider:

Epic MyChart API (SMART on FHIR) — Integrate with 350+ hospital systems
Healthie — White-label EHR for telehealth companies
Canvas Medical — API-first clinical platform

For most health tech startups: integrate with existing clinical systems rather than replacing them.

SMART on FHIR and FHIR R4

FHIR (Fast Healthcare Interoperability Resources) R4 is the current interoperability standard required by the 21st Century Cures Act. Any US hospital or health system subject to that regulation (which is most of them) must expose FHIR R4 APIs for patient data access. This is the "highway" that patient data travels on.

SMART on FHIR adds OAuth2-based authorization on top of FHIR — it's the authentication layer that controls which applications can access which patients' data. Implementing a SMART on FHIR client in your application lets you request access to a patient's records at an Epic, Cerner, or any other FHIR-compliant system.

The practical reality: FHIR R4 APIs are inconsistent across vendors. Epic implements FHIR differently from Cerner, which implements it differently from Athena. Data shapes vary, supported resource types vary, and API reliability varies. Plan for vendor-specific adapters rather than a single universal FHIR client.

HL7 v2

HL7 version 2 is the older, more widely deployed integration standard. It uses pipe-delimited flat file messages (not REST/JSON) and runs over TCP/IP connections (MLLP protocol). Despite being 30+ years old, HL7 v2 carries the majority of clinical data in hospitals today — lab results, ADT (admit/discharge/transfer) events, scheduling messages.

Interfacing with HL7 v2 typically requires a middleware integration engine. Tools like Mirth Connect (open source), Rhapsody, or commercial iPaaS platforms like Boomi handle the HL7 message parsing, routing, and transformation. Building direct HL7 v2 parsing in your application is possible but rarely worth the effort when integration engines exist specifically for this purpose.

Integration Timeline Reality

A realistic FHIR integration with a single hospital system takes 3–6 months: 1 month for access application and approval, 1–2 months for test environment access and initial development, 1–2 months for UAT and go-live coordination. Multiply by the number of systems you need to integrate. This timeline is driven by the healthcare organization's IT review process, not by technical complexity.

For early-stage products, APIs like Health Gorilla or 1upHealth provide aggregated FHIR access across multiple health systems through a single integration, dramatically reducing the time to initial clinical data access.

Methodology

This article is based on hands-on evaluation of healthcare technology stacks, review of HIPAA Security Rule technical safeguard requirements, and analysis of production telehealth applications. Boilerplate recommendations reflect practical experience building compliant health tech products, not marketing claims from boilerplate authors. HIPAA compliance details reflect the regulatory landscape as of early 2026 — consult a healthcare compliance attorney for legal advice specific to your application.

For the full landscape of SaaS boilerplates including healthcare-adjacent options, see our HIPAA-compliant boilerplate guide and the StarterPick boilerplate directory.