Privacy Policy

Effective September 17, 2026.

This Privacy Policy is published by SmileMaxer LLC and covers the PerioMaxer mobile apps, today for iPhone, iPad, and Android, the PerioMaxer office desktop for Windows, periomaxer.com, smilemaxer.com, and related account, licensing, billing, support, and administrative services (together, the “Service”).

The short version

The cloud service stores business-account, billing-reference, licensing, registered-device, and active-session information. The account and licensing service is not designed to receive patient names, periodontal chart values, or voice audio. The same account database, hosted on Google Cloud, also stores the feedback reports people choose to send from the apps and the files they attach, which can contain recorded speech, transcripts, and chart values, as described below.

Speech recognition runs on the device, and voice recognition does not upload audio to the PerioMaxer cloud. The iPhone, iPad, and Android apps installed from the App Store or Google Play save no audio recording of what you say. Test builds (TestFlight and developer builds) include a developer recording tool whose files stay on that device unless someone attaches them to a feedback report. The Windows office desktop keeps a local voice log that, in released versions, records how many words each utterance had and the kind of command instead of the words, and replaces every number with a placeholder; error messages in that log can still contain words. The Windows desktop also has a “Record voice sessions” setting, off by default, that saves microphone audio, what was heard, and the chart values entered in unencrypted files on that computer, keeping the five most recent sessions; those files leave the computer only if someone attaches them to a bug report. In Office Linked mode, chart entries and the limited patient-display context permitted by the product’s local protocol move only between the practice’s own devices and are not sent to the PerioMaxer cloud, except in files someone attaches to a feedback report. We do not sell personal information for money. The mobile apps send Meta limited onboarding and purchase events for advertising measurement, described under “Mobile advertising measurement”; some state privacy laws may treat that as “sharing” personal information.

Interactive website demo

The optional voice demo on the PerioMaxer home page and at periomaxer.com/demo recognizes speech in your browser. Microphone audio stays in the browser. When you use demo voice charting, recognized words and the demo's preceding chart actions are sent over HTTPS to our private charting service so it can return the updated chart. We do not write those words or chart contents to logs or persistent storage. The page contains code that can report which of a fixed list of reasons stopped voice from working (for example, microphone access declined), with no audio and no words; on the home page that report is on and is sent to us; on periomaxer.com/demo it is switched off and nothing is sent. A bounded memory cache keeps temporary chart state for less than two minutes; your browser keeps the current demo history until you reset or leave the page. The demo is for synthetic values only and does not connect to patient records or dental software. Do not enter patient information.

Public software downloads

We use Cloudflare to deliver public installers, speech-recognition model files, and related license files. The website demo may download its speech model when the page opens, before you turn on the microphone. Cloudflare processes network and request information needed to deliver and protect these downloads, such as your IP address, requested file, browser or app information, and request time. We do not send practice account data, patient records, chart entries, microphone audio, transcripts, or feedback attachments through this download service. Cloudflare may process request information globally; see Cloudflare's Privacy Policy.

The Android app downloads its speech-recognition model for the chosen language directly from Alpha Cephei (alphacephei.com), the publisher of the Vosk speech models, which receives your IP address, the requested file, and standard app and system request information. If that download fails or the file does not match the checksum built into the app, the app downloads the same file from our Cloudflare download service instead. No account, chart, or voice data is sent with either request.

App update checks and speech-model downloads

When the apps start or return to the foreground, they check whether an update is needed (the iPhone and iPad app asks periomaxer.com no more than once every six hours). The iPhone and iPad app asks periomaxer.com for the minimum supported version and asks Apple's App Store lookup service whether a newer version exists. The Android app asks periomaxer.com for the minimum supported version and asks Google Play whether an update is available. The Windows desktop asks periomaxer.com for update information as described under “Registered-computer information” and downloads the published chart-order library from periomaxer.com. These requests carry standard network information such as your IP address and app version; the periomaxer.com checks carry no account, practice, or patient information, and we do not store them, apart from counting each request in our day-level visit totals.

Software preferences and availability updates

