These are the third parties that process data on our behalf so the Services can run. Each one is bound by a written agreement that is no less protective than our DPA, and we remain answerable to you for what they do.
This page describes what is running today, not what we plan to run. Where something is not in place, it says so.
| Subprocessor | What it does for us | What it touches | Where |
|---|---|---|---|
| Google LLC (Firebase, Google Cloud) | Sign-in, database, file storage, serverless functions, hosting, and the analytics pipeline described below | Account data, patient identifiers, scans, session video, motion frames, notes | United States (nam5, us-central1) |
| Apple Inc. | Distribution of the app through the App Store and TestFlight | Account identifiers, device data | United States |
| GPU compute provider | Runs the heavy reconstruction of a session: marker tracking, mesh alignment, export generation | Session video, scans and motion frames, for the duration of the job and the retention window below | United States |
We do not publish the name of the GPU compute provider. It is part of how the product is built and our competitors read this page too. We give the name in writing to any Customer who asks, under confidentiality, and a Customer who objects to it on reasonable grounds may say so under Section 6 of the DPA. Hiding a name is a commercial choice; hiding a category, a purpose or a location would be a compliance failure, and we do neither.
There is no advertising network, no marketing tool, no email marketing platform, and no customer-support product with access to Customer Data. When one of those arrives, it arrives on this page first, 30 days before it is switched on.
There is one place where patient material reaches a generative model, and it is described in its own section below rather than buried here.
There is a second copy of session records inside Google Cloud that we want on this page rather than buried in a schema.
What is exported today. A Firebase extension streams the metricas collection into
BigQuery (dataset firestore_export, region us): one derived row per session carrying
duration, frame count, tracking quality, device model, app version, jurisdiction, and whether
training was authorised. The patient, the session and the account appear as pseudonyms computed
with a key that lives on the server side and never travels to BigQuery. It carries no names,
no aliases, no identity documents, no storage links, no clinical notes, and neither the scans nor
the video themselves.
A stable pseudonym is still personal data for as long as the key exists, and we are not going to call it anonymous. What it achieves is that an analytics query never touches identifiable data.
What was exported before, and why it changed. Between 18 February 2026 and 12 September 2026
what was exported was the raw sessions collection, which does carry patient identifiers and
download links to their files. A Firebase download link is a credential: whoever holds it
downloads the file. That is why the export changed collection on 12 September.
What happened to what was already exported. The seven months of history are kept — they show where a capture breaks down and cannot be reconstructed after the fact — in a separate table, with no names, no identifiers in the clear and not a single link. The original raw table is being retired.
What you should know about all of the above:
We found this while checking this page against the live infrastructure before publishing it, and we would rather write that sentence than quietly fix it.
The app can turn a photograph of a patient into a stylised portrait for their record card. When a
professional uses that feature, the photograph is sent to Google's Gemini API
(generativelanguage.googleapis.com) and the stylised image comes back.
We are putting this in its own section because a photograph of a face is the most identifying thing in the whole product, and because "we use Google" is not an honest way to describe sending a patient's face to a generative model.
| What is sent | One photograph the professional took or chose, scaled to at most 1024 px, plus the style instruction |
| What is not sent | The patient's name, identifiers, scans, session video, or anything from the record |
| Recipient | Google LLC, Gemini API, United States |
| When | Only if the patient ticked their box and a professional then presses the button for them. It never happens automatically |
| Purpose | A portrait for the patient card. Nothing else — no analysis, no diagnosis, no training of ours |
| Result | The stylised image is stored with the patient's record and deleted with it |
What we do not know, and will not pretend to: what Google retains on their side and for how long is governed by the Gemini API terms, not by our agreement. That is the reason this feature requires the patient's own box, separate from the clinical one and from model development and starting off, and the reason the patient authorisation form names it in full.
If you would rather it never ran in your practice, do not tick that box for any patient. Nothing else in the product changes.
If you connect your Google Drive account, the app reads the files you choose to bring them into a case: scans, radiographs, whatever you keep there.
That is not a subprocessor, and the difference matters: it is your account, and we read on your instruction. We keep no copy of your Drive and we do not index it. What is worth knowing is that the permission Google asks for is read-only across your whole Drive, because that is the only scope available for this; we use only what you point at, but the permission granted is wider than the use, and we would rather tell you.
You revoke it from your own Google account, in the list of apps with access, without asking us and without anything else stopping.
Everything is in the United States. The Firestore database is in nam5 and the functions are in
us-central1, and neither region can be changed after a project is created.
We are saying this because the honest version of "international transfers" for a European customer is not a comforting sentence about region pinning. It is: your patients' data is processed in the United States, under Standard Contractual Clauses (Module Two, controller-to-processor), with encryption in transit and at rest. If you need the data to stay in Europe, we cannot serve you today, and you should not sign.
When you export a case, we generate a file in the format you asked for and hand it to you. We do not send anything to these vendors.
| Vendor | What we generate | Relationship |
|---|---|---|
| Modjaw | .xml motion file |
Independent vendor. No agreement with us. Only you move the file |
| exocad GmbH | PLY/STL bundle | Independent vendor. No agreement with us. Only you move the file |
| Smilecloud SRL | .xml smile-design file |
Independent vendor. No agreement with us. Only you move the file |
If you upload an exported file to one of those platforms, your relationship with that vendor is governed by their terms, not ours. The day we add a direct push integration, that vendor moves into the table at the top of this page and you get 30 days' notice first.
We do not hold a Business Associate Agreement with the GPU compute provider, and therefore we do not accept customers who are Covered Entities under HIPAA today. Protected Health Information must not be routed through the Services. This is a limit we state rather than a risk we take.
We give at least 30 days' notice before adding a subprocessor that would process patient
material. Write to hola@toothprint.ai to be on the notification list. You may object on
reasonable grounds; if we cannot resolve the objection, you may terminate the affected part of
the Services.
| Date | Change |
|---|---|
| 2026-09-11 | Version 1.0. Reconciled against live infrastructure: removed a region-pinning claim that was not true, removed vendors that were never engaged, added the GPU compute provider and the BigQuery copy |
| 2026-09-12 | Version 1.1. Disclosed that a patient's photograph is sent to Google's Gemini API, which the previous version denied by claiming no third party ran AI inference on patient material |
| 2026-09-12 | Version 1.2. The BigQuery export moved from the raw sessions collection to a derived collection with no identifiers; the history already exported is kept pseudonymised |
Updated September 12, 2026 · Version 1.2
Version 1.1, amended 12 September 2026. Version 1.0 was published on 11 September and contained statements that a review against the running system showed to be wrong. They are corrected here rather than quietly edited, because a published document that changes without saying so is worth less than one that admits it changed: a page that said no third party ran AI inference on patient material, while a patient-photo feature was sending faces to a generative model; a security page that claimed point-in-time recovery and 12-month backups that were never configured; a deletion promise that gave one timeline for three destinations that do not run at the same speed; and a three-year destruction promise with no machinery behind it.
Version 1.2, amended September 12, 2026. The analytics export to BigQuery stopped carrying the raw sessions collection — which holds patient identifiers and download links inside it, and a download link is a credential — and now carries a derived collection with nothing identifiable in it. The history already exported is kept separately, pseudonymised. This is written down because version 1.1 described the previous export, and describing it wrongly after fixing it would be version 1.0's mistake in reverse.