# HIPAA-compliant analytics: how to measure a healthcare website and app without leaking PHI

Canonical URL: https://www.martechdevs.com/blog/hipaa-compliant-analytics

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder at [Martechdevs](https://www.martechdevs.com) and [Growth and Analytics Partners](https://www.growthandanalytics.com)

[LinkedIn](https://linkedin.com/in/jafrinalo)

Published: 2026-10-17

Last updated: 2026-10-17

HIPAA-compliant analytics depends on the data, permitted purpose, contracts and safeguards across the whole collection path. A vendor's BAA can support that arrangement; it does not approve every event or feature. Classify each healthcare journey, identify every recipient and test what leaves the browser or app. Keep protected health information out of destinations that are not approved to receive it.

## What does HIPAA-compliant analytics mean?

It means the analytics activity meets the HIPAA obligations that apply to the organisation and the particular use of protected health information, or PHI. HIPAA is a US federal regime; PHI is individually identifiable health information within its scope. Choosing a product advertised for healthcare is only one implementation decision.

A business associate performs covered functions or certain services involving PHI for a covered entity. Where an analytics provider acts in that role, the relationship needs a business associate agreement, or BAA, and the processing must have an applicable permitted purpose. A signed document cannot turn an otherwise impermissible disclosure into an approved one. [HHS business-associate guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html).

Start with a written decision covering the organisation's role, the intended measurement and the data recipients. A clinic analysing appointment completion is different from a consumer wellness app building advertising audiences. The same company can also have different activities and contractual roles.

This is implementation guidance, not a legal determination for a particular organisation. Have your privacy or legal owner approve the classification and permitted uses before engineering implements them. The [industry stack guide](https://www.martechdevs.com/blog/martech-stack-by-industry) explains why a healthcare journey needs different data-routing rules from an ordinary store checkout.

## Which pages and app screens deserve the first review?

Review authenticated care journeys and flows where people disclose symptoms, appointment details or identifying information first. A public URL does not establish that its contents or requests are harmless.

Use the following as an audit triage model, then approve each actual flow rather than treating the labels as legal conclusions.

| Page or screen | What could leave | Initial engineering action | Evidence required to change that action |
| --- | --- | --- | --- |
| Patient portal or logged-in care app | Identity, treatment, billing and account context | Keep unapproved third-party tracking out | Approved purpose, recipient scope and tested payload |
| Booking, intake or symptom flow | Contact details, selections, appointment identifiers | Isolate the flow and inspect every integration | Field-level map and review of redirects, embeds and logs |
| Condition, provider or treatment page | Health context combined with identifiers or later actions | Hold broad tracking pending review | Actual data flow and documented classification |
| Careers or general corporate content | Ordinary visit data, but possibly sensitive incoming URLs | Evaluate a limited general-analytics route | Clean collection, navigation boundaries and applicable permissions |

HHS's online-tracking guidance identifies particular risks in portals and appointment flows. Its live page also acknowledges the June 2024 court decision vacating the guidance's treatment of the specified combination of an IP address and a visit to a public unauthenticated condition or provider page. That ruling is not blanket permission for every healthcare tracking flow. [HHS tracking guidance and court notice](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html).

A careers page can receive a visitor from a patient portal. Check referrers and shared scripts as well as its visible text. A booking widget can send requests directly from an iframe while the main site's tag manager appears correctly restricted.

A [tracking implementation for regulated sites](https://www.martechdevs.com/analytics-tracking) should produce this page-and-recipient map before a new analytics contract is treated as the solution.

## What rules matter when a health app is outside HIPAA?

A company outside HIPAA can still face federal and state health-data obligations. Do not use “not a covered entity” as the final decision on tracking.

The FTC's amended Health Breach Notification Rule (HBNR) covers qualifying personal-health-record vendors and related entities outside HIPAA. Its definition of a breach includes certain unauthorised disclosures, not only intrusions into a database. Applicability depends on the entity and service; it is not a rule that every wellness website automatically falls into the same category. [FTC rule explanation](https://www.ftc.gov/news-events/news/press-releases/2024/04/ftc-finalizes-changes-health-breach-notification-rule).

These enforcement announcements illustrate different legal routes. The USD amounts are one-time announced penalties or consumer refunds, with status shown beside them; they are not interchangeable examples of HIPAA penalties.

| FTC announcement | Legal route or allegation | Practical tracking lesson |
| --- | --- | --- |
| GoodRx, February 2023 | FTC Act and first HBNR enforcement; agreed USD 1.5 million civil penalty in the announced proposed order | Prescription-related audiences and advertising disclosures need review |
| Premom, May 2023 | HBNR and deceptive-sharing charges; announced USD 100,000 federal civil penalty | Review mobile SDK traffic as carefully as browser pixels |
| BetterHelp, March 2023 | FTC Act deceptive-disclosure allegations and proposed USD 7.8 million consumer refunds | Contact identifiers can carry health context through their origin |
| Cerebral, April 2024 | Privacy, security and deceptive subscription charges; proposed settlement | A tracking audit must include access and operational practices |
| Hims & Hers, July 2026 | Complaint alleging violations of the FTC Act and Restore Online Shoppers’ Confidence Act | Customer-list uploads deserve the same scrutiny as website events |

The rows describe the cited announcements and distinguish proposed orders from allegations. The Hims & Hers complaint is not a finding that the alleged conduct occurred. Primary accounts: [GoodRx](https://www.ftc.gov/news-events/news/press-releases/2023/02/ftc-enforcement-action-bar-goodrx-sharing-consumers-sensitive-health-info-advertising), [Premom](https://www.ftc.gov/news-events/news/press-releases/2023/05/ovulation-tracking-app-premom-will-be-barred-sharing-health-data-advertising-under-proposed-ftc), [BetterHelp](https://www.ftc.gov/news-events/news/press-releases/2023/03/ftc-ban-betterhelp-revealing-consumers-data-including-sensitive-mental-health-information-facebook), [Cerebral](https://www.ftc.gov/news-events/news/press-releases/2024/04/proposed-ftc-order-will-prohibit-telehealth-firm-cerebral-using-or-disclosing-sensitive-data), [Hims & Hers](https://www.ftc.gov/news-events/news/press-releases/2026/07/ftc-states-act-against-hims-hers-deceptive-unlawful-privacy-practices).

Washington's My Health My Data Act can cover consumer health data outside HIPAA, including qualifying inferences from non-health data. The Attorney General explains that covered businesses need a distinct homepage link to their consumer health-data privacy policy, and that violations can be enforced through the Consumer Protection Act by the AG or private action. Have counsel assess scope, exemptions and the actual processing. [Washington AG guidance](https://www.atg.wa.gov/protecting-washingtonians-personal-health-data-and-privacy).

## Which analytics vendors offer a BAA, and what remains outside it?

Some analytics vendors offer BAAs on specified packages, while Google Analytics does not. Verify the signed agreement, service and feature coverage before sending PHI; a sales-page statement is not your executed contract.

The following terms were checked on 17 October 2026. The PostHog figure is a monthly USD package price, excluding separately metered product usage; other rows describe eligibility rather than a price quote.

| Option | Published BAA position | Boundary to verify | Useful first pilot |
| --- | --- | --- | --- |
| PostHog Cloud | Boost, Scale or Enterprise; Boost is USD 250/month | Managed reverse proxy and AI features are excluded | A small approved event set with excluded features disabled |
| Mixpanel | Standard BAA described for Enterprise customers | Contract, project and enabled-feature coverage | One permitted funnel with restricted access |
| Amplitude | Healthcare page says it can enter a BAA | Plan, features and contract scope require confirmation | One approved account or user journey |
| Google Cloud | BAA with listed covered services, including BigQuery and Cloud Run | Executed agreement, exact services and customer configuration | Restricted event store and an internal report |
| Google Analytics | No BAA offered for Analytics | PHI must not reach the service | Only an approved non-PHI collection path |

Sources: [PostHog HIPAA scope](https://posthog.com/docs/privacy/hipaa-compliance), [PostHog packages](https://posthog.com/platform-packages), [Mixpanel HIPAA terms](https://mixpanel.com/legal/mixpanel-hipaa/), [Amplitude healthcare](https://amplitude.com/industry/healthcare), [Google Cloud HIPAA guidance](https://docs.cloud.google.com/docs/security/compliance/hipaa), [Google Analytics policy](https://support.google.com/analytics/answer/13297105).

PostHog explicitly says its AI features should not be enabled in an organisation where any project processes PHI. Separating one project is therefore not enough to assume the organisation-level feature is acceptable. Its documentation recommends Cloud under a BAA over its legacy or hobby self-hosted product for HIPAA needs.

Use [PostHog's cost model](https://www.martechdevs.com/blog/posthog-pricing) or [Mixpanel plan costs](https://www.martechdevs.com/blog/mixpanel-pricing) after establishing eligibility. A cheaper tier that lacks the required agreement is not an equivalent option. For Google's specific restrictions, use [whether GA4 can stay on a healthcare site](https://www.martechdevs.com/blog/google-analytics-hipaa).

## Which architecture fits the measurement job?

Choose the smallest architecture that supplies the required evidence within approved data boundaries. A browser tag, first-party hostname or warehouse does not by itself determine whether processing is permissible.

### Limited analytics on approved general pages

This can fit recruitment or corporate-content reporting where the reviewed flow contains no PHI. Use an explicit allowlist of approved routes and a restricted event schema. Test the transition from care pages into those routes. Default new pages to review rather than inheriting every marketing tag.

### Product analytics under a BAA

This fits a permitted care-product or operational analysis that needs event-level records. Keep the project, users, exports and feature toggles within the reviewed agreement. Start with deliberate events instead of broad autocapture. Enable replay only after a specific need, scope and masking behaviour have been tested.

### A controlled collection service

A server can enforce an event schema, reject unknown fields and route data by destination. It helps only if the actual inbound processing, logs and outbound requests follow the approved design. Filtering after an unapproved vendor already received the raw request is too late.

The [server-side tracking guide](https://www.martechdevs.com/blog/server-side-tracking) separates architecture benefits from compliance claims. Hosting a collector or [server-side GTM implementation](https://www.martechdevs.com/blog/server-side-gtm-setup) on BAA-covered infrastructure does not extend that agreement to GA4 or an advertising destination.

### Warehouse-first operational reporting

This fits questions such as booking completion, service availability and operational failure rates that can be answered inside a controlled environment. Keep identifiers and detailed records restricted; publish only the minimum report each audience needs. Review exports, emailed reports and connected AI assistants as additional data flows.

HHS says a cloud provider maintaining ePHI on behalf of a regulated entity can be a business associate even when the data is encrypted and the provider lacks the key. Self-hosting transfers work to your team and infrastructure providers; it does not remove contracting, risk analysis, access, recovery and incident responsibilities. [HHS cloud guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html).

![Classify the journey and purpose; PHI or uncertainty requires an approved processing arrangement, otherwise stop the flow; approved and non-PHI routes both receive request/log/export tests.](https://www.martechdevs.com/assets/blog/hipaa-compliant-analytics.svg)

## How do you audit the tracking that is already installed?

Follow a synthetic journey from browser or app through every recipient, recording both the expected route and observed requests. The procedure below is a recommended test method, not a report of a healthcare client audit we performed.

1. **Inventory collection paths.** Include GTM, hard-coded tags, CMS plugins, mobile SDKs, chat, scheduling embeds, call tracking, error reporting and server jobs.
2. **Choose representative states.** Cover public browsing, portal login, a failed intake, a successful booking, logout and consent changes. Use synthetic accounts and approved test environments.
3. **Inspect network traffic.** Preserve redirects and inspect request URLs, bodies, headers and initiators. A tag marked “not fired” does not prove another script sent nothing.
4. **Trace the backend.** Check collectors, queues, retries, request logging and error payloads. Identify every place that keeps a raw copy.
5. **Inspect optional capture.** Test replay, autocapture, search, chat and exception reporting using harmless sentinel strings. Confirm masking before transmission, not just in the replay viewer.
6. **Compare with the contract register.** Identify the actual legal recipient, product, plan, feature, subprocessor route and approved purpose for each transfer.
7. **Prioritise containment.** Pause a confirmed unapproved flow and involve the privacy/security owner. Do not keep sending data merely to produce a cleaner diagnostic sample.
8. **Retest the exact failing journey.** Save a redacted evidence record, release version and acceptance result. Restrict any evidence that itself contains sensitive data.

The [GTM container hygiene guide](https://www.martechdevs.com/blog/google-tag-manager-implementation-mistakes) helps identify duplicate tags and competing installations. On mobile, inspect the SDK configuration and network traffic separately; a clean website container says nothing about the app build.

A copyable audit record can stay concise:

```yaml
journey: synthetic booking submission
page_group: booking
purpose_owner: operations lead
privacy_classification: pending approval
recipient_and_feature: replace with verified service and feature
contract_reference: restricted register entry
expected_fields: [event_id, step, result]
prohibited_fields: [form_text, patient_id, raw_url, page_title]
test_case: failed submission must not emit booking_confirmed
evidence_reference: restricted test record
release_version: pending
acceptance: not approved
```

The example intentionally begins unapproved. A form filled with real patient details is not an appropriate substitute for a synthetic fixture.

## How do you reduce data without claiming it is de-identified?

Use deliberate fields, bounded values and destination-specific schemas, while continuing to treat the dataset according to its actual classification. Removing a name, hashing an email or replacing a patient ID with a stable code does not automatically remove identifiability.

HHS describes two HIPAA de-identification methods: Safe Harbor and Expert Determination. Safe Harbor requires specified identifiers to be removed and no actual knowledge that the remaining information identifies an individual. Its guidance addresses dates, URLs, IP addresses and identifying codes; it is more demanding than a query-string filter. [HHS de-identification guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html).

Inside an approved environment, a neutral `booking_step_completed` event can reduce unnecessary detail. It still may be PHI when joined to an identifiable booking. Keep diagnosis, provider selection and free text out unless the permitted analysis needs them. Do not export the event to advertising merely because its name is generic.

Prefer allowlists over a growing list of forbidden field names. Reject an unexpected property, limit value length and use enumerations where possible. Test nested objects, URL-encoded values, error paths and retries. Also inspect the source IP, headers and context attached automatically by the collector.

## What would a clinic booking report look like in practice?

A hypothetical network of twelve clinics can measure booking completion inside its approved environment without exporting a patient-level conversion stream to advertising platforms.

Assume a defined weekly cohort of 120 distinct booking attempts. There are 90 submitted attempts, of which 84 pass validation. At the reporting cutoff, 78 have confirmed bookings and six remain pending. These are illustrative attempt counts, not patients or observed client results.

| Stage | Attempts | Interpretation |
| --- | ---: | --- |
| Booking started | 120 | Eligible attempts in the fixed cohort |
| Submitted | 90 | Includes six validation failures |
| Accepted after validation | 84 | Confirmation may still be pending |
| Confirmed at cutoff | 78 | Six accepted attempts remain unresolved |

The as-of completion ratio is `78 ÷ 120 = 65%`. It is not a mature final conversion rate while outcomes remain pending. A confirmation event must come from the scheduling system's confirmed state; a thank-you screen or accepted request is insufficient.

The network removes unapproved tracking from its portal and intake, reviews condition-page collection, and records only the approved booking events in the contracted analytics or warehouse route. An internal channel report might classify the 78 confirmations as 34 approved campaign-origin attempts, 24 organic-origin attempts and 20 unattributed attempts. Those categories sum to 78; the unattributed group stays visible.

Have the privacy owner approve whether that internal channel join is permitted. Do not forward patient-linked click IDs or bookings to an ad platform merely because an internal report needs them. Any aggregate shared beyond the approved environment needs its own disclosure assessment; small cells and unusual combinations can still identify people.

## How do you keep the design controlled after launch?

Make tracking changes part of release control, with named owners for the data classification, vendor register and technical tests. A valid configuration can become invalid when a new script, feature or export path is introduced.

Require review when a page begins collecting health details, a new SDK is added, a vendor changes its BAA scope or AI features are enabled. Keep a scheduled network review as a backstop, with frequency based on risk; quarterly is a starting operating recommendation, not a statutory interval.

The same recipient review applies to CRM and email workflows. Check their contracts, data purposes and suppression rules separately rather than assuming the analytics agreement covers every system in the journey.

## What should pass before the healthcare analytics release?

Release only when the intended measurement has an approved purpose, documented recipients and evidence that the implementation follows that decision:

## Checklist

- [ ] The organisation's role and applicable laws have been reviewed.
- [ ] Every page, screen and embedded flow has an approved classification.
- [ ] Business-associate relationships and service exclusions are recorded.
- [ ] Only approved event fields and recipients are enabled.
- [ ] Browser, app and server paths have been tested with synthetic data.
- [ ] Logs, retries, exports, replay and AI features are included in the review.
- [ ] Non-approved destinations receive no prohibited data in the test cases.
- [ ] Booking or care outcomes reconcile with their authoritative system.
- [ ] Small-cell and aggregate disclosure decisions are documented.
- [ ] An owner handles changes, exceptions and possible incidents.

At Martechdevs, we can work with your developers on the collection map, event controls and verification evidence your privacy team needs. Start with a [free tracking audit](https://www.martechdevs.com/martech-ai-audit), or [request a scoped tracking implementation quote](https://www.martechdevs.com/analytics-tracking#get-quote). Legal classification and approval remain with your organisation's qualified advisers.

## Frequently asked questions

### Does accepting a cookie banner authorise the disclosure of PHI?

A normal cookie choice is not a HIPAA-compliant authorisation. [HHS tracking guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html). Keep the consent-manager state separate from the legal basis and contractual requirements for the particular health-data use. Have the privacy owner approve that use, then test that the technical controls implement the decision. Our [Consent Mode guide](https://www.martechdevs.com/blog/consent-mode-v2) explains what Google's signals actually change.

### What should a healthcare analytics procurement team request besides a BAA?

Request the covered-service and feature list, security responsibilities, subprocessor information, incident process, retention and deletion terms, and data-return arrangements at exit. Map those documents to your actual collection and reporting paths. A contract reviewed for basic events should not silently become approval for replay, automated exports or an AI assistant added later.

### How should we test masking before enabling session replay on a care journey?

Use an approved test environment and synthetic values in fields, page content, URLs and error states. Inspect outgoing payloads as well as playback. Test what happens when the page changes dynamically or an embed opens. Record failures and keep capture disabled until the feature's contract scope and the actual masking behaviour meet the approved design.

### Can a hashed email be treated as anonymous in healthcare advertising?

No automatic conclusion follows from hashing. A stable hash can still support matching, and the event or audience context can reveal health information. Evaluate the complete disclosure and destination terms rather than the transformation alone. If de-identification is the proposed basis, use the applicable documented method and qualified review instead of declaring the payload anonymous.

### Who should approve a new analytics destination for a clinic?

The organisation should assign approval to people with authority over privacy, security, contracts and the business purpose. Marketing operations can maintain the register and engineering can demonstrate the data path, but neither a campaign deadline nor an installation permission replaces that approval. Retain the decision with the exact service, feature and schema it covers.

## Sources

1. [HHS: Business associates](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html)

2. [HHS: Online tracking technologies and the court notice](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html)

3. [HHS: De-identification methods](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html)

4. [HHS: Cloud computing guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html)

5. [FTC: Health Breach Notification Rule amendments](https://www.ftc.gov/news-events/news/press-releases/2024/04/ftc-finalizes-changes-health-breach-notification-rule)

6. [FTC: GoodRx enforcement announcement](https://www.ftc.gov/news-events/news/press-releases/2023/02/ftc-enforcement-action-bar-goodrx-sharing-consumers-sensitive-health-info-advertising)

7. [FTC: Premom enforcement announcement](https://www.ftc.gov/news-events/news/press-releases/2023/05/ovulation-tracking-app-premom-will-be-barred-sharing-health-data-advertising-under-proposed-ftc)

8. [FTC: BetterHelp enforcement announcement](https://www.ftc.gov/news-events/news/press-releases/2023/03/ftc-ban-betterhelp-revealing-consumers-data-including-sensitive-mental-health-information-facebook)

9. [FTC: Cerebral enforcement announcement](https://www.ftc.gov/news-events/news/press-releases/2024/04/proposed-ftc-order-will-prohibit-telehealth-firm-cerebral-using-or-disclosing-sensitive-data)

10. [FTC: Hims & Hers complaint announcement](https://www.ftc.gov/news-events/news/press-releases/2026/07/ftc-states-act-against-hims-hers-deceptive-unlawful-privacy-practices)

11. [Washington AG: My Health My Data Act guidance](https://www.atg.wa.gov/protecting-washingtonians-personal-health-data-and-privacy)

12. [PostHog: HIPAA and BAA scope](https://posthog.com/docs/privacy/hipaa-compliance)

13. [PostHog: Platform packages](https://posthog.com/platform-packages)

14. [Mixpanel: HIPAA](https://mixpanel.com/legal/mixpanel-hipaa/)

15. [Amplitude: Healthcare](https://amplitude.com/industry/healthcare)

16. [Google Cloud: HIPAA supported services and responsibilities](https://docs.cloud.google.com/docs/security/compliance/hipaa)

17. [Google: HIPAA and Google Analytics](https://support.google.com/analytics/answer/13297105)