Privacy statement

1Who is responsible

Stardent B.V. is the controller for the personal data described in this part: the data of visitors to this website and of the people who order, activate or support a licence.

2Patient data does not reach us

LatinoSoft is a desktop application. It ships with its own database engine and writes everything — patient records, appointments, treatments, images, invoices — to a local database on the computer or the practice server where you installed it. There is no cloud copy, and there is no route by which those records reach Stardent B.V.

The practice therefore remains the controller of its own patient data. Stardent B.V. becomes a processor only for the hosted services a practice switches on itself (the managed mail rail, the online booking connector); the data processing agreement in the DPA governs those. Keeping the database secure and backed up stays with the practice (backup and data retention).

3What this website stores

This site carries no analytics, no advertising and no tracking cookies, and it embeds nothing from an advertising network. We do not build a profile of you from your visit.

This site keeps one value in your browser's local storage: under the key latinosoftCountry, the country page you picked, if you chose one. That value is read only by this page, to send you to the country page you chose; it is not transmitted to us. You can clear them by clearing your browser storage for this site.

The server side is not nothing. This site is served by a web server, and a web server records each request it answers in an access log: the IP address your browser connects from, the page asked for, the time, and what your browser says it is. That log is written on the rented machine described in section 6, so the company that rents us that machine can reach it. We do not feed it into analytics and we do not use it to build a profile of you; it is the ordinary operating record of a running web server.

4When you order a licence or redeem a code

Ordering a subscription happens on pay.stardentlab.com. The order form on the pricing page sends the details you enter and your buyer declaration (practice or clinic name, national registration number, e-mail address, telephone number, country and the plan you chose) to pay.stardentlab.com, where they travel with the payment to Stripe; Stardent B.V. uses them to verify the declaration before it issues a licence. The academic licence request on the home page sends nothing from this site: its button only opens your own e-mail program with a prepared message to dentalsoft@godentalplace.com, and what you send is used only to verify the institution and issue the academic licence. To issue and deliver a licence we process your e-mail address, the practice or company details you enter, the product and edition you chose, and the record of the order and its payments.

Card payments are handled by Stripe as our payment processor. Your card details are entered at Stripe and are not passed through to us; we receive the result of the payment, not the card number. Stardent B.V. is the merchant of record for the sale.

5E-mail we send you

Licence keys, activation codes, order confirmations and support replies are sent from a mail server that Stardent B.V. operates itself. We do not hand your address to a third-party e-mail marketing platform, and we do not sell or rent it to anyone.

6Who else touches it

Two parties other than Stardent B.V. are involved, and no more. Hetzner Online GmbH supplies the machine this website runs on: a dedicated server that Stardent B.V. rents and administers itself, standing in Hetzner's data centre in Helsinki, Finland, inside the EU. It is rented hardware rather than hardware we own, so Hetzner is a sub-processor for everything stored on it — this site, the access log described in section 3, the licence records and, on the edition that has one, the chat conversations. Stripe processes card payments, as described in section 4. The mail described in section 5 leaves from a mail server that Stardent B.V. runs itself on that same rented machine, so there is no third party in the e-mail path at all.

7Why we are allowed to process it

We process order, licence and support data because it is necessary to perform the contract you entered into with us, and we keep the parts of it that belong in our books because Dutch law obliges us to keep them.

8How long we keep it

Licence and support records are kept while the licence is active and for as long afterwards as we may need them to answer a question about it. Invoices and the order records attached to them are kept for the statutory retention period that Dutch law imposes on business administration.

9Your rights

You may ask us for a copy of the personal data we hold about you, and you may ask us to correct it, to delete it, to restrict what we do with it, or to give it to you in a portable form. You may also object to processing. Write to dentalsoft@godentalplace.com and we will answer within one month.

If you believe we handle your data wrongly you are entitled to complain to the data protection supervisory authority of the EU country you live or work in. For Stardent B.V. that authority is the Dutch Autoriteit Persoonsgegevens.

10Changes to this statement

We may update this statement. The version on this page is the one that applies, and the date at the top says when it last changed.

1. Privacy statement for the software

1.1Who issues this statement

