Onboarding a Healthcare Client: A Compliance Checklist

Onboarding a healthcare client compliantly means settling four things before any campaign goes live: whether the client is a covered entity, whether your agency will touch protected health information (and therefore needs a BAA), what tracking is currently on their properties, and what data each ad platform will receive once you start. Curve is the HIPAA-compliant tracking and attribution layer agencies use to settle the last two, with a signed BAA on every plan. The checklist below runs in dependency order, because doing it out of order is what creates rework.

Phase 1: Establish the compliance frame

Confirm whether HIPAA applies at all

Not every health-adjacent client is a covered entity. A supplement brand, a fitness studio, and a cash-pay wellness practice that bills no insurance may sit outside HIPAA while still facing state privacy law, FTC Health Breach Notification exposure, and wiretapping claims under state statutes. Ask directly: do you bill insurance, and do you consider yourself a covered entity or a business associate?

Write the answer down. An agency that assumed HIPAA did not apply, on the strength of a sales call, has no defense worth reading. And note that the answer changing later (the cash-pay clinic starts taking insurance) is a trigger to redo this phase.

Determine whether your agency will handle PHI

You will, in almost every real engagement. Access to the client's CRM, receipt of lead notifications with names and requested services, call tracking recordings, form submission emails, or the client's patient list for a custom audience all constitute handling PHI on their behalf. If any of those are in scope, your agency is a business associate and the engagement requires a signed BAA before the access is granted, not after.

Decide deliberately which of those you actually need. The cheapest compliance posture is scope reduction: an agency that never receives lead-level data has a much smaller surface than one that gets every form submission emailed to a shared inbox.

Get the BAAs signed, in both directions

Two separate documents. The client signs a BAA with your agency covering the services you provide. Your agency signs BAAs with every subcontractor and vendor that will touch PHI on your behalf, because a BAA obligation flows down. Freelance media buyers, offshore reporting teams, and any tool that stores lead data are all in scope.

Note the vendors who will not sign. Meta and Google do not sign BAAs for their advertising products. That is not a blocker; it is the constraint that determines the entire tracking architecture, which is why this step comes before the tracking work rather than after.

Phase 2: Audit what is already there

Scan the client's web properties

Before you touch anything, inventory what is firing. Meta Pixel, Google tag, TikTok pixel, LinkedIn Insight, heat map tools, chat widgets, A/B testing scripts, session recorders, and whatever a previous agency left behind. Run the scan on the pages that matter most: intake forms, booking flows, service line pages, and the thank-you page.

The thank-you page is where the worst exposure usually lives, because URLs there frequently encode the service requested and pixels fire on load with the full URL. Curve's free compliance scanner produces this inventory in a few minutes and gives you something to attach to the onboarding record.

Inventory the data flows, not just the scripts

Scripts are the visible half. Ask where form submissions go (email, CRM, Zapier-style automation, a spreadsheet), where call recordings live, who has logins to what, and whether any patient list has previously been uploaded to an ad platform as a custom audience. That last one is common and rarely disclosed voluntarily.

Automation platforms deserve a specific look, since they often sit invisibly in the middle of a lead flow. Whether the one in use can be covered by a BAA and configured safely is a real question with a real answer: see the analysis of automation tools in healthcare marketing.

Read the existing privacy policy and consent setup

You need to know what the client has already told patients. A privacy policy promising that no data is shared with advertisers, alongside a live Meta Pixel on the booking page, is an FTC problem independent of HIPAA. Flag the mismatch in writing during onboarding. Fixing it is usually the client's counsel's job, but discovering it is yours.

Phase 3: Rebuild the measurement layer

Remove client-side pixels from PHI-adjacent pages

Anywhere a patient identifies themselves or expresses clinical intent, client-side pixels come off. That means intake forms, booking flows, patient portals, and confirmation pages at minimum. The reason is mechanical rather than philosophical: a browser-side pixel sends the page URL, referrer, and whatever the tag manager was configured to grab, directly to a platform that has not signed a BAA, and no configuration inside the platform can pull it back.

Install a server-side tracking layer

Replace the pixels with a server-side path. Events go to infrastructure you control, and only explicitly mapped fields forward from there to each platform. The practical difference for an agency is that "what does Meta receive" becomes a question with a written answer instead of a hope.

Define the event schema before you define campaigns

Agree with the client on what counts as a conversion, in their language, then map each one to a neutral name for outbound use. A booked consultation is a booked consultation in your reporting and a neutral event alias in the ad account. Service line detail stays on your side of the line.

Do this once per client and reuse it across every platform. Agencies that skip this end up with Meta counting one thing, Google counting another, and no way to reconcile either against the client's practice management system.

Wire the outcome path

