I recently spent an evening asking Google's Gemini whether website chat tools for clinicsmpletely certain. Several were wrong, and not all in the same direction.
It told me a name plus a health question "always" equals PHI — too simplistic. It told me a chatbot that stores nothing is "legally a conduit" — HHS reads that exception far more narrowly than that. At one point it declared my own product automatically compliant, which is flattering, and exactly the kind of confident shortcut this article is about.
If the AI assistants clinic owners consult about compliance can get this wrong while sounding authoritative, the topic deserves a slower walkthrough.
For U.S. medical practices, aesthetic clinics, and medical spas, the more useful questions are:
- Is your clinic actually a HIPAA covered entity?
- Does the tool create, receive, maintain, or transmit protected health information (PHI) on your behalf?
- What happens when a visitor voluntarily types personal or health information into the chat?
- Does the vendor retain that information?
- Is identifying information removed before it reaches downstream AI systems?
- Which other technology providers are involved in processing the data?
- If the vendor acts as a business associate, will it sign a Business Associate Agreement (BAA)?
The answers depend on the actual data flow — not on a badge in a website footer.
First: Not Every Medical Spa Is Automatically Covered by HIPAA
HIPAA does not apply to every business that offers health-related or aesthetic services.
The HIPAA Rules apply to covered entities and their business associates. A healthcare provider generally becomes a HIPAA covered entity when it carries out certain standard healthcare transactions electronically, such as specified billing and payment transactions. HHS specifically notes that healthcare providers are covered entities only when they meet the applicable criteria. ion matters in aesthetic medicine, where some practices operate mainly or entirely on a cash-pay basis.
A medical spa should not automatically assume either:
“We provide medical treatments, so HIPAA applies to everything we do.”
or:
“We are cash-pay, so HIPAA definitely does not apply to us.”
The clinic should clarify its own status first.
Being outside HIPAA does not mean health data is unregulated. Other federal and state privacy requirements may still apply depending on the business, the data, and the jurisdiction.
What Is PHI?
Under the HIPAA Privacy Rule, protected health information is individually identifiable health information held or transmitted by a covered entity or its business associate.
The information must relate to a person’s past, present, or future health condition, healthcare, or payment for healthcare and identify the individual, or provide a reasonable basis for identifying them.
Context does the heavy lifting here. A message saying:
“Do you offer Botox?”
is not automatically PHI simply because Botox is a medical treatment.
A message saying:
“My name is Sarah Jones. I have rosacea and take isotretinoin. Can I have this treatment?”
creates a very different situation when it lands in the environment of a HIPAA covered clinic, because it ties identifying information to health information.
The common claim that “PII + a health question always equals PHI” is still too simplistic, because HIPAA’s PHI definition depends on who holds or receives the information and in what regulated context.
But for a HIPAA covered clinic, identifiable health-related conversations deserve careful attention.
“They Are Only a Lead, Not a Patient” Is Not a Safe Rule
Another common belief is that HIPAA only starts when someone becomes an established patient.
It isn't the test. The HIPAA definition of individually identifiable health information includes information relating to the past, present, or future provision of healthcare to an individual.
The regulatory analysis does not solely hinge on whether someone already has a patient record.
A website visitor asking about treatment while identifying themselves can raise HIPAA issues for a covered clinic, even at the enquiry stage.
Calling someone a “lead” does not change the nature of the information being processed.
When Does a Software Vendor Need a BAA?
A Business Associate Agreement is generally required when a vendor acts as a business associate of a HIPAA covered entity.
HHS defines a business associate as an entity that performs certain functions or services involving PHI on behalf of a covered entity. The relevant language includes entities that create, receive, maintain, or transmit PHI on behalf of a covered entity or another business associate. words are “creates, receives, maintains, or transmits” — not “stores permanently.”
Which makes this common vendor statement misleading:
“Our chatbot does not save conversation transcripts, so we don't need a BAA.”
Not retaining conversations is an important privacy safeguard. It reduces the amount of sensitive information that could later be exposed and aligns with good data-minimisation practices.
But permanent storage is only one part of the picture under HIPAA.
“We Don’t Store It” Is Not the Same as “We Never Process It”
Suppose a visitor writes:
“I’m Jane Smith. I had breast surgery last year and want to know whether I can have another procedure.”
A chatbot may process that message without creating a permanent conversation record.
The important questions are:
- Where does the raw message first arrive?
- Is it temporarily processed by the chatbot provider?
- Is personally identifying information detected and removed?
- Does the unredacted message enter application or infrastructure logs?
- Does the full message reach the AI model?
- Is it sent to any additional processors?
- Is any identifiable version retained after the request is completed?
A system that intentionally avoids retaining conversations presents a very different privacy risk from one that stores every conversation indefinitely and builds identifiable lead profiles.
Anonymisation Helps — But Where Does It Happen?
Consider two possible architectures.
Architecture A
A visitor submits an identifiable health question.
The full message is stored as part of a conversation record or lead profile.
The clinic can later open the dashboard and see:
- the visitor’s name;
- contact information;
- health concern;
- treatment interest;
- full conversation history.
The information may also be sent to an AI provider for processing.
Architecture B
The assistant does not ask for a name, email address, or phone number before answering questions.
If a visitor voluntarily provides personally identifying information, a PII-detection layer removes those identifiers before the message reaches downstream AI processing.
Full conversation transcripts are not retained.
Raw conversation content is not stored in production application logs.
The clinic does not receive identifiable chat transcripts or lead profiles.
The dashboard contains only anonymous, aggregated information such as:
- treatments asked about;
- concerns raised;
- treatments requested but not offered;
- frequency counts.
In the second model, the system is built around data minimisation: identifying information is neither required for the conversation nor retained as a business asset.
The words “anonymous chatbot” don't automatically settle every HIPAA question, but the architecture materially reduces how much identifiable information gets exposed, processed, and retained in the first place.
What Happens Before the AI Model Matters
For AI systems, one of the most important architectural questions is whether identifying information reaches the language model itself.
A privacy-first design can insert a dedicated PII-detection and redaction layer before downstream AI processing.
For example:
“My name is Sarah and I have rosacea. Can I have laser treatment?”
might become:
“My name is [name hidden for privacy] and I have rosacea. Can I have laser treatment?”
before the downstream model processes the question.
This is different from sending the full identifiable message to the model and attempting to anonymise it afterward.
Clinics evaluating AI vendors should therefore ask:
Where, exactly, does redaction occur in the processing flow?
And:
Can the unredacted message appear in production logs or retained conversation history?
A privacy architecture is strongest when raw conversational data is not retained unnecessarily at any stage.
Development Logs and Production Systems Are Not the Same Thing
During software development, engineering teams may temporarily enable detailed diagnostic logging to test whether safety, redaction, and routing systems are working correctly.
Those logs should not automatically become part of the production architecture.
For a privacy-sensitive healthcare assistant, production systems should be designed so that raw visitor conversations are not unnecessarily written to application logs, debugging consoles, or monitoring systems.
Once testing is complete, verbose conversation logging should be disabled or replaced with non-identifying operational telemetry.
The goal is simple:
Do not create a database of sensitive conversations that the product does not actually need.
Encryption Does Not Make a Product “HIPAA Compliant”
Encryption matters.
So do access controls, security policies, risk management, and appropriate infrastructure.
But none of these creates an official HIPAA certification.
HHS and the Office for Civil Rights explicitly state that they do not certify products as “HIPAA compliant.” ng:
“We use SSL encryption, therefore we are HIPAA compliant.”
is giving you an incomplete answer.
Similarly, signing a BAA does not magically make every possible use of a product compliant.
A BAA establishes contractual obligations between regulated parties. The actual system architecture, configuration, data flows, and use of PHI still matter.
A BAA Is Not Proof That a Vendor Stores PHI
There is an opposite misconception too.
Some people assume:
“If a software vendor is willing to sign a BAA, that must mean it stores patient records.”
Also wrong.
A vendor may design its system to minimise identifiable information, avoid retaining conversations, and remove personal identifiers before downstream processing while still being willing to enter into a BAA with covered-entity customers where appropriate.
The existence of a BAA tells you about the contractual relationship between the parties.
It does not, by itself, describe the vendor’s data-retention architecture.
A privacy-first vendor can therefore do both:
Minimise PHI technically.
and
Provide appropriate contractual protection where a business-associate relationship exists.
These are complementary safeguards, not alternatives.
What Should “HIPAA Compliant” Mean When You See It on a Software Website?
Clinics need to become slightly more demanding consumers.
Take Workee as a real-world example.
Workee markets its software directly to medical spas, dental clinics, wellness centres, and weight-loss clinics. Its public website displays “HIPAA Compliant,” alongside “PCI Compliant” and “SSL Encryption.” It also promotes booking, client management, automation, client tracking, and the collection of emails and phone numbers as part of its product offering. ng that label could reasonably assume that HIPAA has been dealt with.
But if you are a HIPAA covered entity and the platform will create, receive, maintain, or transmit PHI on your behalf, the next question should be immediate:
Where is the BAA?
More precisely:
“Will you sign a Business Associate Agreement with our clinic, and under which plan or contract?”
While reviewing Workee’s public website for this article, I could not find a publicly available BAA or a clear explanation of the process for executing one.
That does not mean Workee does not provide one privately.
And it does not establish that Workee is non-compliant.
It means that “HIPAA Compliant” on its own is not enough information for a covered clinic making a purchasing decision.
If a vendor expects healthcare businesses to rely on a prominent HIPAA claim, it should be able to explain clearly what happens when a covered entity needs a BAA, which services are covered, and what safeguards apply to PHI processed through the platform.
The answer may be perfectly satisfactory.
But the clinic still needs to ask.
What Better Transparency Looks Like
Now compare that with Jane, a practice-management platform built to hold actual patient information.
The BAA question is unavoidable when a product manages functions such as patient records, scheduling, and clinical workflows.
Jane addresses the issue directly — not in a blog post, but in its legally binding Terms of Use, which state that if a subscriber is subject to HIPAA, Jane will, upon request, enter into its standard Business Associate Agreement with that subscriber. No inference from a footer badge required; the contractual commitment is written into the terms every customer agrees to.
It does mean the contractual question is addressed directly.
And that is a useful standard for clinics evaluating healthcare software.
A vendor that handles identifiable patient data should not leave you trying to reverse-engineer its HIPAA position from a footer badge, an SSL certificate, or promotional copy.
Ask what the system does with PHI.
Ask who else processes it.
And when a BAA is required, ask about the agreement before sending real patient information through the system.
The response will tell you considerably more than the badge.
What About Anonymous Website Chat?
An anonymous patient-education assistant can have a substantially smaller privacy footprint than a traditional lead-capture chatbot.
For example, a system might:
- answer general treatment questions;
- provide practical clinic information;
- avoid requiring a name, email address, or phone number;
- avoid creating identifiable lead profiles;
- avoid giving the clinic access to full conversation transcripts;
- avoid permanently storing conversations;
- remove personal identifiers entered voluntarily by visitors;
- prevent unredacted messages from reaching downstream AI models;
- keep raw conversation content out of production application logs;
- provide only aggregated insights, such as frequently asked treatments or concerns;
- direct visitors who are ready to book to the clinic’s existing booking system.
This follows a simple privacy principle:
Don’t collect identifiable information unless you actually need it.
A person should not have to provide their name and phone number just to ask:
“Do you offer Sculptra?”
or:
“How long is the downtime after CO2 laser?”
The assistant can answer the question first.
When the visitor is ready to identify themselves and book, that information can be entered directly into the clinic’s booking or patient-management system.
Lead Capture Creates a Different Data Flow
Now compare this with a chatbot that immediately asks:
“What is your name?”
“What is your email address?”
“What is your phone number?”
and then:
“What treatment or medical concern would you like help with?”
The system may save everything as a lead profile.
The clinic can log in later and read the conversation.
That may be useful for sales.
But for a HIPAA covered clinic, it creates a very different compliance situation because the software is deliberately linking identifiable individuals with health-related enquiries.
If that vendor is acting as a business associate, the clinic should expect the appropriate BAA and HIPAA safeguards.
This is why clinics should not evaluate healthcare chatbots only by asking:
“Can it capture more leads?”
They should also ask:
“What information does it need to capture at all?”
Does Clicking an External Booking Link Expose Booking Data to the Chatbot?
Not necessarily.
There is an important difference between:
- an AI assistant collecting the visitor’s name, health concern, and contact details itself; and
- an assistant displaying a standard booking link that takes the visitor to a separate booking platform.
In the second case, the visitor leaves the assistant environment and enters their personal information directly into the clinic’s booking or patient-management system.
The chatbot does not automatically receive the data entered on the external booking page simply because it provided the link.
The clinic should separately determine whether its booking or patient-management provider is acting as a business associate and whether a BAA is required.
Keeping those environments separate can help avoid unnecessary duplication of patient data.
The Narrow “Conduit” Exception Should Not Be Used Casually
Some vendors describe themselves as mere conduits because they do not retain data.
HHS interprets the conduit concept narrowly. Its guidance describes conduits as entities whose role is essentially transmission, with only limited or transient access to PHI. Recent HHS telehealth guidance likewise distinguishes true transmission services from vendors that create, receive, or maintain PHI on behalf of a covered entity. that analyses a patient’s message, classifies it, generates a response, or extracts structured information is doing more than acting as a digital delivery service.
A sophisticated AI vendor shouldn't lean casually on “we are only a conduit.”
What the system actually does with the message decides the question, not what the vendor prefers to call itself.
What About Subprocessors?
Modern AI products rarely operate alone.
Depending on the architecture, a service may rely on:
- cloud infrastructure;
- AI model providers;
- security services;
- PII-detection systems;
- database infrastructure;
- monitoring tools.
If PHI is involved, the vendor needs to understand its obligations throughout that processing chain. HHS requires business-associate contracts to address safeguards around PHI and requires business associates to impose corresponding restrictions on subcontractors that have access to PHI. f a public subprocessor list does not automatically mean a product is non-compliant.
But a clinic conducting vendor due diligence should be able to obtain meaningful information about where sensitive information is processed and which third parties may handle it.
A vague response like:
“Don’t worry, our servers are secure.”
is not the same thing as understanding the actual data architecture.
Five Questions to Ask Any AI or Chatbot Vendor
Instead of asking only:
“Are you HIPAA compliant?”
ask:
1. Does your chatbot require personal information before answering questions?
A privacy-focused assistant should not need a visitor’s identity to answer ordinary treatment or practical questions.
2. What happens if a visitor voluntarily types their name or contact information?
Ask whether the system detects and removes identifying information, and at what point in the processing flow this happens.
3. Do you retain full conversations or create identifiable lead profiles?
There is a major difference between anonymous aggregate data and a searchable database of patient conversations.
4. Can raw conversations appear in production logs?
A system may claim not to have a “chat history” while still retaining raw content in application or monitoring logs.
5. If you act as our business associate, will you sign a BAA?
For HIPAA covered clinics, this is a question that should have a clear answer.
The Real Lesson: Start With the Data Flow
There is no universal rule that says:
AI chatbot = BAA required.
There is also no universal rule that says:
Anonymous chatbot = no BAA required.
And this alone is not enough:
No permanent chat storage = HIPAA does not apply.
The right analysis starts with four questions.
Who is the clinic?
Is it a HIPAA covered entity?
What information enters the system?
Can it identify someone and reveal information about their health or healthcare?
Who receives or processes that information?
The chatbot provider? A redaction service? A cloud provider? An AI model?
What happens to the information?
Is identifying information removed? Is the raw message logged? Is the conversation retained? Does the clinic receive an identifiable transcript?
Those questions tell you far more than a “HIPAA compliant” logo.
Privacy-first architecture can dramatically reduce unnecessary exposure.
An assistant that does not force visitors to identify themselves before asking a basic question, does not build unnecessary patient profiles, does not retain conversation transcripts, removes personal identifiers before downstream AI processing, and keeps booking data inside the clinic’s appropriate booking or patient-management system starts from a strong principle:
Collect less. Share less. Retain less.
For clinics, that means fewer unnecessary copies of sensitive information.
For patients, it means being able to ask a simple or private question without immediately surrendering their identity.
And for software vendors, it means designing privacy into the architecture rather than treating a BAA or a “HIPAA compliant” badge as the entire compliance strategy.
For U.S. clinics, the data flow is the compliance story.
--
Nat Guribashvili
Founder, iGlowly
LinkedIn
This article provides general information and is not legal advice. HIPAA applicability depends on the status of the clinic, the services provided, the technology architecture, and the specific data flows involved. Clinics should obtain qualified legal or compliance advice for their own circumstances.