Is Weave HIPAA Compliant? Patient Messaging Verdict

Yes, Weave can be HIPAA compliant for patient messaging. Weave publishes a Business Associate Agreement addendum that supplements its underlying customer agreement, and it operates as a business associate handling PHI on behalf of practices, with encryption in transit and at rest. Confirm your own BAA is executed before storing PHI rather than assuming it arrived with the subscription. The exposure most practices miss sits outside Weave entirely: the ad tracking on the web pages that generate those patients, which discloses service interest to platforms that have signed nothing. Curve is the HIPAA-compliant tracking layer for that, with a signed BAA on every plan.

The direct answer, in more detail

Weave is a practice communication platform used heavily in dental, optometry, and small medical practices. It bundles phone, two-way texting, appointment reminders, missed-call text, payments, and review requests into one system that sits next to the practice management software.

Almost every one of those functions touches PHI. A text confirming an appointment is a disclosure that a specific person is receiving care from a specific provider. That is PHI even when the message says nothing clinical. So the BAA question is not optional here, it is foundational.

Weave's published BAA addendum is a real document with real substance. Notably it goes beyond baseline HIPAA and addresses 42 CFR Part 2, the stricter federal rule for substance use disorder records, including the restriction that those records cannot be disclosed for use in civil, criminal, administrative, or legislative proceedings without a court order or patient consent. A vendor that has thought about Part 2 has thought harder than most.

The addendum also places obligations on you, not just on Weave:

• Notify Weave of any restrictions on PHI use that are more restrictive than HIPAA requires.
• Report changes in, or revocation of, an individual's permission to use or disclose their PHI.
• Do not request uses of PHI that would violate HIPAA.
• Tell Weave if data you provide falls under 42 CFR Part 2, and supply the required notices and consent records.

Those are not boilerplate. They are things a practice has to actually operationalize, and most do not have a process for the second one.

One thing to verify yourself

Weave's published addendum states that it supplements the underlying agreement including the terms of service. What it does not spell out publicly is whether it attaches automatically to every account or requires a separate execution step, and whether availability varies by product configuration. Verify that with Weave directly and keep the executed copy in your compliance file. Do not treat a published legal page as proof that your specific account is covered.

Where Weave is genuinely fine

With the BAA in place, Weave's core workflows are reasonable business associate activities. Appointment reminders, two-way texting with patients, missed-call follow-up, recall campaigns, and review requests all fall inside the range a communication vendor is expected to handle.

The fit is best for the practices that actually buy it: single-site and small-group dental, optometry, veterinary-adjacent, and primary care offices where the front desk is one or two people and the alternative is a personal cell phone. That last point matters more than it sounds. Staff texting patients from unmanaged personal devices is a worse compliance outcome than any platform, and moving that traffic into a system with a BAA, audit trails, and access controls is a genuine improvement.

Encryption is table stakes but it is present: TLS in transit, encryption at rest, access limited to authorized personnel with audit trails.

What the BAA does and does not cover here

A BAA binds a vendor to safeguard PHI, restrict its use, report breaches, and return or destroy data at the end of the relationship. It is necessary. It is not a compliance program, and its edges are sharper than teams assume.

Inside Weave's coverage: message content, contact records, call data, and the PHI Weave creates, receives, maintains, or transmits while delivering the service.

Outside it:

• What the patient does with the message. An SMS lands on a device with a lock screen preview. That is a known and accepted risk in the reminder workflow, which is exactly why the minimum-necessary rule matters in message content.
• Your website and its tracking scripts, including any pages carrying a webchat or scheduling widget.
• Ad platforms. Meta and Google do not sign BAAs for their advertising products, and no vendor addendum changes that.
• Systems you sync to. Practice management integrations, CRMs, email platforms. Each is a separate business associate question. Our verdict on whether Klaviyo is HIPAA compliant for email and SMS covers the marketing-messaging end of that.
• What staff type. A BAA does not prevent someone from putting a diagnosis into a text thread that will be read on a bus.

Message content is where practices actually fail

The standard to hold is minimum necessary. A reminder that says the time, the date, and the practice name is defensible. A reminder that names the procedure is not, and it is trivially easy to create by using an appointment type as a template variable.

Check your templates for merge fields that pull the procedure, the provider specialty, or the reason for the visit. Those fields exist in the practice management system for staff, and a template author reaches for them because they make the message feel personal. That is the whole failure mode in one sentence.

Where the ad tracking problem shows up

Weave sits at the bottom of the funnel. The compliance risk that a communication platform cannot touch sits at the top, on your website, where patients arrive from ads.

The pattern looks like this. A practice runs Google and Meta campaigns to service pages. A patient clicks an ad for a specific treatment, lands on a page whose URL names that treatment, opens a chat or clicks to call, and eventually becomes a conversation inside Weave. Along that path:

• A Meta Pixel sends the full page URL to Meta on page load, along with a browser identifier that persists across sessions and across other sites.
• A Google tag sends the same page view plus the click identifier that ties it to a specific ad and a specific person.
• A click-to-call or chat-open event fires as a conversion, saying that an identifiable browser inquired about a named service on a healthcare site.
• Call tracking numbers swapped into the page create their own data trail, and the recording or transcript is its own PHI question.

None of that touches Weave, so none of it is governed by Weave's addendum. Every one of those calls is a disclosure to a vendor with no BAA in place. This is the mechanism behind healthcare pixel litigation that has cumulatively crossed $100 million in settlements, including Advocate Aurora at roughly $12.225 million. The plaintiffs' theory does not require that a diagnosis was transmitted, only that an identifiable person's health interest was disclosed to a third party. A treatment-named URL travelling with a persistent identifier does that unaided.

