Patient data security is our priority

Yes, and we show it with documents rather than a claim on a web page. The processing agreement sets the scope and the purpose, the data protection impact assessment names the risks, and the record of processing activities is generated from the database in the state it is in today. You get all three to read before you decide.

The technical measures Article 32 GDPR asks for can be checked here one by one: two-factor login, separated roles, per-practice isolation inside the database, TLS 1.3 and AES-256, an immutable audit log, restores rehearsed on a real archive.

One thing is worth knowing. No certificate moves the responsibility for choosing a vendor away from the practice, which stays the controller under Article 24 GDPR, and what a vendor owes it is the measures and the evidence. So instead of a stamp we hand over a list that can be walked point by point.

The practice is the controller, we are the processor. You set the purpose and the scope, and we process the data only on your documented instruction and within the processing agreement (Article 28 GDPR).

That split is not a formality. We answer for our own failures, and if we went beyond your instruction we would become the controller of that processing, with everything that follows from it (Article 28(10) GDPR). This is why access on our side is narrow and bound by confidentiality, and why every record we open lands in the same audit log as yours.

In practice it means the duty to inform patients and the decisions about what the records hold stay with you, while what you should demand from us is security measures and evidence that they work.

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.

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.

We notify you without undue delay and hand over what you need for the report. That duty sits on the processor directly in Article 33(2) GDPR, and the 72 hours to notify the supervisory authority run for the practice from the moment it becomes aware of the breach.

The scope of a breach can be reconstructed from the audit log: who opened which records, when, from which address, and what was exported. That is exactly what a breach notification asks for.

It is also why the log is immutable and why you read it in the panel rather than on request. Notifying the authority and, where it applies, the patients is done by the practice as the controller under Articles 33 and 34 GDPR, but not on its own.

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.