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.

Those requirements land on six distinct layers, and every one of them touches PHI, which means every one of them needs its own signed BAA. The compliance question gets asked once per layer, not once per project.

One unsigned row breaks the chain, regardless of how well the other five are built. Each layer is unpacked further down, in the reference architecture.

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.

Which platform should you build it on?

Run the list through that test and the answer is uncomfortable. The platforms that are best at client-facing portals are the ones that will not sign, and the ones that will sign look like internal database tools. Knack and Caspio both sign and both hold PHI properly, and both carry a client-facing UX ceiling that matters when the portal is part of how clients judge you. Airtable signs only on its top tier, and its own datasheet tells you not to use it as a patient portal. Softr, Noloco and Bubble offer no path at all.

The full breakdown lives on its own page, platform by platform, with each vendor’s documentation linked and the date it was checked: which no-code platforms actually sign a BAA. Start there if you are still choosing a tool.

This guide picks up where that decision lands: you have worked out that no off-the-shelf platform clears every bar at once, and you are building.

When does a custom build make sense?

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.

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 (the full breakdown of which AI vendors will sign one), 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, and it rarely ships alone; it sits on the same systems and automation build as the rest of your operations. 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.