When BrightFit came to us needing a HIPAA-compliant digital referral platform, their previous vendor had delivered something with a consent banner and an SSL certificate and called it compliant. It wasn't. Not even close.
HIPAA compliance in a modern React application touches architecture, data handling, logging, authentication, third-party integrations, and organizational process. Missing any one layer creates liability that no consent banner can fix.
What HIPAA actually requires from your frontend
Most developers focus on the backend — encrypted databases, audit logs, access controls. These are essential. But the frontend carries equal responsibility for how Protected Health Information (PHI) is handled in transit and in the browser.
- →Never store PHI in localStorage, sessionStorage, or Redux state that persists across sessions
- →Automatic session timeout after inactivity — 15 minutes is the standard most covered entities enforce
- →All API calls must go over TLS 1.2 minimum — TLS 1.3 preferred
- →Error messages must never expose PHI — generic user-facing errors only
- →Third-party scripts (analytics, chat, support tools) must have BAAs if they can access PHI
The third-party integration problem
This is where most React applications fail silently. Google Analytics, Intercom, Hotjar, Sentry — these tools are powerful and your team relies on them. But each one that runs on a page containing PHI is a potential HIPAA violation unless you have a signed Business Associate Agreement with the vendor.
Critical Rule
Google Analytics standard does not qualify as HIPAA-compliant. Google Workspace and Google Cloud have BAA-eligible products, but standard GA4 is not one of them. If your analytics script fires on a page showing patient data, you have a problem.
Audit logging at the application layer
HIPAA requires audit controls that record and examine activity in systems containing PHI. This means logging who accessed what record, when, and from where. In a React application, this translates to event logging on every PHI access — not just failed requests, but successful ones too.
We implement this as a middleware layer that intercepts API calls touching PHI endpoints and emits structured log events to an append-only log store. The logs themselves must be protected and retained for a minimum of six years.
The Business Associate Agreement chain
Every vendor in your stack that could touch PHI needs a BAA. Your hosting provider, your database provider, your email service, your CDN. Building on AWS? AWS will sign a BAA. Building on Vercel? Vercel has a HIPAA-eligible infrastructure product. Building on shared cPanel hosting? That is a harder conversation.
The BrightFit platform we built runs on AWS infrastructure with a full BAA in place, end-to-end encryption, automatic session management, and a complete audit trail. What started as "can you just add compliance" became a ground-up architecture decision. That is almost always the right outcome.