Stardent B.V., Europalaan 1E, 9551 DA Stadskanaal, the Netherlands. Chamber of Commerce (KvK) 97830941. VAT NL868250806B01. E-mail: dentalsoft@godentalplace.com. Website: https://latinosoft.godentalplace.com.

This statement concerns LatinoSoft, a program that runs on the computers of your practice. It describes which data the program processes, where that data lives, what leaves your practice and what does not.

1.2Who is responsible for what

1. Your practice is the controller of the patient data in this software. Stardent B.V. supplies the software and has no access to that data.
2. For the limited data that does reach the servers of Stardent B.V. — the update check, the activation of a licence code and the licence check of clause 1.5 — Stardent B.V. is itself the controller. Legal basis: the legitimate interest of Stardent B.V. in publishing updates and administering licences (art. 6(1)(f) GDPR), and, for the code activation and the licence check, performance of the licence agreement (art. 6(1)(b) GDPR).
3. Where Stardent B.V. renders a hosted service on the instruction of your practice — the managed mail rail or the online booking connector with its patient portal — Stardent B.V. is a processor within the meaning of art. 28 GDPR. The data processing agreement in document 2 governs that.

1.3Where the data is

1. LatinoSoft keeps everything in a MySQL/MariaDB database on hardware your practice chooses and runs. No copy goes to Stardent B.V.
2. This software adds no encryption of its own. It builds the database connection from a server, port, user, password, database name and character set and sets no TLS option (Provisioning/DatabaseBootstrap.cs, BuildConnectionString). It encrypts nothing it writes to disk.
3. What protects this data at rest is therefore the disk encryption your practice switches on for that machine, together with the access control on the machine and on the network it sits on. That is your practice to arrange; this software does not do it for you. Document 2, Annex C, lists the measures that belong to it.

1.4User passwords

New and changed passwords are stored as PBKDF2-SHA256, 100,000 iterations, with a random salt per user (Security/PasswordHasher.cs). A password created before that change is still stored as plain text and is replaced by a hash the first time that user signs in.

1.5What leaves your practice

Of its own accord, before your practice switches on any service, at most three things, and nothing else. The first happens at every start; the second only when you redeem an activation code; the third is dormant unless it is configured. None of them carries patient data. What goes out once your practice switches a service on is described with that service: e-mail and SMS in clause 1.8, online booking in clause 1.9. A crash report goes out only if a user e-mails it (clause 1.7).

1. Update check. At startup LatinoSoft fetches https://latinosoft.godentalplace.com/updates.json to see whether a newer version has been published. The request carries the software's own user agent and nothing about your practice. The environment variable SOFTLEX_MANIFEST_URL can point this check elsewhere.
2. Code activation. When you enter an activation code, LatinoSoft sends that code, the machine hash of clause 1.10 and the product key to https://pay.stardentlab.com/api/activate, and then asks https://pay.stardentlab.com/api/activate/status, with the same code and machine hash, until the licence file has been issued. The licence file it receives is stored as license.lic. The software sends no name, no e-mail address and no account; what you entered when you bought or requested the code stays on the page where you entered it.
3. Licence check. Dormant unless the environment variable SOFTLEX_LICENSE_HUB names a licence hub. Left unset, it never runs. When it runs, at each start it sends the licence number, the machine hash of clause 1.10, the software version, the role of this Installation (main server or workstation) and its number within the practice's Licences (clause 3.1) to that hub, so that a revoked licence stops and a licence used on more computers than it covers becomes visible. With a hub configured, and only when a user asks for it in the notice of clause 3.3(2), the software also asks that hub to move the Licence to this computer; that request carries the licence number. A revocation notice received that way is stored as revocation.lic and takes effect at the next start; a slow, unreachable or faulty hub changes nothing.

1.6Who else sees something

1. The addresses in clause 1.5 are served by rented servers which Hetzner Online GmbH operates for Stardent B.V. in Helsinki, Finland (European Union). Hetzner is a sub-processor in its role as hosting provider: it holds the machines that receive those requests.
2. Those machines write the IP address of your practice and the time of each request into their access log. Nothing in this software, and no server configuration shipped with it, stops that logging.
3. If you would rather the requests were not made: the update check can be pointed elsewhere with SOFTLEX_MANIFEST_URL; the licence check never runs unless you configure it; code activation happens only when you redeem a code, and a licence file can instead be imported from a file sent to you.
4. No data is transferred outside the European Economic Area.

