Hastanelerde Hasta Talep Yönetimi: KVKK'yı Bozmadan Tek Havuz Kurmak
Kısa cevap: Sağlık kuruluşlarında hasta talepleri santral, WhatsApp, e-posta ve web formu arasında dağıldığı için kaybolmaz; izi kaybolur. Çözüm, tüm kanalları tek talep havuzunda toplamak, yetkiyi rol + departman + kayıt sahipliği birleşimiyle vermek ve veriyi değiştiren her işlemi sonradan düzenlenemeyen bir kayda yazmaktır. Böylece hem yanıt süresi ölçülebilir hem de erişim denetlenebilir hale gelir.
Bir hastanenin destek yükü tek bir yerden gelmez. Randevu değişikliği santrale telefonla, fatura itirazı muhasebeye e-postayla, sonuç sorgusu kliniğin WhatsApp hattına, anlaşmalı kurumun provizyon sorusu bir müşteri temsilcisinin kişisel gelen kutusuna düşer. Her biri kendi içinde çözülür, ama hiçbiri aynı yerde görünmez.
Ve sağlıkta bu dağınıklığın bedeli, diğer sektörlerden farklıdır: taleplerin içeriği çoğu zaman özel nitelikli kişisel veridir.
Tipik bir gün neye benziyor?
- Hasta yakını sabah santrali arar, öğleden sonra aynı konuyu WhatsApp'tan yazar. İki farklı
temsilci, birbirinden habersiz, iki farklı cevap verir.
- Anlaşmalı kurumun İK birimi bir çalışan için rapor talebi gönderir. Talebi alan temsilci
izne çıkar; talep onun gelen kutusunda kalır.
- Bir şikayet üst yönetime taşınır. "Bu talep ne zaman geldi, kim baktı, ne cevap verildi?"
sorusunun yanıtı üç ayrı ekranı ve bir telefon turunu gerektirir.
Bunların hiçbiri kötü niyetten doğmuyor. Kanal sayısı arttıkça, kanal başına ayrı bir hafıza tutmak imkansız hale geliyor.
Sağlıkta işi ayrıştıran şey: veri hassasiyeti
Bir hasta "geçen haftaki tetkik sonucum" yazdığı anda, o mesaj artık sıradan bir müşteri talebi değildir. Bu üç şeyi zorunlu kılar:
- Kimin neyi göreceği kesin çizilmeli. Muhasebeden bir kullanıcı, fatura talebine
bakarken hastanın klinik yazışmasını görmemeli.
- Kimin neye baktığı kaydedilmeli. Erişimin kendisi de denetlenecek bir olaydır.
- Verinin nerede durduğu bilinmeli. Kurum politikanız veriyi dışarı çıkarmıyorsa,
platform kendi sunucunuzda da çalışabilmeli.
Yetki matrisi: "yönetici/kullanıcı" ikilisi sağlıkta yetmez
Tixenta'da yetki; rol, organizasyon, departman ve kayıt sahipliğinin birleşimiyle verilir (RBAC + ABAC). Pratikte kurabileceğiniz tabloya benzer:
| Kullanıcı | Görmesi gereken | Görmemesi gereken |
|---|---|---|
| Çağrı merkezi temsilcisi | Randevu ve genel bilgi talepleri | Klinik yazışma, fatura detayı |
| Muhasebe kullanıcısı | Kendi departmanına atanmış fatura talepleri | Tetkik/sonuç içerikli talepler |
| Klinik sekreteri | Kendi kliniğinin talepleri | Diğer kliniklerin kayıtları |
| Kurumsal müşteri temsilcisi | Anlaşmalı kurum talepleri | Bireysel hasta yazışmaları |
| Kalite/denetim | İşlem kayıtları ve süre raporları | Serbest içerik erişimi gerekmez |
Kritik nokta şu: yetki bir "gizleme" değil, erişimin hiç oluşmaması. Klinik yazışma o kullanıcının ekranına gelmez.
"En kısa sürede dönülecek" bir taahhüt değildir
Anlaşmalı kurumlarla imzalanan hizmet seviyesi taahhütleri, ancak ölçülüyorsa taahhüttür. Tixenta ilk yanıt ve çözüm sürelerini sayaçla izler; süre dolmadan önce uyarı, aşıldığında anlık alarm üretir. Çeyrek sonunda "genelde hızlı dönüyoruz" demek yerine hangi talebin ne kadar beklediğini gösterirsiniz.
Hastaya üyelik açtırmayın
Portal üyeliği zorlamak talebi öldürür; hasta yakını parola sıfırlamakla uğraşmaz, telefona sarılır. Tixenta'da üyeliksiz talep akışı vardır: hasta e-posta ve takip kodu ile talep açar, aynı kodla durumu izler; akış spam ve bot korumalıdır. Talep sisteme girer, santral trafiği azalır.
Zincir hastane ve poliklinik ağları
Grup bünyesindeki ayrı tüzel kişilikler için ayrı kurulum gerekmez. Tixenta tek adres altında birden fazla organizasyonu barındırır ve her organizasyonun verisini diğerlerinden yalıtır. Merkez konsolide görüntüyü alır; tesisler birbirinin verisini görmez.
5 adımda başlangıç
- Son 30 günün taleplerini kanal kanal sayın; kaçının bir sistemde kayıtlı olduğunu bulun.
- Yukarıdaki yetki matrisini kendi birimlerinizle doldurun.
- Talep tiplerini adlandırın (randevu, fatura, sonuç, şikayet, kurumsal) ve her birine hedef
yanıt süresi koyun.
- Üyeliksiz talep akışını web sitenizde tek bir görünür bağlantıya bağlayın.
- Kurulum yerini (bulut / kendi sunucunuz) bilgi işlem ve hukuk birimiyle birlikte karara
bağlayın.
Sık sorulan sorular
Hastane için ayrı bir çağrı merkezi yazılımı mı gerekir? Çoğu durumda hayır. Asıl ihtiyaç, kanaldan bağımsız tek bir talep havuzu ve o havuz üzerinde çalışan yetki + süre + kayıt katmanıdır. Telefon zaten bir kanaldır; kaydı sisteme düşürmek yeterlidir.
KVKK açısından en kritik başlık hangisi? Erişim sınırlaması ve izlenebilirlik. "Kimin görmemesi gerektiği" teknik olarak uygulanmıyorsa, politika metni tek başına bir savunma değildir.
Veri kurum dışına çıkmasın istiyoruz, mümkün mü? Evet. Tixenta bulut hizmeti olarak da (SaaS), kendi sunucunuzda da (on-premise) çalışır.
Mevcut HBYS ile birlikte çalışır mı? Tixenta'nın OpenAPI 3.1 uyumlu arayüzü, yetkisi sınırlanabilen API anahtarları ve olay bildirimleri (webhook) vardır; talep açma ve durum güncelleme akışları bağlanabilir.
İlgili içerikler
- Tixenta özellikleri: dokuz yeteneğin ayrıntısı
- Karşılaştırma: alternatiflerle satır satır fark
- Demo talep edin: kendi akışınızla deneyin
Tixenta, müşteri destek taleplerinin yönetimi ile şirket içi anlık ekip sohbetini tek adres altında birleştiren, Türkiye merkezli ve KVKK uyumlu kurumsal destek platformudur.