Healthcare & Health Tourism

The first decision is data classification: which field is health data and which is operational? Health data is special-category personal data with separate rules for processing, access, retention and cross-border transfer. Flights, accommodation and transfers are operational. Without this split in the data model, the whole system gets designed to the highest protection level and operations become needlessly heavy.

• Patient journey: first contact → pre-assessment → quotation → planning → treatment → post-discharge follow-up, with a defined record owner and hand-off point at each stage.
• Multilingual operation: recording the language of communication, versioning document templates per language, and showing appointments in the patient's time zone.
• Agency and commission: agency and sub-agency chains, the stage at which commission is earned, and reversal on cancellation or partial treatment.
• Document sharing: medical reports and images shared inside the system through time-limited personal links, with every access logged.
• Consent management: consent texts versioned per language, with a record of which version each patient approved.
• Interpreter planning: checking interpreter availability together with the appointment.

International patient operations use health tourism software, customer and opportunity management uses CRM, data exchange with clinical systems uses API and system integration, and patient or staff apps use mobile app development. Architectural decisions are covered in our health tourism CRM guide.

Clinical information systems, appointment and theatre scheduling, messaging and e-mail channels, payment infrastructure, e-invoicing and accounting.

In healthcare and health tourism the starting point is usually a fragmented communication stack: patient enquiries in messaging apps and e-mail, medical documents on personal devices, agency reconciliation in spreadsheets. It appears to work, but data responsibility is undefined.

The first exercise produces a personal data inventory: which data is held where, who accesses it, how long it is retained and which cross-border transfers occur. Because special categories of personal data are processed, this inventory comes before any software decision.

• Patient journey state: enquiry, pre-assessment, quote, scheduling, procedure, follow-up — each with a date and an owner.
• Document record: document type, uploader, access log and retention period; a file name alone is not enough.
• Agency and commission: agency per case, commission rate, settlement state and currency.
• Language and contact preference: the patient's language and channel consent, with marketing consent kept apart from treatment communication.
• Audit log: who accessed a medical document and when, in a form that cannot be deleted.
• Consent record: which version of which text was accepted, and when.

1. Data inventory and authority: role definitions, access scope, retention periods and consent texts.
2. Enquiry and case tracking: multilingual enquiry forms, case states and quote generation.
3. Documents and communication: secure document sharing, access logging and multi-channel history.
4. Agency and finance: commission calculation, settlement, multi-currency handling and collections.

Phase one cannot be skipped. When authority and retention rules are added later, everything accumulated until then sits outside those rules.

• Time between case states (enquiry to quote, quote to approval)
• Number of unanswered enquiries and first response time
• Case count and commission settlement state per agency
• Auditability of access records on medical documents
• Enquiry distribution by language

• Keeping medical documents in a messaging app. No access log can be produced and deletion requests cannot be honoured.
• Merging marketing consent with treatment communication. Withdrawing consent also stops clinical information.
• Not versioning consent texts. Which text was accepted cannot be proven.
• Calculating commission outside the case. Settlement and case state drift apart and reconciliation becomes manual.

Should the clinical system and CRM be separate?

Usually yes, and that is the correct separation: the clinical system holds the medical record while the CRM manages the journey and commercial process. Only necessary fields should pass between them; copying the full medical record into the CRM needlessly widens the protection obligation.

How is cross-border data transfer handled?

The legal basis, the scope of explicit consent and what happens to each data item on withdrawal must be defined in advance. This is a legal decision that the software must reflect, not a software decision.

Which measurements are meaningful?

Conversion by source (enquiry → quotation → arrival → treatment), the distribution of time to first response, cancellation reasons and the completion rate of post-discharge follow-up.

Where should the data of an international patient be held?

Data residency is both a regulatory and a contractual matter; technically, server location, backup location and sub-processor locations must each be determined separately. They need not be identical, but all three must be defined in writing. We clarify the scope with the legal side at the start of the project.

Should an agency portal see all patient data?

No. Case state, scheduling date and financial information are enough for an agency to run its commercial process; medical documents and clinical detail belong in a separate authority scope. That separation is a direct application of data minimisation.

How is multilingual content managed?

Every text field needs its own record per language, and machine translation should not be published by default. For patient information texts, translation approval is kept as a distinct step, recording which version was approved in which language.