Klinik ve Diş Hekimi Web Sitesi: Randevu, KVKK ve Güvenli Bilgilendirme

Kliniğinizin web sitesi, ziyaretçinin doğru hekimi ve adresi bulduğu, onaylı sağlık bilgisine eriştiği ve randevu talebinin ne durumda olduğunu anlayabildiği bir hizmet noktasıdır. Güzel bir tasarımın yanında cevaplanması gereken operasyon soruları vardır: Talep kime düşüyor? Takvimde görünen saat gerçekten uygun mu? Çekilen röntgen hangi sistemde tutuluyor? Mesai dışında gönderilen mesajı kim görecek? Bu sorular çözülmeden eklenen bir “hemen randevu” düğmesi beklentiyle gerçek işleyişi birbirinden uzaklaştırabilir.

1. Sağlık web sitesini güncel yayın kurallarına göre planlayın

12 Kasım 2025 tarihli yönetmelik, sağlıkta reklamı yasaklarken bilgilendirme sınırlarını düzenler. Adres, çalışma saatleri, doğrulanmış mesleki bilgiler ve sağlığı koruyucu içerikler bu çerçevededir. Ücret/kampanya anlatımı ve arama motoru kullanımı da kurallara tabidir. Web bilgisinin güncelleme tarihi ve editöre ulaşılabilecek iletişim bilgileri görünür olmalıdır. Eski bir 2023 rehberini tek dayanak olarak kullanmayın.

Diş hekimliği tarafında TDB’nin 4 Mart 2026 tarihli yayın kılavuzunu da değerlendirin. Kılavuz; yanıltıcı üstünlük anlatımı, ücretle rekabet ve sertifikayı yasal uzmanlık gibi sunma konusunda sınırlar içerir. Bilgilendirmenin muayene ve tanı yerine geçmediğinin açıkça belirtilmesini ister. Sitenin içerik sorumlusunu belirleyin; klinik onayı olmadan otomatik sağlık metni yayımlamayın.

Bu yazı TankDev’in kendi yazılım hizmetini açıklayan sayfasıdır. Buradaki paket kartını veya yazılım teklifi çağrısını kliniğinizin sağlık hizmeti sayfasına aynen kopyalamayın. Tasarım öncesinde kuruluşun ruhsatına ve gerçek kadrosuna uygun, sorumlu hekim tarafından onaylanmış bilgi envanteri hazırlayın. Genel bir ticaret sitesi şablonundaki her bölüm sağlık kuruluşuna uygun değildir.

2. Sayfa yapısını hasta yolculuğundaki gerçek sorulara bağlayın

Başlangıçta kuruluş ve hekim bilgileri, onaylı hizmet bilgilendirmeleri, çalışma saatleri, ulaşım, iletişim ve gerekli veri işleme açıklamaları yeterli bir iskelet oluşturabilir. Diş hekimliği kuruluşunda muayenehane, poliklinik veya merkez adlandırmasını keyfî seçmeyin; resmî kimlikle eşleştirin. Hekim ayrıldığında biyografisi, çalışma takvimi ve ilgili sayfaların birlikte güncellenmesini sağlayın.

Bir hizmet sayfasını satış metni hacmiyle değerlendirmeyin. Onaylı içeriğin amacı ziyaretçinin hizmetin genel kapsamını, değerlendirmenin kim tarafından yapılacağını ve kişiye özel planın muayeneden sonra belirlenebileceğini anlamasıdır. Aynı metne onlarca ilçe adı ekleyerek sayfa çoğaltmak yerine, gerçekten ayrı bir adres veya hizmet bilgisi olup olmadığını kontrol edin. İsimlendirmeler ve mesleki unvanlar çeviride de aynı gerçeği anlatsın.

• Hekim kaydı: onaylı ad/unvan, görev durumu, yetkili olduğu bilgi alanı ve yayın onay sorumlusu.
• Kuruluş kaydı: gerçek ad, adres, iletişim, çalışma saatleri ve erişim/ulaşım bilgisi.
• Bilgilendirme kaydı: kaynak, hekim incelemesi, güncelleme tarihi ve yayından kaldırma akışı.
• Randevu kaydı: talebin durumu, sorumlu ekip ve ziyaretçiye gösterilecek açıklama.

3. Randevu talebi, kesinleşmiş randevu ve tedavi planı farklı kayıtlardır

