Every medspa operator we talk to wants online booking. Patients expect it, ads need it, and the front desk wants the phones to ring less. The question we hear much less often is: is the booking tool we're using actually HIPAA compliant?
The honest answer, most of the time, is no — or "we're not sure." And for a medspa that runs physician-supervised treatments, not being sure is the problem.
This post is a practical walkthrough of what HIPAA compliance actually requires for a patient-facing booking flow, where most off-the-shelf tools fall short, and what a compliant integration with DrChrono looks like in practice.
Why Medspa Booking Is a HIPAA Issue at All
The question isn't whether your practice is a medspa — it's whether you're handling protected health information (PHI). PHI is any individually identifiable information tied to past, present, or future healthcare.
When a patient books a Botox appointment, fills out a skin-type intake form, or selects a provider for a laser treatment, that's healthcare information tied to an identifiable person. Your booking flow is touching PHI from the moment the patient enters their name alongside a service type.
A general-purpose scheduling tool — a third-party widget, a SaaS booking platform, a Typeform-style intake form — is typically not a HIPAA-covered entity and won't sign a Business Associate Agreement (BAA). That means any PHI flowing through it is unprotected, and the liability sits with your practice.
The Three Places Most Booking Flows Break
After building booking integrations for several medspas and clinics, we've seen the same failure modes repeat:
1. No BAA with the booking vendor
This is the most common and most legally significant gap. If a vendor stores or transmits PHI on your behalf and won't sign a BAA, using them for healthcare booking is a HIPAA violation — even if their software is technically secure. Many popular booking tools explicitly exclude healthcare providers from BAA eligibility, or make it an expensive enterprise add-on.
2. PHI passes through your website server
A lot of DIY booking setups work like this: the patient fills out a form on your website, the form data POSTs to your server or a serverless function, and then your code calls the DrChrono API. The problem is that your website server now has PHI in transit or in logs. If that server — or its hosting provider — doesn't have a BAA in place, you're exposed.
The correct pattern is to keep PHI off your website server entirely. The booking form on the page communicates directly with a HIPAA-eligible backend service that you control, and that service is the only thing that talks to DrChrono.
3. Ad attribution data ends up stored with PHI
This one trips up practices that run ads and want to know which campaign produced each booking. The naive approach: append UTM parameters to the booking form URL, pass them through the form, and store them on the appointment record in DrChrono.
That's fine as long as it's done correctly. Where it breaks: storing UTM data in a Google Sheet, a CRM without a BAA, or a browser-side analytics tool alongside the patient's name and treatment type. Google Analytics, for instance, explicitly prohibits sending PHI to its servers — and yet we've seen practices building booking confirmation steps that fire GA events with appointment details attached.
What a Compliant Booking Flow Looks Like
The architecture we use for medspa booking integrations follows a simple rule: PHI lives only inside systems that have a BAA in place.
Here's how the pieces fit together:
- The booking page lives on your website and shows real-time availability pulled from the DrChrono Appointments API. No PHI is stored here — it's a read-only display of open slots.
- The form submission goes to a lightweight backend service we control, hosted on a provider with a signed BAA (we use Cloudflare Workers or similar, depending on the practice's existing infrastructure). This is the only server that receives patient data.
- The backend service creates the appointment in DrChrono via the API and stores nothing on its own side — DrChrono is the system of record.
- UTM and ad-source data is captured from the URL at page load and stored on the DrChrono appointment's
custom_vitalsor a custom field — inside DrChrono, which is already your BAA-covered EHR. The attribution data travels with the appointment, not through a separate non-covered system. - Confirmation messages (SMS, email) go out through a HIPAA-eligible messaging provider with a BAA in place.
The goal is not to avoid touching PHI — the goal is to make sure PHI only ever touches systems that are contractually covered under HIPAA. The patient booking form is where most practices accidentally step outside that boundary.
The Compliance Checklist Before You Go Live
Before launching any patient-facing booking integration, we run through this:
- BAA in place with your hosting provider for any server that processes form submissions
- BAA in place with your email/SMS confirmation vendor (Twilio, SendGrid, and similar all offer healthcare BAAs — not always on the free tier)
- No PHI in server logs — many Node and Python frameworks log request bodies by default; disable or redact them
- No PHI sent to client-side analytics — audit your GA, Meta Pixel, and similar tags to confirm they don't fire with patient identifiers
- OAuth token handling secured — your DrChrono API credentials should live only on the server, never in client-side JavaScript
- HTTPS everywhere — obvious, but check that your form endpoint isn't somehow HTTP in staging and HTTPS in production
- BAA with DrChrono itself — DrChrono offers a BAA as part of its standard terms for medical practices; confirm yours is current
What "Compliant" Doesn't Mean
Compliance isn't about encryption checkboxes or SSL badges on your website. It's about data flows: where PHI goes, who handles it, and whether every handler in the chain is contractually covered.
A booking tool can be technically secure — encrypted at rest and in transit — and still be a HIPAA violation if the vendor won't sign a BAA. That's the nuance most marketing-focused booking tools gloss over.
Putting It Together
For the medspas we work with, the booking integration is often the most visible piece of the custom software we build — patients interact with it directly, and it's the first thing a new lead sees after clicking an ad. Getting the compliance architecture right matters both for legal protection and for the patient trust that depends on it.
If you want attribution data tied to every booking — which campaign, which ad, which keyword drove the visit — that's fully achievable within a compliant architecture. It just requires that the UTM data lands inside DrChrono rather than in a spreadsheet or a non-covered analytics tool. We cover how that join works as part of the broader booking and attribution integrations we build.
If you're running ads to a booking page and you're not sure whether your current setup is compliant, or you want to build something tighter, reach out and describe what you have. We can usually tell you within a short conversation where the gaps are and what a compliant build would take.