How Smile Fitter handles patient data, and why
Written for the practice owner, office manager or agency who has to check this before anything goes on a website. It describes how the system works. The commitments we sign up to are in the terms, data processing terms and privacy policy.
Why it's built this way
A smile preview sits at the most sensitive moment on a dental website. Someone uploads a photo of their face and, if they like the result, hands over their name and phone number. On many practice websites, the page around that moment is also running advertising and analytics tags.
Those tags have drawn lawsuits and regulators across US healthcare. The Federal Trade Commission took action against GoodRx and BetterHelp in 2023 over health details shared through advertising pixels, and health providers, dental groups among them, have faced class actions over tracking on their appointment and contact pages. Whether any of that applies to your practice is a question for you and your advisers. What we could do was build Smile Fitter so the question doesn't come up inside the preview.
So the patient page runs no advertising pixels and no third-party analytics, in any situation. The only company it talks to is Cloudflare, which hosts it: for the bot check, and for Cloudflare Web Analytics, which counts page loads and measures speed without cookies (the /cdn-cgi/rum requests). You can confirm that yourself: open any preview page, open your browser's developer tools, and watch the Network tab while you use it.
One request, from selfie to dashboard
The page
The preview is served from smilefitter.com. On a practice's website it opens in a frame, so the practice's own tags (its analytics, its ad pixels) can't see inside it: not the photo, not the form, not the result. Our embed script places the button and the frame and does nothing else on the practice's page.
The photo
The patient takes or picks a photo. Face detection runs in their browser with a model we host ourselves. Nothing is uploaded.
The bot check
Cloudflare Turnstile checks that a person is using the page. It sees browser and device signals, never the photo or anything typed. Our server verifies the check before counting the preview against any limit, so bots can't burn through the daily allowance.
The preview
A 512-pixel close-up of the mouth goes to our server, which sends it to Cloudflare Workers AI with a fixed instruction for the treatment. The edit comes back and is blended into the photo on the patient's device. Nothing from this step is stored.
The request
To unlock the result, the patient sends a first name and one way to reach them, plus small before and after close-ups if they leave that box checked. It's stored in Cloudflare Workers KV under the practice's name. The patient gets a private link token so only they can add consultation details to their own request.
The practice
The practice opens its dashboard with its own key and sees only its own requests. It can update each one's status and export them as a spreadsheet.
Safeguards
- HTTPS on every page and request; requests encrypted at rest by Cloudflare.
- A separate dashboard key for each practice. A practice key can't see another practice's requests.
- Request tokens stored only as hashes, and IP addresses only as salted hashes kept for about an hour.
- Fixed AI instructions kept on the server. Patients can't send their own.
- Limits of 30 previews per visitor per hour and a daily cap overall, behind the bot check.
- Practice logos served with a locked-down security policy, so an uploaded file can't run code.
- No patient photos used to train AI, and none sold or shared.
What we don't claim
Smile Fitter is in beta. We don't sign HIPAA Business Associate Agreements yet, we haven't had an outside security audit, and we don't hold certifications such as SOC 2. We'd rather tell you that here than have you find out later. If your practice needs any of these before using a patient-facing tool, tell us what you need.
Related pages
Security or privacy questions: [email protected].