Practice growth
Delegating to a secretary without giving away the record
How granular permissions let your front desk do more, while the clinical chart stays yours.
7 min read
Encrypting a database with one key protects it against theft of the disks and against nothing else. Doctopass gives the most sensitive categories in a record their own keys, isolated from the rest of the record, and then checks authorisation twice on every access — because a key is not a judgement about who should be reading.
One key for the whole building
"Encrypted at rest" normally means one store behind one key. That is a real protection: steal the disks and the data is unreadable. It is also a flat one. Once the system is running and that key is in use, every record it covers is equally reachable.
For most data the trade is right. For a medical record it is not. A note about a sprained ankle and a note about a psychiatric admission sit behind the same door, and the door was sized for the ankle. Field-level encryption is the practice of giving named, especially sensitive fields their own keys instead of leaving them under the one that covers everything.
Separate keys for the sensitive fields
The most sensitive protected health information, mental health, and other protected categories are encrypted at the field level with separate keys, isolated from the rest of the record. Transport and storage are covered on their own terms: personal data is encrypted in transit over TLS and at rest, and stored files are reached only through short-lived signed URLs.
Isolation is the word doing the work. The keys that open those categories are not the key that opens the record around them, so a compromise on the ordinary path does not hand over the extraordinary content with it. The computerised patient record is one object to the doctor reading it and several differently protected objects underneath.
One neighbouring control deserves naming here, because it protects the same note on a different path: personal identifiers are stripped before any prompt leaves our servers for AI processing, so the model sees the clinical picture and not the identity. That is not encryption and we do not present it as encryption; it belongs with the rest of what AI does inside a Tunisian practice.
Two layers, checked every time
Who may open a record is decided by authorisation, not by cryptography. Every access to patient data passes a two-layer check: a role-based guard, then a per-record ownership and permission check in the service layer. Access to health data is restricted on a need-to-know basis, so a user reaches only the health data they are authorised to reach.
It is tempting to fuse the two mechanisms and say that a key is released only to whoever holds the right permission for that specific note. We will not write that sentence. A key settles whether a stored field is readable outside the system; who may open it inside the system is settled by the two-layer check. We would rather write that limit down than let it be discovered after signature.
| Mechanism | What it settles | What it leaves open |
|---|---|---|
| Field-level encryption, separate keys | Whether the stored field is readable outside the system | Who inside the system may open it |
| Role-based guard | Whether a role may reach this kind of data | Whether this particular record belongs to this user |
| Per-record check in the service layer | Whether this user may reach this record | Whether the reading was appropriate |
A colleague is a further case again. A doctor other than the one who created a record can view it only where the patient has given explicit consent, granted per doctor and revocable, and every such access is recorded. An assistant is a different case a third time, and is treated under secretary permissions.
A trail that records reads
The full audit trail starts at Pro. It is immutable, it records reads and writes of patient data, including access by another doctor, and it is available to the responsible doctor. Full audit logging captures who viewed a record, who changed it, and when, in lines that read in plain language, naming who opened the record and the minute they did it.
Deletion is the other half of the same accounting. Patient data is never hard-deleted. Soft deletes preserve the clinical and legal record while honouring the patient's wishes — recoverable, accountable, auditable.
The trail is gated by plan, and the gate is worth printing:
| Capability | Essential | Pro | Premium |
|---|---|---|---|
| Full audit trail | No | Yes | Yes |
| Audit log search and investigation interface | No | No | Yes |
That gate is about the trail, not about the keys. The rest of the model — the encryption, the authentication list, the audit trail sitting under both — is set out in the security architecture.
What field-level encryption does not do
It does not replace access controls, audit logging or careful permissions; it works alongside them. It does not make a field unreadable to someone entitled to read it. And it decides nothing: a key opens or it does not, and the judgement about who should be holding it lives in the authorisation layer above.
It also buys complexity, and the whole point of carrying that complexity well is that a doctor never meets it. Keys are the product's problem, not the practice's.
Two things we will not publish. We will not put a price on your breach. The figure usually reached for is IBM, Cost of a Data Breach Report 2026, which gives a global average of USD 4.99 million, "a 12% increase over last year and a record high" — an average across all industries worldwide, not a number about a Tunisian practice, and we will not scale it into one. And we will not tell you what a breach then obliges you to do; the answer is the INPDP's and your Ordre's, not a vendor's.
Worth remembering
Treat the two mechanisms as two. Sensitive categories carry separate keys isolated from the rest of the record, and every access is checked twice, by role and then by record. Read the trail before you widen anyone's reach, and read the plan gate before you rely on the trail; field-level encryption isolates the most sensitive fields, it does not decide who may open them.
Frequently asked
Which fields get their own keys?
The most sensitive protected health information, mental health, and other protected categories, encrypted at the field level with separate keys and isolated from the rest of the record. We name the categories our security architecture names and stop there: a field-by-field inventory would be a more impressive claim and a less checkable one.
Does a separate key stop a colleague reading the note?
No, and this is the limit worth stating plainly. Cryptographic separation is not an access decision. Whether a colleague may open a record is settled by the two-layer authorisation check and, where the record belongs to another doctor, by the patient's explicit consent, granted per doctor and revocable, with every such access recorded.
How do I see who opened a record?
Through the audit trail, which records every read and every write of patient data, including cross-doctor access, and is available to the responsible doctor. Read the plan gate before you rely on it: the full trail starts at Pro, and audit log search with the investigation interface is Premium.
What do the three plans cost?
69, 159 and 269 DT per doctor per month, billed annually. There are no setup fees and no per-note charges, data migration is free, and patients are free and unlimited on every plan. The audit-trail gate sits beside everything else on the three plans compared.
Encryption is a boundary, not a verdict. To watch the two mechanisms work separately — the separate keys underneath, then the role guard and the per-record check on the way in — request a 30-minute demo: bring the one record in your practice you would least like opened by the wrong person, and we will take it through both.