Patient data security is our priority
Patient records are the most sensitive data a practice holds. Below we set out what protects them in ZenMed.
Nine things you will not find in a feature table
Every vendor has encryption and backups by now. The difference starts at the decisions nobody asks about during a demo: who must carry a second factor, what that factor is, and what happens on the day a backup has to come back.
The second factor follows the permission
The requirement covers every account that can reach patient data, so a doctor and a nurse carry it on the same terms as an administrator. What counts is what the account can actually do.
A passkey instead of a code
The credential is created bound cryptographically to the sign-in address, so it will not work on a forged page. A code in a message can be phished out of someone, a passkey cannot.
The weaker path closes itself
Once an account holds an authenticator app or a passkey, e-mail code sign-in switches itself off for that account. Nobody gets around the stronger safeguard by falling back to the weaker one.
No new table without a policy
A migration that adds a table holding practice data goes through an automatic check. Without row level security enabled and a policy of its own, it does not reach the database at all.
No subdomain per practice
Every practice works under one application address. Public certificate logs therefore give away nobody who works with us, while a vendor using subdomains hands over the same list in a single query.
A link with a token stays out of the logs
The single-use addresses we send to patients are written to the logs with the token cut out. Reading the log entry is therefore not enough to walk through the door the link opened.
A full set of headers on the panel
The panel answers with HSTS, a content security policy and a block on being framed by anyone else. That one you can verify yourself, from outside, in half a minute.
Backups the server cannot read
The archive is encrypted to a public key, and the private key stays away from the cluster, from the deployment automation and from our own hands. The bucket that holds the copies has a delete lock.
Restore proven on production
We rehearse the restore from a real archive and count the result. Patient and audit row counts have to match to the row, and the hash chain in the audit log has to come back with no gap.
A practice answers for patient data to the patient and to the supervisory authority. We answer to the practice. So every safeguard in ZenMed takes a form you can check: a mechanism in the code, a policy in the database or a clause in the processing agreement.
Legal basis and standards
Two articles of the GDPR set what a practice may demand from a vendor, national rules on medical records add the retention period and the form documents take, and the NIST guideline settles what a second factor of authentication has to be. Each of these you can read at the source, without going through us.
NIST SP 800-63B
The guideline treats a code sent over the telephone network as a restricted factor and asks for at least one factor without that restriction beside it. We have two, on every plan: an authenticator app and a passkey.
Article 32 GDPR
It sets the technical measures a practice may demand from a vendor. Here that means encryption in transit and at rest, per-practice separation inside the database, an immutable audit log and access driven by permissions.
Article 28 GDPR
It sets what the processing agreement has to say. You sign the scope, purpose and duration of processing, the subprocessor list with 30 days notice of any change, the right to audit and how you leave with your data.
National rules on medical records
How long records must be kept and the form they take are set by the law of your country. The duty sits with the practice, and the system has to carry it, export on the way out included.
Frequently asked questions about security
Because practices are separated by the database, not by application code. Every table holding patient data has its own access policy, and the role the application runs as has no permission to bypass it. Even a bug in the code will not show you another practice record, because the query simply will not return it.
Most systems for clinics do it differently: one application split into subdomains, everyone in the same tables, separated by a condition in the query. Every condition someone forgets is then a leak.
That decision has a second effect, visible from outside. We give no practice its own subdomain, so host names give away nobody who works with us. Where a subdomain does exist, the public certificate log is enough to read the customer list.
Yes, and you do not need our agreement for it, only to give notice. The processing agreement gives the controller the right to audit compliance with its terms, either directly or through an appointed external auditor, after notifying us at least 14 days ahead.
We make security documentation and other evidence of compliance available on a reasoned request. The controller carries the cost of the audit, unless the audit shows a breach of the agreement, in which case we carry it.
Much of what an auditor usually asks for does not have to come through us at all. You review the audit log yourself, filtered by staff member, patient and date, and you download the record of processing activities from the system whenever you want it, in the state it is in that day.
You get an export of all your data in JSON and CSV within 30 days of termination. Once you confirm you have received it, we delete the data within a further 60 days and issue a written confirmation of deletion.
The exception is data we are required by law to keep. How long medical records must be retained is set by the law of your country, and that duty sits with the practice as the controller, so collect the export before you switch systems rather than after.
The 30 days run from termination, not from the day you ask for the export. We do not tie you down with a long notice period either, and JSON and CSV were chosen because every other system reads them, not only ours.
The database, the files and the backups sit in Poland, and medical data does not leave the European Union. TLS 1.3 protects it in transit, AES-256 at rest.
There is one processor outside the Union and we name it before you ask. Cloudflare sits in front of the application and filters traffic, but stores no data. The full list of subprocessors is an annex to the processing agreement, and any change to it is announced 30 days ahead, with a right to object.
On our side, only people bound by confidentiality can reach the data, and processing happens on your documented instruction. Every read of a patient record leaves an entry in the audit log with the time, the user and the IP address.
Book a short online demo.
We will show the system on examples from your specialty and answer your team's questions.
- Demo tailored to your specialty
- No commitment. You decide whether to go further
- We open the account on request, the free plan included
Prefer email? Write to [email protected] Or call us at +48 502 565 106
Thank you for the chance!
We have received your request. We will reach out to arrange the demo or open your account.