1.7Error logs and crash reports

1. Unhandled errors are written on your own machine, to %LOCALAPPDATA%\LatinoSoft\logs\errors.log (ExceptionShield.cs). The same folder holds the log of the online booking module (onlinebooking.log), the mail log (mail.log, one line per message with the recipient's address and the subject), the database schema check (schema.log), the first-run seed (seed.log) and the log of the automatic jobs of clause 1.8(4) and document 5 (run-jobs.log, with the summary of the last run in run-jobs-last.json).
2. Every log is capped (BoundedLog.cs): at 2 MB a log is rolled over, at most three older copies of it are kept, and a log file that has not been written to for 90 days is deleted at the next sign-in or the next automatic run. On the same 90-day rule, and at the same moments, the software also deletes mail logs (mail*.log) that have not been written to for 90 days from the log folder, under %LOCALAPPDATA%, of the sister program this software is built from, where an earlier Dutch build kept its mail log; nothing else in that folder is touched.
3. When an error is shown to the user, the software also writes a crash report to %LOCALAPPDATA%\LatinoSoft\crashes (CrashReporter.cs): the product and version, the time, the type of error, its message with e-mail addresses, IBANs and runs of six or more digits removed, and the program's stack trace. That removal is a filter, not a guarantee: a name that happens to be part of an error message is not recognised. Read a report before you share it.
4. The error notice has a button that prepares an e-mail to dentalsoft@godentalplace.com. It opens your own e-mail program with a short draft that names the error and points to the report file; the software itself sends nothing through it. You decide whether to attach the report and whether to send the e-mail.
5. The software never sends a log or a crash report by itself. If support asks for one, you attach it to an e-mail yourself, after reading it.

1.8E-mail and SMS

1. E-mail and SMS go out only if your practice configures them.
2. E-mail then goes through the SMTP server your practice configured; or through the managed mail preset, which submits over SMTP to the mail server Stardent B.V. runs itself (Stalwart) on the same rented infrastructure; or through the SoftlexMail service of Stardent B.V. at the service address entered in the settings, identified by the key of your practice. For the managed preset and the service Stardent B.V. is a processor (document 2). A third-party marketing e-mail provider is never used.
3. SMS goes through the SMS gateway your practice configures in the settings; Stardent B.V. is not in that path.
4. Automatic messages. The program can send four kinds of e-mail to patients by itself, on behalf of your practice, always through the route of item 2 that your practice configured and never through another: (a) an appointment reminder 48 hours and 24 hours before an appointment, the 24-hour one no later than two hours before it; (b) a recall when a check-up is due, by default from 14 days before the recall date until 60 days after it, and not when the patient already has a future appointment of that kind; (c) a payment reminder for an invoice still unpaid, by default, 14 days after its due date, once per invoice, with the invoice attached as a PDF that names the treatments on it; (d) a confirmation when an appointment is created or changed.
5. Messages (a) to (c) go out only when your practice switches on Automatic messages in the mail settings; (c) also needs a switch of its own. The confirmation has its own switch and needs a template chosen for it. All of them are off on a new installation. Reminders, recalls and payment reminders are sent by the program's automatic run, a minute after a user signs in and, if your practice installs the scheduled task that comes with the program, every 30 minutes, also while nobody is signed in. A confirmation is sent when the appointment is saved. Automatic messages are e-mail only.
6. An automatic message goes only to a patient whose record allows contact by e-mail and who has not switched that kind of message off; a patient who was never asked counts as not having switched it off. A copy to a second address is added only where the patient agreed to it, and never to a payment reminder. Messages (a), (b) and (d) may carry only the patient's name, the date and time of the appointment or the recall date, the practice's name, address and contact details and the name of the user; the program refuses a template that asks for anything else, such as the patient's date of birth or address, a citizen service number or insurance details. Every message sent is recorded in the patient's correspondence in the practice database; (a) to (c) are also recorded in a send log there, from which each automatic run deletes the entries older than 400 days.

1.9Online booking (optional module)

The module works only if your practice switches it on and pairs it, by entering in the settings the address of a booking server and a practice key. The address must begin with https; plain http is accepted only for a server on the same computer, and with any other address the module stays unpaired. Until then the module makes no request at all. Once paired, the software talks to that one server only, every minute while the program runs and, when Automatic messages are on, on each automatic run of clause 1.8(5), and every request carries the practice key.

1. The software sends the booking server nothing but: (a) the open time windows, each with its book, date, start time and duration, the treatments that may be booked in it, the booking step, the minimum notice and how far ahead it may be booked, together with your practice's time zone and the list of treatments offered online (number, name as your practice wrote it, duration), leaving out every window on a date your practice has closed; (b) HMAC-SHA256 hashes of (patient number | date of birth) of every active, living patient, keyed with a secret of your practice, so that an existing patient can be recognised without the server holding the patient file (the server holds the same secret, to check what a patient types against this list), only if that secret is set and only when the list has changed; (c) if your practice switches the patient portal on, an HMAC-SHA256 hash, keyed with the same secret, of the personal link of each patient who holds one, without name, patient number or e-mail address, and with the portal off an empty list, which closes every personal link; (d) your practice's cancellation terms: the number of hours before an appointment until which a patient may cancel without charge, the text and the web address of your no-show policy, and the time zone, only when they have changed; (e) for each appointment booked online, from today on, its booking reference, date, start time, duration, book, treatment and whether it is still confirmed or cancelled, only when something has changed; (f) the references of the bookings it has imported (item 3).
2. The software receives from the booking server: (a) new bookings, each with the chosen window, book and treatment; for a new patient first name, name prefix, last name, date of birth, telephone number, e-mail address and, only if the patient filled it in, sex (F or M); for an existing patient only the patient number; for a patient who booked through the personal link only the hash of that link; a rebooking names the booking it replaces; (b) what patients did themselves: which booking was cancelled or moved, when, and whether a cancellation came after your practice's deadline; (c) the server's short name for your practice, the web address of its booking page and whether the server offers its agenda function. No booking carries a citizen service number.
3. As soon as a booking has been imported into the practice database, the software acknowledges that to the server and the server deletes the personal data of that booking. A maximum retention period for a booking that is never imported: unknown; still to be set by Stardent B.V.
4. Portal invitation. Only when a user clicks it on a patient's card, and only if the portal is on, the secret and the no-show text are filled in, the patient allows contact by e-mail and has an e-mail address, and mail is configured, the software e-mails that patient a personal link through the mail route of your practice (clause 1.8). One click sends one e-mail. It names the practice, contains the link and states the cancellation deadline and, if your practice entered one, the web address of its no-show policy; it names no treatment and no appointment date. The practice database keeps a hash of the link, never the link itself: the copy of the e-mail in the patient's correspondence has the secret part of the link removed. Each invitation is recorded (patient, user, address, result); while Automatic messages are on, each automatic run deletes such records older than 400 days. A user can withdraw a link; it stops working once the next update of item 1(c) has reached the server.
5. The booking server is the one whose address was entered at pairing. When that server is operated by Stardent B.V., it runs on the same rented infrastructure as clause 1.6 and Stardent B.V. is the processor of your practice for this module (document 2, Annex A).

1.10What this software keeps on your computer

Besides the practice database, LatinoSoft writes the following under %LOCALAPPDATA%\LatinoSoft:

• license.lic, your licence, when one is installed
• the first-run marker, a small file recording the date this install first started without a licence; it grants nothing
• revocation.lic, a revocation notice from the licence issuer, verified against the issuer's key, when one has been received
• machine.dat, the machine hash: a salted SHA-256 hash of the Windows machine identifier and the computer name, shortened to 24 characters; the identifier and the name themselves are not stored in it and are not sent
• workstation.flag, a small marker present only while this Installation holds a verified Workstation licence (document 3, clause 3.1); the launcher then does not start the bundled database engine on this computer; the marker is removed as soon as the licence is not a Workstation licence
• databases.json, the database connections offered on the sign-in screen, each with the role this computer has for it (main server or workstation)
• fullscreen.flag, the window preference
• backups, the database backups this software has made (document 5), unless your practice chose another folder for them
• logs, the logs of clause 1.7, capped and deleted as described there
• crashes, the crash reports of clause 1.7
• mail-tmp, the PDF of an invoice while it is being e-mailed; it is deleted after the send
• claims-tmp, only in an edition with the Dutch claims module: a claim file opened for viewing, deleted when the viewer closes, or at the next sign-in once it is an hour old
• data, the practice database itself, when the bundled database engine is used: the launcher creates it there on first run

1.11No browser storage, no cookies

There is no browser storage and no cookie of any kind: this is a program on your own computer. The cookie statement for the website is document 7.

1.12Retention on the side of Stardent B.V.

1. Access log on the rented servers (IP address and time): a limited period; the exact period is unknown and is still to be set by Stardent B.V.
2. Licence and activation records (licence number, machine hash, product, version, the Installation's role and number within the practice's Licences, the code redeemed, and any request to move a Licence): for as long as the licence relationship lasts; records linked to an invoice for seven years after the end of the financial year (Dutch fiscal retention duty).
3. Purchase data (name, billing address, payment): seven years after the end of the financial year (Dutch fiscal retention duty).
4. Data Stardent B.V. processes as a processor: see document 2, clause 2.10.

1.13Your rights

1. Where the data is data for which Stardent B.V. is the controller (clause 1.2(2) and the purchase), you can exercise your rights under arts. 15 to 22 GDPR — access, rectification, erasure, restriction, portability, objection — through dentalsoft@godentalplace.com. Stardent B.V. answers within one month.
2. Where the data is patient data, the patient turns to the practice, not to Stardent B.V. Stardent B.V. does not hold that data and can neither read nor change it.
3. You can lodge a complaint with the Dutch supervisory authority, the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl), or with the supervisory authority of the member state where you live or work.
4. As at the date above Stardent B.V. has not designated a data protection officer. Questions about data protection go to dentalsoft@godentalplace.com.

