How this tool handles a photograph

Written for a practice deciding whether this tool can be used with patients, and for whoever advises them on data protection. It describes what the software actually does. It is not legal advice or a privacy notice. A practice needs its own.

What this product is for

A clinic provides a branded link. The visitor chooses and uploads their own smile photo, receives a plain-language visual guide, and may request an illustrative AI preview before deciding whether to speak with the clinic. The output supports information and discussion. It is not a diagnosis, medical advice, a treatment recommendation, a treatment plan, or a prediction of results.

What happens to a photograph

The image is chosen in the browser and held in the page's memory. Nothing is uploaded when it is selected.
Before the first transfer, the visitor must confirm that they are an adult or authorised to upload the photograph and explicitly consent to the Roboflow transfer described below.
Resolution, brightness and sharpness are measured in the browser. That check never leaves the device.
Before anything is sent, the browser locates the mouth itself. A face detector runs on this device; the photograph is not uploaded for it, and the detector's model is served from this site rather than from Google.
On “Create visual guide”, only a cropped rectangle is encoded and sent to this site's own endpoint, /api/analyze. Where a face is recognised, the crop is taken below the eye line, typically under a third of the picture and never containing the eyes.
Where no face is recognised, as with a close mouth photograph, nothing is sent automatically. The crop is drawn on screen and the person using the tool decides whether it goes. Declining sends nothing. The software cannot tell a close-up of teeth from a portrait whose face it failed to find, so it does not guess. It shows the picture and asks.
If nothing tooth-coloured can be found at all, nothing is sent and the photograph is refused.
That endpoint forwards the crop to Roboflow, which returns the outline and position of each tooth it finds. Those outlines are mapped back onto the full photograph in the browser.
Outlines, photo colour and visible proportions are calculated in the browser from the returned data. The visual guide is assembled there.
Any additional views (lateral, occlusal) are held in the browser for display only and are never sent anywhere.
The visual guide offers an illustrative edit of the same smile. The photo-based version is drawn in the browser from the outlines already returned and uploads nothing at all.
A second, AI illustration is made by an image model. This separate upload happens only after the visitor gives a separate explicit consent and presses its button. It sends a fresh crop containing the teeth and the lips around them to this site's own /api/simulate, which forwards it to OpenAI. That crop reaches no more than about one tooth's height above the gum line, so it cannot include the eyes whatever the original photograph was framed like. Never consent and press it, and nothing goes.

What is kept, and for how long

Data	Where	Retained
The photograph	Browser memory during the guide journey. A compressed copy is sent to the practice only after the separate sharing permission.	Not written to any database or disk by this application. The browser copy is gone when the tab is closed; a shared copy follows the practice's email retention.
A crop of the mouth	In transit through the endpoint to Roboflow	Held only for the length of the request. Not stored by this application at either end.
A crop of the mouth and lips, for the AI illustration only	In transit through the endpoint to OpenAI, and only if that button is pressed	Held only for the length of the request. Not stored by this application at either end. OpenAI's own retention is a matter for the agreement the operator holds with them.
The visual guide	Browser memory	Until the tab is closed or a new photo guide is started. Saving a PDF writes a file on the reader's own machine and uploads nothing.
A consultation request	The clinic account database, only after the separate contact form is submitted	Name, phone or email, optional note, status and contact-consent evidence remain until the clinic's published retention period ends.
An optionally shared photograph and visual guide	Sent to the practice by email only after the separate, unchecked sharing permission is selected	The application records the exact permission text, time and version. It does not store the photograph or guide in its database. The practice controls retention in its email system.
Clinic account and subscription data	Supabase and Stripe	Held while the clinic account and legal or accounting retention duties apply. Model and payment secret keys never reach the browser.
Caller IP address	Endpoint memory	Up to 60 seconds, used only to rate-limit requests. Not logged by the application, not linked to any image.
Journey measurement: a random visit identifier, the campaign tags on the link followed, the referring site, device type and browser family, which steps were reached, their order and how long each took	The clinic account database	Up to 400 days, so a practice can compare a month with the same month a year earlier. It holds no photograph, no observation and no contact detail. Where no consultation request was sent it identifies nobody and survives the deletion of other records; where one was sent, the practice can view that visit's six-step path beside the request.