Sadece geri arama talebi alan bir form kullanıyorsanız bunu açıkça yazın: seçilen saat tercih olabilir, kesin randevu olmayabilir. Gerçek zamanlı takvim sunulacaksa onayın hangi sistemde verildiğini belirleyin. Klinik personelinin kullandığı mevcut yazılım esas takvimse web sitesi ikinci ve bağımsız bir takvim oluşturmamalıdır. İki ekranda aynı saatin boş görünmesi tek başına uygunluk kanıtı değildir.

Temsili bir diş kliniğinde hekim, ünit ve işlem süresi birlikte planlanır. Bazı ziyaretlerde ekipman veya hazırlık aralığı da gerekebilir; süre ve kaynak kurallarını klinik belirler. Web geliştiricisi bütün işlemlere aynı süreyi atamamalı veya ilk mesajdan tedavi planı çıkarmamalıdır. Başlangıçta bir insanın teyit ettiği talep akışı, doğrulanmamış “anında kesin rezervasyon” iddiasından daha yönetilebilir olabilir.

Tekrar tıklamada aynı talebin iki kez açılmaması, ağ kesilince kaydın durumunun sorgulanması ve iptalin takvime yansıması kabul kriterleri olsun. Randevu onayı bile tıbbi işlemin uygunluğunu veya tedavi sonucunu garanti etmez. Sağlık değerlendirmesi yetkili klinik ekibinin sorumluluğundadır. Mesai dışı formun sürekli izlendiği izlenimi yaratmayın; kliniğin onayladığı acil başvuru açıklamasını görünür tutun.

4. İlk formda sağlık verisini gereksiz yere toplamayın

KVKK, sağlık verilerini özel nitelikli kişisel veriler arasında sayar; işlenmeleri kanundaki şartlara ve yeterli önlemlere tabidir. Bu yüzden bir randevu tercihi almak için herkesten röntgen, ilaç listesi, kimlik belgesi veya ayrıntılı sağlık öyküsü istemeyi varsayılan tasarım kabul etmiyoruz. Hangi verinin hangi amaçla gerektiğini klinik belirlemelidir.

Önerdiğimiz ilk temas formu, geri dönüş için gerekli sınırlı alanlarla başlar. Serbest açıklama alanında gereksiz sağlık ayrıntısı paylaşılmamasını isteyen, klinik tarafından onaylı bir yönlendirme bulunabilir. Hasta dosyası, görüntü veya rapor gerçekten gerekiyorsa kimlik ve yetki doğrulaması yapılan ayrı bir kanal kapsamlandırılır. Gönderilen belgenin dosya adı veya bağlantısı genel ziyaretçi analizine taşınmaz.

KVKK’nın 2026/347 sayılı ilke kararı duyurusu, aydınlatma ile açık rızanın ayrı düzenlenmesini açıklar; başka işleme şartına dayanılan faaliyette ayrıca açık rıza metni sunulmamasını belirtir. Her formu tek bir zorunlu “KVKK kabulü” kutusuyla çözmeye çalışmayın. İletişim talebi, tıbbi işlem onamı, görsel yayını ve pazarlama izni aynı işlem değildir; uygulanacak metin ve hukuki sebebi ilgili faaliyet için belirleyin.

5. Hasta dosyasını, bildirimleri ve analiz araçlarını ayırın

Bir dosyanın zor tahmin edilen bağlantıda durması yeterli erişim kontrolü değildir. Özel belgeler public klasöründe tutulmamalı; indirme anında kullanıcının o hastaya ve belgeye yetkisi denetlenmelidir. Resepsiyonun ihtiyaç duyduğu randevu bilgisi ile klinik ekibinin erişeceği sağlık dosyası aynı yetki grubunda olmak zorunda değildir. Teknik destek erişimini de görev ve süreyle sınırlandırın.

• Yönetim: kişiye özel hesap, çok faktörlü doğrulama, rol bazlı yetki ve ayrılan çalışanın erişiminin iptali.
• Dosya varsa: özel depolama, süreli/yetkili erişim, yükleme boyut/tür sınırı ve zararlı dosya kontrolü.
• Bildirim: SMS/e-posta içinde tanı veya işlem ayrıntısı yerine gerekli asgari bilgi; kilit ekranı ve paylaşılan telefon ihtimalini düşünme.
• Kayıtlar: form içeriğini URL’ye, analitik olayına, hata loguna veya reklam sistemine yazmama.
• İşletim: saklama ve silme planı, yedek erişimi, geri yükleme denemesi ve olay bildirim sorumlusu.

