Skip to content

Create an account

Sign in
HekimBis home

KVKK-compliant patient tracking builds compliance as a flow

Health data is special-category personal data under KVKK. So in patient tracking software the phrase KVKK-compliant cannot be a checkbox or a settings menu; compliance is a flow that starts the moment data enters a record and passes through screens, roles, records and processes. HekimBis builds this flow into the product, from the moment a patient first arrives at the clinic to a data subject request.

Try it free for 7 daysRequest a demo

This page is for information and is not legal advice. Which legal basis applies to which processing is the decision of the data controller, meaning your clinic. Official source: Personal Data Protection Authority(opens in a new tab).

A staff member holds a closed navy folder beside a records room door

The privacy notice, explicit consent and clinical consent are separate records

This is the most commonly confused subject: if a single sheet a patient signs on arrival contains the privacy notice, consent and treatment consent, all three are incomplete. Decision 2026/347 of the Personal Data Protection Board stresses that the privacy notice and explicit consent must be provided separately. HekimBis separates them on screen and in the record.

A patient signing on a signature pad held by a nurse in a waiting area

  • Privacy notice

    Who the data controller is, for what purpose data is processed, the legal basis, who it is transferred to, how long it is kept and the patient's rights. The notice is an information text; a viewed record is kept, and it does not stand in for consent. The version of the text and the time it was shown are recorded.

  • Explicit consent

    Given only for a specific processing that really needs consent, freely, through a separate action, and revocable. It is not bound to the service record as mandatory or pre-ticked. A separate consent step is used, for example, for permission for marketing messages, use of a photo in promotion, or sharing data with a third party.

  • Informed clinical consent

    Specific to a procedure or treatment: the procedure text, its version, the signer, the representation relationship (parent or guardian), the time and the evidence components. A signature pad, biometric trace, one-time code, witness and timestamp are stated separately; they ensure evidence integrity and are not called a qualified electronic signature.

The flow shows this: instead of one combined consent checkbox, the three records are requested separately. When consent is withdrawn, new processing stops, records that must legally be kept are not deleted silently, and the affected actions are visible on screen. The legal basis, retention period and deletion effect are defined separately for each flow. See Forms, consent and documents for details.

The separation continues on the messaging side: appointment reminders and service information are classified separately from marketing messages, and no marketing message is sent without channel permission and, where needed, an İYS check. See Patient messaging.

Record05End

Withdrawal: affected processing becomes visible

  • The process is complete here.
5 / 8

All steps

  1. 01 Privacy notice shown (version, time) (Patient)
  2. 02 Explicit consent: a separate action, only for the specific processing (Patient)
  3. 03 Clinical consent: procedure-specific text, signature components (Staff)
  4. 04 Evidence record: signer, version, channel, time (Record)
  5. 05 Withdrawal: affected processing becomes visible (Record)

Alternative path from 01 Privacy notice shown (version, time); it returns to the main flow at 02 Explicit consent: a separate action, only for the specific processing.

  1. 01a One combined checkbox: rejected, three separate records required (Patient)

05 Withdrawal: affected processing becomes visible

Who sees what

One of the basic principles of KVKK is data minimization: an employee should see only the data their work needs. In HekimBis, access is determined by the combination of four things: the feature your package opens, the action your role allows, the status and sensitivity of the record, and your care relationship with that patient. The default role template is as follows; in the Pro and Clinic packages custom roles can be defined.

  • Physician

    Sees identity, contact, clinical record, tests and images in full, and follows debt and payment as a summary. Sensitive note segments are seen only by the physician who wrote them and the people assigned.

  • Clinical staff

    See identity and contact details according to the context they work in, and the clinical record and tests according to their care relationship with the patient.

  • Front desk

    Sees identity and contact details, the contact history and payments; clinical record screens are not part of this role's workspace.

  • Finance

    Sees debt and payments in full, and identity and contact as far as needed.

  • Call center

    Sees appointment availability and contact history; identity and contact details are limited.

  • Compliance and audit

    Opens read access with a stated reason; sees audit records in full.

Three more mechanisms sit on top of this template. Sensitive notes can be segmented, and a segment opens only to named people. Fields such as the ID number can be masked on screen, and unmasking needs permission and a reason. Emergency access by someone without a care relationship needs a reason, a time limit and extra verification and leaves a separate audit record. In multi-branch organizations the same patient is one identity, but the clinical record of another branch opens only through membership and a duty relationship. See Roles, permissions and audit trail.

The audit trail provides accountability

A locked filing cabinet drawer with a key and a navy folder on top.

