Trust & Security

The practice side of Talcho is only reachable by signing in. Everyone at your practice has their own account with their own email address and password, there are no shared logins, and no practice screen loads patient or treatment data until someone is signed in.

The one page that opens without a login is the link you send a patient. Patients get no account and no password — the link carries a long random code that only that patient has, and opening it shows them their own plan and nothing else. It cannot be guessed or walked from one patient to another, and it gives no way into the practice app. Talcho stores only a one-way hash of that code, so it cannot be read back out of the database.

Anyone can switch on two-factor authentication for their own account, from Security & 2FA in the account menu. You scan a QR code with an authenticator app such as 1Password, Authy or Google Authenticator, type the 6-digit code once to confirm, and from then on Talcho asks for a fresh code every time you sign in. You can turn it off again in the same place. It is optional and set per person, so a practice can encourage it but Talcho does not force it on.

Once someone has it on, the check is not just a screen in the way. The same rule is enforced inside the database: patient records are read under that person's own login, and the database refuses to return them to a session that has not passed the code. A stolen password on its own does not open the app.

There are four roles, and an owner decides which one each person gets.

Owner — the practice principal. Sees everything, and is the only role that can invite or remove staff, change roles, edit practice settings, set goals, and permanently delete patient records. There is always at least one owner: the last one cannot be removed or demoted.

Associate — a dentist working in the practice. Sees every part of the app, but only for the patients assigned to them.

Coordinator — runs the pipeline and the follow-up. Sees the day-to-day work and the money figures by default. The owner decides individually whether a coordinator can also see statistics, and can switch the money figures off for that person, from Practice settings → Team. Practice settings themselves, including the follow-up and timing rules and the consent templates, stay with the owner.

Reception — the front desk. Sees the practice's whole day-to-day board, for every patient: cases on both the treatment and clinical boards, appointments, tasks, lab work, clinical notes, the record of what has been said to and about the patient, and the log of who changed what. The one screen this role cannot open is Statistics. Dollar amounts are kept off the screen too, though that one is a display rule rather than a database boundary. Reception cannot change practice settings or the follow-up rules, cannot invite or remove staff, and cannot empty the Trash.

The associate boundary is the one worth spelling out, because it is enforced by the database rather than by the interface. Each associate account is linked to a provider name, and a row-level security rule means their login can only ever return cases whose provider matches that name. The records hanging off a case — plans, tasks, lab cases, contact history — follow the same rule, so if a screen were built wrong, or someone queried those records directly instead of using the app, another dentist's patients still would not come back. Only an owner can set or change which provider name an account is linked to; an associate cannot repoint their own.

One limit worth stating plainly: that scoping covers the records in the database, not the files uploaded against a case. Plan PDFs and other case documents sit in one practice-wide store that any signed-in member of your practice can reach, so an associate who went looking for them could open a document belonging to another dentist's patient. The app never puts those cases in front of them; on files the boundary is the app rather than the database. Bringing file access into line is on the list.

Practice data is stored in a managed Postgres database run by Supabase on AWS in the Sydney region (ap-southeast-2). Patient records are kept only there, and Talcho will not relocate them outside Australia without your practice's written agreement. Each practice gets its own database project with its own credentials, so one practice's records are not sitting alongside another's.

Traffic is encrypted in transit with TLS, and the stored data is encrypted at rest. Serving the app itself, and the few jobs Talcho runs on the server rather than in your browser, such as issuing a consent link or building the signed consent PDF, use the hosting provider's infrastructure, which may sit outside Australia. That traffic is encrypted, and the record itself is written back to the Sydney database. The database provider takes daily automated backups, and those backups stay in the Sydney region too.

Patients never get database access of any kind. The link described above opens one page: their own plan, the consent forms that go with it, the visit-by-visit journey if you have published one, and anything they have already signed. It reaches nothing about any other patient.

You choose how long that link stays live when you create it, and it is 90 days unless you change it. You can withdraw a link at any point and it stops working straight away. Any PDF the patient opens is served through a one-off address that stops working after ten minutes.

Access to the servers is limited to the people who run Talcho. They are bound by confidentiality, use the least access their task needs, and use it only for support your practice has asked for or for keeping the service running. There is no offshore support team.

Talcho holds the information your practice puts into it: patient names and contact details, the treatment plans presented and what they cost, which stage each patient is at, appointments, notes, the record of what has been said to and about the patient, consent forms, and documents attached to a case. It also holds the account details each staff member needs to sign in, and a record of who changed what.

Lab work is part of Talcho itself rather than something imported from a lab system. Lab cases are tracked through their stages with due dates and the teeth involved, and costs are estimated from the lab price list your practice sets up in Practice settings → Lab price list.

Where your practice imports data from another system — for example, treatment plans read out of your practice-management software — that data is held under exactly the same access controls as anything typed in by hand.

Talcho does not sell practice data, does not use it for advertising, and does not use it to train AI models. It is processed to provide the service and for nothing else. The demo environment contains only made-up patients.

For the practical side of privacy: the app has a per-device toggle that hides patient names, and another that hides dollar amounts, for when someone is standing behind you at the front desk. Both are display-only, so they cover the screen rather than change who is allowed to see what.

Your practice's data is kept for as long as your practice is using Talcho. Owners can take it out at any time from Practice settings → Data & export: a spreadsheet of all cases, or a full backup — every record, plus download links for every stored file (consent packs, signed PDFs, case documents). Those links stay live for an hour, so download the files in the same sitting as the backup; running the export again gives you fresh links.

Owners remove staff accounts from Practice settings → Team. Deleting a patient sends the record to Trash first, and only an owner can empty it, which is what makes the deletion permanent.

If your practice stops using Talcho, your data stays available for export for 30 days, and the database and its backups are then deleted on the provider's normal backup-expiry cycle. Ask and we will confirm the deletion in writing. Keeping the records your health-records obligations require is your practice's responsibility, so export what you need before you go.

Talcho is built around the Privacy Act 1988 (Cth) and the Australian Privacy Principles. Your practice collects the patient information and decides what it is used for; Talcho stores and processes it on your instructions, to run the service, and acquires no rights in it.

Talcho secures the application and the platform controls described above. Your practice is responsible for deciding who holds an account and what role they get, for removing people who leave, for strong unique passwords and for turning on two-factor authentication, and for handling patient data in line with the rules that apply where you practise.

Talcho does not hold ISO 27001, SOC 2 or any similar third-party certification, and does not claim to. This page describes controls that are in place today; it is not legal, regulatory or clinical advice, and it certifies nothing. If your practice or its group needs an independent security review, that is welcome and can be arranged.

If you believe you have found a security vulnerability in Talcho, please tell the owner who set up your practice, or reach the Talcho team through the contact details shared with your practice. Please do not post vulnerability details publicly. If we become aware that something has gone wrong with your practice's data, we will tell your practice without undue delay, and in any case within 72 hours of becoming aware, with what we know at that point and what it means for your practice.