How to Build a HIPAA Compliant Portal

Most healthcare operations don’t break in a dramatic way. They break slowly, in an inbox.

Here’s a pattern I’ve seen up close. A small specialty practice produces medical evidence — independent opinions, evaluations, the kind of documentation that law firms and other partners depend on. The intake comes by email. Status updates go out by email. Documents get attached, renamed, re-sent, lost. Someone keeps a spreadsheet to track what stage each case is in, and that spreadsheet is always a little out of date. Then a partner firm stops sending new work, because they can never tell where anything stands without sending yet another email.

Nothing was technically “down.” The operation just got slower and less trustworthy until a client walked.

If you run something like this — a practice, a clinic, a health care service that handles patient or client health information for other businesses — a portal fixes it. One place where clients see status, where your team manages the work, where messages and files live behind real access controls instead of in fifteen separate inboxes. The hard part isn’t the idea. The hard part is that the obvious tools to build it with mostly can’t legally touch the data you need them to hold.

This is a guide to doing it right: what a HIPAA compliant portal actually is, why the popular platforms fail, what passes, and what a real build looks like under the hood.

Why a client portal is worth building

Before getting into the legal and technical mechanics, here is the practical case for the portal in the first place. The same operational pain shows up in almost every healthcare business that grows past a handful of recurring clients, and a well-built portal addresses each piece of it directly.

Email volume drops. The “any update on case X?” message — the one your team answers fifteen times a week — stops getting sent the moment clients can see status themselves. That alone recovers hours a week across an operations team and removes one of the most consistent sources of context-switching for clinicians, paralegals, and case managers.

Client satisfaction climbs because visibility is constant. When a partner firm or referring provider can log in and see exactly where their case stands — received, in review, awaiting documents, complete — they stop wondering whether anything is happening. The relationship moves from “I have to chase them for updates” to “I know what’s going on.” In B2B healthcare work, that’s the single biggest driver of repeat referrals and renewed contracts.

Status is always current. Spreadsheets and shared docs go stale the moment someone forgets to update them. A portal driven by your team’s actual work updates itself — every status change clients see is the same status change your operations dashboard sees, with no manual sync between two systems that always disagree.

Files stop getting lost. Intake forms, evidence, signed letters, deliverables: all uploaded and downloaded through the portal, attached to the case they belong to, with access controls that match the case. No more email attachments that someone has to dig out of a thread eight weeks later.

Communication has a record. Every message about a case lives inside that case, behind authentication and role-based access — visible to the right people and no one else, with a timestamped trail of what was said and when. That’s a meaningful operational upgrade and a meaningful compliance upgrade at the same time.

Your compliance posture improves automatically. Conversations and documents that used to live in inboxes — outside any controlled environment — now live behind authentication, audit logging, and least-privilege permissions. The portal isn’t only a productivity tool. It’s the single biggest upgrade most healthcare operations can make to how they handle PHI day to day.

These are the table-stakes outcomes. Most healthcare operations that handle case-based work for other businesses should be running on a portal. The hard part isn’t whether to build one — it’s building it on a foundation that’s legally allowed to hold the data.

What is a HIPAA compliant portal?

A HIPAA compliant portal is a web application that stores, transmits, or displays Protected Health Information (PHI) on behalf of a healthcare provider or business associate — and meets every requirement of the HIPAA Privacy Rule and HIPAA Security Rule while doing it.

PHI is broader than most people think. Clinical records are PHI, but so is anything that ties an identifiable person to a healthcare service. A patient name combined with an appointment date and the name of a provider is PHI even with no diagnosis attached. The fact that a person is connected to a healthcare service is itself protected. Any client portal in healthcare is handling PHI from the moment a case is connected to a person.

Practically, a HIPAA compliant portal has to clear a specific bar. It runs on HIPAA-eligible infrastructure. Every third-party vendor in its stack has signed a Business Associate Agreement (BAA). It enforces role-based access and least-privilege permissions. It encrypts data at rest and in transit. It logs every read and write of PHI for audit, with retention covering at least six years. Miss any one of those and “compliant” is a marketing word, not a legal one.

The rest of this guide explains why most of the obvious tools you’d build a portal with cannot meet that bar, what the few that can look like, and how to build one yourself when no-code isn’t the right path.

The one question that decides almost everything

Before you compare a single tool, you need one concept, because it disqualifies most of them in a single sentence.

Once a third-party tool touches PHI on your behalf, it becomes a Business Associate under HIPAA. The law requires a signed contract before that happens: a Business Associate Agreement, or BAA. The BAA is what makes the vendor legally accountable for protecting that data and for reporting breaches.

