True-Doctor
Treated as a healthcare data system.
Patient information is sensitive by default. The controls below are part of how True-Doctor is built rather than something added once somebody asked — and the last section says plainly what we do not yet claim.
The controls
Each of these is enforced in code, not in a policy document.
One hospital cannot see another
Every record carries the hospital it belongs to, and every query is filtered by a scope applied at the database layer — not by a condition each developer has to remember. A dedicated test suite exists solely to try to read across that boundary and fail.
Encryption at rest
Card numbers, bank details and other protected fields are encrypted in the database, so a copy of the data on its own does not give them up. Card numbers are additionally stored as a hash for lookup, never in the clear.
A full audit trail
Who viewed or changed which record, and when. Reads as well as writes. Workflow histories — a visit’s stages, a claim’s statuses, an order’s progress — are append-only and are never edited in place.
Role-based access
Nine roles, each with its own menu, screens and fields. A nurse cannot record a diagnosis; a cashier cannot open clinical notes. The same rules are enforced in the web panel and in the API, from one definition.
No default passwords
The first administrator account is created with a random password printed once to the console and a forced change on first sign-in. Staff are invited the same way. There is no shipped password to look up.
One hardened API
A single token-authenticated API — versioned, rate-limited, origin-locked, with one response envelope. No second authentication path and no legacy bypass, because the one that gets less attention is the one somebody finds.
Money cannot half-move
Every payment, refund and stock movement runs inside a database transaction with the affected rows locked. A balance and the ledger that explains it can never disagree because something failed halfway.
Offline, without giving it away
A device holds only what that member of staff may already see, and no password is ever stored on it. The server re-checks every permission when the work is sent back — the device is never treated as trusted.
What we do not claim
Because a page that claims everything is worth nothing.
We are not certified against HIPAA, ISO 27001 or SOC 2.
No audit has been carried out and we do not describe ourselves as compliant with any of them. The controls on this page are real and we are happy to walk your team through them; a certificate is a different thing and we do not have one.
We do not hold your data in your country unless you ask.
Where the application and its backups are hosted depends on the deployment. If data residency matters to your facility, raise it before you sign up rather than after.
Availability is not guaranteed by a contract.
We take reasonable measures to keep the service up and we tell you when it is not. There is no uptime SLA with money attached to it, and we will not pretend otherwise on a marketing page.
Two-factor authentication is not yet on every account.
It is planned for administrator accounts and is not shipped. Until it is, the protections that exist are a forced password change, per-attempt rate limiting on sign-in, and a session you can revoke.
Reporting a vulnerability
If you have found something, we would much rather hear it from you.
Email hello@true-doctor.online with enough detail to reproduce it. We will acknowledge within two business days and tell you what we are doing about it. Please do not test against a real hospital’s data — ask us and we will point you at an instance you can hit.
We will not pursue anybody who reports a genuine issue in good faith, keeps the detail private until it is fixed, and does not access, change or remove data that is not theirs.
Have a compliance question?
We will walk your team through exactly how patient data is stored, isolated and audited — including the parts that are still on the list.
Ask us