Leads are not outcomes. Set up the return path from the client's CRM or practice management system so booked, arrived, and completed appointments flow back and match to the original click, through webhooks or bulk upload with click-ID matching. Configure it during onboarding while you have the client's technical attention, because retrofitting it three months in requires the same access and a much less enthusiastic counterpart. Related reading: lead routing from ad click to CRM without PHI.

How Curve fits into agency onboarding

Curve is HIPAA-compliant ad tracking, attribution, and analytics built for healthcare, and healthcare marketing agencies are one of its target segments precisely because this checklist repeats on every account.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than directly to the ad platforms, which is the structural change that makes the rest controllable:

• Per-destination field mapping. Only explicitly mapped fields forward to a given destination, and the default is that nothing goes. Onboarding becomes a configuration you can show the client.
• Neutral event aliases. The platform sees a neutral event name, not the service line.
• Identifier hashing. SHA-256 per each platform's conversion API requirements.
• PHI-pattern detection. A monitoring layer that flags PHI-shaped values in payloads, which catches the legacy form nobody mentioned during onboarding.
• Bridge tokens. Attribution survives the click-out to IntakeQ, Calendly, or Jane App instead of breaking at the exact moment the conversion happens.
• Incoming webhooks and offline conversion uploads. Outcomes return from the CRM or EHR matched on email, click ID, or bridge token, with protected core attribution and contact fields that incoming data cannot override.
• Signed BAA on every plan, so the measurement layer is inside the covered chain and your subcontractor flow-down obligation is satisfied for this vendor.

Destinations covered server-side include Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft UET, LinkedIn CAPI, and GA4. For the architecture underneath, see the conversion API architecture overview.

Phase 4: Verify before you spend

Configuration is a claim. Verification is evidence, and the difference matters when someone asks two years later.

1. Submit a real test lead through every live form and booking path, using test data you control.
2. Inspect the outbound payload to each destination. Look at what actually left, field by field, not at what the mapping screen says.
3. Confirm the conversion arrived in each ad platform under its neutral name, and that it deduplicates correctly against any remaining browser event.
4. Re-scan the site after the client's web team has done its final deploy, because someone re-adds a tag more often than you would like.
5. Screenshot everything and file it in the client record with a date. This is the artifact that turns "we were careful" into "here is what we configured and when."

Only then does spend go live.

Phase 5: Set the standing cadence

Onboarding ends, obligations do not. Fix a monthly compliance line item in the client report covering active scripts, destinations and their fields, PHI-pattern alerts, and BAA status. Re-scan quarterly at minimum. Re-run the access review whenever someone joins or leaves the account team, and treat client offboarding as a checklist of its own, ending in documented disposal or return of PHI.

Frequently asked questions

Does a marketing agency really need a BAA?

If it creates, receives, maintains, or transmits PHI on behalf of a covered entity, yes. Access to the client's CRM, lead notifications containing a name plus a requested service, or call recordings all qualify. Running only aggregate media with no lead-level access may not, but that arrangement is rarer than agencies assume.

Can we just have the client sign something that says we do not handle PHI?

Not usefully. The obligation follows the facts of the data flow, not the label in the contract. If PHI reaches you, you are a business associate regardless of what the services agreement calls the relationship.

What if the client refuses to remove their existing pixels?

Document the recommendation, the specific pages at risk, and the client's decision in writing, then decide whether you are willing to run the account under that condition. Litigation and OCR enforcement both look at who knew what. Since 2026-01-28, OCR civil monetary penalties run from $145 to $2,190,294 per violation category per year, and healthcare pixel litigation settlements have cumulatively crossed $100M.

How long should compliant onboarding take?

The paperwork and audit phases move at the speed of the client's counsel and web team. The tracking rebuild itself is days, not months, when the measurement layer is a product rather than a custom build. Budget for the client's legal review being the long pole.

Do we need consent banners on a healthcare site?

Depends on jurisdiction and the client's audience, and it is a legal question rather than a marketing one. Consent management is worth configuring regardless, but treat it as a complement to server-side controls, not a substitute. Consent to cookies is not authorization to disclose PHI.

Can we upload the client's patient list to build a custom audience?

No, not as a routine agency practice. Uploading a list of a covered entity's patients to a platform that has not signed a BAA is a disclosure of PHI. First-party audience activation needs to happen inside a covered, controlled path rather than by handing a file to an ad platform.

Where to start

Turn this into a stored checklist that every account director runs, with a completed copy filed per client. The value is in the repetition. An agency that runs the same audit on every new healthcare client finds the surprises in week one, when they are cheap.

Start with the scan, because it takes minutes and it usually reframes the conversation with the client. Run the free compliance scanner against a prospect's site before the pitch, then visit curvecompliance.com to see how the tracking layer and BAA work across a book of healthcare accounts.

Reviewed August 2026. Ad platform conversion APIs and healthcare advertising policies change frequently. Verify current requirements before implementation.