1
In your instance
Identifiable and encrypted. Only for your team.
- Name
- An Peeters
- Born
- 12-03-1961
- Treatment
- tVNS
- Symptom score
- 62 → 41
- Measured
- 4 Feb and 29 Apr 2026
Personal data
Privacy and GDPR
Health data needs more than a promise. This is where we stand.
Kliva processes health data for your practice. Here you can see, measure by measure, what is already built, what we still build before the first practice goes live, and which questions are still open.
- 13Built: already work in the codebase Kliva grows out of
- 10Partly done: have started, but are not finished or not enforced yet
- 22Planned: are designed, but not built yet
- 6Open question: wait for a lawyer, a committee or the government
Status as of 5 November 2026.
Your practice decides. Kliva carries it out.
Under the GDPR you are the controller: you decide why and how patient data is used. Kliva is your processor and only acts on your instructions.
Data subject
Patient
Fills in questionnaires and can object at any time.
care relationship
Controller
Your practice
Decides why and how data is used, and signs the data processing agreement.
instructions and contract
Processor
Kliva
Only acts on your instructions. Never uses your data for itself, including for training AI.
only what is needed
Sub-processors
Microsoft Azure
Hosting, database and keys in Azure Belgium Central.
Mistral AI
Optional. EU, totals only, no training, nothing kept.
Email and SMS
Email through Azure Communication Services, with data in the EU. The EU provider for SMS is still to choose. They only receive a name and a link.
Mediris, Synops, Vesalius.ai and Jotform are your own suppliers, not Kliva's sub-processors. Kliva only reads from them, on your instructions. You hear about every new sub-processor in advance and can object.
The further data travels, the less it says about anyone.
The Belgian framework law of 30 July 2018 sets an order: anonymous where possible, otherwise pseudonymised, and identifiable data only when that is not enough. This is what it looks like for one patient.
2
Research export
Pseudonymised, with a different pseudonym per study.
- Pseudonym
- S2-7F3A
- Age
- 60–69
- Treatment
- tVNS
- Symptom score
- 62 → 41
- Measured
- day 0 and day 84
Still personal data
3
Public page and network
Totals only. Groups smaller than 10 stay hidden.
| Treatment | n | Symptom score |
|---|---|---|
| tVNS | 118 | −14.2 |
| tDCS | 74 | −9.8 |
| Other | hidden, n < 10 | |
Anonymous
Fictitious patient. The rules: art. 197, 199 and 206 of the framework law of 30 July 2018.
A patient who says no disappears everywhere.
Patients can always object to their data being used for research. Their care does not change.
The patient objects
Through the link in every invitation, at the front desk or by email.
Your team records it
With date and channel, in one step.
Kliva excludes the patient
From that moment, enforced in the code. Nobody has to remember.
Research exports
n = 117
Research statistics
n = 117
Network figures
n = 411
Public page, if you choose
n = 311
An export that a researcher already has cannot be recalled. The patient information says so, and the audit log shows which exports included the patient.
Partly done The field already exists. Enforcing it in every export is built before the first practice goes live.
What is in place, and what comes next.
Grouped by moment. Everything in the first two blocks is done before the first patient of a practice enters Kliva.
-
Already built
In the existing codebase Kliva grows out of.
- Built
Encryption before the database
Sensitive fields are encrypted with AES-GCM before they are stored. The keys are in Azure Key Vault.
- Built
Keys that can be replaced
Every key has a version, and there is a procedure to replace keys without losing data.
- Built
Search without decrypting
Blind indexes find a patient without storing the name or national register number in readable form.
- Built
Encrypted transport
TLS on every connection, with HSTS and strict security headers.
- Built
Sign-in with MFA
Only through Microsoft Entra ID with multi-factor authentication. Shared computers require signing in again.
- Built
An audit log that cannot be erased
Every action is logged, including who viewed a patient. The log can only be added to.
- Built
Quarantine when in doubt
A patient who cannot be matched with certainty goes to a screen where a person decides.
- Built
National register number removed on arrival
The number is removed as soon as data arrives, except where it is needed for matching.
- Built
Only the fields that are needed
From the calendar's patient register, Kliva only takes the fields needed for matching and four contact fields.
- Built
Small groups hidden
Analyses do not show groups smaller than 5 patients.
- Built
Backups that stay in the region
Restorable for 35 days, without a copy outside the region. Restoring an encrypted backup is tested and documented.
- Built
Ready for a Belgian data centre
The setup is described as code for Azure Belgium Central.
- Built
Emergency access with a trail
If support has to access the data, it goes through a logged procedure and with the practice's permission.
-
Before the first practice goes live
This is done before a single patient of a practice is in Kliva.
- Planned
Data processing agreement
With all clauses required by art. 28, breach notice within 24 hours, a ban on AI training and deletion at the end of the contract.
- Planned
Annex with all security measures
Encryption, keys, access, logging, backups, testing and AI settings, written down and signed.
- Planned
Public list of sub-processors
With version, location and contract per party. You hear about every change in advance.
- Planned
A separate instance per practice
Its own database, storage and key vault per practice, set up automatically. Today the code runs for one practice.
- Partly done
Access limited per role
Roles exist, but today every role can read patient data. Research and AI will only get pseudonymised or aggregated data.
- Partly done
Opt-out enforced in every export
The field exists, but no export reads it yet. It becomes a rule in the code, not something to remember.
- Planned
A separate switch for invitations
A patient can stop receiving questionnaires without any change to their care.
- Partly done
Patients' rights
Access, erasure and restriction are built, but not yet merged into the main code.
- Planned
Pseudonymised research export
A pseudonym per study, age in bands and dates as days since the start. To SPSS, R or Castor.
- Partly done
Retention periods that actually delete
The retention engine exists, but runs in test mode until your practice sets its periods.
- Partly done
All secrets in the key vault
Encryption keys are already in Key Vault. The other secrets move there too.
- Partly done
Records of processing
A filled-in template for your records, with the extra research fields Belgian law requires. A first draft exists.
- Partly done
Impact assessment template
A DPIA you complete with your own context, with separate chapters for AI and the network. A first draft exists.
- Partly done
Patient information in three languages
Short on every invitation, in full on your website, and a poster for the waiting room. The parts on research and opt-out are still to be added.
- Partly done
Data breach procedure
The procedure for the practice exists. Kliva's own procedure, the register and the 24-hour deadline are being added.
- Planned
Security policy and training
A formal information security policy and regular training for the team. The Belgian data protection authority asks for this explicitly.
- Planned
Security testing
Automated scans of the code and the cloud setup before the first practice goes live. An external penetration test when a practice asks for one.
- Planned
Contracts on a European basis
The data processing agreement follows the European Commission's standard clauses and is reviewed before the first practice signs. A full review by a privacy lawyer follows as Kliva grows, or earlier if your DPO asks for it.
- Planned
Language model locked down
No training on your data, nothing kept by the provider, no feedback feature. Or an open model inside your own instance.
- Planned
Invitations through an EU provider
No health information in the message, no tracking pixels, and a link that works once.
- Planned
Report behind a one-time code
The progress report is not sent as an attachment, but sits behind a link with a separate code.
-
Before the second practice
As soon as Kliva works for more than one practice.
- Planned
Data protection officer
Kliva appoints a DPO with health data experience and registers them with the data protection authority.
- Planned
Alerts on anomalies
An alert on unusual exports, spikes in record views and failed sign-ins.
- Planned
Leaving without a trace
You take all your data with you. Then we delete your instance, with a written statement of what is kept for a short time.
-
When you publish or use AI
These features are off by default. You switch them on, and that decision is logged.
- Planned
Public page without identifiable patients
Only groups of at least 10, rounded counts, no small subgroups and a re-identification test before you approve.
- Planned
No tracking on the public page
No analytics and no tracking cookies, so no cookie banner either.
- Planned
AI only sees totals
A question is calculated inside your instance. The language model only receives the aggregated result.
- Planned
AI text always labelled
Every text from the model carries a label and is checked by a person. A register records which model received what.
- Partly done
Not a medical device
Kliva gives no advice per patient. That is a design rule; a written analysis under the MDR will record it.
-
For the research network
Later: practices that pool their numbers.
- Planned
Only anonymous tables leave your instance
Each practice calculates its own figures. Patient data never moves from one practice to another.
- Planned
Agreements between practices
An arrangement for joint responsibility, for practices that choose questionnaires and analyses together.
- Planned
Ready for the European Health Data Space
Coded questionnaires and treatments, a data dictionary per dataset and descriptions in a European format.
-
Open questions
We do not have a final answer here yet. We work it out with a lawyer, an ethics committee or the government.
- Open question
Opt-out or consent for research?
No Belgian rule settles this in general. Kliva supports both; the ethics committee chooses per study.
- Open question
Comparing outcomes: care or research?
Does comparing your own results count as care or as research? That decides the legal basis.
- Open question
Is Kliva part of the medical record?
Each practice decides. If the answer is yes, a retention period of 30 to 50 years applies.
- Open question
Authorisation for external researchers
For a pseudonymised export to a researcher outside the practice, we assume an authorisation from the Information Security Committee is needed.
- Open question
Access by US authorities
Microsoft is subject to the US CLOUD Act, also for data in Belgium. Encryption limits what is readable; we still have to decide on keys in our own hardware module.
- Open question
Ethics of the public page
Communicating results publicly is also a question for the Order of Physicians. We will ask them.
Your patients' rights, and how Kliva helps.
You answer requests within a month. If a request reaches Kliva instead, we forward it to you within two working days.
Partly done Access, erasure and restriction are built, but not yet merged into the main code.
art. 15
Access
One export with everything Kliva holds on the patient, including who viewed it and which exports included them.
art. 16
Rectification
Identity and treatment can be corrected. The patient's own answers only with a reason in the log.
art. 17
Erasure
Approved by a second person. Exceptions: the medical record and ongoing research datasets.
art. 18
Restriction
Everything stops, except storage.
art. 20
Portability
The patient's answers in JSON and CSV.
art. 21
Objection
The opt-out above, for all research.
art. 22
No automated decisions
Kliva makes no decisions about patients.
How long data is kept.
No longer than needed. Most periods are proposals: your practice sets them in its records.
Raw source documents
14 to 90 days
Logs at the email and SMS provider
30 days
Quarantine
30 days after resolution, 180 if unresolved
AI questions and answers
90 days in your instance, nothing at the provider
Audit log
5 years, proposed
Data for outcome analysis
10 years after last contact, proposed. Then anonymous.
Medical record, if Kliva is part of it
30 to 50 years after last contact, by law
After your contract ends, you get all your data in an open format. Then we delete your instance. You get a written statement of what Azure still keeps and for how long: a database backup for 5 days, the key vault for 90 days.
What is coming.
Rules that affect Kliva, with their dates. We take them into account now.
1 Sep 2026
New Penal Code
Professional secrecy moves to art. 352. Our team's confidentiality follows that article.
26 Mar 2027
European Health Data Space
The regulation starts to apply. Kliva is not a patient records system and will not become one.
2 Dec 2027
AI Act, high risk
Rules for AI in high-risk areas. Kliva is outside them, as long as it gives no advice per patient.
2 Aug 2028
AI Act, medical devices
Rules for AI in medical devices. Kliva stays outside them, for the same reason.
26 Mar 2029
Reuse of health data
Practices can be asked to share data for research. Practices with fewer than 10 people are exempt, unless Belgium decides otherwise.
26 Mar 2031
Questionnaire data too
Questionnaires then fall under those rules too, after the first publication. Kliva already describes datasets in a European format.
Also watched: the appeal against the EU-US Data Privacy Framework (case C-703/25 P). We keep standard contractual clauses ready for every US supplier.
Questions from your DPO or lawyer?
Email us. We share our full analysis per article, with sources, and the checklist we keep this page up to date with.
This page describes how Kliva is designed and how far it has been built. It is not legal advice.