When you answer the website’s software question, we count your selected system to guide future integrations. These counts are anonymous and are not linked to an email or account. If you separately request an availability update from that question, we store your email, selected software, any software name you provide, and the time of your consent. Your browser’s session storage remembers that you have seen the question.

If your practice's dental software is not yet supported when you check out, the checkout page asks which software you use and offers an availability update, with the email box already checked. When you submit that page, we store your signed-in email, the software you chose, and any software name you typed, together with the time of your consent only if the box was checked. We store the email and the answer even when the box is unchecked, and our support team is emailed the practice name, your email, the software, and whether you asked for updates. We use your email for an availability update only when you asked for one. These records have no scheduled deletion, are not removed when a practice account is deleted, and are deleted on request.

Information we collect

Account information: work email, full name, password hash, role, verification status, authentication settings, and login-security events. Each sign-in session, email-verification or password-reset token, and security event is recorded with the public IP address and, for sessions, the browser user agent it came from. At signup we also keep a record of the Terms and End-User License Agreement versions accepted, including the accepted text.
Practice information: practice name, full physical location address, billing contact, and Business Associate Agreement signing details (signer name and title, signing time, the signer's public IP address and browser user agent, and a copy of the signed text). BAA signing is not open yet.
Billing references: Stripe customer, checkout, subscription, payment, and invoice identifiers and status, plus the Stripe-provided card fingerprint used to enforce one trial per payment method. Stripe receives the card details; SmileMaxer does not store complete card numbers.
Registered-mobile-device information: office and location identifiers, installation/device identifier, device label, platform, operating-system and app versions, enrollment and revocation status, and last-seen time. When an office admin creates a phone setup link, we also store its label, the recipient email if the link is emailed, its six-character code, and, for the reusable office link, the link itself.
Registered-computer information: office and location identifiers, installation/machine identifier and fingerprint, display name or hostname, platform, operating-system and app versions, license and operatory assignment, selected PMS configuration, last-seen time, and the computer’s local-pairing certificate fingerprint and protocol version. A phone can join an office computer by typing a short code shown on that computer’s screen, so each computer also reports the number of wrong typed pairing codes it has counted, when the last one was tried, and whether typed codes are locked and until when, together with a random identifier for the lock and the identifier of the last reset our staff sent. The code itself is never reported to us, and none of this names a phone, an address or a patient. Our staff can turn typed codes back on for a computer from the staff console; the reset, who sent it, when, and the reason they typed are kept with the computer and in the audit log.
Active-session information: registered phone and selected office computer, office, plan, public IP address, coarse country/region when supplied by our trusted edge, session timestamps, heartbeat timestamps, and status needed to enforce simultaneous-session limits. When a location's public IP address changes, we keep the previous and current addresses. When phones in one office appear to be charting from clearly different places, we keep a review record with the addresses, coarse regions, and the names of the devices involved. One-use office-computer pairing tickets are stored only in hashed form and expire after two minutes.
Office Link diagnostics: when an enrolled phone or a registered office computer uses Office Link, the app sends us short diagnostic events about the connection: when it connected and disconnected, why a connection ended, counts of chart messages sent and acknowledged, error codes, timings, and the app and engine versions, together with the practice and the registered device or computer the report came from and a random session number. Windows connection-ready and charting-start events also include the dental software name and its numeric executable version when available. Fields are limited to fixed codes, counts, times, random report identifiers and bounded software versions. These reports cannot carry chart values, tooth numbers, patient names, the local patient display label, pairing credentials, or network addresses, and our service rejects any report that does not fit that fixed format. We use them only to find and fix connection problems. You can turn them off in the app's settings under "Share connection diagnostics", and a separate optional page follows the terms during first-run setup on phones and the first desktop sign-in. The box starts checked unless you previously turned it off. No connection report is sent before you press Continue to record that choice; the app preserves a prior off choice. You can uncheck it and continue using the app. A phone's reports also carry the random installation identifier described under "Mobile onboarding measurement" below. A phone that has no office account but pairs with an office computer by reading its code sends the same fixed-format connection events, if the box is on, keyed only to that identifier; no practice, account, or device registration is attached. On a phone enrolled in an office, the identifier travels with the office credential, so our staff console can associate that installation's onboarding measurement with the office and registered phone.
Billing notices we send you, and our record of them: we email the practice's billing contact about the subscription: when a free trial starts, before it ends, when a payment is received, before an annual subscription renews, and once a year for any subscription. These describe the subscription only and carry no patient or chart information. Because card network rules and automatic-renewal laws require several of them, we keep a record of every email our service sends, whether or not the provider accepted it: the kind of email, the practice, the recipient address, the subject line, the language, the time, and, for a billing notice, the amount, currency, billing frequency and date it announced. We do not keep the message text, any link it contained, or any token. A subject line we keep can include a support ticket's subject or a sender's email address.
Configuration: selected practice-management system, operatory labels, chart-order configuration, and related non-patient settings.
Manual setup compatibility reports (Windows): You can separately choose to share a tested Manual desktop setup to help us plan support for more dental software. This choice is optional and separate from connection diagnostics and chart-layout support reports. The report contains only a software choice from our fixed list, bounded software/app/engine versions, the generic full-mouth charting order and directions, displayed row order when supplied, gingival-margin sign convention, sweep boundaries when supplied, and fixed entry rules: keyboard or number-pad input, advance/blank/sign behavior, automatic row transitions, pauses between sweeps, multi-digit support, sign reset behavior, and input delay. It also contains a new random report identifier, report time, and the accepted consent-notice version and time. Displayed row order also says which rows that setup shows. We add the time we received the report and two fingerprints computed from the report itself, one of the whole report and one of the software choice plus the setup, so that repeats and shared setups can be counted. The registered computer's credential associates it with its office and computer. It contains no patient name, chart value, actual missing/implant teeth, chart flag values, chart/record/upload/profile identifier, keypad coordinates, window title, application path, screenshot, audio, transcript, arbitrary message, or contact address. These reports appear in the staff Manual PMS page for compatibility analysis; they do not create a support ticket or send an email. A computer may keep an unsent report for retry. Turning this choice off or changing the signed-in account cancels unsent reports; it does not delete reports already received.
Audit and support information: account changes, device actions, administrative events, and messages sent to support. Audit records store the public IP address of the request and can include email addresses and names involved in the change. Do not include patient information in support requests.
Practice-software layout reports (Windows): If PerioMaxer cannot verify a supported chart layout after automatic recovery, you can send a fixed-format support report. Automatic sending is off unless you separately enable "Automatically report chart layout problems" after reading its notice. That choice is separate from "Share connection diagnostics". These reports contain the supported software name and version, PerioMaxer and engine versions, fixed failure codes, window state and dimensions, display scale, monitor count, calibration format, recovery-attempt and occurrence counts, whether a saved calibration was used, a random report identifier, and the report and consent times and consent-notice version. The registered computer's credential associates the report with its office and computer. They contain no screenshot, chart or patient content, audio, transcript, log file, window title, monitor name, or arbitrary message. Reports create a support ticket visible to your office in its account portal; we notify PerioMaxer support, and staff replies are emailed to the office billing address. If a report cannot be sent, the computer can retain it locally for retry. Turning automatic reporting off stops new automatic reports and removes unsent reports. It does not withdraw a report already received. Manually sending a report does not turn automatic reporting on.
App feedback: when you choose to send a bug report or feedback from inside the PerioMaxer app for iOS, Android, or Windows, we receive the name and email address you type, your message, the app and operating-system versions and device model, non-clinical facts about your setup that the app already holds (for example the engine version, whether the chart order uses the default or a custom preset, how the phone connected to the office computer, or, on Windows, the operatory label), and any files you choose to attach. Windows reports also include the selected dental software and its version when the app can verify it from the chart window's process. The files you can attach are: on iPhone and Android, a capture from the practice chart in the bug-report form, which includes what the speech recognizer heard and the commands and values entered in that practice chart; in test builds of the phone apps, voice session recordings; and on Windows, the most recent session recordings made with the “Record voice sessions” setting. Session recordings contain microphone audio, what was heard, and the chart values entered in that session, with the date and time. Sending through the Report Bug form is voluntary and user-initiated every time, and nothing is attached unless you choose it. The separate opt-in Windows layout-report feature is described above. If the app holds an office credential, the report also names the practice and the registered device or computer it came from. When a report arrives, our email provider delivers an alert to PerioMaxer staff that quotes your name, email address, and message, and replies you send by email are stored with the report. The service is not designed to receive patient information and cannot tell whether a message or file contains it. Do not include patient information in feedback or in attached files.
Campaign links: we post short links of our own (periomaxer.com/r/...) on social media and elsewhere. Following one is counted in a daily total for that link, and nothing else about the tap is kept: no address, no browser, no per-visitor record. We also store the campaign's name in a first-party cookie, `smx_ref`, for 30 days (see Cookies and analytics). If you go on to create an account, we keep that campaign name, for example `tiktok-september`, on the practice's record, so we know which post worked. It is one of our own labels and says nothing about you.
Mobile onboarding measurement: while a phone walks the PerioMaxer app's first-run setup, the app reports which setup screens and setup questions were viewed and for how long, the subscription-screen taps (plan picked, checkout opened, completed or abandoned, trial started), that the terms were accepted and whether the "Share connection diagnostics" box was left on at that moment, and that setup finished. If the "Share my setup answers" box is left checked (it starts checked), it also reports the non-clinical setup answers: tooth-numbering system, gingival-margin label and sign convention, the charting software the office uses if answered, professional role, chart style, the chart order (the identifier of the built-in order in use, or “custom”), whether the row order is the default or custom, and whether setup was skipped. During and after setup, whenever the phone's own App Store or Google Play subscription changes, the app also reports its new state (free trial, free trial cancelled, paid, paid but set not to renew, or ended) and its plan (monthly, 6 months, or annual). When a subscription screen appears on a phone that has no access, or Restore Purchases is tapped, the app also reports what the store says about that phone's subscription at that moment (active, cancelled but still paid for, payment being retried, ended, refunded, or none) and, for Restore, whether it found the subscription. These reports come from App Store and Google Play installs, carry no payment details, Apple ID, or Google account, and are not sent to Meta. Each report carries a random installation identifier created for onboarding measurement, the platform, the app version, and which version of the first-run setup the phone was shown. On a phone with no office account, that identifier is not linked to an account, an office, or a registered device, and it is kept as funnel history. On a phone enrolled in an office, the same identifier is also sent with the phone's Office Link diagnostics, so it becomes associated with that office and registered phone; those reports are kept as funnel history too.
Public-site usage: aggregate page views, referral or campaign information carried by the request, and interactions used to improve public marketing pages. On a fixed allowlist of public pages, our first-party tracker may also record an ephemeral per-tab visit identifier, page path, clicked element label and approximate coordinates, viewport size, referring host, coarse browser family, and a bounded session replay of page interactions. The replay records page text, layout, pointer movement, scrolling, and clicks; the values typed into form fields are masked in your browser before upload. Login, signup, checkout, password, verification, invitation, enrollment, account, and staff pages are excluded. This first-party measurement runs in every region and does not depend on the cookie banner or a Global Privacy Control signal.
Visit counts: we count requests to the website, the account portal, and the app services per day. Our code can also record the country, region, and city of those requests and estimate the number of distinct visitors from a one-way hash of the IP address held briefly in server memory, but only for requests that arrive through Cloudflare's network with location information; our website and account services are not served through Cloudflare today, so those fields stay empty. Daily counts are deleted after one year.
Chart-order submissions and waitlist entries: if you submit a charting order through the chart-order form on our website, we store your email, dental software, any notes, the drawn order, and the time, record the submission with your public IP address in our audit records, add your email and software to our former waitlist list, and email you a thank-you the first time you submit. Earlier waitlist sign-ups (email, practice name, practice type, role, and dental software) are also still stored.
Crash reports: our service has an intake for crash reports that a person approves one at a time. It is switched off by default and no current PerioMaxer app sends crash reports. If it were used, it would keep the app version, operating-system version, device model, language, the error reason and stack trace, with no IP address, account, or practice, for up to 90 days after the crash last occurred.

Information excluded from account and licensing interfaces

The licensing and account interfaces are not designed to receive or store:

patient names, dates of birth, record numbers, or other patient identifiers;
periodontal chart values or other clinical measurements;
voice recordings or voice transcripts;
images of the PMS or a patient chart;
the local patient display label used during a paired Office Link session.

A voluntary feedback report is a separate data path. We receive its message and the files the sender attaches, which can include recorded speech, what the speech recognizer heard, and the chart values entered in a session. The service is not designed to receive patient information, cannot tell whether a message or file contains it, and asks senders not to include it. Do not send patient information.

How local Office Link data is handled

A phone joins the office by opening the practice’s office link or by scanning the code on an office computer. The office link is one reusable link for the whole practice: it stays valid until an office admin turns it off or replaces it, and each phone that opens it gains a durable office membership until an admin revokes that phone. Enrollment is separate from an operatory session. For each session the phone connects to the office computer whose code it scanned; a phone that has connected before can reconnect to a remembered computer, and the authenticated cloud service then lists only computers registered to that office and authorizes the connection with a short-lived, one-use ticket.

The clinician’s phone connects directly to the selected Windows office desktop over the practice LAN, encrypted and verified against that computer’s own credentials. For the integrated Open Dental and Dentrix workflows, chart entries are held in session-scoped desktop memory long enough to enter them into the practice-management system and are cleared when the connection ends. Chart values the phone has not yet delivered can wait on the phone until the computer accepts them or a different patient's chart is opened; the Android app keeps them in encrypted storage. If an office turns on “Read Open Dental's database” on the Windows desktop, the desktop reads patient names, missing and implant teeth, and earlier exam values from the practice's own Open Dental database, in memory, and, if the office also turns on sending earlier exams to the phone, sends the patient's most recent earlier exam to the phone over the same local connection. To find and fill the right cells, the desktop reads the dental software's window, including its title and the on-screen chart, in memory. Those reads are not uploaded; a layout calibration can keep cell positions and pixel samples of the chart grid in the desktop's local files.

A patient display label may be echoed from a supported PMS to the paired phone so the clinician can confirm the chart context. That label stays in RAM on the local connection, is not logged or recorded by SmileMaxer, and is not sent to the cloud service.

Manual desktop mode has a different local storage workflow. A phone can send a named chart to the paired desktop over the authenticated encrypted local connection. Names and chart contents are patient information. The desktop keeps the five most recently saved records in a protected local store associated with the active office/computer. Saving another chart automatically removes the oldest after the new chart is safely stored. Users can open, Delete, or Clear All of those desktop records; switching to Open Dental or Dentrix automatic mode clears the Manual desktop history. The phone must be connected to that Manual desktop to chart or open its saved records. Saved records are fetched from the desktop, rather than kept as a separate phone library. An interrupted, unsent chart and the exact pending upload needed to retry a transfer may remain on the phone for recovery, but cannot be viewed or edited until the same computer reconnects. On Android that recovery copy is encrypted by the app; on iPhone it is kept in the app's local database, which is protected by iOS Data Protection rather than by separate app encryption. After a confirmed transfer, the phone removes its recovery copy. These named records and recovery data are not sent to PerioMaxer servers. The optional Manual setup compatibility report described above is a separate channel and cannot include them.

Patient data kept on phones

The mobile apps store the patient records and charts you enter on the device: on iPhone and iPad in the app's database under iOS Data Protection, and on Android in a file the app encrypts. Two features move patient information out of that storage at your direction:

On iPhone and iPad, saving a patient with a phone number, after you allow Contacts access, adds a contact to the phone's Contacts with the patient's first and last name, phone number, and “PerioMaxer - PT” followed by the patient's record number, or “PerioMaxer” when no record number is set. That contact is saved to the phone's default contacts account, which may be synced by iCloud, Google, Exchange, or another account set up on the phone, and it is not removed when the patient or the app is deleted.
Exporting a chart as a PDF creates a document with the patient's name, date of birth, and chart values, and hands it to the app or service you pick. On Android the file name includes the patient's name, and a copy stays in the app's cache until the system clears it.

Files kept on the Windows office desktop

The Windows desktop keeps files under the signed-in Windows user's local application data folder (`%LOCALAPPDATA%\PerioMaxer`). Uninstalling does not remove them.

Settings: dental-software choice, operatory label, chart-order setup, the name and email remembered for bug reports, consent records, and, if entered, the Open Dental database server and user name, with the database password protected by Windows data protection.
Caches that help the desktop enter charts, including a Dentrix route cache that records which teeth were missing in earlier sessions, without a patient name.
A typed-pairing-code file that records how many wrong codes have been typed at this computer, when the last one was tried, and whether typed codes are locked and until when. It never holds the code itself, and uninstalling keeps it.
Local diagnostic logs: the voice log described in “The short version”, which in released versions replaces every number with a placeholder; a write-failure log with every digit removed; a connection log; chart-display and Manual-mode error logs and a crash log that record error messages and stack traces. The voice and write-failure logs are capped at about 2 MB each plus one older file; the others are not size-limited. None of these logs is uploaded by the app.
Session recordings from the “Record voice sessions” setting, described in “The short version”.

How we use information

We use collected business and account information to:

create and secure accounts;
verify email addresses and reset credentials;
create and manage subscriptions, trials, and invoices;
register, authorize, list, and revoke mobile devices and office computers;
enforce registered-mobile-device and simultaneous-session limits;
expire sessions whose heartbeats stop;
detect fraud, investigate repeated simultaneous activity from clearly different geographies, and route uncertain cases to human review;
provide support, send service notices, and maintain audit records;
operate, secure, and improve the public website and cloud service.

We use public IP addresses to secure sign-in sessions and one-time tokens, to keep audit records, to notice when a location's network changes or phones appear to chart from clearly different places and route those cases to human review, to limit request rates against abuse, and, only in hashed form held in memory, to count visitors. We do not bind an office license to a fixed IP address, and normal office-network changes are accepted when the enrolled device and office account still match.

Mobile advertising measurement

During first-run setup only, App Store and Google Play builds of the mobile apps that include Meta’s measurement SDK send Meta setup-screen views and timing, the subscription-screen taps, and setup completion. The plan-selection event includes the chosen plan's store product identifier, the checkout event includes the product identifier, price, and currency, and the free-trial event includes the price and currency; and every event names the platform and which version of the first-run setup the phone was shown. If “Share my setup answers” remains checked (it starts checked), they also send the non-clinical setup answers described above, including the identifier of a built-in chart order. Standard device and network information, such as a per-vendor identifier and IP address, accompanies these events. The app does not request the cross-app advertising identifier; Apple install attribution uses SKAdNetwork. Automatic SDK event logging is disabled, and the apps send Meta no events after onboarding. On Android, Meta's SDK still starts with the app and may contact Meta for its own settings after onboarding. Meta handles these events under Meta’s Privacy Policy.

App and device integrity checks

PerioMaxer uses Firebase App Check with Apple App Attest on iOS and Google Play Integrity on Android to help verify app requests and prevent abuse of its cloud services. These checks exchange app/device integrity proofs and short-lived verification tokens with Apple, Google, and our service, together with network information needed for those requests. Patient records, chart values, voice recordings, transcripts, and feedback attachments are not sent to the attestation providers. These security checks operate separately from optional connection diagnostics.

On Android, the Firebase SDK also sends device and operating-system details, the installer source, and Firebase SDK versions. Google uses this metadata to measure platform adoption and maintain Firebase services. This collection operates separately from optional connection diagnostics.

Firebase describes its processing and retention of App Check materials and tokens in Privacy and Security in Firebase. Apple and Google handle their attestation services under their applicable terms and privacy policies. Firebase services may process this security information globally; they are not limited to the region hosting our account database.

Cookies and analytics

Authentication uses Secure, httpOnly, SameSite cookies. Short-lived functional cookies may preserve the selected signup plan and billing cadence through email verification. Browsers used by our own staff also carry two marker cookies, the same value for everyone who has them, that keep staff visits out of our measurements.

Our own campaign links set one first-party cookie, `smx_ref`, for 30 days. It holds the name of the campaign and nothing else, is httpOnly, is readable only by us, and never follows you to another website. It is not set if your browser sends a Global Privacy Control signal. Our code is also designed not to set it in the EEA, the United Kingdom, or Switzerland, but that check needs location information from Cloudflare's network, which our website does not currently receive, so today the cookie is set in every region unless your browser sends that signal. The click is counted in the daily total either way. Public marketing pages use the first-party, cookieless measurements and masked session replay described above, which run whether or not you accept the cookie banner and whether or not your browser sends a Global Privacy Control signal. The visit identifier exists only in that browser tab’s session storage and is not tied to an account. Credential-bearing and authenticated pages do not load the public interaction tracker, and the server rejects interaction uploads for paths outside the public allowlist.

Public website pages, including the login, signup, signup confirmation, email-verification notice, checkout, checkout confirmation, downloads, and former waitlist pages, may also use third-party marketing and analytics tools: Meta Pixel (Meta Platforms), Google Analytics 4 and Google Ads conversion measurement (Google), and Microsoft Clarity (Microsoft). These tools help us measure our advertising and understand how visitors use the public site. They may set cookies and, in Clarity’s case, record anonymized page interactions. They run only on public website pages. They never run inside the signed-in app, the admin or staff portals, or token-bearing password-reset, invitation, or enrollment pages, and they never receive chart values, voice audio, or patient information. By default all of these tools load only after you accept the cookie banner, in every region. If we turn on Google's consent mode, Google Analytics and Google Ads may load before you choose, with advertising storage denied until you accept, and Google's regional default keeps analytics storage denied in the EEA, the United Kingdom, and Switzerland until you accept; Meta Pixel and Clarity still wait for acceptance. You can change your choice at any time through the “Privacy choices” link in the site footer, and we honor the Global Privacy Control browser signal as a decline for these third-party tools. Your choice is remembered in your browser's local storage, and a tab-scoped marker keeps a signup or purchase from being reported twice. Each provider handles the data it receives under its own privacy policy.

Service providers

We use service providers for limited business purposes:

Stripe for payment processing, subscriptions, invoices, and its customer billing portal. Stripe receives the practice's legal name, billing email, full address, and our practice and location identifiers, as well as the card details you enter;
Resend for transactional email, including the billing notices and receipts described above, phone setup links, support and feedback replies, alerts to our staff that quote support and feedback messages with the sender's name and email, and incoming replies to those emails;
Google Cloud Platform for application and database hosting, including feedback reports and the files attached to them;
Cloudflare for the public software downloads described above;
Google Firebase App Check, Apple App Attest, and Google Play Integrity for the app-integrity checks described above;
Namecheap for domain registration and authoritative DNS;
Meta Platforms for public-website advertising and conversion measurement and the first-run mobile measurement described above;
Google (Google Analytics 4 and Google Ads) for website analytics and advertising measurement on the public website only;
Microsoft (Clarity) for anonymized public-website usage analysis only.

Office Link does not send clinical chart traffic to these providers. Google Cloud hosts the voluntary feedback reports and attached files described above, which can contain recorded speech, transcripts, and chart values. Feedback attachments are not sent to advertising or website analytics providers. The Android app's speech-model download from Alpha Cephei, and the update checks with Apple and Google Play, are described above.

Retention

Account, practice, subscription, registered-mobile-device, and registered-computer records are retained while the account is active. When a practice account is deleted, staff logins, registered devices, and the other records listed on our account deletion page are deleted at once (for a practice with an open setup hold, self-service deletion currently stops partway, after some of those records are deleted, and our support staff complete it). The practice record (legal name, address, billing email, Stripe customer reference, campaign name, and any BAA signing details) and the subscription history are kept for legal, tax, fraud-prevention, and dispute purposes, with no scheduled deletion.
Trial-eligibility claims, including normalized practice identity and Stripe card fingerprint, are retained to enforce the one-trial limit and prevent repeat abuse.
Active seat state expires after session heartbeats stop. Security and audit events are deleted after two years, except the entry recording a Business Associate Agreement signature, which is kept with the BAA signing record.
A location's history of public IP address changes, and review records about phones charting from clearly different places, have no scheduled deletion and are kept after a practice account is deleted.
Sign-in sessions end after 30 days, or earlier when you log out, and are then deleted. Password-reset and verification token records are deleted 30 days after the token expires.
One-use phone-to-computer pairing tickets expire after two minutes and are removed by automated maintenance.
Phone setup links, including the office link, and their codes are deleted 7 days after they expire or are turned off. Phones that joined through a link stay registered.
Office Link diagnostic events are kept as support history. They hold fixed codes, counts, and times only; if the table grows large we may trim the oldest.
Mobile onboarding measurement, including subscription and store reports, is kept as funnel history, with no scheduled deletion.
App feedback reports and the files attached to them are kept as support history, with no scheduled deletion, and are not removed when a practice account is deleted. To have yours deleted, send a Question from Report Bug in the app, or open a support ticket in your account. We confirm the request with the email address given on the report before deleting it.
Support tickets are kept until the practice account is deleted.
Windows layout-report tickets, their structured report details, replies, and notification records are deleted after one year without activity on the ticket.
Manual setup compatibility reports are retained for integration analysis until you request deletion or the associated office/account or computer record is deleted. There is no scheduled age-based deletion. Manual named charts stay in protected desktop storage until deleted, replaced by the five-record rolling limit, or cleared by switching to automatic mode, as described above.
Availability-update requests from checkout and from the website's software question, chart-order submissions, and former waitlist entries have no scheduled deletion and are deleted on request.
Masked session replays of public-site visits are deleted after 30 days, unless we keep a particular recording to improve the site. Other public interaction data carries no account and has no scheduled deletion. Daily visit counts are deleted after one year.
The campaign-link cookie (`smx_ref`) expires after 30 days. Daily click totals for our own campaign links carry no identifier and are kept while the link exists. The campaign name on a practice's record is kept with the account.
Our record of the emails we sent is kept for 3 years for billing notices and receipts, because they are the evidence that a practice was told before its card was charged, and 90 days for everything else. Deleting an account erases that account's non-billing email records and keeps its billing notices for the rest of that period.
BAA signing records have no scheduled deletion and are kept at least as long as the agreement and applicable law require.

Security

We use administrative and technical safeguards appropriate to the limited business information the cloud service holds, including encryption in transit, access controls, passwords and most one-time tokens stored only as hashes, and authenticator-app secrets stored encrypted. The mobile app locks itself behind a PIN or biometric after a period of inactivity set on each device (10 minutes unless changed).

No system is perfectly secure. Practices remain responsible for their local network, device controls, PMS access, workforce authorization, and prompt device revocation.

Your choices and rights

You may update most account and registered-device information from the admin portal. The practice owner can delete the whole account, and any other staff member can delete their own login, from Settings in the admin portal. You may request access, correction, or deletion of account-level information, feedback reports, their attachments, availability-update requests, and Manual setup compatibility reports by contacting us. Turn off the Manual setup-sharing choice in the desktop app to stop those reports and cancel unsent reports. Turn off “Automatically report chart layout problems” in the Windows app to stop automatic layout reports and clear unsent reports. Turn off “Share connection diagnostics” in app settings to stop those connection reports and clear the local queue; this does not itself delete reports already received. During onboarding, uncheck “Share my setup answers” to withhold those optional answers. We may retain records required for tax, security, fraud-prevention, contractual, or legal purposes.

The Service is intended for dental professionals and business users, not children.

International use

Our account-service cloud infrastructure is hosted in the United States. Public-download delivery may process network and request information globally. App-integrity providers may process security information globally as described above. If you use the Service from another country, business-account information may be processed in the United States, subject to applicable law and contractual safeguards.

Changes and contact

We may update this policy when the Service or our data practices change. We will update the effective date and provide additional notice when required.

Privacy requests: open a support ticket from Support in your account, or send a Question from Report Bug in the app. Email to support@periomaxer.com is not filed as a support ticket, so use one of those routes for a request that needs an answer.