Session Replay and HIPAA: Proceed Only With Extreme Care

If you run a healthcare application and you’re evaluating session replay, start from “no” and force the tool to argue its way in. That’s the opposite of my advice for almost every other vertical, and it’s not reflexive caution. The session replay HIPAA problem is structural: a replay tool records what the screen showed, and in a healthcare app, what the screen showed is the protected health information. Every mitigation that works elsewhere — mask the inputs, redact the forms — solves the wrong layer here.

I’ll explain why, where the narrow defensible configurations are, and why self-hosting changes the math. One sentence of scope: I’m an engineer who has worked through HIPAA security reviews, not a healthcare attorney, so validate anything here against your compliance officer’s read.

The session replay HIPAA problem: displayed data is the PHI

Everywhere else, replay masking focuses on inputs: what the user types. Mask every field and you’ve removed most of the sensitive content, because on a typical SaaS the page chrome is generic and the sensitive stuff is what users enter.

A healthcare app inverts that. A patient portal displays diagnoses, medication lists, lab results, appointment types, provider names. A clinician-facing EHR displays them for many patients per session. None of that is typed into an input. It’s rendered text in the DOM — and DOM capture is precisely what session replay does. maskAllInputs: true on a patient portal is a lock on the window next to an open door.

And identifiability is nearly automatic. HIPAA’s de-identification standard has eighteen identifier categories; a replay session on an authenticated portal trivially links health information to an individual account, which makes the recording PHI more or less by construction. Even a fully text-masked recording still leaks through the shape of things: page URLs (/conditions/hiv-management), navigation patterns, which module of the app was opened. Under HIPAA’s definitions, information about the provision of health care to an identified individual is PHI — the fact of the visit can be PHI even when its content is hidden.

The BAA wall

HIPAA doesn’t ban any technology. What it requires is that any vendor touching PHI on your behalf sign a Business Associate Agreement and carry the compliance obligations that come with it — breach notification, security rule adherence, liability exposure.

Here’s the market reality, stated carefully because policies change: most mainstream session replay and analytics vendors either won’t sign a BAA, or will only do so on enterprise tiers with specific configurations, and several explicitly prohibit sending them PHI in their terms. From the vendor’s chair this is rational — a multi-tenant pipeline optimized for capturing everything is a bad place to accept HIPAA liability. From your chair it’s disqualifying: using a replay vendor without a BAA on an app where PHI reaches the recording isn’t a gray area. It’s an impermissible disclosure, and “we had masking turned on” is a mitigation narrative, not a defense.

So the vendor conversation has exactly one acceptable shape: a signed BAA, or architecture where the vendor never touches the data. There is no third option in which you quietly hope the masking holds.

The narrow configurations that are defensible

There are deployments where replay on a healthcare property survives scrutiny. They’re narrower than anyone wants.

Unauthenticated marketing pages only. Recording the public site — pricing, content pages, signup funnel — and hard-stopping the recorder at the auth boundary. Enforce it structurally (the snippet is not present in the authenticated app’s bundle), not with a config flag someone can flip. One caution: symptom-checker or condition-search interactions on public pages have themselves become an enforcement and litigation focus in the healthcare-adjacent tracking cases, so “unauthenticated” is not automatically “safe.”

Block-all-and-allowlist inside the app. If you genuinely need replay on authenticated flows — say, a broken scheduling wizard — invert the masking model: everything is masked by default, and only specific, individually reviewed UI regions are recorded. This demands ongoing discipline; every new component ships masked until someone argues otherwise, in writing. It’s the only masking posture I’d defend for PHI-adjacent screens, and it pairs with the shortest retention you can tolerate — days, not months. Retention design deserves its own thought; see designing a replay retention policy.

Self-hosted, inside your HIPAA boundary. This is the configuration that changes the calculus most. If the replay pipeline runs on your own infrastructure — script served from your domain, recordings stored on servers already inside your compliance perimeter — there is no business associate, and therefore no BAA to fail to obtain. The recordings become another internal PHI datastore, governed by the Security Rule controls you already operate: access control, audit logging, encryption, retention. That’s the honest reason self-hostable tools like LogReplay get deployed in healthcare when SaaS recorders get vetoed. Be clear-eyed about what it does and doesn’t buy you: it eliminates the vendor-disclosure problem entirely, and it converts the remaining risk into internal-controls work — because you now own an archive of watchable patient sessions, and “who watched what, and why” needs an answer your auditor will accept.

My actual recommendation

For a patient-facing app: default to no replay on authenticated pages. Use error monitoring, structured logs, and traces — which can be scrubbed field-by-field — to debug, and accept that you’ll reproduce some bugs the slow way. If a specific flow justifies recording, do it self-hosted or under a signed BAA, block-all-with-allowlist, minimal retention, access-logged, and documented in your risk analysis before the first session is captured.

That’s a lot of qualifiers. That’s the point. Session replay is a genuinely useful tool carrying an unusually bad interaction with this one regulation, and the teams that get it right in healthcare are the ones who treated every recorded pixel as PHI until proven otherwise — not the ones who found a vendor whose marketing page said “HIPAA-friendly” and stopped reading there.