The uncomfortable version: a practice can run a textbook-clean messaging operation inside Weave and still have its highest-risk disclosure happening on the home page, in a script nobody has looked at since the site was built.

The architecture that works

Three planes, kept separate.

1. Clinical. Practice management and EHR. PHI lives here and moves only to vendors with signed BAAs.
2. Communication. Weave, under its BAA, holding the minimum patient data needed to run a conversation, with templates that never name the procedure.
3. Measurement. Ad platforms and analytics receive conversion signals and matching keys. They never receive page URLs that describe care, service parameters, call transcripts, or uploaded patient lists.

Two habits hold it together. Generic URLs, because a path naming a treatment is a disclosure every time it travels. And a single server-side decision point between an event happening and anything leaving, so what reaches an ad platform is a configuration you can read rather than a guess about what a tag does.

Attribution is the objection that always comes next, and it is a fair one. If the ad platforms stop receiving rich page context, how do campaigns optimize? The answer is that they optimize on conversion events and matching keys, not on descriptions. Our walkthrough of HIPAA-compliant lead routing from ad click to CRM covers the full path, and the honest answer on whether the Meta Pixel or conversion API is safe covers what each actually transmits.

How Curve handles a practice running Weave

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It replaces the client-side pixels on your site with a server-side path where you control what leaves.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than straight to the ad platforms. From there:

• Per-destination field mapping decides what forwards. Only fields you explicitly map reach a given destination, configured separately per destination. Page URLs, service parameters, and form values stay behind unless you deliberately map them. The default is that nothing goes.
• Identifiers are SHA-256 hashed to meet each platform's conversion API requirements before forwarding.
• Neutral event aliases keep the service line out of the ad account. A call, chat, or appointment request forwards as a generic event rather than one naming the treatment, so nobody browsing Ads Manager sees a condition.
• PHI-pattern detection monitors payloads, flagging PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences. It is a monitoring layer that tells you when something upstream changed. The protection is the field mapping plus hashing.
• Bridge tokens preserve attribution across click-outs into a separate booking or intake tool, so a conversion completed on another domain still credits the right campaign without carrying content across.
• Incoming webhooks match outcomes back by email, click ID, or bridge token, and incoming data cannot override protected core attribution and contact fields.
• Offline conversion uploads push confirmed appointments or treatment starts from your practice management system with click-ID matching, so the conversions that matter most reach the campaigns that earned them.

Clean conversions forward server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, LinkedIn, and GA4. Because the path is server-side, it is unaffected by ad blockers and browser tracking prevention, which usually raises measured conversion volume rather than lowering it. A signed BAA is included on every Curve plan.

Checklist for a practice using Weave

1. Confirm the BAA is executed for your account and keep the copy in your compliance file. Published legal terms are not proof of your own coverage.
2. Audit every message template for merge fields that pull procedure, provider specialty, or visit reason.
3. Check your Part 2 exposure. If any of your data falls under 42 CFR Part 2, the addendum requires you to say so and to supply the required notices and consents.
4. Review who has access and whether departed staff still do.
5. Look at call recording and transcription settings and decide deliberately whether you need them and where those artifacts live.
6. Read your website's service page URLs as a stranger would. Rename anything that names a condition or treatment.
7. Watch the network tab through a real ad-click-to-contact journey. Filter to ad platform domains and read what actually leaves. This is the only step that tells you the truth.

Multi-location dental and DSO groups should pair this with our dental marketing compliance checklist, since location pages multiply the surface area quickly.

Frequently asked questions

Does Weave sign a BAA?

Weave publishes a Business Associate Agreement addendum that supplements its underlying customer agreement and covers PHI, including data subject to 42 CFR Part 2. Confirm with Weave that yours is executed for your specific account before storing PHI in the platform.

Is texting patients HIPAA compliant?

It can be, under a BAA, with minimum-necessary content. SMS reaching a lock screen is a known limitation of the channel, which is why appointment reminders should carry time and place rather than the reason for the visit.

Can we put the procedure name in an appointment reminder?

You should not. The template variable exists because the practice management system knows the answer, not because the message needs it. Name the practice and the time, and keep the clinical detail out of the channel.

Does Weave's BAA cover our website?

No. It covers PHI Weave handles while delivering its service. Your site, its analytics, and its ad pixels sit entirely outside that relationship and need their own solution.

What about call recordings and transcripts?

Treat them as clinical records, because patients volunteer symptoms and medication names on the phone constantly. Confirm where recordings are stored, who can access them, and that nothing derived from them reaches marketing tooling.

Can we upload our patient list to build a lookalike audience?

No. A list of your patients identifies people as patients, and Meta and Google do not sign BAAs for their advertising products. Optimize on conversion events forwarded server-side with hashed identifiers instead.

Can we still measure which campaigns produce booked appointments?

Yes. Push confirmed appointments as offline conversions matched by click ID, or forward a neutral appointment event server-side. Either gives you campaign-level truth without telling the platform what the appointment was for.

Where to start

Weave publishes a substantive BAA and operates as a business associate, so patient messaging can be run compliantly on it once your own agreement is confirmed and your templates are clean. The failure modes that remain are template variables that name procedures, and the tracking on the website that produced the patient in the first place.

Curve handles the second one. Server-side collection, per-destination field mapping, hashed identifiers, neutral event aliases, bridge-token attribution, and offline conversion uploads let a practice keep optimizing Meta and Google campaigns against real booked appointments without disclosing what anyone came in for. A signed BAA is included on every plan. Run our free compliance scanner against your practice website to see what is leaving right now, or visit curvecompliance.com to walk through the funnel.

Reviewed August 2026. Vendor BAA policies change. Confirm current terms with the vendor.