Sağlık Turizmi Yazılımı

Sağlık turizmi operasyonu, bir hastanenin klinik bilgi sisteminden farklı bir problem çözer: satış öncesi süreç, lojistik ve çok taraflı ticari ilişki. Bu platform, hasta talebinin geldiği andan takip görüşmesine kadar olan yolculuğu tek kayıt üzerinde izler.

Sektörde en sık gördüğümüz başlangıç tablosu şudur: talepler mesajlaşma uygulamalarında ve e-postada dağınık, tıbbi belgeler kişisel cihazlarda, acente mutabakatı ayrı bir tabloda. Bu yapı çalışıyor görünür ancak üç şey ölçülemez:

• Bir talebe ne kadar sürede dönüldüğü,
• Hangi acentenin kaç vaka getirdiği ve hakedişinin durumu,
• Tıbbi bir belgeye kimin eriştiği.

Üçüncüsü yalnızca operasyonel değil, hukuki bir gerekliliktir: özel nitelikli kişisel veri işleniyorsa erişimin kayıt altında olması gerekir.

Her talep bir vaka kaydı açar. Vaka, tanımlı durumlar arasında ilerler ve her durum geçişi tarih ve sorumlu ile kaydedilir. Böylece "talepten teklife kaç gün", "teklifte onaya kaç gün" soruları rapordan yanıtlanır.

İletişim geçmişi (e-posta, mesaj, çağrı notu) vakaya bağlanır; kişiye değil kanala dağılmış bir geçmiş bırakılmaz. Tıbbi belgeler ayrı bir yetki kapsamında tutulur: ticari süreci yürüten kullanıcı vaka durumunu ve finansal bilgiyi görür, klinik belgeyi görmez.

• Talep ve vaka: çok dilli form, kanal etiketi, ön değerlendirme, teklif üretimi.
• Planlama: operasyon tarihi, konaklama, transfer ve refakatçi bilgisi.
• Belge: yükleme, sürüm, erişim kaydı ve saklama süresi.
• Acente: acente tanımı, komisyon oranı, vaka listesi, hakediş ve mutabakat.
• Finans: çoklu para birimi, tahsilat takibi, kalan bakiye.
• İletişim: dile göre şablon, izin durumu, gönderim geçmişi.

Web formu ve reklam kanalları, e-posta ve mesajlaşma kanalları, CRM süreçleri, tahsilat için banka entegrasyonu ve fintech altyapısı, muhasebe ve e-belge, hastane bilgi sistemleriyle veri alışverişi için API entegrasyonu.

• Rol bazlı yetkinin yanı sıra veri kapsamı: acente yalnızca kendi vakalarını görür.
• Tıbbi belge erişimi ayrı yetki ve silinemez erişim kaydı ile korunur.
• Pazarlama izni ile tedavi bilgilendirmesi ayrı izinlerdir; biri geri çekildiğinde diğeri durmaz.
• Rıza metinleri sürümlenir; hangi sürüme onay verildiği kaydedilir.
• Saklama süresi kayıt türüne göre tanımlanır ve süre dolduğunda uygulanır.

Veri yerleşimi: Sunucu, yedek ve alt işleyici konumlarının her biri ayrı ayrı belirlenir ve yazılı olarak tanımlanır. Bu kapsam proje başında hukuk tarafıyla birlikte netleştirilir.

• Klinik / hastane uluslararası hasta birimi: talep havuzu, teklif ve planlama.
• Aracı kurum: çoklu klinik, acente ağı ve komisyon yönetimi.
• Tek branş merkezi: dar tanımlı işlem seti, standart teklif şablonları.

1. Veri envanteri ve yetki: roller, erişim kapsamı, saklama süreleri, rıza metinleri.
2. Talep ve vaka takibi: kanallar, durumlar, teklif üretimi.
3. Belge ve iletişim: güvenli paylaşım, erişim kaydı, çok dilli şablonlar.
4. Acente ve finans: komisyon, hakediş, çoklu para birimi.

Birinci faz atlanmaz: yetki ve saklama kuralları sonradan eklendiğinde o tarihe kadar biriken veri kural dışı kalır.

Bu bir hastane bilgi yönetim sistemi (HBYS) yerine geçer mi?

Hayır. Klinik kayıt, tetkik ve reçete tarafı HBYS'nin işidir. Bu platform, satış öncesi süreç, lojistik ve ticari ilişki tarafını yönetir ve gerektiğinde HBYS ile veri alışverişi yapar.

Acente portalı hasta verisinin tamamını görmeli mi?

Görmemeli. Ticari süreci yürütmek için vaka durumu, planlama tarihi ve finansal bilgi yeterlidir. Tıbbi belge ve klinik detay ayrı yetki kapsamındadır.

Çok dilli içerik nasıl yönetiliyor?

Her metin alanının dil başına ayrı kaydı vardır. Hasta bilgilendirme metinlerinde çeviri onayı ayrı bir adımdır ve hangi sürümün hangi dilde onaylandığı kaydedilir.

Silme talebi geldiğinde ne oluyor?

Kayıt türüne göre silme veya anonimleştirme uygulanır; finansal kayıt gibi saklama yükümlülüğü olan veriler ayrı ele alınır. Bu ayrımın hangi kayıt için nasıl işleyeceği devreye alma öncesinde tanımlanır.