Here’s the part that kills most candidate tools: if a vendor won’t sign a BAA, you cannot put PHI on it, period. It doesn’t matter how good their encryption is. It doesn’t matter that they’re SOC 2 certified. It doesn’t matter that a salesperson said they’re “HIPAA friendly.” Encryption is a security control; a BAA is a legal one, and HIPAA requires both. No BAA means no PHI, full stop.

That single test — will this company sign a BAA? — is the fastest way to cut a long list of tools down to a short one. Run every option through it first.

The tools everyone reaches for, and why they fall short

Is Airtable HIPAA compliant?

Airtable is where a lot of teams start, because it’s the friendliest database most non-technical people have ever used. It’s genuinely great software, and we use it heavily across non-PHI operations work. For a client-facing HIPAA compliant portal at scale, it’s still the wrong foundation — but the reasons are more nuanced than “Airtable doesn’t do HIPAA.”

The legal piece first. Airtable will sign a Business Associate Agreement, but only on its Enterprise Scale tier. On every plan below that — Free, Team, Business — there is no BAA. So if you’re starting out on any of the entry tiers, you cannot legally put PHI into Airtable, period. That alone disqualifies the path that most small healthcare teams would actually take to start.

If you go up to Enterprise to unlock the BAA, the architectural problem shows up next. Airtable’s built-in way to expose data to outside users — Interfaces, with portal-style sharing — is priced per external client. For an internal-only operations tool with a handful of admin users, that math is fine. For a client portal that has to scale to dozens or hundreds of partner organizations, each with multiple users inside them, the per-client portal model grows linearly with your client base. The system you’d be building is one where every new client you sign makes the platform itself more expensive to run, which is the opposite of what a healthy client-portal architecture looks like.

So Airtable is doubly bounded for this use case: legally bounded below Enterprise (no BAA) and structurally bounded at Enterprise (per-client portal pricing scales linearly with the size of your client base). Either bound is a problem on its own. Together, they make Airtable the wrong primary platform for a client-facing HIPAA compliant portal — even though Airtable remains an excellent choice for everything behind the portal that doesn’t directly touch PHI.

Verdict: BAA available only on Enterprise tier. Per-external-client Interfaces pricing makes Airtable economically unscalable as a client-facing portal at any meaningful client count.

Is Softr HIPAA compliant?

Softr is a popular way to put a clean front end on top of an Airtable base — exactly the kind of “portal in a weekend” promise that’s tempting here. We build a lot on Softr for non-PHI workflows. The trouble for healthcare is structural. Softr’s front end proxies and caches the data it displays, which means PHI passes through and is held by Softr’s infrastructure. That makes Softr a Business Associate by function. And Softr does not offer a BAA. A clean interface over a non-compliant foundation is still non-compliant.

Verdict: Not HIPAA compliant. Cannot be used as a portal layer over PHI.

Is Noloco HIPAA compliant?

Noloco is a more capable Airtable-style front-end builder, and on the surface it looks like it could carry a real portal. But there’s no documented BAA program. When you push past the marketing and ask the direct question, the answer is that they’re not set up to be a HIPAA Business Associate.

This one is worth a personal warning. I’ve watched a vendor’s support chatbot give soft, evasive “we take security seriously” answers that sounded like a yes. It wasn’t until a direct conversation with the company that the real answer — no formal BAA — came out. Never accept a chatbot’s word on this. Get it in writing, from a human, in the form of a signed agreement.

Verdict: Not HIPAA compliant. No formal BAA program.

Is Bubble HIPAA compliant?

Bubble is far more powerful than the others here; you can build genuinely sophisticated apps on it. But on HIPAA it’s blunt and, to their credit, honest. Bubble’s own documentation states that the platform and its internal processes don’t meet HIPAA’s requirements, and that apps built on Bubble therefore cannot achieve HIPAA compliance. As of early 2026, Bubble does not provide a BAA.

There’s a workaround people use — keep all PHI out of Bubble entirely and use it only as a presentation layer that never stores or transmits protected data, routing PHI to a separate compliant backend. It can be done, but it’s an architecture project in its own right, and at that point you’ve taken on most of the complexity of a custom build while still being boxed in by the platform’s limits. For a portal that is fundamentally about managing protected case data, that’s a lot of contortion for not much payoff.

Verdict: Not HIPAA compliant. Bubble’s own documentation rules out apps built on the platform.

The compliant-but-painful options nobody mentions