Clinic authentication uses a browser session managed by Supabase. There are no third-party analytics, advertising or tracking scripts, and nothing here follows a visitor to another site. The journey measurement described above is first-party: it is written by this application to the practice's own account, under a random identifier that is renewed after thirty minutes of inactivity and never matched against a person. Both typefaces are served from this site, so loading the visual guide makes no font request to a third party.

Finished visual guides stay listed for as long as the browser tab is open, so the visitor or clinic can move between them during a session. That list lives in the memory of the page: it is not written to the device, not sent anywhere, and closing the tab erases it.

Who is involved

The parties that can touch a photograph do not carry the same responsibilities. A practice deciding whether to use this tool needs all relevant roles considered in writing before the first visitor photograph is processed.

Party	What it does here
The visitor	Chooses the photograph in their own browser and starts each transfer. Nothing is sent merely because the branded page was opened.
The practice	Subscribes to and brands the experience, provides the link, and holds the relationship with the visitor if a consultation is requested. Its own privacy information and lawful basis must cover its role.
The operator of this deployment	Runs this site and the `/api/analyze` endpoint, and holds the Roboflow API key. The image passes through infrastructure the operator controls on its way to Roboflow. Who this is depends on who is hosting; it is not necessarily the practice.
Roboflow	Performs tooth detection on the image and returns outlines. Operated from the United States.
OpenAI	Creates the AI illustration, and only when that is requested. Receives a crop of the mouth and a mask covering the dental arches. Operated from the United States.

Because the image passes through the operator's endpoint rather than going from the browser straight to either service, the operator is part of the processing chain and cannot treat this as a matter between the practice and those services alone. Where the operator is not the practice, the two need an agreement setting out which is controller and which is processor, and the operator needs its own agreement with each of Roboflow and OpenAI covering the onward transfer.

The transfer

Tooth detection runs on Roboflow's hosted inference service, which is operated from the United States. What crosses the border is a crop of the mouth, not a photograph of a face. This is a real reduction and worth stating plainly to a visitor. It is not anonymisation: dentition is itself capable of identifying a person, which is why it is used for exactly that. Treat the crop as a transfer of special-category data outside the European Economic Area, because that is what it is.

Asking for the AI illustration is a second transfer, to a second company, and the tool treats it as one: it never happens on its own, and the crop sent is cut for that purpose rather than reused from the detection. A practice that would rather make no such transfer can use the visual guide without pressing that button. The photo-based illustration and the rest of the guide remain available.

A practice using this tool with real patients needs to satisfy itself on the usual points before doing so: a lawful basis and an Article 9 condition, an entry in its record of processing, its own patient-facing privacy information, and a written agreement with whoever operates the deployment. The software does none of that for anyone, and cannot. It is a tool, not a compliance position.

What the tool does not do

It does not diagnose. The detector also emits caries, crack and cavity classes; those are discarded at the endpoint and never reach the interface.
It does not find every tooth. The published recall for the model is around 48%, so a tooth it did not find is not a statement about that tooth.
It does not provide medical advice, propose treatment, select a procedure, assess suitability, or create a treatment plan.
It does not predict an achievable outcome. The AI preview is an illustration and may be unrealistic or unachievable.
It does not turn photo-derived scores into validated clinical measurements or information for a clinical decision.
It does not store the photograph, crop or visual guide. A consultation form stores contact details; an additional unchecked permission can send a compressed photograph and the guide to the practice by email without saving those files in the application database.
It does not upload a face without someone having seen the picture first. Where a face is recognised the crop excludes the eyes; where none is, the crop is shown and confirmed before anything leaves.

The provenance of the code, the model licence and the third-party components are documented separately in THIRD_PARTY_NOTICES.md and IP_AND_DATA_POLICY.md in the source repository. FDI labels are approximate location references, and a dentist must assess oral health and treatment options independently.