Türkiye's Personal Data Protection Law (Law No. 6698, known as KVKK) classifies health data as special-category personal data. For a clinic this means something simple: a patient file, a test result, a diagnosis, even an appointment record is subject to stricter rules than ordinary customer data. This article summarizes KVKK's basic concepts on health data for clinic managers and physicians and what they mean in daily operations. It is not legal advice. For application specific to your organization, consult your health-law adviser and the guidance and decisions published by the Personal Data Protection Authority.
Why is health data special?
The law separates health data from other personal data because its disclosure can have lasting and serious consequences for a person. The general rule is that processing special-category data depends on the data subject's explicit consent. For health data the law makes a specific exception: data relating to health and sexual life may be processed without the data subject's explicit consent, for the purposes of protecting public health, preventive medicine, medical diagnosis, treatment and care services, and planning and financing of health services, by persons under a confidentiality obligation or by authorized institutions and organizations.
This exception is often misunderstood. For processing within examination and treatment, explicit consent may not always be needed. But that does not mean a clinic can do whatever it likes with health data. Use for marketing, product promotion, campaign messages or purposes outside treatment falls outside the exception and must be assessed separately.
Three separate records: privacy notice, explicit consent, clinical consent
The most common confusion in clinics is squeezing three different documents into one signature. They have different legal functions:
| Record | Function | When |
|---|---|---|
| Privacy notice | Who the data controller is, for what purpose and on what legal basis data is processed, who it may be transferred to, how it is collected, and a statement of rights | When data is collected, in every case |
| Explicit consent | Consent given on a specific subject, based on information and free will | Only for operations that really require consent |
| Informed clinical consent | Consent for a medical procedure or treatment, given after information specific to the procedure | Before the intervention |
The Personal Data Protection Board's public announcement about its 2026 principle decision stresses that privacy notices and explicit consent texts must be prepared separately. You can reach the announcement on the KVKK website(opens in a new tab). The practical conclusion: a single "I have read and accept" box cannot collect the privacy notice, explicit consent and marketing permission together.
Withdrawal
If the patient withdraws consent, new data processing stops and the affected operations are visible. Past records that must be kept by law are not deleted.
- The process is complete here.
- Photo sharingNew processing stopsAffected
Names, times and records on the screen are examples.
All steps
- 01 Notice shown (Patient) The notice text is shown to the patient; the text version and the time shown are recorded.
- 02 Explicit consent (separate action) (Patient) Taken only for an operation that really needs consent, on a separate screen, with a separate action. Independent of the notice.
- 03 Clinical approval (Staff) A procedure-specific text is shown; the patient signs (pad, OTP, timestamp, witness where needed).
- 04 Evidence record (Record) The signer, text version, time, channel and evidence components are recorded one by one; the document becomes a PDF and cannot be changed.
- 05 Withdrawal (Patient) If the patient withdraws consent, new data processing stops and the affected operations are visible. Past records that must be kept by law are not deleted.
Alternative path from 02 Explicit consent (separate action); it returns to the main flow at 02 Explicit consent (separate action).
- 02a Single combined checkbox: rejected (Record) A flow that tries to gather notice and explicit consent in one box is not accepted by the system; two separate screens and two separate actions are required.
Alternative path from 04 Evidence record; it returns to the main flow at 03 Clinical approval.
- 04a Expired: re-consent (Record) If the consent has expired or the text version has changed, re-consent is requested; the old record stays with its old version.
05 Withdrawal
On the product side, keeping these three records separate means the following: when the privacy notice is shown, its version and time are recorded; explicit consent is taken only for the needed operation and by a separate action, and can be withdrawn; clinical consent is stored with procedure-specific text and with the record of the signer and the representation relationship. When consent is withdrawn, new processing stops; past records that must be kept under law are not silently deleted.
Access control: who sees what?
The most effective measure in protecting health data is limiting access. The law obliges the data controller to take the necessary technical and administrative measures to ensure an appropriate level of security. In practice:
- Role-based access: Reception sees the appointment but not the examination note. Accounting sees collections but not the diagnosis. A physician sees their own patients' records.
- Care relationship: A physician is normally blocked from opening the file of a patient they are not caring for. For emergencies there may be an exception path that is recorded with a reason and a time limit.
- Branch and organization boundary: An employee of one branch cannot see the records of a branch they are not a member of.
- Audit trail: The answer to "who opened which record when" sits in a record that cannot be changed.
- Access of departing employees: At departure, access closes in a single step.
The role structure is described on the roles and permissions page, and the general framework of the security approach on the security page.
Where the data is kept, and transfers
Transferring health data abroad is subject to the relevant provisions of the law, and those provisions have changed in recent years, so current conditions need to be checked. A practical principle: a software provider that keeps production health data in Türkiye and openly lists the subprocessors that can touch health data reduces this risk from the start. At HekimBis, production health data is kept in Türkiye, and even subprocessors that do not touch health data are not connected to the system without a separate data flow and risk decision.
Not sending health information inside patient messages is also a transfer safeguard. Given that an SMS or messaging service passes through a third-party infrastructure, a message with general content like "your result is ready, secure link" means the data never leaves in the first place.
Data subject requests
The law gives the data subject (the patient) a set of rights: to learn whether their data is processed, to request information if it has been processed, to learn the purpose, to request correction, and, where legislation allows, to request deletion or destruction. As a rule an application must be answered within thirty days. The critical point for the clinic is to know where the data is and to manage the request with a record.
Health data has a known tension on deletion: the patient wants deletion, but legislation requires certain records to be kept for a certain period. In that case the right answer is to separate records that must legally be kept from those that need not, and to explain the reason to the patient. For this separation the software should have a defined, versioned retention policy per data class; signed clinical records are not hard-deleted, and at the end of the period only an approved archive or destruction policy applies. This aspect of the data life cycle is a principle that HekimBis also reflects in its contracts.
Data breach: when, to whom?
The law asks the data controller to notify the data subject and the Board as soon as possible if personal data is obtained unlawfully by others. Under a Board decision, notification to the Board must be made within seventy-two hours of learning of the breach. So a clinic must know in advance what it will do at the moment of a breach: who decides, who notifies, which record is kept as evidence?
Three steps are enough for preparation: appoint an incident owner, write the steps to follow when a breach is suspected, and settle in the contract how quickly the software provider will notify you of a breach. The provider's audit trail and incident records are the most important evidence in determining the scope of a breach.
Responsibility between software provider and data controller
When a cloud-based clinic software is used, the clinic is the data controller; the software provider is in most cases in the position of data processor. The processor acts only on the controller's instruction. This relationship should be regulated by a written contract (a data processing agreement). The contract should contain at least: the subject and duration of processing, data types, security measures, use and notification of subprocessors, breach notification time, assistance with data subject requests, and return or destruction of data at the end of the contract.
A common mistake here is assuming all responsibility can be handed to the software provider. As controller, the clinic must take care in choosing the provider, authorize and train its employees, provide the privacy notice and answer requests. The provider only ensures technical and administrative measures and does not act outside instructions. HekimBis's contract texts in this framework are published under data processing agreement and the legal pages.
Staff training: the weakest link is often the human
However strong the technical measures, a significant part of breaches is human: a document sent to the wrong person, a patient file left open on a screen, a shared password, patient information shared through a personal messaging app. A simple training program reduces these risks markedly:
- Short, role-appropriate KVKK and confidentiality training for a new employee in the first week
- A ban on shared passwords; everyone works with their own account
- A habit of screen lock and sign-out
- Sharing patient information only through institutional channels
- Annual refresher training and a short awareness check
Keeping a record of attendance is also concrete proof, in an audit, of saying "the necessary administrative measures were taken."
Data controllers' registry (VERBİS)
Data controllers above certain thresholds may be subject to an obligation to register in the Data Controllers' Registry (VERBİS). Verify from the Authority's current announcements and from your adviser whether your organization falls under this obligation and what information must be entered. The data inventory the software provides helps in preparing this registration.
A twelve-item list for a clinic
- Is the privacy notice shown to the patient as a separate text, with version and time recorded?
- Is explicit consent taken only for operations that really need it, and by a separate action?
- Is permission for commercial messages not tied to the service record as mandatory or pre-ticked?
- Is clinical consent taken with procedure-specific text?
- Are roles and care relationships defined, and does reception see clinical notes?
- Is every access to a patient file written to an audit trail?
- Is a departing employee's access closed?
- Is there no health information inside messages?
- Where is data kept, and who are the subprocessors?
- Is there an application route and an owner for data subject requests?
- Is there a written procedure to follow in case of a breach?
- Is the retention and destruction policy defined per data class?
Conclusion
KVKK compliance is not a setting but a flow: a privacy notice when data is collected, separate explicit consent where needed, procedure-specific clinical consent, role-based access, an audit trail, request management and breach readiness. Software can support this flow, but responsibility rests with the clinic as data controller. To look at the topic from the product side, see KVKK-compliant patient tracking, and to see how privacy notice and consent records are kept, look at the forms, consents and documents feature.