Here’s the part most “Airtable vs Softr” blog posts skip: compliant no-code platforms do exist. Knack and Caspio both sign BAAs and are built to hold PHI. If your only goal is “legal,” they’re real answers, and they belong in an honest comparison.

The catch is the part you can’t put in a compliance checklist: they look dated. For an internal tool nobody outside your team ever sees, that can be fine. For a client-facing portal that partners log into and judge your professionalism by, the aesthetic and UX ceiling is a genuine business constraint, not vanity. If your portal is part of how clients experience your brand, “compliant but it looks like 2009” is a real liability. Worth knowing they exist; worth being clear-eyed about why you might still pass.

Verdict: HIPAA compliant. Will sign BAAs. Client-facing UX rarely meets a modern bar.

Custom build

Which brings us to building it properly. A custom HIPAA compliant portal — a modern web app on HIPAA-eligible infrastructure — is the option that clears every bar at once: you control the data, you sign BAAs with each underlying provider, and you’re not fighting a platform’s ceiling on design or features.

The honest pros and cons:

The upside is total fit. The portal does exactly what your operation needs, looks the way client-facing work should look, and isn’t hostage to a no-code vendor’s roadmap or platform changes. You own the architecture and the compliance posture end to end.

The downside is that it’s a real project. It takes longer to stand up than picking a tool off the shelf, and it needs an engineer who actually understands HIPAA architecture — not someone who’ll bolt encryption on at the end and call it compliant. It also needs ongoing maintenance; “compliant” isn’t a state you reach once. If you don’t have access to that kind of engineering, custom is the wrong call, and one of the compliant no-code platforms is the safer bet even with the trade-offs.

My rule of thumb: custom makes sense when the portal is core to how the business runs and how clients perceive it, and you have a trustworthy engineer with prior HIPAA experience. If both are true, the build is worth doing. If either is missing, reconsider.

Verdict: HIPAA compliant when built properly. Maximum fit and control. Requires real engineering.

Quick comparison

It is never just the app builder

This is the trap that catches teams who did the hard part right. You can pick a compliant foundation and still end up non-compliant, because a portal is never one tool. It’s a stack, and every link in it that touches PHI needs its own BAA.

Walk the data flow and check each piece:

Hosting and database. The major clouds (AWS, Google Cloud, Azure) sign BAAs, but only specific services are HIPAA-eligible — a BAA with AWS doesn’t bless every AWS service. Confirm each one you use is on the eligible list.

Email and SMS notifications. The moment a notification contains anything identifying — “Your case #1234 for [client] has moved to review” — it’s PHI in transit. The sending service needs a BAA. Consumer email tools and most default transactional senders don’t qualify.

Payments and invoicing. This is a common surprise. QuickBooks doesn’t sign BAAs, which rules it out the second an invoice ties a payment to a patient or a health-related service. Stripe will sign a BAA for invoicing, so a Stripe-based flow with webhooks is usually the cleaner path when the client is open to it.

Automation glue. Zapier does not sign BAAs on any plan, and its native data features sit on the same non-eligible infrastructure — so the convenient “just Zap it over” step is often the exact place PHI leaks out of your compliant stack. Make.com and similar tools need the same scrutiny, and we configure those carefully on PHI-adjacent workflows for healthcare clients.

AI features. If you’re adding any AI — summarizing case notes, drafting messages, intake triage — the model provider needs a BAA too, and you should confirm the agreement covers whether your data can be used for training. We cover this in more depth in our AI implementation work for compliance-heavy businesses.

The discipline here is simple to state and easy to forget: map where PHI flows, and make sure there’s a signed BAA at every stop. One unsigned link makes the whole chain non-compliant, no matter how clean the rest of it is.

What a HIPAA compliant portal actually includes

Compliance is the floor, not the product. Here’s what the portal is for — the features that turn the email mess back into an operation.

Case and work progress. The thing that ends the “any update?” emails. Clients log in and see exactly where each of their cases stands: received, in review, awaiting documents, complete. Status changes as your team works, so the portal is never out of date the way a spreadsheet always is. This single feature is usually what brings a paused client back.

Tasks and what’s-blocking-what. Internally, every case is a small pipeline with steps and owners. The portal makes that explicit — who has the ball, what’s overdue, what’s waiting on a client to upload something. The same data that drives the client status view drives your team’s task list, so there’s one source of truth instead of two that disagree.

Secure communication between client and team. Replace the email thread with messaging that lives inside the case, behind authentication and access controls. Everything about a case stays attached to that case, visible to the right people and no one else, with a record of what was said and when.

