Data Protection for Medical Tourism: GDPR and KVKK
An informational guide to handling patient data in medical tourism under GDPR and KVKK: health data, roles, consent, transfers, retention and security measures.
Medical tourism sits at an uncomfortable intersection for data protection. You handle health information, which almost every regime treats as the most sensitive category of personal data. Your patients live in another country, so more than one legal regime may apply to the same file. The information arrives through consumer messaging apps rather than clinical systems, and it passes through several organisations — agency, clinic, hotel, transfer company — before treatment happens.
This article is informational and does not constitute legal advice. It describes concepts and common practices to help you frame the right questions. It does not tell you what the law requires of your organisation. Obligations depend on your corporate structure, the countries you operate in and market to, the contracts you have signed, and how supervisory authorities interpret the rules. Verify your own position with qualified legal counsel before acting on anything here.
That said, the operational failures in this sector are rarely subtle points of legal interpretation. They are passports sitting in a shared inbox, and departed staff whose accounts still open.
Why health data is treated differently
Both the EU General Data Protection Regulation and Turkey’s Personal Data Protection Law (KVKK) place data concerning health in a special or sensitive category. In broad terms, this generally means three things.
- A narrower set of lawful bases. Ordinary personal data can be processed on a wider range of grounds. Special-category data is typically restricted to a shorter list of specific conditions, which commonly include explicit consent and grounds relating to the provision of health care.
- A higher expectation of security. Regulators generally expect measures proportionate to the risk, and the risk attached to health data is treated as high by default.
- Greater consequences when it goes wrong. Breach notification thresholds, supervisory scrutiny and penalty exposure all tend to be more serious for this category.
More of your file is health data than teams assume. Beyond medical history, test results, photographs and treatment plans, the following commonly qualify too: a procedure name attached to a named person, a WhatsApp message describing symptoms, or an appointment record with a named department. Treating the whole patient record as sensitive is usually simpler and safer than separating it item by item.
Controller or processor: establishing your role
The distinction matters because it determines who owes which duties and what contracts you need. In simplified terms:
- A controller determines the purposes and means of processing — what data is collected, why, and for how long.
- A processor processes personal data on the controller’s behalf and on the controller’s instructions.
Medical tourism arrangements rarely map onto this cleanly, and the answer depends on the facts of your particular relationships. Common patterns to examine include the following.
| Scenario | Question to resolve | Typical documentation |
|---|---|---|
| Agency acquires the lead, clinic treats | Does each decide its own purposes? | Joint controller arrangement or controller-to-controller terms |
| Clinic subcontracts marketing to an agency | Does the agency act only on instruction? | Data processing agreement |
| Agency uses a CRM to store patient files | Does the vendor process only on instruction? | Data processing agreement with the vendor |
| Interpreter or transfer partner receives details | What minimum data do they actually need? | Written terms plus data minimisation |
| Clinic shares outcomes back to the agency | Purpose and lawful basis for the return flow | Documented in the controller arrangement |
Two practical rules help. Never assume you are a processor because you feel like the junior partner: if you decide which patients to contact, what to record and how long to keep it, you are likely a controller regardless of who pays whom. And wherever data crosses an organisational boundary, there should be a written document describing the flow, its purpose, categories, recipients and retention.
Information notices and lawful basis
An information notice tells the individual who is processing their data, for what purposes, on what basis, with whom it is shared, where it goes, how long it is kept and what rights they have. Both regimes generally expect it at the point of collection, in clear language.
For medical tourism this creates a specific practical problem: the point of collection is often a Meta lead form or a WhatsApp message, not a web page with a footer. Wherever the first data capture happens, a notice needs to reach the patient there — a linked notice in the lead form, an automated first message containing a link, and the notice available in the languages of the markets you serve.
On lawful basis, one point is widely misunderstood. Consent is not the only available basis and is frequently not the most robust one: it must generally be freely given, specific, informed and unambiguous, and it can be withdrawn — awkward midway through delivering a treatment package. Where a contract with the patient exists, or processing is necessary for the provision of health care, other grounds may suit the core service better, with consent reserved for optional processing such as marketing or promotional photographs. Which basis applies to which activity is a question for counsel, not for internal debate.
A related discipline: keep marketing consent separate from service processing, record when and how it was obtained, and make withdrawal as easy as giving it.
International transfers
Medical tourism is inherently cross-border, so transfers are not an edge case. A transfer occurs whenever personal data moves to, or becomes accessible from, another country — including when a system is hosted abroad or a support team accesses it remotely.
Both regimes restrict such transfers and provide mechanisms for making them lawful; the details differ and change over time. Map your transfers first, then take advice on each. The mapping exercise is straightforward:
- List every system holding patient data and the country where it is hosted.
- List every third party that receives or can access patient data, and where they are located.
- List every location from which your own staff access the data, including remote workers and offices abroad.
- For each item, record the categories of data involved and the purpose of the flow.
- Take advice on the appropriate transfer mechanism for each, and document the outcome.
Hosting location is worth deciding deliberately rather than inheriting from a vendor default, and it is a fair question to put to any CRM supplier before signing, alongside their sub-processor list and breach notification commitments; MoonCRM sets out its position on the security page.
Retention and deletion
Indefinite retention is one of the most common findings in this sector, and it is usually caused by absence of a policy rather than by a deliberate decision. The principle in both regimes is that personal data should not be kept longer than necessary for the purposes for which it was processed, subject to other legal obligations that may require certain records to be retained.
A workable approach:
- Define periods by category, not by file. Enquiries that never converted, marketing consent records, clinical records, financial records and identity documents will not share a retention period.
- Check the mandatory floors. Medical record retention and accounting record retention are often set by other laws, and those requirements may override a shorter preference. Confirm the applicable periods with counsel for each jurisdiction you operate in.
- Delete at the narrowest level that works. Passport scans and photographs usually need to go long before the treatment record does.
- Make deletion a system function. A retention rule that depends on someone remembering to clear a folder will not be applied consistently. It needs to run automatically and leave an audit record that it ran.
- Handle backups explicitly. Deleting from the live system while a copy persists in an unmanaged backup is a common gap; backup retention should be defined and bounded.
A technical and organisational measures checklist
Both regimes expect measures appropriate to the risk. The following is a practical baseline for a medical tourism operation, not a legal standard.
Access control
- Role-based permissions so consultants see only the patients they work on, enforced by the system rather than by convention — this is the purpose of granular roles and permissions
- Named individual accounts with no shared logins
- Multi-factor authentication on all accounts with patient data access
- A documented joiner, mover and leaver process, with same-day revocation on departure
- Quarterly access review, with the list of who can see patient data actually read by a named person
Technical measures
- Encryption in transit and at rest
- Audit logging of who viewed, exported or changed a patient record, retained and reviewable
- Restrictions on bulk export, with exports logged and limited to defined roles
- Tested, access-controlled backups, with restoration tested rather than assumed
- Patching and vulnerability management on any self-hosted component
Organisational measures
- A written data inventory and processing record
- Data processing agreements with every vendor and partner that touches patient data
- Staff training at induction and annually, covering health data specifically
- An incident response procedure with named roles and awareness of the applicable notification deadlines
- A defined procedure for handling data subject requests within the applicable statutory timeframe
- A rule that patient data does not leave approved systems: no personal-device photo libraries, no personal email, no ad hoc spreadsheets
That last point is where most real exposure in this sector lives. Passport scans in a WhatsApp gallery on a personal phone, or patient lists on personal drives, are not manageable under any regime: you cannot restrict, log, delete or report on them. The structural case against spreadsheets is made in why Excel fails at patient tracking; the compliance case is that only a system with access control, logging and enforceable retention makes the checklist above achievable, which is the argument for consolidating patient data into one operational platform.
Where to start, and what to ask counsel
Starting from nothing, the sequence with the most risk reduction per hour is: map your data flows and systems; close off unmanaged storage on personal devices and spreadsheets; implement individual accounts, role-based access and multi-factor authentication; then write your retention schedule and information notices.
The questions worth taking to a qualified lawyer are these. Which regimes apply to us, given our structure and markets? Are we controller, joint controller or processor in each partner relationship? Which lawful basis applies to each processing activity, and where is consent genuinely required? What transfer mechanism suits each cross-border flow? What mandatory retention periods apply to our clinical and financial records? What are our breach notification obligations and deadlines?
None of those can be answered by an article, including this one. What an article can do is ensure you arrive at that conversation with your data flows already mapped, which makes it shorter and cheaper.