Privacy Policy

Effective September 23, 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 or, in our own developer builds, the files are copied to our development computer over the local network. 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. Windows developer (Debug) builds also offer 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. Release builds do not create these recordings. Previously created files can remain on the computer; the current Windows Report Bug form does not attach session recordings. 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.

When a Windows desktop update’s release metadata passes verification, the app downloads its installer automatically and asks before installing it. It keeps the installer in a protected system application-data folder. It attempts to delete downloads that fail verification or are no longer needed before installation, including when you choose Later. After an installer has started, its file may remain; the next time the desktop app starts, it attempts to remove staged installers that are at least two days old. This cleanup runs at app startup, not on a two-day timer.

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. Mobile minimum-version checks and chart-order library requests carry no account, practice, or patient information. Desktop update requests identify the platform, update channel, current version and, when supplied, processor architecture (x64 or ARM64). The update service also accepts an optional machine fingerprint to choose a staged-rollout group in memory. It does not write these request fields to the application database; day-level request counts are kept separately.

On Android, the latest successfully fetched minimum-version policy is stored on the device without an age-based expiry and remains in effect offline until replaced. Google Play manages its own update processing. Google documents collection of device metadata, application version and installed module/asset-pack information for in-app updates, with a provider retention period whose duration is not specified on its In-App Updates data-safety page.

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, for the reusable office link, the link itself, and the public IP address of the phone that opened it.
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, the computer’s local-pairing certificate fingerprint and protocol version, and, when a phone joins it by scanning its code, which registered phone that was, when, and how it joined. The computer also reports the time of its last code-scan pairing with its license checks, and the public IP address that redeemed its activation is kept with the activation record. 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 the typed-code data 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. Records of ended charting sessions, with their public IP address, coarse region and device name, are kept until the practice account is deleted. 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. On iPhone and iPad, unsent reports are queued on the device with a limit of 500 events and no age-based expiry. Turning diagnostics off clears the pending queue and attempts to delete its file; a request already in progress may still complete. Queued reports use the office credential available when they are sent, so a report recorded before an office change may be associated with the office used at sending.

On Android, unsent connection diagnostics are kept in a bounded queue on the device without an age-based expiry. Turning diagnostics off stops new collection, clears the in-memory queue, cancels the send task and attempts to remove the saved queue. A network request already in progress may still finish. Queued events use the office credential available when they are sent; changing or removing enrollment does not itself erase the queue, so older events may be associated with a newer enrollment or sent under the installation identifier alone.

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): The current Windows desktop does not offer this sharing control or send these reports. Versions that offer the control can let you 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, and on iPhone, a capture from a practice odontogram, which includes what the speech recognizer heard and the entries made in that practice odontogram. A practice chart or odontogram is blank, belongs to no patient, and is discarded when it closes; in test builds of the phone apps, voice session recordings. The current Windows Report Bug form has no file-attachment control and does not attach session recordings. Recordings submitted from earlier versions may remain in support history. Session recordings contain microphone audio, what was heard, and the chart values and odontogram entries made 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 or reply arrives, our email provider sends staff a neutral alert with a link to the staff console. The alert does not quote the submitter's name, email address, message, reply, or attachment details. The report and replies remain stored with the support record and are available to authorized staff in the console. 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, whether setup was skipped, and the app language. 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 a setup-variant label. On iPhone and iPad, the event named “trial started” records a successful subscription purchase, whether or not it includes a free trial. 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. We may share or publish onboarding measurement and setup answers, for research and other purposes, in a form that does not identify you, your office, or your phone.
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.
App store sales reports: we download the sales and subscription reports that Apple and Google provide to app publishers. Google's reports list each order with its order number, product, price, time, device type and the buyer's country, state and postal code; they carry no buyer name or email. We keep these reports with no scheduled deletion, to count sales and subscriptions.

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 or whose short code it typed. A phone that has connected before can reconnect to a remembered computer with the credential that computer gave it, without the cloud service. Otherwise the authenticated cloud service 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 credentials. Production Open Dental and Dentrix integrations read the dental software’s displayed window, including its title and chart, in memory; they do not read a PMS database. The desktop uses those reads to locate cells and, where supported, obtain missing and implant teeth and current or earlier exam values. Chart entries are held in session-scoped desktop memory while they are entered into the PMS. Window reads are not uploaded; local layout calibration can retain cell positions and pixel samples of the chart grid.

