Notifications
Clear all
Topic starter
20/08/2026 5:44 pm
TL;DR: Healthcare websites and mobile apps can violate HIPAA when third-party tracking technologies collect or transmit protected health information without the right disclosures, and OCR’s 2024 guidance tightened the operational examples, per Jscrambler. The real issue is client-side data exposure in browser-based architectures, where privacy, security, and identity governance collide at the point of collection.
NHIMG editorial — based on content published by Jscrambler: HIPAA guidance on online tracking technologies and PHI exposure
By the numbers:
- 100 US hospitals had tracking codes on their, acking codes on their websites, and in seven cases those codes were added to password-protected patient portals.
Questions worth separating out
Q: How should healthcare organisations control tracking technologies in patient portals?
A: They should treat patient portals as sensitive execution environments and block or tightly restrict scripts that can observe form inputs, session state, or page content.
Q: Why do tracking pixels create compliance risk even when there is no explicit cookie banner rule?
A: Tracking pixels can still collect or disclose personal information under broader privacy rules, so the absence of a banner requirement does not remove the obligation to be transparent and, where needed, obtain consent.
Q: What do security teams get wrong about business associate agreements?
A: They often assume a business associate agreement solves the problem on its own.
Practitioner guidance
- Inventory browser-side data flows Map every tag, pixel, SDK, and embedded script that can observe form fields, page context, or authenticated portal traffic.
- Restrict third-party visibility in sensitive workflows Separate marketing and analytics tooling from authenticated healthcare pages, and block scripts from pages where PHI may appear.
- Test scripts against real portal states Assess pages differently when they are public, authenticated, or context-sensitive.
What's in the full article
Jscrambler's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step timeline of the OCR guidance and related legal milestones that shaped the current compliance position
- The article’s examples of when tracking technologies may or may not create a HIPAA violation in web and mobile contexts
- More detail on how browser-based tracking can differ between public pages, authenticated portals, and app experiences
- Jscrambler's client-side protection framing for first-party scripts and third-party tags in regulated environments
👉 Read Jscrambler's analysis of HIPAA tracking technologies and PHI exposure →
HIPAA tracking technologies: what healthcare teams need to fix?
Explore further
20/08/2026 6:27 pm
Client-side data collection is now a governance boundary, not a marketing detail. When tracking code can read inputs in a patient portal, the risk is no longer limited to analytics misuse. The organisation has created a parallel data path outside its server-side privacy design, and that path must be governed like any other sensitive workflow. For healthcare and regulated industries, browser telemetry belongs in the same control conversation as access control and disclosure review.
A question worth separating out:
Q: How do you know whether browser-side privacy controls are actually working?
A: Look for evidence that sensitive fields are blocked, storage access is constrained, outbound requests are logged, and opt-out or GPC signals cause immediate technical suppression. If the only proof is policy text or a checkbox in a dashboard, the control is not being enforced where it matters.
👉 Read our full editorial: HIPAA tracking technologies expose a client-side PHI governance gap
