The enforcement climate has made "we'll sort out compliance later" expensive. URMC paid $2.85 million and Froedtert $2 million over marketing-adjacent data disclosures; the Cerebral case put marketing data flows under federal scrutiny; and Klaviyo's telehealth deplatformings showed vendors will cut off healthcare accounts to protect themselves. Call tracking sits in exactly that blast radius: a vendor holding identified patient calls, wired to your ad platforms.

Here's how the major options actually compare in 2026 — and how to get attribution without the exposure.

What makes call tracking a HIPAA problem

Dynamic number insertion (DNI) — the core mechanism — swaps your website's phone number per visitor so the call can be attributed to its source. To do that, the tracking vendor:

1. Runs a script on your website that fingerprints the visit (source, campaign, click IDs, pages viewed).
2. Routes the call through its numbers, capturing caller ID and duration.
3. Usually records and transcribes the call — where the caller states their name, DOB, symptoms, and insurance in the first 30 seconds.
4. Syncs the outcome to ad platforms for conversion optimization.

Steps 2–3 create PHI at the vendor. Step 4 is where practices historically leaked it to Google and Meta. So the questions that matter: Will the vendor sign a BAA? What does its "healthcare mode" actually disable? And what does the ad platform receive?

CallRail: a real healthcare plan, with fine print

CallRail offers a Healthcare plan with a signed BAA — legitimate, and better than most. The trade-offs live in what the plan restricts and what it costs:

• Call recordings and transcripts are limited/disabled or access-restricted depending on configuration; several of the analytics features you bought call tracking for (keyword spotting, conversation intelligence on raw audio) are constrained in HIPAA mode.
• Integrations get narrowed — some CRM and ad-platform syncs are curtailed because they'd move PHI outside the BAA boundary.
• It's a plan upgrade: you pay healthcare pricing on top of per-number and per-minute costs.
• And the BAA covers CallRail — not what your team does with exports, or the non-covered tools you pipe call data into.

We've written up the fine print in detail: Is CallRail HIPAA Compliant? Healthcare Plan Fine Print. Verdict in one line: usable, if you buy the right plan, accept the feature restrictions, and audit every integration.

CallTrackingMetrics: BAA available, more rope

CallTrackingMetrics (CTM) also signs BAAs and markets to healthcare. Its posture is more configurable than CallRail's — which cuts both ways. You can build a compliant setup (recording off or consent-gated, redaction on transcripts, restricted roles), and you can just as easily build a non-compliant one with the same account, because the platform doesn't force healthcare-safe defaults. CTM setups we audit most often fail on: recordings enabled with no consent announcement, agency staff with unscoped access to all call audio, and raw caller data synced to Google Ads via imports that include phone numbers.

If you run CTM: treat the BAA as the starting line and lock the configuration down yourself — then document it.

The category's shared weak points

Whichever vendor: four risks come with the architecture itself.

The recording is the richest PHI you hold. Callers volunteer everything. If you record, you need consent handling (and two-party-consent states make the announcement mandatory anyway), retention limits, and role-scoped access. Ask your vendor how a recording is deleted — for real, including from their backups.

The script sees your whole site. A third-party DNI script observes page paths (/services/std-testing/) alongside a visitor identity it's building. Script scope and data minimization matter as much as the BAA.

Ad-platform syncs are the leak point. The value of call tracking is feeding conversions back to Google/Meta. Done naively, that sync ships caller phone numbers and call context to platforms that will never sign your BAA — the exact pattern behind the pixel litigation wave. The safe pattern is an offline conversion upload: the ad platform gets "the click with this ID converted, value $X" — never the caller's identity or the call content.

Number pools go stale. DNI pools are finite; when a pool number gets reassigned or a stale number lingers in a cached page, Google index, or GBP listing, calls misroute or attribution corrupts. Nobody notices until a month of "direct" calls turns out to be a broken swap.

How we do DNI on PilotPractice

We built call tracking into the platform rather than bolting a third-party script onto client sites, which let us fix the category's defaults:

• Pool-based DNI gated by paid-click recency. A visitor gets a tracking number from the pool only when there's a recent paid-click signal worth attributing. Organic visitors see your real, consistent number — better for local SEO (NAP consistency) and it stops burning pool numbers on traffic that doesn't need per-session attribution.
• Automated headless swap verification. A headless browser regularly loads client pages and verifies the number swap is actually rendering correctly — the right number, in the right conditions — instead of trusting that the script "should" be working. Broken DNI gets caught by a machine, not by a month of misattributed calls.
• Call records are treated as PHI by the schema. Calls — like leads and messages — carry field-level encryption in the database; access runs through middleware that writes to an append-only HIPAA audit log; login auditing and insider-threat analytics watch who's pulling call data and whether the pattern is normal.
• Attribution without identity leakage. Ad platforms receive conversion events tied to click IDs — never form contents, never caller identity (see how the same principle runs through our whole tracking architecture).
• And there's one BAA covering the site, the forms, the tracking, the texting, and the calls — instead of a BAA patchwork with gaps at every integration seam.

The call-tracking vendor checklist (ungated)

1. BAA signed — the actual agreement, not a compliance marketing page.
2. Recording: off by default, or consent-announced, redacted where possible, retention-limited, role-restricted.
3. Transcripts: same rules as recordings — they're PHI in text form.
4. Ad-platform sync: conversion events only (click ID + value). No phone numbers, no names, no call content leaving the BAA boundary.
5. DNI script audited: what does it collect, where does it send it, does it fire on PHI-sensitive pages?
6. Pool hygiene: numbers verified live, swap behavior tested on real pages (both mobile and desktop), stale numbers purged from GBP/citations.
7. Access: per-user roles, MFA, and an audit trail of who listened to what.
8. Two-party-consent states handled (announcement on every recorded call).
9. Export discipline: call logs with caller IDs don't get emailed around as CSVs.
10. Offboarding plan: how do you get your data out — and deleted — if you leave?

The do-marketing answer

Call attribution isn't optional if you're spending on ads — flying blind means funding keywords that ring zero phones. The choice is between assembling CallRail-or-CTM + BAA + configuration + integration audits yourself, or using a platform where DNI, encryption, audit logging, and ad-platform feedback are one pre-wired, self-verifying system — with an agency team reading the reports and reallocating your budget every week. That second option is us.

Start with visibility: run the free PHI leak scanner on your site — it flags third-party scripts (call trackers included) sending visitor data off-domain. No email gate.

Then book a demo and we'll show you live call attribution — source, campaign, recording controls, and the audit log — on a real practice account.

Related: Is CallRail HIPAA Compliant? · Cross-Location Attribution Under HIPAA · The 2026 Guide to HIPAA-Compliant Marketing

Security details: trust.pilotpractice.com