Formun yanında görünen harita, video, canlı destek ve analiz bileşenleri de veri akışının parçasıdır. Sunucunun Türkiye’de olması, tarayıcıdan dış servise giden bilgiyi ortadan kaldırmaz. Hangi sağlayıcının ne aldığını çıkarın; aktarım ve saklama değerlendirmesini klinik yapsın. Önerdiğimiz teknik ölçümde toplam hata ve yanıt süreleri izlenir; kişinin sağlık ilgisini açığa çıkaran ayrıntılar ölçüm sağlayıcısına gönderilmez.

6. Hasta görsellerinde “izin var” tek başına yeterli değildir

Sağlık Bakanlığının SSS belgesi, öncesi/sonrası paylaşımını bütünüyle yasak saymaz; çok sayıda koşula bağlar. Görsel onamı, geri çekme, aynı çekim koşulları ve tarihler, teknolojik değişiklik yasağı, gerekli uyarılar ve kullanıcı etkileşimleri birlikte değerlendirilmelidir. Yalnız bir onam kutusuna dayanarak otomatik galeri açmayın; tüm şartlar yetkili ekipçe incelenmeden hasta görseli yayımlamayın.

Yazılım açısından önerdiğimiz kayıt, görselin kendisiyle yayın değerlendirmesini birbirine bağlar: onaylayan kişi, izin kapsamı, yayın yeri ve kaldırma durumu. Geri çekme geldiğinde ana görseli silmekle yetinmeyin; küçük resim, önbellek ve yayınlanan diğer kopyaları da yönetin. Yeni bir tasarım denemesi için gerçek hastanın yüzünü veya diş görüntüsünü üretken yapay zekâya göndermeyi varsayılan geliştirme işlemi saymayın.

Bu rehberde gerçek hasta görseli, başarı oranı, hasta yorumu veya hayalî klinik referansı kullanmıyoruz. Örnek randevu akışı ve aşağıdaki testler temsilidir. TankDev’in kendi yazılım hizmetini anlatması, kliniğiniz adına hasta sonucu iddiası ürettiği anlamına gelmez.

7. Klinik yazılımı entegrasyonunda takvimin sahibini belirleyin

Mevcut hasta yönetim yazılımının API izni, sağlayıcı sözleşmesi ve sunduğu işlemler incelenmeden “tam entegrasyon” sözü vermeyin. Sadece uygun saat okuma, talep iletme, kesin randevu oluşturma ve iptal farklı yetkilerdir. Web sitesine bütün hasta geçmişini kopyalamak yerine iş için gerekli veriyle sınırlı bir bağlantı değerlendirin. API ve sistem entegrasyonu rehberimiz, veri sahipliği ve hata yönetiminin teknik tarafını açıklar.

Temsili hata senaryosu: klinik yazılımı randevuyu kaydetti, fakat yanıt web sitesine ulaşmadı. Aynı işlemi körlemesine tekrar göndermek çift kayıt oluşturabilir. İşlem kimliğiyle durum sorgulama, tekrar gönderim denetimi ve personelin çözeceği belirsiz durum kuyruğu tanımlayın. SMS’in gönderilememesi ile randevunun oluşmaması farklı hatalardır; panel bunları ayrı göstermelidir.

8. Teknik SEO, çok dillilik ve yapay zekâda doğru kimlik

Teknik teslimatın hedefi; onaylı bilginin doğru adreste okunabilmesi, eski hekim bilgisinin kaldırılması, dil eşlerinin tutarlı olması ve özel hasta sayfalarının kamuya açık dizine girmemesidir. İçerikte bulunmayan unvanı veya hizmeti arama motoruna yönelik kodda da üretmeyin. Yapılandırılmış veriyi görünür ve onaylı kuruluş bilgileriyle eşleştirin; uydurma değerlendirme puanı veya tedavi sonucu eklemeyin.

Teknik SEO/GEO rehberimiz adres, tarama ve dil sorunlarını açıklar. Genel işletme pazarlaması önerilerini sağlık kuruluşuna otomatik taşımayın. Avukat web sitesi rehberinde de düzenlenmiş bir meslekte teknik teslimat ile mesleki yayın değerlendirmesini ayırıyoruz; sağlık sektörünün kuralları ayrıca incelenmelidir.

