Is Amplitude HIPAA Compliant? What Digital Health Teams Need to Know

Is Amplitude HIPAA compliant? Conditionally, yes. Amplitude will sign a Business Associate Agreement (BAA) on its Enterprise and Growth plans, which is a prerequisite for HIPAA-compliant use. However, the BAA alone does not make your implementation compliant. The single most important condition is this: you must configure Amplitude so that no protected health information (PHI) flows into event properties, user properties, or session data without proper safeguards, and most default digital health implementations fail this requirement. This article is current as of July 2026.

TL;DR

• Amplitude offers a BAA on Enterprise (and in some cases Growth) plans; it does not offer a BAA on its free Starter plan.
• A signed BAA is necessary but not sufficient; PHI commonly leaks through event names, URL parameters, user properties, and device identifiers in standard Amplitude instrumentation.
• HHS OCR's online tracking guidance (updated December 2022, supplemented in 2024) treats any patient-identifying analytics data collected by a third-party tool as a potential HIPAA violation if no BAA is in place or if minimum-necessary principles are ignored.
• Digital health teams using Amplitude must strip or pseudonymize identifiers before data hits Amplitude's servers, or use a compliant proxy layer.
• Amplitude's healthcare analytics capabilities are strong for product teams, but marketing teams running ad pixels alongside Amplitude face additional compliance risks that Amplitude itself does not solve.
• Alternatives exist for teams that need HIPAA-compliant tracking without building a custom data pipeline.

What Amplitude Does With Visitor and Patient Data

Amplitude is a product analytics platform. It ingests behavioral event data (page views, button clicks, feature usage, conversion events) and ties those events to user profiles. For digital health applications, this data often includes:

• User IDs that map back to patient accounts
• Event properties such as "appointment_type," "condition_searched," or "medication_refill"
• Device IDs and IP addresses captured automatically by Amplitude's SDKs
• URL paths and query parameters that may contain referral codes, provider IDs, or condition-specific page slugs
• Session replay data (if enabled) that can capture form inputs, including health information typed by patients

Under HIPAA, any individually identifiable health information is PHI. A device ID or IP address combined with a health-related event (for example, "user_123 clicked schedule_appointment on /oncology") constitutes PHI because it links an identifier to a health condition or healthcare service. This is the core risk with Amplitude in healthcare settings.

Amplitude BAA: Availability and Terms

Amplitude will execute a BAA with customers on qualifying paid plans. Based on publicly available documentation and reports from healthcare customers, the BAA is available on the Enterprise plan and has also been offered on certain Growth plan contracts. It is not available on the free Starter tier. You should confirm current terms with Amplitude directly, as plan structures and BAA availability can change.

The Amplitude BAA typically covers data stored and processed within the Amplitude platform. It does not extend to third-party integrations you connect through Amplitude (such as sending data to a warehouse, a CRM, or an advertising platform). Each downstream tool that receives PHI also needs its own BAA and compliant configuration.

What the BAA covers

• Event data ingested into Amplitude's servers
• User profile data stored in Amplitude
• Data at rest and in transit within Amplitude's infrastructure

What the BAA typically does not cover

• Data sent from Amplitude to third-party destinations via integrations
• Client-side data collection before it reaches Amplitude (your responsibility)
• Session replay content unless explicitly included in the BAA scope

Safe vs. Unsafe Configurations for Healthcare

Having a BAA does not mean you can send any data you want to Amplitude. HIPAA's minimum-necessary standard requires that you share only the PHI needed for the specific purpose. For analytics, that threshold is often zero PHI if you design your pipeline correctly.

Unsafe (common default implementations)

• Using Amplitude's client-side JavaScript SDK with default settings, which automatically captures IP addresses, device IDs, referrer URLs, and page paths
• Naming events with health-specific terms (e.g., "depression_screening_completed") tied to identifiable user profiles
• Passing URL query parameters that contain patient names, email addresses, or condition codes
• Enabling session replay without excluding form fields that capture health information
• Syncing Amplitude user profiles to advertising platforms (Meta, Google) without de-identification

Safer configurations

