Sağlıkta yazılımın ilk tasarım kararı
İlk karar veri sınıflandırmasıdır: hangi alan sağlık verisi, hangisi operasyonel veridir? Sağlık verisi özel nitelikli kişisel veri kapsamındadır; işlenmesi, erişimi, saklanması ve yurt dışına aktarımı ayrı kurallara tabidir. Uçuş, konaklama ve transfer ise operasyonel veridir. Bu ayrım veri modeline yazılmazsa tüm sistem en yüksek koruma seviyesine göre kurgulanır ve operasyon gereksiz ağırlaşır.
Kritik süreçler
- Hasta yolculuğu: İlk temas → ön değerlendirme → teklif → planlama → tedavi → taburculuk sonrası takip; her aşamada kayıt sahibi ve devir anı tanımlı olmalıdır.
- Çok dillilik: İletişim dilinin kayıtta tutulması, belge şablonlarının dil bazlı sürümlenmesi, hastanın saat dilimine göre randevu gösterimi.
- Acente ve komisyon: Acente/alt acente zinciri, komisyonun hangi aşamada hak edildiği, iptal ve kısmi tedavide geri alınması.
- Belge paylaşımı: Tıbbi rapor ve görüntülerin sistem içinde, süreli ve kişiye özel bağlantıyla paylaşılması; her erişimin kaydı.
- Rıza yönetimi: Rıza metinlerinin dil bazlı sürümlenmesi ve hangi hastanın hangi sürümü onayladığının kaydı.
- Tercüman planlama: Randevuyla birlikte tercüman müsaitliğinin kontrol edilmesi.
Hangi çözüm neye karşılık geliyor?
Uluslararası hasta operasyonu için [sağlık turizmi yazılımı](/urunler/saglik-turizmi), müşteri ve fırsat yönetimi için [CRM](/urunler/crm), klinik sistemleriyle veri alışverişi için [API ve sistem entegrasyonu](/cozumler/api-entegrasyonu), hasta ve personel uygulamaları için [mobil uygulama geliştirme](/cozumler/mobil-uygulama-gelistirme) kullanılır. Mimari kararları [sağlık turizminde CRM mimarisi rehberimizde](/blog/saglik-turizmi-rehberi) ele alıyoruz.
Zorunlu entegrasyonlar
Klinik bilgi sistemleri (HBYS), randevu ve ameliyathane planlama, mesajlaşma ve e-posta kanalları, ödeme altyapısı, e-fatura ve muhasebe.
Nereden başlıyoruz?
Sağlık ve sağlık turizminde başlangıç durumu genellikle parçalı bir iletişim yığınıdır: hasta talepleri WhatsApp ve e-postada, tıbbi belgeler kişisel cihazlarda, acente mutabakatı Excel'de. Bu yapı çalışır görünür ancak veri sorumluluğu tanımsızdır.
İlk çalışmanın çıktısı kişisel veri envanteridir: hangi veri nerede tutuluyor, kim erişiyor, ne kadar süre saklanıyor ve hangi yurt dışı aktarımı yapılıyor. Özel nitelikli kişisel veri işlendiği için bu envanter yazılım kararlarından önce gelir.
Veri modelinde net olması gerekenler
- Hasta yolculuğu durumu: Talep, ön değerlendirme, teklif, planlama, operasyon, takip — her durum tarih ve sorumluyla.
- Belge kaydı: Belge türü, yükleyen, erişim kaydı ve saklama süresi; dosya adı tek başına yeterli değildir.
- Acente ve komisyon: Vaka başına acente, komisyon oranı, hakediş durumu ve para birimi.
- Dil ve iletişim tercihi: Hastanın iletişim dili ve kanal izni; pazarlama izni tedavi iletişiminden ayrı tutulmalı.
- Erişim kaydı (audit log): Tıbbi belgeye kimin, ne zaman eriştiği — silinemez biçimde.
- Rıza kaydı: Hangi metnin hangi sürümüne, ne zaman onay verildiği.
Devreye alma sırası
1. Veri envanteri ve yetki: Rol tanımları, erişim kapsamı, saklama süreleri ve rıza metinleri.
2. Talep ve vaka takibi: Çok dilli talep formu, vaka durumları, teklif üretimi.
3. Belge ve iletişim: Güvenli belge paylaşımı, erişim kaydı, çok kanallı iletişim geçmişi.
4. Acente ve finans: Komisyon hesabı, hakediş, çoklu para birimi ve tahsilat takibi.
Birinci faz atlanamaz. Yetki ve saklama kuralları sonradan eklendiğinde, o tarihe kadar biriken veri kural dışı kalır.
Neyi ölçüyoruz?
- Vaka durumları arasında geçen süre (talepten teklife, teklifte onaya)
- Yanıtlanmamış talep sayısı ve ilk yanıt süresi
- Acente bazında vaka sayısı ve komisyon hakediş durumu
- Tıbbi belgeye erişim kayıtlarının denetlenebilirliği
- Dil kırılımında talep dağılımı
Sık yapılan hatalar
- Tıbbi belgeyi mesajlaşma uygulamasında tutmak. Erişim kaydı üretilemez, silme talebi karşılanamaz.
- Pazarlama iznini tedavi iletişimiyle birleştirmek. İzin geri çekildiğinde tedavi bilgilendirmesi de durur.
- Rıza metnini sürümlememek. Hangi metne onay verildiği ispat edilemez.
- Komisyonu vaka dışında hesaplamak. Hakediş ile vaka durumu birbirinden kopar, mutabakat elle yapılır.
Sık sorulan sorular
Klinik sistemi ile CRM ayrı mı olmalı?
Genellikle evet ve bu doğru bir ayrımdır: klinik sistem tıbbi kaydı, CRM yolculuğu ve ticari süreci yönetir. Aralarında yalnızca gerekli alanlar tanımlı bir arayüzle paylaşılmalıdır; tıbbi kaydın tamamını CRM'e kopyalamak koruma yükümlülüğünü gereksizce genişletir.
Yurt dışına veri aktarımı nasıl ele alınır?
Aktarımın hukuki dayanağı, açık rızanın kapsamı ve rıza geri çekildiğinde hangi verinin ne olacağı önceden tanımlanmalıdır. Bu bir yazılım kararı değil, yazılıma yansıtılması gereken bir hukuki karardır.
Hangi ölçümler anlamlıdır?
Kaynak bazlı dönüşüm (talep → teklif → geliş → tedavi), ilk yanıta kadar geçen sürenin dağılımı, iptal nedenleri ve taburculuk sonrası takip tamamlanma oranı.
Yurt dışındaki hastanın verisi nerede tutulmalı?
Veri yerleşimi hem mevzuat hem sözleşme konusudur; teknik olarak sunucu konumu, yedek konumu ve alt işleyicilerin konumu ayrı ayrı belirlenmelidir. Bu üçü aynı yerde olmak zorunda değildir, ancak hepsi yazılı olarak tanımlanmalıdır. Kapsamı proje başında hukuk tarafıyla birlikte netleştiriyoruz.
Acente portalı hasta verisinin tamamını görmeli mi?
Görmemeli. Acentenin ticari süreci yürütmesi için vaka durumu, planlama tarihi ve finansal bilgi yeterlidir; tıbbi belge ve klinik detay ayrı yetki kapsamında tutulmalıdır. Bu ayrım, veri paylaşımını en aza indirme ilkesinin doğrudan uygulanmasıdır.
Çok dilli içerik yönetimi nasıl kurulur?
Her metin alanının dil başına ayrı kaydı olmalı; otomatik çeviri varsayılan olarak yayınlanmamalıdır. Hasta bilgilendirme metinlerinde çeviri onayı ayrı bir adım olarak tutulur ve hangi sürümün hangi dilde onaylandığı kaydedilir.