İngilizce sayfa açılması tek başına sağlık turizmi yetkisi vermez. Yönetmelik madde 8, yetki belgeli uluslararası sağlık turizmini ayrı koşullarla düzenler. Bu kapsam düşünülüyorsa yetki, hedef kitle ve ayrı yayın yapısı kuruluşça değerlendirilmelidir. Türkçe içeriği çevirip farklı bir reklam rejimine geçtiğinizi varsaymayın.

Bir asistanın kliniğin eski adresini göstermesi bilgi doğruluğu problemidir; kimlik kayıtlarını incelemek anlamlı olabilir. Bundan önerilme veya hasta artışı garantisi çıkmaz. Sohbet kutusu da otomatik tanı koymamalı, kişiye tedavi seçmemeli veya tıbbi aciliyeti dışlamamalıdır. Başlangıç kapsamını onaylı idarî bilgiler ve insan ekibe aktarım üzerinden kurun; sağlık belgelerini modele gönderme ayrı bir değerlendirme gerektirir.

9. TankDev klinik ve diş hekimi web sitesi paketleri

TankDev olarak klinikler ve diş hekimleri için özel kodlanan, mobil uyumlu web siteleri geliştiriyoruz. Onaylı içerik, yönetilebilir iletişim ve doğru teknik yayın altyapısı üzerine kapsam oluşturuyoruz. Aşağıdaki tutarlar yazılım teklifimizin başlangıç bedelleridir; sağlık hizmetine ait ücret veya kampanya değildir. Paket satın almak tıbbi içerik onayı ya da mevzuata uygunluk garantisi sağlamaz.

Güncel paketleri karşılaştırın. İngilizce yazılım teklifinde Essential $1,000, Advanced $3,000 başlangıç bedelindedir; ayrı pazar teklifleridir, kur dönüşümü değildir. Gerekli modülleri, sağlayıcı izinlerini, dil ve sayfa sayısını görüşerek netleştirin. Kliniğinizin web sitesi ihtiyacını anlatın; ilk görüşme için hasta dosyası veya röntgen paylaşmanız gerekmez.

10. Teslimatı çalışan randevu akışıyla değerlendirin

Temsili kabul testinde iki kişi aynı saati seçer; yetkili takvimin çakışmayı nasıl çözdüğü incelenir. Ardından bağlantı kesilir, aynı talep tekrar gönderilir ve durum sorgulanır. İptal, bildirim hatası ve farklı kullanıcının belgeye erişim denemesi ayrı ayrı denenir. Yalnız formun yeşil bir mesaj göstermesi bütün bu akışların çalıştığı anlamına gelmez.

• İçerik: onay sorumlusu, güncelleme tarihi, gerçek kimlik ve çeviri eşleşmesi.
• Randevu: talep/onay ayrımı, çakışma, tekrar gönderim, iptal ve bildirim durumu.
• Veri: asgari alanlar, yetki, dış servis akışı, saklama ve geri yükleme.
• Teslim: alan adı/hesap sahipliği, kaynak devri, güncelleme sorumlusu ve destek sınırı.

İşletimde önce kaybolan talepleri, başarısız bildirimleri ve yanıt bekleyen kayıtları izleyin. Ziyaret, telefon düğmesine tıklama, randevu talebi, onaylı randevu ve gerçekleşen ziyaret farklı ölçümlerdir. Bunları aynı başarı sayısı gibi toplamayın; izleme tasarımında sağlık verisini gereksiz toplamadan hangi soruya cevap arandığını belirleyin.

Kaynaklar ve kapsam

Birincil kaynaklar ve paket alanları 8 Kasım 2026’da kontrol edildi. Randevu ve kabul senaryoları temsilidir; hasta sonucu veya çalışan bir klinik entegrasyonu örneği değildir. Klinik türü, yetki, kullanılan sistemler ve güncel kurallar için somut değerlendirme gerekir.

• Sağlık Bakanlığı — 2025 Tanıtım ve Bilgilendirme Yönetmeliği
• Sağlık Bakanlığı — Yönetmelik SSS
• TDB — 4 Mart 2026 yayın kılavuzu
• KVKK — Özel nitelikli kişisel veriler
• KVKK — 2026/347 ilke kararı duyurusu