1.14Personal data breaches

If Stardent B.V. discovers a breach concerning data it processes for your practice, it informs your practice without undue delay and at the latest within 24 hours after becoming aware of it, so that your practice can meet its own 72-hour notification duty (art. 33 GDPR).

1.15Changes

Stardent B.V. may amend this statement when the software or the services change. The date at the top identifies the version in force. A substantive change is announced through the update notice in the software and on https://latinosoft.godentalplace.com.

1.16Contact

By e-mail only: dentalsoft@godentalplace.com. See document 8.

7. Website cookie statement

7.1What this statement covers

This statement concerns the website https://latinosoft.godentalplace.com. The software LatinoSoft itself uses no cookies and no browser storage (document 1, clause 1.11).

7.2What the website does

1. The website sets no tracking cookies and no advertising cookies.
2. The website loads no fonts, scripts or analytics services from third parties. There are no visitor statistics from an external party. Nothing on this website is loaded from any other host.
3. If a cookie is set at all, it is the website's own (first party) and strictly necessary for a function you use yourself, such as a sign-in session. No consent is required for such a cookie (art. 5(3) of Directive 2002/58/EC as implemented nationally).
4. The website keeps a small number of values in your browser's local storage; they are named one by one, with what happens to them, in the privacy statement of the website (section 3 of its first part). No cookie is involved in that.

7.3Payment page

If you buy a Licence, you are redirected to a payment page of Stripe Payments Europe Ltd. On that page Stripe's cookie and privacy statements apply, not this one.

7.4Server log

The server that serves https://latinosoft.godentalplace.com and https://latinosoft.godentalplace.com/updates.json writes the IP address and the time of every request into its access log (document 1, clause 1.6). That is not a cookie, but it is mentioned here for completeness. Retention period: unknown, still to be set by Stardent B.V.

7.5If this is not accurate

This statement describes the website as it is meant to be. If you nevertheless find on https://latinosoft.godentalplace.com a cookie or a third-party service not listed here, report it through dentalsoft@godentalplace.com; the website or this statement will then be corrected.