Demo ekranında hızlı ve şık görünen bir yazılım, sözleşmesinde veri merkezinin nerede olduğunu yazmıyorsa kliniği veri sorumlusu sıfatıyla yalnız bırakır. Bu reçete, satın almadan önce sorulması gereken güvenlik sorularını ve cevapların nasıl doğrulanacağını anlatır.
Kimin için
Muayenehane sahibi, veri sorumlusu, klinik yöneticisi
Bulut tabanlı muayenehane yazılımı seçimi çoğu klinikte iki soruya indirgenir: aylık kaç para ve ekranlar kolay mı. Bu iki sorunun cevabı doğru olsa bile, hastanın tetkik sonucu ile kimlik bilgisinin hangi ülkedeki hangi sunucuda durduğu, sizden başka kimin görebildiği ve sağlayıcı yarın kapanırsa verinin ne olacağı cevapsız kalır. Oysa KVKK karşısında veri sorumlusu yazılım firması değil, kliniktir; sorumluluk devredilemez, yalnızca paylaşılır. Aşağıdaki adımlar, satın alma görüşmesini demo izlemekten çıkarıp cevapları yazılı olarak toplayan kısa bir denetime çevirir. Amaç mükemmel sağlayıcıyı bulmak değil; hangi riski bilerek üstlendiğinizi bilmektir.
01 · Şikâyet
Klinikte ne görünüyor?
Yazılım seçiminde güvenlik sorusu genellikle sözleşme imzalandıktan sonra, bir aksaklık yaşandığında akla gelir. Aşağıdaki durumlar, kararın güvenlik tarafı hiç konuşulmadan verildiğini gösterir; hiçbiri tek başına felaket değildir, ama birlikte kliniği kendi verisi hakkında cevap veremez hâle getirir. Listeyi teklif almadan önce okuyun; sonrasında maliyeti yükselir.
Verinin nerede durduğunu kimse bilmiyor
Sağlayıcıya “sunucularınız nerede” diye sorulduğunda cevap “bulutta” oluyor. Hangi ülke, hangi veri merkezi, hangi altyapı sağlayıcısı sorularının yazılı bir cevabı yok. Klinik, hasta karşısında veri sorumlusu sıfatını taşımasına rağmen verisinin fiziksel adresini söyleyemiyor. Sorun genellikle sağlayıcının gizlisi saklısı olması değil, kimsenin bu soruyu satın alma sırasında sormamış olması.
Herkes aynı şifreyle giriyor
Klinikte tek bir kullanıcı hesabı var; hekim, sekreter ve stajyer aynı bilgilerle giriyor. Yazılım rol tanımı sunuyor olabilir, ama kimse kurmamış. Böylece bir kaydı kimin değiştirdiği, hangi dosyayı kimin açtığı sorusunun cevabı baştan imkânsız hâle geliyor; hesap paylaşımı zamanla kurumsal körlüğe dönüşüyor.
Yedek sağlayıcıda var sanılıyor
Yedekleme sorulduğunda “bulut zaten yedekliyor” cevabı veriliyor; ama yedeğin ne sıklıkla alındığı, ne kadar geri gidilebildiği ve klinik yanlışlıkla bir dosyayı silerse o kaydın kaç saatte geri geleceği bilinmiyor. Sağlayıcının altyapı yedeği ile kliniğin kurtarma ihtiyacı aynı şey sanılıyor. İki kavram arasındaki fark ancak bir kayıp yaşandığında öğreniliyor.
Sözleşmede veri değil, özellik yazıyor
İmzalanan metin modül listesi, kullanıcı sayısı ve fiyattan ibaret. Kişisel verilerin işlenmesine dair bir ek, gizlilik taahhüdü, ihlal bildirim süresi ve sözleşme sonunda verinin nasıl teslim edileceğine dair bir madde yok. Klinik, hukuken en kritik ilişkisini sıradan bir ürün siparişi gibi kurmuş durumda.
02 · Tanı
Sorunun asıl kaynağı nedir?
Bu tablonun kökeninde bir rol karışıklığı var: klinik, yazılımı satın aldığında sorumluluğu da devrettiğini sanıyor. Hukuk bunu böyle görmez. Sağlayıcı veri işleyendir; hastaya, denetime ve kamuoyuna karşı sorumlu taraf kliniktir. Karışıklık giderilmeden yapılan seçim, iyi niyetli bir kumardır. Üç bulgu, bu karışıklığın nerelerde somut risk ürettiğini gösterir.
1
Sorumluluk devredilemez, paylaşılır
KVKK, veri sorumlusu ile veri işleyeni ayırır. Kliniğin hastadan topladığı veriyi bir yazılıma taşıması, sorumluluğu o yazılıma geçirmez; yalnızca yeni bir taraf ekler. Bu yüzden sağlayıcıyla imzalanan metinde kimin neyi taahhüt ettiği, hangi güvenlik tedbirlerinin uygulandığı ve bir ihlal durumunda kliniğin kaç saat içinde bilgilendirileceği yazılı olmalıdır. Yazılı olmayan taahhüt, sorun çıktığında karşılıklı suçlamaya dönüşür ve hasta karşısında klinik yalnız kalır.
2
Konum bir tercih değil, kural sorusudur
Sağlık verisi özel nitelikli kişisel veridir; Kişisel Verileri Koruma Kurumunun bu alandaki rehberi, işleme ve aktarım için daha sıkı tedbirler bekler. Verinin yurt dışındaki bir sunucuda tutulması, aktarımın kendi kurallarına tabi olması demektir ve klinikten ek yükümlülükler doğurur. Sağlayıcının hangi altyapıyı hangi ülkede kullandığını bilmiyorsanız, bu yükümlülüğün doğup doğmadığını da bilemezsiniz. Bilinmeyen bir yükümlülük, yönetilemeyen bir risktir.
3
Çok kurumlu sistemde asıl soru izolasyondur
Bulut yazılımları yüzlerce kliniği aynı altyapıda barındırır; bu kendi başına sorun değildir, tasarım sorusudur. Kritik olan, bir kliniğin verisinin diğerinden hangi katmanda ayrıldığıdır. Ayrım yalnızca uygulama kodundaki bir filtreye bırakılmışsa, tek bir yazılım hatası kurumlar arası sızıntıya dönüşebilir. Veritabanı düzeyinde satır bazlı izolasyon uygulanan bir sistemde ise aynı hata komşu kurumun kayıtlarını açmaz.
Bu sorunun ölçülebilir bedeli
Sözleşmede yazılı olmayan taahhüt
Çoğu maddede
Sözlü verilen güvenlik sözlerinin bir uyuşmazlıkta ispat değeri bulunmaz.
Veri taşıma ve çıkış süresi
2-8 hafta
Dışa aktarım biçimi tanımsızsa geçiş projesi beklenenden uzar.
Yanlış silinen kaydın geri dönüşü
Belirsiz
Kurtarma süresi taahhüt edilmemişse bekleme süresi öngörülemez.
Hesap paylaşımı nedeniyle kaybolan iz
Tüm işlemler
Ortak kullanıcıda denetim kaydı hiç kimseyi işaret etmez.
03 · Reçete
Adım adım uygulama
Güvenli seçim, uzun bir teknik şartname yazmayı gerektirmez; doğru soruları doğru sırayla sormayı gerektirir. Aşağıdaki altı adım, teklif toplama aşamasından sözleşme imzasına kadar olan süreci kısa bir denetime çevirir. Her adımın çıktısı yazılı bir cevaptır; demo sırasında duyduğunuz güzel cümleler değil, sözleşmeye giren maddeler karar verdirir.
01
Sunucunun nerede olduğunu satır satır sorun
Teklif aşamasında bir kez, yıllık teyit
Satın alma görüşmesinde sorulacak ilk soru fiyat değil, adrestir: verilerimiz hangi ülkede, hangi veri merkezinde tutuluyor? Cevabı sözlü almak yeterli değildir; teklif ekinde ya da sözleşme metninde yazılı olarak isteyin. Sağlayıcı kendi altyapısını başka bir bulut şirketinden kiralıyorsa, o şirketin adı ve bölgesi de bu cevabın parçasıdır. Zincirin bir halkası bilinmiyorsa cevap tamamlanmamıştır.
Yedeklerin nerede tutulduğunu ayrıca sorun; ana verisi Türkiye’de olup yedeği başka bir ülkeye kopyalanan kurgular mümkündür. Sonra destek ekibinin verinize erişip erişemediğini, eriştiğinde bunun kayda geçip geçmediğini öğrenin. Uzak destek bağlantısıyla hasta kaydına bakabilen bir teknik ekip, sözleşmede tanımlanmamışsa görünmeyen bir erişim kapısıdır.
Veri merkezi ülkesini ve altyapı sağlayıcısını yazılı olarak isteyin
Yedeklerin hangi ülkede tutulduğunu ayrıca sorun
Destek ekibinin erişim yetkisini ve kaydını sözleşmeye yazdırın
PratiVia’da karşılığı
PratiVia verilerini Türkiye’deki veri merkezinde tutar; bu bir opsiyon değil, ürünün kuruluş şartıdır. Yedekler de aynı bölgede kalır, hangi verinin nerede durduğu sorusunun tek bir cevabı vardır.
02
Rol modelini deneme hesabında sınayın
Karar öncesi bir kez, kurulumda tekrar
Broşürde “rol bazlı yetkilendirme var” yazması yeterli değildir; bu cümlenin arkasında bazen yalnızca iki seçenek bulunur: yönetici ve kullanıcı. Deneme hesabında gerçek bir sınav yapın. Sekreter rolüyle giriş yapıp bir hastanın seans notunu açmayı deneyin; muhasebe rolüyle tanı bilgisine ulaşmayı deneyin. Görmemesi gereken bir ekran açılıyorsa, o yazılımın yetki modeli kliniğinizin ihtiyacını karşılamıyor demektir.
Aynı sınavı yetki kapatma tarafında da yapın: bir kullanıcıyı pasife alın ve o hesapla tekrar giriş deneyin. Erişimin ne kadar sürede kapandığı, açık oturumun devam edip etmediği ve kullanıcının indirdiği belgelerin ne olacağı önemlidir. Personel değişikliği her klinikte yaşanır; yetki kapatmanın tek işlemle ve anında olması, sonradan telafi edilemeyen bir özelliktir.
Deneme hesabında en az üç farklı rolle giriş yapıp sınırları test edin
Görülmemesi gereken ekranların gerçekten kapalı olduğunu doğrulayın
Kullanıcı pasife alındığında erişimin ne kadar sürede kesildiğini ölçün
PratiVia’da karşılığı
PratiVia’da Owner, Admin, Professional, Manager, Secretary, Accountant ve Intern rolleri hazır gelir; yetki matrisi kurumun kendi düzenine göre daraltılabilir ve bir kullanıcının erişimi anında kapatılabilir.
Denetim izi, bir kaydı kimin ne zaman açtığını ve değiştirdiğini gösteren kayıttır; KVKK açısından da klinik içi güven açısından da belirleyicidir. Ancak birçok yazılımda bu kayıt yalnızca giriş ve çıkış saatlerini tutar. Deneme sırasında bir hasta kaydını açın, bir alanı değiştirin ve ardından denetim ekranında bu iki işlemin göründüğünü kendi gözünüzle kontrol edin.
İkinci soru daha önemlidir: bu kaydı kim silebiliyor? Yönetici tarafından temizlenebilen bir denetim izi, en çok ihtiyaç duyulduğu anda boş çıkar. Kaydın değiştirilemez olması ekibi denetlemek için değil, herkesi korumak içindir; bir suçlama olduğunda kimin ne yaptığı tartışmaya değil kayda bakılarak belirlenir.
Deneme sırasında yaptığınız işlemin denetim ekranında göründüğünü doğrulayın
Denetim kaydının yönetici tarafından silinip silinemediğini sorun
Kaydın ne kadar süre saklandığını sözleşmede netleştirin
PratiVia’da karşılığı
PratiVia’da denetim kayıtları değiştirilemez biçimde tutulur; veritabanı düzeyinde güncelleme ve silme engellenir. Bu kayıt kurum yöneticisi tarafından da temizlenemez.
İki teknik soru, cevaplarını tam anlamasanız bile ayırt edicidir. Birincisi: hassas alanlar veritabanında şifreli mi saklanıyor? Kimlik numarası ve benzeri veriler açık metin olarak duruyorsa, veritabanına erişen herkes için okunabilir demektir. İkincisi: benim kurumumun verisi başka bir kliniğin verisinden hangi katmanda ayrılıyor? Cevap yalnızca uygulama içindeki bir filtreye dayanıyorsa, ayrım kod hatasına açıktır.
Sağlıklı cevap, izolasyonun veritabanı seviyesinde de uygulandığını söyler; yani yazılım katmanında bir hata olsa bile veritabanı komşu kurumun satırlarını döndürmez. Bu soruyu sormanız, size teknik detay anlatılmasını sağlamaktan çok, konunun düşünülmüş olup olmadığını ortaya çıkarır. Hazırlıksız kalan bir cevap tek başına anlamlı bir sinyaldir.
Kimlik numarası gibi alanların şifreli saklandığını yazılı olarak sorun
Kurumlar arası izolasyonun hangi katmanda uygulandığını öğrenin
Yüklenen dosyaların zararlı yazılıma karşı taranıp taranmadığını sorun
PratiVia’da karşılığı
PratiVia’da kurum bazlı izolasyon veritabanı düzeyinde satır güvenliğiyle sağlanır; kimlik numarası gibi hassas alanlar şifreli saklanır ve yüklenen dosyalar karantina taramasından geçer.
Bulut sağlayıcısının kendi altyapısını yedeklemesi, sizin kurtarma ihtiyacınızı karşılamaz. İki farklı soru vardır: sistem çökerse ne kadar sürede ayağa kalkar ve klinik yanlışlıkla bir dosyayı silerse o kayıt geri getirilebilir mi? İkinci soruya cevap veremeyen bir sağlayıcı, en sık yaşanan veri kaybı türüne hazırlıksızdır; çünkü kliniklerde asıl kayıp felaketten değil, sıradan bir hatadan doğar.
Cevapları rakama çevirin: yedek ne sıklıkla alınıyor, en fazla kaç saatlik veri kaybı kabul ediliyor, kurtarma talebi kaç saatte karşılanıyor. Bu üç rakam yazılı olarak alındığında sözleşme, güven ifadesi olmaktan çıkıp ölçülebilir bir taahhüde dönüşür. Rakam veremeyen sağlayıcı bu senaryoyu bugüne kadar hiç çalışmamış olabilir.
Yedek sıklığını ve kabul edilen azami veri kaybı süresini yazılı isteyin
Yanlışlıkla silinen kaydın geri getirilme süresini sorun
Bir kurtarma talebini deneme sürecinde bizzat test edin
PratiVia’da karşılığı
PratiVia yönetilen veritabanı ve nesne depolama üzerinde çalışır; yedekleme ve saklama süreleri kurulum sözleşmesinde tanımlanır, klinikten ayrı bir yedek altyapısı kurması beklenmez.
06
Sözleşme sonunu ve ihlal bildirimini baştan yazın
Sözleşme imzasında bir kez
İlişkinin en riskli anı başlangıç değil, bitiştir. Sözleşme sona erdiğinde ya da sağlayıcı değiştirildiğinde verinizi hangi biçimde, ne kadar sürede ve hangi ücretle alacağınız baştan yazılmalıdır. “Talep hâlinde veririz” cümlesi yeterli değildir; dışa aktarımın kapsamına belgeler dâhil mi, kayıtlar hangi dosya biçiminde teslim edilecek, teslim sonrası sağlayıcı verinizi ne zaman silecek — hepsi maddeye bağlanmalıdır.
Aynı metne ihlal bildirimini de ekleyin: sağlayıcı tarafında bir güvenlik olayı yaşandığında klinik kaç saat içinde bilgilendirilecek? Bu süre önemlidir, çünkü Kişisel Verileri Koruma Kurumuna bildirim yükümlülüğü kliniğe aittir ve süre olaydan itibaren işlemeye başlar. Sağlayıcı size üç gün sonra haber verirse, gecikmenin sonucuna klinik katlanır.
Veri dışa aktarımının kapsamını ve biçimini sözleşmeye yazdırın
İhlal bildiriminin azami süresini saat cinsinden tanımlayın
Sözleşme sonunda verinin silinme takvimini netleştirin
PratiVia’da karşılığı
PratiVia bu soruları satın alma görüşmesinde açık biçimde cevaplar: veri sorumlusu klinik, veri işleyen PratiVia’dır; çıkış, silme ve bildirim koşulları sözleşme metninde tanımlanır.
04 · PratiVia farkı
Bu reçeteyi PratiVia neden kolaylaştırır?
Bu listeyi PratiVia için de uygulamanızı bekliyoruz; iyi bir güvenlik duruşu, sorulduğunda cevap verebilmektir. Aşağıdaki dört madde aynı soruların PratiVia tarafındaki cevabıdır — pazarlama vaadi olarak değil, mimari karar olarak. Beğenmediğiniz cevabı sözleşmede tartışabilirsiniz.
Türkiye’de barınma bir seçenek değil
Veri ve yedekler Türkiye’deki veri merkezinde tutulur; bu, sonradan açılan bir bölge tercihi değil, ürünün kurulduğu andaki kısıttır. Yurt dışına aktarım gerektiren bir mimari kurgu bulunmadığı için klinik bu başlıkta ek yükümlülük üstlenmez.
İzolasyon veritabanının kendi kuralıdır
Kurumlar arası ayrım uygulama kodundaki bir filtreye bırakılmaz; veritabanı satır güvenliğiyle zorunlu kılınır. Uygulama katmanında bir hata olsa bile sorgu komşu kurumun kayıtlarını döndürmez. Bu, tek bir hatanın çok kurumlu sızıntıya dönüşmesini yapısal olarak engeller.
Denetim ve rıza kayıtları veritabanı düzeyinde değiştirilemez; kurum yöneticisi bile temizleyemez. Buna karşılık personel erişimi tek işlemle kapatılabilir. Kalıcı olması gereken ile anında kapanması gereken bilinçli olarak ayrılmıştır; bu ayrım hem kliniği hem çalışanı korur.
Yukarıdaki denetim listesini PratiVia görüşmesinde madde madde sorabilirsiniz; cevaplar demo ekranında değil, kendi deneme hesabınızda doğrulanır. Bir maddede beklentinizi karşılamayan cevap varsa, bunu imzadan önce bilmek sonradan öğrenmekten iyidir.
05 · Takip
Sonucu nasıl ölçersiniz?
Seçim bittiğinde iş bitmez; kurulumdan sonraki ilk üç ay, sözleşmedeki taahhütlerin gerçekten çalıştığını doğrulama dönemidir. Dört gösterge bu doğrulamayı somutlaştırır ve hepsi klinik tarafından ölçülebilir. Ölçmeyen klinik, taahhüdün tutulup tutulmadığını asla öğrenemez.
Gösterge
Hedef
Nasıl ölçülür
Yazılı cevap alınan güvenlik sorusu
Listedeki soruların tamamı
Denetim listenizi işaretleyin; sözlü cevap sayılmaz, yazılı cevap sayılır.
Rol dışı erişim denemesi
Tamamı engellenmeli
Her rolle ayda bir kez görmemesi gereken bir ekranı açmayı deneyin.
Aktif kullanıcı sayısı doğruluğu
Fiili çalışan sayısıyla birebir
Kullanıcı listesini bordroyla karşılaştırın; ayrılan hesap kalmamalı.
Kurtarma tatbikatı sonucu
Taahhüt edilen süre içinde
Yılda bir kez bir test kaydının geri getirilmesini talep edip süreyi ölçün.
4 haftalık uygulama planı
1. hafta
Denetim listenizi hazırlayın; adaylardan yazılı cevap isteyin.
Karar kriterleri fiyat listesinden güvenlik cevaplarına genişledi.
2. hafta
Deneme hesabında rol, yetki ve denetim izi sınavlarını yapın.
Broşürdeki ifadeler canlı sistemde doğrulandı.
3. hafta
Yedekleme, kurtarma ve ihlal bildirimi sürelerini rakama bağlayın.
Taahhütler ölçülebilir maddelere dönüştü.
4. hafta
Sözleşmeyi veri çıkışı ve silme maddeleriyle imzalayın; kullanıcıları rolleriyle açın.
Kurulum, ilk günden yetki düzeni tanımlanmış hâlde başladı.
Yan etkiler ve dikkat edilecekler
Sağlayıcının belgesi kliniğin uyumunu tek başına sağlamaz; veri sorumlusu sıfatı KVKK karşısında klinikte kalır.
Deneme hesabına gerçek hasta verisi girmeyin; seçilmemiş bir sisteme canlı sağlık verisi taşımak riski erken başlatır.
Fiyat farkı güvenlik farkını gerekçelendirmez; ucuz sistemin bedeli çoğu zaman veri çıkışı ve kurtarma anında ödenir.
Kullanıcı sayısı arttıkça lisansın nasıl davrandığını sorun; ekibi hesap paylaşımına zorlayan fiyat yapıları uyumu bozar.
06 · Sık sorulanlar
Bu reçete hakkında merak edilenler
Bulut yazılım, klinikteki bilgisayarda tutmaktan daha mı güvenli?
Çoğunlukla evet, ama otomatik olarak değil. Klinik bilgisayarında tutulan veride yedek, şifreleme, erişim kaydı ve fiziksel güvenlik tamamen kliniğin omzundadır ve pratikte çoğu muayenehanede bu yükün altı boş kalır. Bulut sağlayıcısı aynı işleri profesyonelce yapabilir; ancak yaptığını sözleşmede ve teknik cevaplarında gösteremiyorsa, tek değişen şey riskin adresi olur. Karşılaştırmayı bulut mu yerel mi diye değil, hangi tarafta hangi tedbirin yazılı olduğu sorusuyla yapın.
Sunucunun yurt dışında olması doğrudan yasak mı?
Hayır; kişisel verilerin yurt dışına aktarılması mutlak biçimde yasaklanmış değildir, kendi şartlarına tabidir. Sorun yasaklık değil, farkındalıktır: aktarım gerçekleştiğini bilmeyen klinik bu şartları yerine getirip getirmediğini de bilemez ve aydınlatma metninde bundan söz edemez. Sağlık verisi özel nitelikli olduğu için beklenen özen daha yüksektir. En pratik yol, verinin ve yedeklerinin Türkiye’de kaldığı bir kurguyu tercih ederek bu başlığı gündeminizden çıkarmaktır.
Küçük bir muayenehane bu soruların cevabını nasıl değerlendirsin?
Cevapların teknik derinliğini değerlendirmeniz gerekmez; tutarlılığını ve yazılı olmasını değerlendirmeniz yeterlidir. İyi hazırlanmış bir sağlayıcı sunucu konumunu, yedek sıklığını ve ihlal bildirim süresini tereddütsüz söyler, yazılı vermekten çekinmez. Cevap belirsizleşiyor, konu değiştiriliyor ya da her şeyin güvende olduğunu söyleyen genel bir cümleye bağlanıyorsa sinyal yeterince nettir. Teknik bilgi değil, kaçamak cevabı fark etmek yeterlidir.
Yazılım değiştirmek istersem verimi gerçekten alabilir miyim?
Bu, sözleşmeyi imzalamadan önce çözülmesi gereken bir sorudur; sonrasında pazarlık gücünüz düşer. Kayıtların hangi biçimde dışa aktarılabildiğini, belgelerin ve eklerin bu aktarıma dâhil olup olmadığını ve teslim süresini yazılı isteyin. Uygulamada en sık yaşanan sorun verinin hiç verilmemesi değil, kullanılamaz bir biçimde verilmesidir: yeni sisteme aktarılamayan ham bir dosya yığını, pratikte elinizde veri olmadığı anlamına gelir.
Sağlayıcı güvenlik belgesi gösteriyor; bu yeterli sayılır mı?
Belge, sağlayıcının belirli süreçleri tanımlı biçimde yürüttüğünü gösterir ve olumlu bir sinyaldir; ancak sizin kliniğinizdeki kullanımı denetlemez. Belgeli bir sistemde de tüm ekip aynı hesabı paylaşabilir, yetkiler açık bırakılabilir, hasta verisi kişisel telefondan gönderilebilir. Yani belge sağlayıcı tarafını, kurulum ve alışkanlıklar sizin tarafınızı belirler. Doğru okuma şudur: belge gerekli bir ön koşuldur, uyumun kendisi değildir.
Pazar sinyali kaynağı: BulutKlinik. Son güncelleme: 28 Temmuz 2026.
Devam eden tedavi
Aynı sorunun komşu reçeteleri.
Bir operasyon sorunu tek başına gelmez. Bu reçeteyi tamamlayan diğer adımlarla kliniğinizin akışını bütün olarak kurun.