Data handling · for medical, dental, and professional practices

Where patient information goes, and where it does not.

If you run a practice, the question before anything else is whether hiring me creates a HIPAA problem. Here is the direct answer, with the sources, so your office manager or your counsel can check it instead of taking my word for it.

First, the thing most web shops will not tell you. There is no such thing as a "HIPAA compliant website." It is not a certification, there is no body that issues it, and any vendor who puts that badge on a sales page is selling you a feeling. What exists is a set of obligations that attach to your practice, and a question about whether a given vendor touches protected health information on your behalf. If they do, you need a Business Associate Agreement with them. If they genuinely do not, you do not.

So the default build is designed so that nobody touches PHI. Not the site, not the chatbot, not the reminder system. That is the cheapest, cleanest answer to the question, and it is achievable for the large majority of practices, because a marketing website's job is to get a new patient to call you, not to discuss their condition.

The default setup

How each piece stays out of PHI territory

01

The website itself. Static pages. No patient login, no portal, no records, no intake form asking about symptoms. It loads, it informs, it gives someone a way to reach you. There is nothing for a breach to expose because there is nothing stored.

02

The contact form. Name, phone, email, and a general reason for reaching out. The form explicitly tells visitors not to include medical details, and the field labels are written so they are not invited to. Submissions land in your email, not in a database I run.

03

The chatbot. Configured to answer questions about your hours, location, insurance accepted, services offered, and to book a call or a visit. It is instructed to decline clinical questions and to tell people to call the office instead. It never asks for a condition, a medication, or a history.

04

Appointment reminders. "You have an appointment with Dr. Chen on Tuesday at 2pm. Reply STOP to opt out." A name, a date, a time, a provider. No procedure name, no diagnosis, no reason for the visit.

05

Review requests. Sent after the visit, asking for a review. Nothing about what happened during it. Sent to everyone, never filtered by who seemed happy, because filtering violates Google's policies.

What happens if a patient types something clinical anyway

People do this. Someone will type their symptom into a chat window no matter what the window says. So the honest answer is not "that cannot happen," it is what the system does when it does happen.

The chatbot is instructed to stop, not engage with the clinical content, and direct the person to call the office. The conversation is not written to a database on my side: it lives in the visitor's browser tab and is gone when they close it. The message does pass through Anthropic's API to generate the reply, which is exactly why the next section matters if your practice decides that risk is not acceptable at any level.

The same applies to your contact form. If somebody writes three paragraphs about their back pain, that text lands in your email inbox, which is your own system under your own controls, and in Netlify's form store until it is deleted. Both are worth knowing about before you decide the form is harmless.

If the default is not enough

The BAA path, and what it actually costs

The AI assistant

Anthropic

  • Anthropic does offer a Business Associate Agreement
  • It is available only for their HIPAA-eligible services, including those qualifying for zero data retention
  • It carries configuration requirements and feature limits, so the chatbot would be a narrower build
  • Source: Anthropic's own HIPAA notice

The texting

Twilio

  • Twilio offers a BAA covering PHI in messaging
  • Signing one requires their Security or Enterprise account edition, which is a real recurring cost
  • Compliance is shared: their platform, your workflow, your consent handling
  • Source: Twilio's HIPAA page

If your practice wants PHI to flow through any of this, the honest version is that it becomes a different project: a higher monthly floor, a narrower feature set, and paperwork with two vendors before anything switches on. I will scope it and tell you the number. What I will not do is leave the default setup in place and quietly call it compliant.

The rules, from the source

What appointment reminders actually require

01

HIPAA does not require patient authorization to send an appointment reminder. HHS puts reminders inside treatment: they "are considered part of treatment of an individual and, therefore, can be made without an authorization." HHS FAQ 286.

02

The real conditions are FCC rules, not HIPAA rules. 47 CFR 64.1200(a)(9)(iv) sets the conditions: only to the number the patient gave you, the message must identify the provider, no marketing and no billing content, 160 characters for a text, an opt-out in every message, honored immediately.

03

The "three per week" figure is widely misquoted. It is a condition of the exemption for reaching a wireless number without prior express consent, not a blanket ceiling on texting your patients. Vendor blogs present it as a flat rule. That distinction changes how your reminder sequence gets configured, which is why it is worth getting right.

04

Consent and opt-out handling belong to your practice. You are the sender of record. I build the system to follow these conditions and I will show you exactly what it sends, but the obligation lives with you, and any vendor who tells you otherwise is describing something they cannot deliver.

Where the data physically sits

The website and any form submissions are on Netlify, in the United States. Chat messages pass through Anthropic's API and are not stored by me. A booked appointment writes into a Google Calendar. Text messages go through Twilio. Your email is wherever your practice already keeps it. That is the entire list, and if you need it in a vendor assessment format for your compliance file, ask and I will write it up.

What I will not do

I will not build you a patient portal, handle records, or touch your practice management system. I will not put a "HIPAA compliant" badge on your site. I will not tell you that a chatbot is safe for clinical questions. And if your situation needs more than I can honestly deliver, I will tell you that in the first meeting rather than the third invoice.

This is not legal advice

I am a web developer, not your compliance officer and not your attorney. Everything above is sourced so the people who do hold those roles at your practice can verify it in a few minutes. That is the point of writing it this way.

Want this reviewed against your own compliance requirements?

Send me your questions