Clinic and Dental Websites: Appointments, Health Data and Secure Information

Your clinic’s website should help visitors identify the right practice, find approved health information and understand the status of an appointment request. Its design also needs operational answers: who receives a request, is the displayed time genuinely available, where are uploaded images stored, and who reads messages outside opening hours? A prominent booking button can create false expectations if the underlying workflow has not been defined.

1. Plan around current healthcare publishing requirements

The regulation dated 12 November 2025 prohibits healthcare advertising while defining permitted information. This includes addresses, opening hours, verified professional details and health-protective information. Prices/campaigns and search-engine use are regulated too. Websites must show the information’s update date and contact details for the editor. Do not rely solely on an old guide to the 2023 framework.

For dentistry, assess TDB’s publishing guidance of 4 March 2026 as well. It addresses misleading superiority claims, price competition and presenting certificates as statutory specialist qualifications. It calls for clear information that published material does not replace examination and diagnosis. Assign a clinical content owner; do not automatically publish unreviewed health copy.

This article is on TankDev’s website explaining our software service. Do not copy its software package card or development enquiry invitation directly into a clinic’s healthcare information pages. Before designing, establish an approved information inventory consistent with the organisation’s licence and actual staff. A general commercial template is not evidence that every available section is appropriate for healthcare use.

2. Structure pages around real information needs

A manageable starting structure can cover the organisation and clinicians, approved service information, opening hours, directions, contact and necessary data-processing explanations. Use the organisation’s actual registered identity and facility classification rather than choosing a more impressive description. When a clinician leaves, update their biography, availability and affected pages together.

Do not assess an information page by the volume of sales copy it contains. Approved information should help a visitor understand the general scope, who carries out assessment and that an individual plan may depend on examination. Before generating numerous near-identical location pages, establish whether they represent genuinely different addresses or information. Translated names and qualifications must describe the same underlying facts.

• Clinician record: approved identity/title, current role, authorised information area and content approver.
• Organisation record: actual name, address, contact details, hours and access/directions.
• Information record: source, clinical review, update date and withdrawal process.
• Appointment record: request status, responsible team and the explanation shown to the visitor.

3. Separate requests, confirmed appointments and treatment plans

If a form only requests a callback, explain that the selected time is a preference rather than a confirmed appointment. If real-time scheduling is included, define which system authorises confirmation. Where the clinic’s existing software is the authoritative calendar, the website should not create a second independent source of truth. Two interfaces showing the same time as free do not prove that a booking can be accepted.

In an illustrative dental practice, clinician, dental unit and visit duration may all affect scheduling. Some visits also need equipment or preparation buffers; the clinic sets these rules. A developer should not give every visit the same duration or infer a treatment plan from the first message. A human-confirmed request workflow may be a more manageable initial scope than an unverified promise of immediate confirmed booking.

Acceptance criteria should cover repeated clicks, record-status lookup after a network interruption and cancellation reaching the calendar. Even a confirmed appointment is not a guarantee of treatment suitability or outcome. Clinical assessment remains with the authorised healthcare team. Do not imply that an unattended form is continuously monitored; show the practice’s approved explanation of urgent contact routes.

4. Minimise health information in the first form

KVKK classifies health data as special-category personal data; processing requires a statutory condition and appropriate additional measures. We therefore do not treat collecting an X-ray, medicine list, identity document or full medical history from every appointment requester as a default design. The clinic must determine what information is needed and why.

Our suggested initial form starts with limited information needed for a reply. Where a free-text field exists, the practice can approve wording discouraging unnecessary medical detail. If images, reports or a patient file are actually required, scope a separate channel with identity and permission checks. Filenames and private links should not flow into general visitor analytics.

KVKK’s announcement concerning principle decision 2026/347 explains the separation of privacy information and explicit consent, and that an additional consent text should not be presented for processing based on another statutory condition. Do not resolve every form with one compulsory “I accept KVKK” box. Contact requests, clinical informed consent, image publication and marketing permission are different activities: determine the applicable text and legal basis for each.

5. Separate patient files, notifications and analytics

An unpredictable file URL is not sufficient access control. Private documents belong outside public folders, with a permission check for the patient and document at download time. Reception staff’s scheduling access does not necessarily require access to the full clinical record. Technical-support permissions should also have a defined purpose and duration.

• Administration: individual accounts, multi-factor authentication, role-limited permissions and revocation when staff leave.
• Files if included: private storage, authorised/time-limited access, size/type limits and malicious-upload checks.
• Notifications: minimum necessary information rather than diagnoses or procedure details; consider shared phones and lock-screen previews.
• Logs and measurement: keep form contents out of URLs, analytics events, error logs and advertising systems.
• Operations: retention/deletion plans, restricted backups, restore exercises and an incident owner.