• Server-side event ingestion only, stripping IP addresses and device fingerprints before data reaches Amplitude
• Using opaque, non-reversible user IDs (pseudonymous identifiers that cannot be linked back to patients without a separate, secured mapping table)
• Genericizing event names so they carry no health semantics in Amplitude (e.g., "form_step_3" instead of "insulin_dose_logged")
• Disabling all auto-capture features and explicitly allowlisting only non-PHI properties
• Restricting Amplitude integrations so no data flows to non-BAA-covered tools

This level of configuration work is non-trivial. It requires close coordination between engineering, product, privacy, and legal teams. Many digital health companies discover compliance gaps only after an audit or a breach report, not during initial implementation. For a parallel analysis of similar risks in another product analytics tool, see Is Mixpanel HIPAA Compliant? Product Analytics Rules for Digital Health.

HHS OCR Guidance and What It Means for Amplitude

In December 2022, HHS OCR issued guidance on the use of online tracking technologies by HIPAA-covered entities and business associates. The guidance was supplemented in 2024 following legal challenges, but the core principle remains: if a tracking tool collects individually identifiable information in connection with healthcare services, that data is PHI, and the tool's vendor must be a business associate with a signed BAA.

OCR explicitly stated that IP addresses combined with visits to health-related pages constitute PHI. This means that even "anonymous" analytics data is not truly anonymous if it includes any identifier (IP, device ID, cookie) paired with health-related behavioral signals.

For Amplitude specifically, this guidance means:

• If you are a covered entity or business associate, you need a BAA with Amplitude before sending any data that could constitute PHI.
• Even with a BAA, you must apply the minimum-necessary standard. Sending full-fidelity behavioral data with health context may violate this principle.
• Client-side SDK deployments are particularly risky because they capture identifiers automatically before your server-side logic can strip them.

The FTC Health Breach Notification Rule applies to digital health companies that are not HIPAA-covered entities but handle health data. The BetterHelp and GoodRx enforcement actions demonstrated that sharing health-related behavioral data with analytics and advertising platforms can trigger FTC action regardless of HIPAA status. Amplitude users outside the HIPAA-covered entity framework still face regulatory risk if they share health information with third parties without consumer consent. State laws like Washington's My Health My Data Act (MHMDA) add further restrictions on the collection and sharing of health data, including with analytics tools.

For teams managing advertising compliance alongside analytics, Hospital System Marketing Compliance: HIPAA-Compliant Digital Advertising for Health System CMOs provides a deeper framework for separating marketing measurement from PHI exposure.

The Marketing Layer Problem

Many digital health organizations use Amplitude for product analytics but also run marketing tools (Google Analytics, Meta Pixel, HubSpot) on the same web properties. The compliance risk multiplies because:

• Marketing pixels fire on the same pages where patients interact with health content
• Amplitude's user IDs may be shared with marketing platforms through integrations or data warehouses
• Conversion events tracked in Amplitude (e.g., "subscription_started") may be synced to ad platforms for optimization

Amplitude does not solve this marketing-side problem. It is a product analytics tool, not a HIPAA-compliant marketing attribution platform. Teams that need compliant ad conversion tracking, form analytics, or call attribution need purpose-built infrastructure. For context on Google Analytics risks specifically, see Is Google Analytics 4 HIPAA Compliant? No -- Here Are 3 Alternatives That Are. For CRM-layer risks, see Is HubSpot HIPAA Compliant? What Healthcare Marketers Need to Know About Enterprise vs Standard.

Phone-based conversions present their own set of challenges; Healthcare Call Tracking: HIPAA-Compliant Phone Attribution Architecture for Marketing Teams covers compliant phone attribution in detail.

Safe-Use Checklist for Amplitude in Healthcare

Before you deploy

• Confirm your Amplitude plan includes BAA eligibility and execute the BAA with Amplitude's legal team.
• Document in your data map exactly which data elements will flow to Amplitude.
• Conduct a PHI assessment: for every event property and user property, determine whether it could constitute PHI when combined with a user identifier.
• Designate an internal owner (privacy officer or engineering lead) responsible for Amplitude's HIPAA configuration.

During implementation

• Use server-side ingestion via Amplitude's HTTP API rather than client-side SDKs wherever possible.
• Strip IP addresses before events reach Amplitude (Amplitude offers an option to exclude IP tracking, but verify it is active).
• Replace real user IDs with pseudonymous, non-reversible tokens. Store the mapping table in a HIPAA-secured environment separate from Amplitude.
• Disable auto-capture of URL parameters, referrers, and device properties unless you have confirmed they carry no PHI.
• If using session replay, exclude all form fields and text inputs by default; allowlist only confirmed non-sensitive elements.
• Restrict outbound integrations so Amplitude data does not flow to non-BAA tools.