In Office Linked mode the phone keeps one saved exam. It holds the values entered on the phone and the chart the office computer read from the dental software and sent to the phone, with no patient name. It is stored like other charts on the phone (on iPhone and iPad in the app's database under iOS Data Protection, on Android in the encrypted file) and stays until the next office exam replaces it or someone discards it. After a restart the app can offer to send its unconfirmed values again.

The app may keep chart entries that have not yet been sent while the office connection is unavailable or charting is paused. Unsent entries can remain after the chart screen or connection closes. iPhone and iPad hold this sending queue in memory; Android stores it in encrypted preferences so unsent entries can survive an app restart. Android also stores identifiers for the chart, entries, and connection context with the queue. Entries leave this queue when sent, when already satisfied by the current chart, or when discarded by context or compatibility checks; sending is separate from confirmation that the office computer recorded them. A reconnect or changed chart must pass fresh context checks before queued entries can be sent. The queue has no scheduled age-based deletion.

When supported and enabled on the office computer, Office Link can send an earlier exam over the local connection for reference on the phone. The phone's Previous-exam switch is a saved display preference, initially on. Turning it off hides the earlier exam; it does not stop the computer reading or sending it, or immediately remove the received copy from memory. Office-relayed reference data stay in memory until cleared at a chart-context or connection boundary. Locally saved patient charts are separate.

A supported office computer may send a display-only patient label over the local connection. The app keeps that label in memory for the connection and clears it when the connection ends; it does not include the label in its stored queue, logs, or automatic reports, or send it to the cloud service. Separately, opaque chart-context and revision identifiers accompany local chart messages and may be kept with unsent values so they are not sent into another chart.

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. The desktop deletes each record automatically once it is 48 hours old, measured from when it arrived. It checks when it starts and every five minutes while it runs, so a record can last longer while the desktop is closed, signed out, or signed in to a different activation, or if its protected store cannot be read. Users can open, Delete, or Clear All of those desktop records sooner; switching between Manual and automatic mode does not delete them. 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.

The phone normally checks office entitlement about once a month when a check is due and it has a connection. Its last confirmed answer remains in effect while offline until a later check receives an authoritative answer; an access restriction or credential rejection takes effect when received. Desktop licensing is separate.

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, a Manual number-pad map (small grayscale pictures of the dental software's number-pad keys, their positions, and the program's file name, window class, size and display scale, never the window title), the name and email remembered for bug reports, consent records, and legacy or developer-test Open Dental database settings, if present, with any saved database password protected by Windows data protection. Production charting does not use those database settings.
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 and app-event log; an update log with one line for each failed update check or download, with web addresses cut before any query and kept under 256 KB; 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 previously created by developer (Debug) builds with the “Record voice sessions” setting, described in “The short version”. Release builds do not create new recordings or erase existing ones merely because they are Release builds.

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

App Store and Google Play builds of the mobile apps that include Meta’s measurement SDK record setup-screen views and timing, subscription-screen taps, and setup completion during first-run setup for delivery to Meta. 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 includes the platform and a setup-variant label. On iPhone and iPad, the event named “trial started” records a successful subscription purchase, whether or not it includes a free trial. 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. The apps stop recording new setup-measurement events for Meta after onboarding; previously recorded events may be delivered afterward. 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, neutral staff alerts with a link to the staff console, 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, open setup holds, support tickets, and the other records listed on our account deletion page are deleted together in one database transaction. If that transaction fails, its database changes are rolled back rather than leaving the account partly deleted. 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. Computer activation records, with the IP address that redeemed them, and records of ended charting sessions are kept until the practice account is deleted.
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, including after a practice account is deleted. 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 request removal, send a Question from Report Bug in the app, or open a support ticket in your account. Include the email address used for the report so support can identify it. There is no self-service feedback-deletion control.
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 removed by the desktop's first check after they are 48 hours old, whichever comes first, 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. In desktop versions that offer Manual setup sharing, turning it off stops those reports and cancels 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.