Document exchange. The intake forms, evidence, signed letters, deliverables — uploaded and downloaded through the portal instead of as email attachments. Files inherit the same access rules as the case they belong to.

The internal management side. The portal isn’t only client-facing. Your team needs the operations view: every case across every client, queues, workload, what’s stuck, what’s due. The win is that clients and staff work in one system — the client sees their slice, your team sees the whole board, and nobody is reconciling a separate internal tracker against what clients were told. The internal management tool and the client portal are two views of the same data, not two systems you keep in sync by hand. We did exactly this kind of consolidation for Affinity Care — five disconnected tools collapsed into one operations system, with caregiver onboarding cut from 21 days to 8.

Two more that aren’t glamorous but aren’t optional:

Access model and onboarding. Decide early how people get in. For a B2B portal, admin-provisioned onboarding usually beats open self-signup: you create the partner organization, invite their first admin with a time-limited magic link, and let that admin invite their own people inside their own walled-off tenant. Each client firm sees only its own cases. Getting tenant isolation right is most of what “secure” means in practice.

Audit logging. HIPAA expects you to know who accessed what and when. Build an audit trail from day one — it’s painful to retrofit, it’s central to breach response, and it’s the kind of thing an investigation will ask for. Plan to retain records for at least six years.

A reference architecture for a custom HIPAA compliant portal

If you go custom, here’s the shape that works, described plainly enough to hand to an engineer as a starting point.

Keep PHI in a HIPAA-eligible backend you have a BAA for — direct on AWS, or a managed option like Supabase with its HIPAA add-on. The decision between those usually comes down to what your engineer already knows and has infrastructure templates for. Familiar tooling beats a marginally newer option you have to learn from scratch.

Build the front end as a modern web app (Next.js and Tailwind is a sensible default) that treats PHI carefully and never becomes an unmanaged copy of it. Host it somewhere covered by your BAAs.

Wrap it in real auth: individual accounts, multi-factor authentication, role-based access control so a client paralegal, a client admin, and your internal staff each see exactly their scope and nothing more, and session timeouts. Encrypt PHI both at rest and in transit — and remember encryption is necessary, not sufficient; it doesn’t replace the BAA. Log access for the audit trail. Apply minimum-necessary everywhere: the portal should fetch only the data a given user is allowed to see, not pull everything and filter in the browser.

None of this is exotic. It’s standard, careful web engineering applied with HIPAA in mind from the first commit instead of bolted on before launch.

Red flags to watch for

A few patterns that should make you stop:

“We’re HIPAA friendly” or “HIPAA ready.” These phrases mean nothing legally. The only question is whether they will sign a BAA. Ask it directly and get the document.

A chatbot or salesperson confirming compliance. I’ve been burned by this — soft assurances that evaporate the moment you talk to someone who can actually commit the company. Verify vendor claims with a human and a signed agreement, never with an AI assistant’s answer or a marketing page.

Encryption presented as the whole answer. Strong encryption is great and still doesn’t make a vendor compliant without a BAA. If someone leads with encryption and goes quiet on the agreement, that’s your signal.

“We don’t really store the data, so we’re fine.” If a tool displays, caches, proxies, or routes PHI — even briefly — it’s handling it, and it needs a BAA. Softr is the textbook example. Don’t let “we’re just a front end” do the talking.

A short checklist before you build

• Will every vendor that touches PHI sign a BAA? (Get each one in writing.)
• Have you mapped the full data flow — app, hosting, email/SMS, payments, automation, AI — and confirmed a BAA at every stop?
• Are you using only the HIPAA-eligible services from your cloud provider?
• Does the design enforce minimum-necessary access and per-client tenant isolation?
• Is there MFA, role-based access, encryption at rest and in transit, and an audit log from day one?
• Do you have an engineer with prior HIPAA experience — or should you take a compliant no-code platform instead?
• Have you decided which features the portal actually needs to deliver in v1, instead of trying to build everything at once?

Work that list top to bottom and you’ll either have a HIPAA compliant portal you can defend in front of an auditor and put proudly in front of a client, or a clear, early answer that custom isn’t the right path for you yet. Both outcomes beat finding out after launch that the friendly tool you built on was never allowed to hold your data.

If you’re at the point of needing a HIPAA compliant portal and you’d like a second opinion on whether to go no-code or custom — and which BAAs you’ll actually need to chase down — that’s the kind of question we answer in a free intro call. It’s the same conversation we’ve had with every healthcare client we’ve ever built for.