Access control answers the question of who can do what, and the audit trail answers who did what. Without both, accountability cannot be achieved.

In HekimBis, sensitive reads, writes, downloads, views, exports and support access are recorded. A record carries the person acting, the time, the patient, the purpose and the reason, and audit records are stored in a tamper-proof way. A signed clinical record does not change silently; a correction is made as an additional record with a reason, and who changed what and why stays visible. Records are not deleted; they are archived.

The support side needs special care. HekimBis staff access to your data is not through a permanent super-administrator account but through temporary access granted with a ticket number, a reason, your approval, a narrow scope, a time limit, default masking and multi-factor verification. The access closes when the time ends or when you ask, and the whole session is recorded. Your own organization's compliance officer can also filter and review audit records. See Security for the general approach to security.

In a KVKK inspection or a patient complaint these records work as evidence: which version of the privacy notice was shown and when, who gave consent and through which channel, and who opened a patient file in the last year can be exported from the system. The flow itself produces the evidence instead of it being collected afterwards.

How a data subject request is handled

KVKK gives the data subject, meaning the patient, the right to ask for information about their data and to request correction, deletion and to object. The clinic must be able to track these requests, answer them in time and prove the answer. In HekimBis the flow has five steps.

  1. RequestThe patient applies on the portal, in writing or at the clinic, and the request is recorded in the system. The portal has a ready flow for data access, correction and printout requests and for account closure. See Patient portal.
  2. Identity verificationIt is verified that the applicant is the patient or, if a parent, guardian or representative, that they have authority; data is given only to the verified person.
  3. AssessmentThe request is assigned to someone responsible; which data, which system, any retention obligation and third-party rights are assessed. If some data cannot be deleted because of a legal retention period, this is documented with that reason.
  4. ResponseA response is prepared and sent within the period set in the legislation; the deadline is followed as a task.
  5. Reasoned responseIf the request cannot be met in part or in full, the reason is written and kept in the record.

The KVKK page guides requests that HekimBis receives as a data controller in its own right. For patient data processed on behalf of your clinic, the data controller is your clinic and HekimBis acts as the data processor. See Data processing agreement for the text that defines this relationship.

Technical and administrative measures

Regulations and guides look for technical and administrative measures together. We summarize them under four headings.

Identity and access
Multi-factor verification, session and trusted-device management, an invitation and role-change flow, and immediate closure of access when an employee leaves. Each employee has their own account; shared accounts are not needed.
Isolation and encryption
Organizations are logically separate from one another's data; health data in the production environment is hosted in Türkiye and encrypted at rest and in transit. Services that do not touch health data are not connected without a separate data flow and risk decision.
Logging and monitoring
Sensitive actions are written to the audit trail; patient content is not carried into logging, monitoring or analytics tools, and sensitive fields are hidden by default.
Administrative processes
Role definitions, information security training, sub-processor assessment, incident management, and retention and destruction policy. This heading covers the processes of both the clinic and the vendor; HekimBis explains its own share separately in contracts and documents.

The hosting approach is described on the Technology page. As you set up your clinic's own administrative processes, HekimBis's role templates, consent flows and audit records make those processes workable and provable.

Frequently asked questions

What does KVKK-compliant patient tracking software mean?

It means the software keeps the privacy notice, explicit consent and clinical consent as separate records, limits access by role and care relationship, writes actions to an audit trail and can manage data subject requests. Compliance is not achieved by software alone; the organization's processes are needed too.

Is patient consent taken on paper or on screen?

Either. On screen it is taken with a signature pad or a one-time code; each is recorded with version, signer, time and channel. Paper documents can be scanned and attached to the patient's file.

Is explicit consent needed for every process?

Which processing rests on which legal basis is decided with the data controller's legal adviser. HekimBis lets you define each basis as a separate flow and take consent through a separate action when needed.

Does my data leave the country?

Health data in the production environment is hosted in Türkiye. Sub-services that do not touch health data are not connected without a separate data flow and risk decision.

What should I do when an employee leaves?

You deactivate their account; access closes immediately and their past actions stay in the audit trail. No password sharing is needed.

What can I show in a KVKK inspection?

Privacy notice versions and display records, consent evidence, access and audit records, data subject request records and permission definitions. These can be exported from the system.

How does a patient request their own data?

A patient can create a data access, correction or printout request and an account closure request on the portal. The request is recorded in the system, assigned to someone responsible, and the response deadline is followed as a task.

Related pages

Features

Specialties

Solutions and process

Software guides

Company and support