How to Build a HIPAA-Compliant App in 2026

TL;DR: Building a HIPAA-compliant app takes a platform with the right infrastructure, like encryption and a signed BAA, plus your own correct setup of privacy rules, access controls, audit logging, and PHI-safe workflows. Map your PHI flows before you build, and confirm your platform supports HIPAA under a signed BAA. Platform compliance alone doesn’t make your app compliant.

Compliance gaps have a way of surfacing only after healthcare builders have already shipped something. By then, it usually means an expensive rebuild or a delayed launch. That’s why HIPAA compliance needs to be part of your architecture decisions from day one.

Even a platform that supports HIPAA won’t do the work for you. You’re the one who has to configure it, use it, and keep it that way. By the end of this guide, you’ll know how to map your PHI flows, build in the right safeguards, set up compliant workflows, and pick a platform based on BAA availability and security features.

What makes an app builder HIPAA-compliant

Protected health information, or PHI, is any information about a patient’s health, care, or payment that can identify them. When that information exists electronically (which is nearly always true for an app), HIPAA calls it ePHI. A HIPAA-compliant app builder gives you the infrastructure and tools to protect it.

Three things every HIPAA-compliant app builder must provide:

• A signed business associate agreement: A BAA is a legally required contract between you and any vendor that creates, receives, maintains, or transmits PHI on your behalf. If you’re the covered entity or business associate, you need one with every vendor that touches PHI. Skip it, and you’re violating HIPAA no matter how secure the platform is. Penalties can run up to $2,190,294 per violation. Some platforms only offer a BAA on higher-tier plans, and some don’t offer one at all. Either way, you can’t handle PHI there without it.
• Technical safeguards built into the platform: Technical safeguards are the tech and policies that keep ePHI protected. Think access controls, unique user IDs, automatic logoff, audit controls, and encryption. HIPAA calls some of these “required” and others “addressable,” which just means you have some flexibility in how you meet them, not that you can skip them. A HIPAA-compliant app builder either builds these in for you or hands you the tools to set them up yourself. Either way, having the tools isn’t the same as using them. You still have to configure everything correctly.
• PHI separation and access control: Store ePHI separately from non-sensitive data where you can, and scope access to only the users and roles that need it. HIPAA calls this minimum necessary access. Row-level and field-level permissions make this achievable without writing custom code, but you’re the one who has to define those rules correctly for your app.

Once you know what to look for in a platform, you can evaluate whether HIPAA applies to your specific app.

Does your app actually need to be HIPAA-compliant?

HIPAA kicks in when your app handles PHI for a covered entity, or when your app itself acts as a business associate to one. Covered entities are organizations that directly provide healthcare, like hospitals, clinics, health plans, and healthcare clearinghouses. Business associates are the vendors and contractors working on their behalf, creating, receiving, maintaining, or transmitting PHI for them.

Ask yourself these five questions to figure out whether HIPAA applies to your app:

1. Does your app collect, store, or transmit protected health information on behalf of a healthcare provider, health plan, or healthcare clearinghouse?
2. Do you have a direct relationship with a covered entity that involves handling PHI for them?
3. Does your app pull data from, or send data to, an EHR or another covered entity’s system?
4. Would the data in question identify a specific person’s health condition, treatment, or payment history?
5. If your app is used entirely by consumers with no link to a healthcare provider or insurer, does any other law, like the FTC Health Breach Notification Rule, still apply?

Here’s how that plays out in practice:

• A telehealth platform that stores appointment records and clinical notes for a medical practice: HIPAA applies. The platform handles PHI on behalf of the practice (the covered entity) and requires a BAA.
• A standalone wellness or fitness tracker that a consumer uses independently, with no connection to a healthcare provider: HIPAA likely doesn’t apply, though other federal or state privacy rules may. If the app doesn’t receive data from or send data to a covered entity, HIPAA doesn’t govern it.
• A patient portal built by a hospital’s operations team to give patients access to their own records: HIPAA applies. The hospital is the covered entity, and the portal handles PHI directly.

Once you’ve confirmed HIPAA applies, the next step is setting the architectural foundation.

How to set your foundation before you build

The platform can provide the tools, but the planning and configuration work is on you.

Map where PHI lives and moves

A PHI map is a document that identifies every place ePHI is collected, stored, processed, and transmitted in your app. You can’t protect data you haven’t located.

Start by documenting three categories:

• Collection points: This covers where PHI enters your app, such as intake forms, appointment booking flows, and EHR integrations. If users upload medical documents or enter symptom data, those are collection points.
• Storage locations: This means identifying which database fields contain PHI, and separating identifiers (name, date of birth, insurance ID) from clinical data (diagnoses, prescriptions). Map each field to determine which need field-level privacy rules.
• Transmission paths: Check whether PHI travels to third-party services such as a messaging provider, an analytics tool, or an AI model. Each of those vendors needs a BAA if they receive ePHI. For example, if your app sends patient appointment reminders via email, the email service provider must sign a BAA.

The PHI map becomes your audit evidence and your guide for setting privacy rules in the next build phase.

Choose HIPAA-eligible infrastructure

HIPAA-eligible infrastructure means the vendor has signed a BAA and set up their systems to meet HIPAA’s requirements. Even then, you’re the one who has to configure those systems correctly. And if a platform doesn’t support HIPAA-compliant apps under a signed BAA, you can’t handle live PHI on it, no matter how strong its security features look.

When you’re evaluating platforms, look for three things:

• BAA availability: Does the platform offer a BAA today, and on which plan? Some only offer one on enterprise tiers, and some don’t offer one, or support HIPAA, at all. Without a signed BAA, you legally can’t handle PHI there.
• Data residency and hosting: Is the data stored on HIPAA-eligible cloud infrastructure? AWS and Google Cloud both publish BAAs and lists of HIPAA-eligible services, so check current coverage for whichever cloud your platform runs on. Data residency can also affect other privacy or regulatory requirements, so confirm what your jurisdiction requires before you pick a hosting location.
• Portability: Can you export your data, and your app logic if you need to, should you ever move platforms? Being able to walk away reduces your operational and compliance risk. Check your export and migration options before you commit to a platform.

Which technical safeguards to build into your app

The HIPAA Security Rule splits safeguards into three buckets: technical, physical, and administrative. This section is all about the technical ones, the safeguards that live inside your app and that you have to configure yourself.

Physical safeguards, like device security and facility access, and administrative safeguards, like policies and training, are on you too. Even when a platform hands you supporting infrastructure, setting it up correctly for your app is still your job.

Encryption at rest and in transit

Encryption at rest means the data sitting in your database is scrambled, so it’s useless to anyone who gets their hands on the storage itself. Encryption in transit means data moving between your app and a server, or between servers, gets encrypted with TLS along the way. AES-256 is the go-to standard for encryption at rest right now.

Here’s what to check on your platform:

• At rest: Check whether your platform encrypts the database by default or whether you have to switch it on, and make sure it’s using AES-256 or better. Most HIPAA-ready platforms handle this automatically, but it’s worth double-checking.
• In transit: Make sure your app enforces HTTPS everywhere, and check every external connection point, including webhook calls and API integrations, for spots where PHI could slip through unencrypted.
• Keys: Find out who holds the encryption keys, and whether the platform rotates them automatically or leaves that up to you. Automatic rotation cuts down the risk of a key getting compromised over time.

Encryption at the platform level won’t save you from your own mistakes. If PHI ends up in a URL parameter or a notification payload, it travels unencrypted no matter how well your database is locked down. Check your logs, analytics tools, and any third-party integrations without a BAA to make sure PHI hasn’t snuck in.

Role-based access control and authentication

Role-based access control, or RBAC, just means each user’s access depends on their role. A patient sees only their own records, a clinician sees records for their assigned patients, and an admin sees everything. HIPAA’s minimum necessary standard is what pushes you toward this level of granularity.

Here’s what to put in place:

• Unique user IDs: Give every user their own unique ID. No shared logins. HIPAA requires this, and you need it anyway if you want audit logs that actually mean something, since shared logins make it impossible to tell who did what.
• Role definitions: Map out your roles before you start building, things like patient, clinician, admin, and billing staff, and decide what each one can see and do. A billing staff member, for instance, needs insurance information but not clinical notes.
• Field and row-level permissions: In a visual development platform, privacy rules let you control which records a user can query and which fields they can read or write, no SQL required. You still have to set those rules up correctly for your app. A patient, for example, should only be able to read their own medical records, not everyone’s.
• Multi-factor authentication: Turn on MFA for any role that touches PHI. It’s already a strong security practice, and proposed HIPAA Security Rule changes would make it mandatory for all ePHI access. MFA just means a second verification step beyond a password, like a code sent to your phone or a fingerprint.
• Session timeouts: Automatic logoff after a period of inactivity is a HIPAA technical safeguard. Set your timeout window based on your risk analysis and organizational policy. Most organizations keep it short for anything touching PHI.