Maps, embedded videos, live support and analytics are also part of the data flow. A server located in Turkey does not prevent a browser from sending information to another provider. Inventory who receives what; the practice assesses transfers and retention. Our suggested operational measurements track aggregate errors and response times without sending unnecessary details revealing a person’s health interests to a measurement provider.

6. Patient-image publication needs more than a permission box

The Ministry of Health FAQ does not impose a blanket ban on before/after images; it sets multiple conditions. Image consent, withdrawal, matching recording conditions and dates, restrictions on technological alteration, required warnings and user interactions need joint assessment. Do not automatically enable a gallery on the strength of one consent box; publish no patient images until the authorised team has assessed all conditions.

In software, link an image to its publication review: approver, permission scope, publication locations and withdrawal state. When removal is requested, address thumbnails, caches and other published copies rather than deleting only the original file. Sending a real patient’s face or dental image to a generative model for a design experiment is not a default development activity.

This guide uses no real patient images, success rates, patient testimonials or invented clinic references. Its scheduling and acceptance scenarios are illustrative. TankDev’s description of its software service does not establish clinical outcomes for your practice.

7. Establish calendar ownership before integrating clinic software

Do not promise full integration before checking the existing patient-management provider’s API permissions, contract and supported operations. Reading available times, forwarding a request, confirming a booking and cancelling it are separate permissions. Consider a connection limited to necessary information instead of copying the entire clinical history into the website. Our API and system integration guide explains data ownership and engineering failure handling.

Consider an illustrative failure: the clinic system saves an appointment, but its reply never reaches the website. Blindly repeating the operation can create duplicates. Define operation identifiers, status lookup, repeat-submission controls and a queue for staff to resolve uncertain outcomes. Failure to send an SMS and failure to create a booking are different events; the panel should distinguish them.

8. Technical publishing, languages and accurate AI identity

Technical delivery should make approved information readable at the correct URL, remove obsolete clinician details, preserve language pairs and keep private patient pages out of public indexes. Do not introduce qualifications or services into machine-readable code that are absent from approved visible content. Structured data should match actual information, with no invented ratings or treatment outcomes.

Our technical SEO/GEO guide explains URL, crawl and language issues. Do not transfer general business-marketing recommendations automatically into healthcare. Our Turkish lawyer website guide also separates technical delivery from professional publishing review; healthcare requirements need their own assessment.

An English page does not by itself authorise international health-tourism activity. Article 8 of the regulation sets separate conditions for authorised international health tourism. If relevant, the organisation should assess authorisation, audience and a separate publishing structure. Translating domestic pages does not automatically place them under a different promotional regime.

An assistant showing an obsolete clinic address is an information-accuracy problem; checking approved identity records may help. It does not guarantee recommendations or increased patient numbers. A chat interface should not automatically diagnose, select an individual’s treatment or rule out medical urgency. Start with approved administrative information and human handover; sending health documents to a model requires separate assessment.

9. TankDev clinic and dental website packages

TankDev develops custom-coded, mobile-friendly websites for clinics and dental practices. We scope approved content, manageable contact workflows and accurate technical publishing. The amounts below are starting prices for our software offer, not healthcare prices or treatment promotions. Purchasing a package does not purchase clinical approval or a guarantee of regulatory compliance.

Compare current packages. The Turkish software offer starts at TRY 50,000 for Essential and TRY 150,000 for Advanced; these are separate market offers, not currency conversions. Agree modules, provider permissions, languages and page volume. Describe your clinic website requirements; no patient file or X-ray is needed for the initial discussion.

10. Accept a working appointment workflow

In an illustrative acceptance exercise, two people choose the same time and the authoritative calendar’s conflict handling is examined. Then interrupt the connection, repeat a request and query its status. Test cancellation, notification failure and an attempt to access another user’s document separately. A green success message alone does not prove that all these workflows operate correctly.

• Content: named approver, update date, actual identity and equivalent translations.
• Appointments: request/confirmation distinction, conflicts, repeat submission, cancellation and delivery status.
• Data: minimum fields, permissions, provider flows, retention and restoration.
• Handover: domain/account ownership, source delivery, update owner and support boundaries.

In operation, first monitor lost requests, failed notifications and records awaiting a response. A page visit, phone-button click, appointment request, confirmed booking and attended appointment are different measurements. Do not add them together as one success total. Decide what question a metric answers without unnecessarily collecting health information.

Sources and scope

Primary sources and package fields were checked on 8 November 2026. Scheduling and acceptance scenarios are illustrative, not patient outcomes or evidence of a deployed clinic integration. Facility type, authorisation, systems and current requirements need assessment for the actual project.

• Ministry of Health — 2025 information/promotion regulation
• Ministry of Health — Regulation FAQ
• TDB — Publishing guidance of 4 March 2026
• KVKK — Special-category personal data
• KVKK — Principle decision 2026/347 announcement