Ongoing operations

• Audit Amplitude event schemas quarterly for PHI drift (new events or properties added by product teams that may carry health data).
• Train product and engineering teams on what constitutes PHI in the analytics context.
• Maintain access controls within Amplitude so only authorized workforce members can view data.
• Include Amplitude in your HIPAA risk assessment and breach response plan.
• Review Amplitude's subprocessor list periodically; changes in their infrastructure vendors may affect your compliance posture.

Compliant Alternatives for Healthcare Analytics and Marketing

If the configuration burden of making Amplitude HIPAA compliant is too high for your team, or if your primary use case is marketing analytics rather than product analytics, purpose-built healthcare analytics platforms may be a better fit.

For marketing teams specifically (tracking ad conversions, form submissions, call attribution, and session behavior across healthcare web properties), Curve is a HIPAA-compliant tracking and analytics platform built for healthcare marketers. Curve provides a signed BAA, PHI-safe server-side conversion delivery to Google, Meta, and Microsoft ad platforms, session replay designed for healthcare, and form analytics, all without requiring your engineering team to build a custom data pipeline. If your compliance challenge is on the marketing side rather than the product analytics side, Curve may solve the problem Amplitude was never designed to address.

For product analytics specifically, other options include self-hosted analytics platforms, data warehouse-native analytics (where you control the infrastructure and can enforce HIPAA safeguards directly), and analytics vendors that specialize in regulated industries. Evaluate each option based on BAA availability, data residency controls, minimum-necessary configuration defaults, and the engineering effort required to maintain compliance.

Frequently Asked Questions

Does Amplitude sign a BAA for healthcare companies?

Yes, Amplitude offers a BAA on its Enterprise plan and in some cases on Growth plans. The BAA is not available on the free Starter plan. You should contact Amplitude's sales team directly to confirm current BAA availability for your specific plan and use case.

Can I use Amplitude's client-side SDK in a patient-facing health app?

You can, but it requires significant configuration to avoid capturing PHI. Client-side SDKs automatically collect IP addresses, device IDs, and page URLs, all of which can constitute PHI when paired with health-related events. Server-side ingestion with pre-processing to strip identifiers is the safer approach for HIPAA compliance.

What happens if my team accidentally sends PHI to Amplitude without a BAA?

This constitutes a potential HIPAA violation and may qualify as a reportable breach depending on the data involved. You would need to conduct a breach risk assessment under the HIPAA Breach Notification Rule, potentially notify affected individuals and HHS OCR, and remediate the data flow. The 2022-2024 wave of enforcement actions against healthcare organizations using tracking pixels without BAAs demonstrates that OCR takes these violations seriously.

Is Amplitude compliant enough for marketing conversion tracking in healthcare?

Amplitude is a product analytics tool, not a marketing attribution platform. It does not natively solve the problem of sending conversion data to ad platforms like Google Ads or Meta in a PHI-safe manner. Healthcare marketing teams typically need a separate, purpose-built solution for compliant ad conversion tracking, even if they use Amplitude for product analytics.

How does Amplitude compare to Mixpanel for HIPAA compliance?

Both Amplitude and Mixpanel offer BAAs on enterprise-tier plans, and both require careful configuration to avoid PHI exposure through event properties and user identifiers. The compliance challenges are structurally similar: client-side SDKs capture identifiers by default, event schemas can leak health context, and integrations can send data to non-compliant downstream tools. The choice between them should be based on product analytics features, not compliance posture, since neither is inherently more or less compliant than the other.

Do I need a BAA with Amplitude if my app collects health data but I am not a HIPAA-covered entity?

If you are not a covered entity or business associate, HIPAA's BAA requirement does not technically apply to you. However, the FTC Health Breach Notification Rule and state laws like Washington's MHMDA may still restrict how you share health data with analytics vendors. The BetterHelp and GoodRx cases show that non-covered entities face enforcement for sharing health-related behavioral data with third parties. A BAA with Amplitude is still a best practice because it contractually obligates Amplitude to protect your users' data.