Audit logs and data integrity

An audit log is a tamper-evident record of who accessed or changed PHI, when, and from where. HIPAA requires audit controls, meaning you need the ability to record and review activity in any system that touches ePHI.

A solid audit log captures:

• Access events: Who viewed a patient record, when, and from which IP or device. If a clinician opens a patient chart, for instance, the log should capture their user ID, timestamp, and IP address.
• Modification events: Who changed a field, what it used to say, and what it says now. This is what keeps your data trustworthy: If a diagnosis changes, the audit trail shows exactly who made the change and when.
• Admin events: Configuration changes, permission updates, new user accounts. If an admin grants a new staff member access to patient records, that needs to show up in the log too.
• Failed access attempts: Login failures and unauthorized access attempts, the kind of activity that can tip you off to a breach in progress.

Keep your audit logs safe from tampering or deletion, and store them according to your risk analysis and compliance needs. How long you keep them should come down to your organization’s HIPAA documentation and legal obligations.

Some platforms hand you server logs or configurable logging tools out of the box. Others don’t. Either way, check whether HIPAA-grade audit logging is actually built in, what it captures, and whether you’ll need to configure extra workflows to fill the gaps.

How to build compliant workflows and integrations

HIPAA compliance extends to every workflow that touches PHI and every external service your app connects to. These are configuration decisions you make as the builder, regardless of whether your platform is HIPAA-compliant.

Build PHI-safe workflows

Cover these workflow-level decisions that protect PHI:

• Keep PHI out of notifications: Push notifications, SMS, and email should never contain PHI in the message body. A notification can say “You have a new message from your care team,” not “Your lab results for diabetes are ready.” The distinction matters because notifications often travel through third-party services that may not have signed BAAs.
• Scope API calls to minimum necessary data: When your app calls an external service, only send the fields that service actually needs. Don’t pass a full patient record to a scheduling API that only needs an appointment time. This reduces the risk of exposing PHI to vendors who shouldn’t have access to it.
• Log workflow events: Every workflow that reads, writes, or transmits PHI should generate an audit event. In a visual workflow editor, this means adding a logging action to relevant workflows. For example, “When a clinician views a patient record, create an audit log entry.”

Connect to EHRs and third-party services safely

An electronic health record (EHR) is the digital record system used by healthcare providers to store clinical data. EHR integrations are common in healthcare apps, and they’re one of the riskiest points for PHI to leak out.

Follow these practices:

• Require BAAs from every integrated vendor: Any third-party service that receives ePHI, such as a messaging provider, an analytics platform, an AI model, or a payment processor, must sign a BAA. If a vendor won’t sign one, don’t send them PHI. Verizon’s 2026 Data Breach Investigations Report found third-party involvement now shows up in 48% of breaches, making every unsecured integration a potential vector of attack. This applies even to seemingly innocuous services like analytics tools. If they receive patient identifiers, they need a BAA.
• Use server-side API calls: PHI should travel through your backend, not through client-side JavaScript that a user could inspect. In a visual development platform, this means routing PHI through server-side workflows rather than browser-side calls. Client-side calls expose data to the user’s browser console, where it could be intercepted or logged.
• Use standards-based healthcare APIs where appropriate: FHIR (Fast Healthcare Interoperability Resources) is a widely used standard for exchanging healthcare data between systems. Many EHRs expose FHIR APIs, and validating mappings carefully reduces the risk of integration errors that could expose PHI.

What to look for in a platform that supports HIPAA-compliant app building

It’s entirely possible to build a HIPAA-compliant app without hiring developers. You just need a platform that makes the required safeguards possible without custom code and that currently supports HIPAA-compliant apps under a signed BAA, and you need to set it up correctly.

Even with a signed BAA and full HIPAA compliance, your app doesn’t build itself. You still have to do that part right.

Here’s a checklist to help you evaluate platforms:

When you check platforms against this checklist, look at their current, first-party documentation, not just their general security reputation. Some platforms with strong security otherwise still don’t support HIPAA-regulated workloads yet. Bubble is a good example: strong general security, but official documentation that doesn’t yet support HIPAA-compliant apps. More on where Bubble fits later in this guide.

Where Bubble fits for healthcare-adjacent apps

The safeguards and workflows covered so far apply no matter what platform you build on. Since this guide is written for builders without a dev team, it’s worth getting specific about where Bubble fits into that picture.

If you’re building something HIPAA-regulated

We’re not there yet. Bubble doesn’t currently meet HIPAA standards, so apps built on Bubble won’t achieve HIPAA compliance today, regardless of our other security features.

But we’re working on it. Our co-founder Emmanuel shared in an July 2026 community update that HIPAA compliance is in progress, with a dedicated Enterprise plan targeted for by the end of 2026. If HIPAA is part of your roadmap, keep an eye on that update.

If you’re building something healthcare-adjacent

Plenty of healthcare-related apps never touch PHI at all: marketing sites, provider directories, internal admin tools without patient data, wellness apps with no tie to a covered entity, or non-clinical prototypes. For these use cases, here’s what Bubble brings to the table:

• Generate fast, refine by hand: Describe your app in plain language, let Bubble AI generate a foundation, and refine the UI, database, workflows, and API integrations visually from there.
• Privacy rules review by Bubble AI: When the Bubble AI Agent (beta) creates data types that look like they hold sensitive information, it can add privacy rules automatically. Give those a look and refine them yourself before you deploy, since the Agent won’t always add rules to data types you’ve already created.
• Security dashboard: Bubble’s built-in security dashboard scans your app for vulnerabilities before you deploy: exposed API keys, misconfigured privacy rules, database leak risks. It lives right in the editor and the deploy flow, with a “Fix in the editor” button that takes you straight to the problem.
• Encryption and infrastructure: Bubble runs on AWS, with TLS encryption in transit and AES-256 at rest through RDS. It’s also SOC 2 Type II compliant.
• Visual workflows: Every workflow in Bubble is a visible, editable flowchart, so you can inspect every step and confirm data isn’t heading somewhere it shouldn’t. Visibility alone isn’t compliance, but it makes mistakes a lot easier to catch before they become problems.
• Native mobile from one platform: Bubble builds native iOS and Android apps from the same visual editor, sharing the same backend, database, and privacy rules as your web app. No separate mobile codebase, no second set of security settings to maintain.

You’re responsible for your own compliance

If you need to build something HIPAA-regulated today, go with a platform whose current documentation backs HIPAA under a signed BAA, and get legal and security counsel involved before you touch any PHI. Whatever you build with, platform compliance and app compliance are two different things. The platform can hand you the pieces, but putting them together correctly is on you.

And it doesn’t stop once you launch. Keep your PHI map current, revisit your privacy rules and audit logs as your app grows, and bring in legal and security review before anything touching PHI goes live.

Frequently asked questions

Does a HIPAA-compliant app builder automatically make my app HIPAA-compliant?

No. A HIPAA-compliant app builder provides the infrastructure and tools, like encryption, a BAA, and access controls, but you’re responsible for configuring privacy rules, scoping access by role, logging PHI events, and training your team.

Can I build a HIPAA app on Bubble today?

No, not yet. Bubble’s current official documentation says the platform does not support HIPAA-compliant apps and does not recommend using Bubble for apps that require HIPAA compliance today. Bubble has publicly stated that HIPAA compliance work is in progress, targeted for the second half of 2026 under a dedicated Enterprise plan, so this could change. Until that support is confirmed in Bubble’s official documentation, don’t build a PHI-handling app on Bubble. For non-PHI apps, healthcare-adjacent tools, and prototypes that do not involve regulated patient data, Bubble’s security features (privacy rules, security dashboard, SOC 2 Type II, AES-256 encryption at rest, TLS in transit) remain useful.

Can I use a general-purpose AI model like ChatGPT in a HIPAA-compliant app?

Do not send PHI to an AI service unless the specific product, account, and use case are covered by an appropriate BAA and configured for healthcare requirements. OpenAI states that it offers a BAA to ChatGPT for Healthcare and API healthcare customers to support HIPAA compliance. Verify the specific eligible product, endpoint, and contractual requirements before sending PHI.

What is the difference between a BAA and HIPAA certification?

There’s no such thing as HIPAA certification for software platforms. HIPAA doesn’t issue certifications. A BAA is a legal contract that establishes the vendor’s responsibilities for protecting PHI. SOC 2 Type II compliance is an independent security audit that provides evidence of strong security controls, but it’s not the same as HIPAA compliance.

Do HIPAA rules apply to mobile apps differently than web apps?

HIPAA applies to the data and the workflows, not the device type. A mobile app that stores or transmits ePHI on behalf of a covered entity must meet the same technical safeguards as a web app — encryption, RBAC, audit logging, and a signed BAA with the platform. Mobile apps introduce additional risk surfaces: push notifications (which must not contain PHI), offline storage (which must be encrypted), and device-level authentication (which should enforce MFA or biometric verification).