Denetim kaydı kliniğin hafızasıdır: kim baktı, ne değişti, hangi liste dışarı çıktı. Bu reçete audit log’un neyi tutması gerektiğini, bir olayda nasıl okunacağını ve ihlal bildiriminde kliniği nasıl savunduğunu anlatır.
Bir cuma akşamı hasta arıyor: “Randevumu kim iptal etti?” Sekreter iptal etmediğini söylüyor, hekim zaten o gün sisteme girmediğini. Kayıt yok, tartışma var. Audit log — Türkçesiyle denetim kaydı — tam olarak bu boşluğu doldurur: yazılımda yapılan her görüntüleme, değişiklik ve silme işlemini kimin, ne zaman, hangi kayıt üzerinde yaptığıyla birlikte saklar. Muayenehane yazılımında audit log, denetimden korkulduğu için eklenen bir süs değil; hasta verisi erişim kaydının hem KVKK tedbiri hem de kliniğin gündelik hakemi olmasıdır. Bu reçete, kaydın neyi tutması gerektiğini, nasıl okunacağını ve bir sorun çıktığında nasıl kullanılacağını anlatır.
01 · Şikâyet
Denetim kaydının yokluğu gündelik akışta hiç hissedilmez; her şey yolunda görünür, çünkü kimse kimseye hesap sormaz. Eksiklik ancak bir şey ters gittiğinde, hem de en kötü anda ortaya çıkar. Aşağıdaki dört tablodan biri bile yaşandıysa, kliniğin elinde olay anını anlatacak bir kaydın olmadığını görmüşsünüzdür.
Takvimde bir randevu yok, bir tahsilat tutarı değişmiş, bir hasta notu boşalmış. Ekipten kimse yaptığını hatırlamıyor ve büyük ihtimalle kimse yalan da söylemiyor; belki bir yanlış tıklama, belki iyi niyetli bir düzeltme söz konusu. İz olmadığı için konu teknik bir sorudan çıkıp kişisel bir güven meselesine dönüşüyor.
Danışan, dosyasına kimlerin eriştiğini öğrenmek istiyor; bu, Kanun’un ilgili kişiye tanıdığı bilgi talep etme hakkının doğal uzantısı. Klinik ise ancak “yalnızca ilgili çalışanlar” diyebiliyor. Cevap samimi ama belgeye dayanmıyor; başvuru yazılı hâle geldiğinde ekte gösterilecek tek bir çıktı bulunamıyor.
Bir çalışan hasta listesini tabloya aktarıp kendi e-postasına gönderiyor; sistemde bu, sıradan bir rapor indirme gibi geçiyor. Sağlık verisi sızıntılarının önemli bölümü gösterişli bir saldırıyla değil, tam olarak böyle sessiz bir kopyalamayla başlar. İz bırakmayan dışa aktarma, ihlali görünmez kılar.
Bir ölçüm değeri ya da tanı notu sonradan düzeltilmiş; ekranda güncel hâli duruyor ama önceki hâli buharlaşmış. Hasta itirazı ya da resmî bir talep geldiğinde kliniğin “bu kayıt ne zaman, neden değişti” sorusuna verecek yanıtı yok. Değişiklik tamamen meşru olsa bile ispatlanamıyor.
02 · Tanı
Dört tablonun ortak nedeni, yazılımın yalnızca son durumu tutmasıdır. Ekranda gördüğünüz şey kaydın bugünkü hâlidir; o hâle nasıl geldiği hiçbir yerde yazmaz. Oysa sağlık verisinde süreç en az sonuç kadar önemlidir ve mevzuat da sonucu değil, işlemi izlenebilir kılmanızı bekler.
Her yazılım veriyi tutar; ama çoğu, verinin üzerine yazar. Telefon numarası güncellendiğinde eskisi kaybolur, not düzeltildiğinde önceki metin silinir. Denetim kaydı bunun tersini yapar: veriyi değil, veriye yapılan işlemi ayrı bir yere ve dokunulmaz biçimde yazar. Bu ayrım kritiktir, çünkü bir inceleme sırasında sorulan soru “veri neydi” değil, “veriye ne oldu”dur. İki katman aynı tabloda tutulduğunda geçmiş de bugünle birlikte değiştirilebilir hâle gelir.
Kanun uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri ister, ayrıntısını Kurumun rehberlerine bırakır. Özel nitelikli kişisel verilere ilişkin rehber ise bu verilere erişimin kaydedilmesini ve kayıtların düzenli olarak incelenmesini açıkça bekler. Yani denetim kaydı isteğe bağlı bir konfor değil, sağlık verisi işleyen kliniğin karşılaması beklenen bir başlıktır. Üstelik ihlal bildiriminde etkilenen kişi ve kayıt sayısının belirtilmesi gerekir; o sayıyı üretebilen tek kaynak logdur.
Denetim kaydının bütün değeri, sonradan düzeltilememesinden gelir. Yöneticinin silebildiği bir log hem iç tartışmada hem resmî incelemede tartışmalıdır; en yetkili kişi kendi izini kapatabiliyor demektir. Bu yüzden kaydın veritabanı seviyesinde güncellemeye ve silmeye kapalı olması, kaydın var olmasından bile önemlidir. Kliniğin “logumuz var” demesi yetmez, “logumuza kimse dokunamaz” diyebilmesi gerekir. Aksi hâlde kayıt, kliniği koruyan bir delil değil, sahibine göre değişen bir anlatı olur.
Bu sorunun ölçülebilir bedeli
Olay sonrası inceleme süresi
Günler
Kayıt yoksa herkesle tek tek konuşulur, sonuç yine tahmine dayanır.
Erişim başvurusuna kanıtlı cevap
Üretilemiyor
Kim baktı listesi çıkarılamadığı için başvuru genel ifadelerle yanıtlanır.
Fark edilmeyen toplu dışa aktarma
Sınırsız
İz tutulmayan sistemde liste indirmeleri hiçbir ekranda görünmez.
İhlal bildiriminde eksik beyan riski
Yüksek
Etkilenen kayıt sayısı hesaplanamadan 72 saatlik bildirim doldurulamaz.
03 · Reçete
Denetim kaydı satın alınan değil, işletilen bir mekanizmadır; özelliğin açık olması tek başına hiçbir şey ifade etmez. Aşağıdaki altı adım, kaydın neyi tutacağını belirlemekle başlar, kaydı dokunulmaz ve okunabilir kılmakla sürer, bir olay anında saatler içinde cevap üretebilen bir düzenle biter. Küçük bir muayenehanede toplam kurulum yükü birkaç saattir.
Her tıklamayı kaydetmek gürültü üretir, hiçbir şey kaydetmemek boşluk bırakır. Doğru orta yol, hasta verisine dokunan olayları listelemektir: dosya görüntüleme, kayıt oluşturma, alan değişikliği, silme, belge indirme, liste dışa aktarma, oturum açma ve başarısız giriş denemesi. Bu sekiz başlık, bir kliniğin karşılaşacağı olayların neredeyse tamamını kapsar.
Listeyi çıkarırken her olay için üç bilgiyi zorunlu tutun: kim, ne zaman, hangi kayıt. Değişiklik olaylarında dördüncü bir bilgi daha gerekir — alanın önceki ve sonraki değeri. Bu dördüncüsü olmadan kayıt, bir şeyin değiştiğini söyler ama neye dönüştüğünü söyleyemez; itiraz anında en çok ihtiyaç duyacağınız bilgi tam olarak budur.
PratiVia’da karşılığı
PratiVia bu olayları ürünün varsayılan davranışı olarak işler; dosya görüntüleme, kayıt değişikliği ve silme işlemleri kullanıcı, zaman ve kayıt bilgisiyle birlikte denetim kaydına düşer, ayrıca açılması gereken bir ayar yoktur.
Ekip ve rollerKaydın kime kapalı olduğunu bilmek, ne tuttuğunu bilmek kadar önemlidir. Doğru kurulumda hiçbir kullanıcı — kurucu hekim dahil — geçmiş bir satırı düzenleyemez ya da silemez. Yanlış yazılmış bir kayıt düzeltilmez; üzerine açıklayıcı yeni bir kayıt eklenir. Muhasebedeki ters kayıt mantığı burada da geçerlidir ve tarihi korur.
İkinci mesele süredir. Denetim kaydının kendisi de kişisel veri içerir, dolayısıyla sonsuza kadar tutulamaz. Kliniğin belirlediği saklama süresi, ilgili hasta kaydının süresiyle uyumlu olmalı ve süre dolduğunda log da imha edilmelidir. Bu süreyi yazmadığınızda iki risk birden doğar: erken silinen kayıt savunmasız bırakır, süresiz saklanan kayıt yeni bir uyum sorunu yaratır.
PratiVia’da karşılığı
PratiVia’da denetim kayıtları veritabanı seviyesinde güncellemeye ve silmeye kapalıdır; tetikleyiciler bu işlemleri en yetkili hesap için bile reddeder, dolayısıyla geçmiş sonradan yeniden yazılamaz.
Ekip ve rollerKaydın işe yaradığı an, bir şeyin ters gittiği andır; o an protokol yazacak vakit olmaz. Bir sayfalık kısa bir metin yeterlidir: incelemeyi kim başlatır, hangi filtrelerle bakılır, sonuç nereye yazılır, kiminle paylaşılır. Bu metin olmadığında inceleme kişiden kişiye değişir ve çoğu zaman hiç yapılmaz.
Protokolün özü sıralamadır. Önce olayın zaman aralığı daraltılır, sonra ilgili hasta kaydı ya da kullanıcı seçilir, ardından o aralıktaki tüm işlemler kronolojik okunur. Bulgular tarih ve satır referansıyla not edilir; yorum ile veri ayrı tutulur. Sonuç, ekiple konuşulurken de saklanır, çünkü suçlama değil düzeltme üretmek hedeftir.
PratiVia’da karşılığı
PratiVia’nın denetim kaydı kullanıcı, tarih ve işlem türüne göre filtrelenebilir; bir hasta dosyasının kim tarafından ne zaman açıldığını görmek için ayrı bir sorgu yazmanız gerekmez.
Klinikte veri riskinin en yoğunlaştığı iki hareket vardır: çok sayıda dosyanın kısa sürede açılması ve listelerin dosya olarak indirilmesi. İkisi de tek tek bakıldığında normaldir; toplu bakıldığında desen verir. Bu yüzden bu iki olay, diğer kayıtlar arasında kaybolmasın diye ayrı bir gözle taranmalıdır.
Ayda on dakika ayırıp şu soruları sorun: geçen ay kim, kaç kayıt dışa aktardı ve neden? Bir kullanıcı kendi hasta listesi dışında olağandışı sayıda dosya açtı mı? Mesai dışı saatlerde toplu görüntüleme oldu mu? Cevapların çoğu masumdur; ama sorunun sorulabiliyor olması bile davranışı değiştirir, çünkü herkes eriştiğinin görünür olduğunu bilir.
PratiVia’da karşılığı
Belge indirme ve liste dışa aktarma işlemleri PratiVia’da ayrı olay türü olarak kaydedilir; kullanıcı bazında filtrelendiğinde aylık tarama tek ekrandan birkaç dakikada tamamlanır.
Ekip ve rollerİlgili kişi, verisinin kimlere aktarıldığını ve nasıl işlendiğini sorma hakkına sahiptir ve başvuruya en geç otuz gün içinde cevap verilmesi gerekir. Bu cevabın gücü, genel bir güvence cümlesi yerine sistemden alınmış bir çıktıya dayanmasından gelir. Denetim kaydı bu çıktıyı zaten üretmektedir; yapılması gereken tek şey, onu anlaşılır bir yanıta çevirmektir.
Yanıtta ham log ekranını göndermeyin. Kayıttan çıkardığınız bilgiyi sade bir dille özetleyin: hangi tarihlerde, hangi görevdeki çalışanların hangi amaçla dosyaya eriştiği. Diğer hastaların verisi hiçbir şekilde görünmemeli, çalışan kimlikleri de gereğinden fazla açılmamalıdır. Bu denge, hem ilgili kişinin hakkını hem ekibin kişisel verisini korur.
PratiVia’da karşılığı
PratiVia’da bir hasta kaydına ait erişim geçmişi dosya bazında listelenebilir; başvuruya cevap hazırlarken arşiv taramak yerine tek bir filtreyle ihtiyacınız olan satırlara ulaşırsınız.
Hasta yönetimiVeri ihlali öğrenildiğinde Kurula en kısa sürede, kural olarak yetmiş iki saat içinde bildirim yapılması beklenir. Bu süre kısa görünür ama asıl darboğaz bildirimin kendisi değil, bildirimde istenen bilgidir: ihlalin niteliği, etkilenen kişi ve kayıt sayısı, olası sonuçlar ve alınan tedbirler. Kaydı olmayan klinik bu alanları tahminle doldurmak zorunda kalır.
Bu yüzden ihlal planınızın ilk maddesi denetim kaydına bakmak olmalıdır. Şüpheli hesap ve zaman aralığı belirlenir, o aralıkta erişilen kayıtlar listelenir, sayı ve kapsam çıkarılır. Yılda bir kez, gerçek olmayan bir senaryoyla bu akışı prova edin; tatbikat yapılmamış planların krizde işlemediğini en çok bu alanda görürsünüz.
PratiVia’da karşılığı
Denetim kaydı PratiVia’da işlem türü ve zaman aralığına göre süzülebildiği için, şüpheli bir hesabın belirli bir dönemde eriştiği hasta kayıtlarının listesi bildirim hazırlanırken doğrudan çıkarılabilir.
04 · PratiVia farkı
Birçok klinik yazılımında denetim kaydı sonradan eklenmiş bir modüldür: açılıp kapatılabilir, temizlenebilir ve genellikle yalnızca birkaç işlemi kapsar. PratiVia’da kayıt, verinin yazıldığı yerin hemen yanında ve aynı zorunlulukla üretilir.
İşlem web panelinden, mobil uygulamadan ya da danışan portalından gelmiş fark etmez; hepsi aynı denetim kaydına aynı biçimde düşer. Böylece bir kanaldan yapılan değişikliğin izi başka bir kanalda kaybolmaz ve olay incelemesi tek bir kaynaktan yürütülür.
Modülü inceleyinBir alan güncellendiğinde yalnızca yeni hâli değil, önceki hâli de saklanır. Hasta itirazında ya da resmî bir talepte kaydın hangi tarihte neye dönüştüğü satır satır görünür; klinik hafızaya değil, çıktıya dayanarak konuşur ve iyi niyetini ispat edebilir.
Denetim kayıtları da hasta verisi gibi kurum bazında izole tutulur; veritabanı seviyesindeki satır bazlı güvenlik log tablosuna da uygulanır. Hiçbir kurum bir başkasının işlem geçmişini göremez, ortak bir havuzda karışma ihtimali doğmaz.
Modülü inceleyinBir hastanın verisi silindiğinde ya da anonimleştirildiğinde işlemin kendisi kayıtta kalır: kim, ne zaman, hangi kayıt üzerinde. Böylece silme hakkının yerine getirildiğini ispatlarken kişiyi yeniden tanımlanabilir kılan bir veri saklamak zorunda kalmazsınız.
Modülü inceleyin05 · Takip
Denetim kaydının işlediğini, log satır sayısıyla değil cevap üretme kabiliyetiyle ölçersiniz. Aşağıdaki dört gösterge ilk çeyrekte kaydın gerçekten kullanılan bir araç mı yoksa açık ama okunmayan bir özellik mi olduğunu gösterir.
| Gösterge | Hedef | Nasıl ölçülür |
|---|---|---|
| İz bırakan kritik işlem oranı | Sekiz olay türünde tam kapsam | Belirlediğiniz olay listesini örnek işlemlerle test edip kayda düşüp düşmediğini doğrulayın. |
| Olay incelemesinin sonuçlanma süresi | Şüphe anından itibaren 48 saat altı | İnceleme başlangıç ve tutanak tarihini kaydedip aradaki farkı ölçün. |
| Erişim başvurusuna kanıtlı cevap oranı | Gelen başvuruların tamamı | Log çıktısına dayanarak cevaplanan başvuru / toplam başvuru; yanıt kopyalarından sayın. |
| Açıklanamayan dışa aktarma sayısı | Aylık sıfır | Aylık taramada gerekçesi bulunamayan indirme ve aktarma işlemlerini sayın. |
4 haftalık uygulama planı
1. hafta
Kaydedilecek olay listesini yazın; mevcut yazılımda hangilerinin tutulduğunu test edin.
Kliniğin izleme kapsamı ve boşlukları net.
2. hafta
Kaydın değiştirilemezliğini doğrulayın; saklama süresi ve düzeltici kayıt kuralını belirleyin.
Log artık kanıt değeri taşıyabilecek durumda.
3. hafta
Olay inceleme protokolünü tek sayfada yazıp ekibe duyurun; ilk taramayı yapın.
İnceleme kişiye değil yazılı akışa bağlı.
4. hafta
Dışa aktarma taramasını ve ihlal akışının ilk provasını gerçekleştirin.
Kriz anında kullanılacak yol denenmiş ve ölçülmüş.
Yan etkiler ve dikkat edilecekler
06 · Sık sorulanlar
Hayır; amaç gözetim değil izlenebilirliktir. Hasta verisine dokunan olayları kaydetmek yeterlidir: dosya görüntüleme, kayıt oluşturma ve değiştirme, silme, belge indirme, liste dışa aktarma ile oturum açma denemeleri. Menüde gezinme ya da ekran kaydırma gibi hareketleri loglamak kaydı okunamaz hâle getirir, gerçek sinyali gürültüde boğar. İyi bir denetim kaydı aylarca kimsenin açmadığı, ama bir olay çıktığında tek filtreyle cevap veren kayıttır.
Kanun tek bir süre söylemez; saklama süresi kaydın hizmet ettiği amaca göre belirlenir. Pratikte makul yaklaşım, log süresini ilgili hasta kaydının saklama süresiyle uyumlu tutmak ve geriye dönük incelemelere imkân verecek kadar uzun seçmektir. Çok kısa süre kliniği savunmasız bırakır, süresiz saklama ise yeni bir uyum sorunu doğurur çünkü logun içinde çalışan ve hasta verisi bulunur. Süreyi yazıp imha takvimine bağlayın.
Bozulmaması, uygulamanın nasıl anlatıldığına bağlıdır. Denetim kaydı kişiyi değil, hasta verisini korur; bunu ekibe açıkça söylemek gerekir. Kaydın hangi olayları tuttuğunu, kimin inceleyebildiğini ve neyin incelenmediğini baştan paylaşın. Deneyimde çoğu ekip bu şeffaflıktan rahatsız olmaz, aksine memnun olur: bir kayıt bozulduğunda kimse şüpheli konumuna düşmez, çünkü işlemin sahibi kayıtta zaten bellidir.
Kullanıcı tarafında ek bir işlem yoktur; kayıt, siz çalışırken arka planda oluşur ve ayrıca doldurulacak bir form getirmez. Performans etkisi doğru kurgulanmış bir sistemde hissedilmez. Asıl emek kaydı üretmekte değil, okunabilir tutmakta ve düzenli bakmaktadır: ayda on dakikalık tarama ile yılda bir kez yapılan tatbikat. Bu iki alışkanlık dışında audit log gündelik iş yüküne dokunmaz.
Düzeltmezsiniz; üzerine açıklayıcı yeni bir kayıt eklersiniz. Bu, muhasebedeki ters kayıt mantığıyla aynıdır ve kasıtlı bir tasarım tercihidir: geçmişi değiştirilebilir kılan her istisna, kaydın kanıt değerini sıfırlar. Örneğin bir işlem yanlış hesapla yapıldıysa, doğru açıklama tarihli bir not olarak eklenir ve iki satır birlikte okunur. Böylece hem gerçek akış korunur hem de hata şeffaf biçimde belgelenmiş olur.
Yeterli olmaz; log kanıt tabanıdır, süreç değildir. İhlal yönetimi tespit, sınırlama, kayıt altına alma, Kurula bildirim ve gerektiğinde ilgili kişilere bildirim adımlarından oluşur ve bu adımların yazılı bir planı olmalıdır. Denetim kaydı bu planın en kritik girdisini üretir: kimin hangi kayıtlara eriştiği ve kaç kişinin etkilendiği. Planı olmayan klinik, elinde mükemmel bir log olsa bile yetmiş iki saatlik süreyi doğru kullanamaz.
Pazar sinyali kaynağı: KVKK. Son güncelleme: 28 Temmuz 2026.
Devam eden tedavi
Bir operasyon sorunu tek başına gelmez. Bu reçeteyi tamamlayan diğer adımlarla kliniğinizin akışını bütün olarak kurun.
Tek parolayla herkesin her kaydı gördüğü klinikte veri minimizasyonu kâğıt üzerinde kalır ve sorumluluk tespit edilemez. Bu reçete, görev-veri haritasından yetki matrisine, rol düzenini beş adımda kurmayı anlatır.
Ayrılan bir sekreterin hesabı çoğu klinikte aylarca açık kalır; kimse kapatmayı reddetmez, kimse kapatmakla görevli de değildir. Bu reçete, çıkış gününü yarım saatlik bir erişim kapatma rutinine bağlar ve geride gösterilebilir bir iz bırakır.
Sağlık verisi, KVKK’nın en sıkı koruduğu özel nitelikli veri sınıfındadır; kilitli dolap ve parolalı dosya bu yükü taşımaz. Bu reçete, hasta dosyasını uyumlu, izlenebilir ve tek merkezli hâle getirmenin sırasını verir.
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.
Kimliklendirme ve kayıt bildirimi klinikler için hem yasal bir yükümlülük hem de hasta sahiplerine karşı bir sorumluluktur. Kâğıt üzerinde yürütüldüğünde her ikisi de aksar.
Tek bilgisayarda tutulan hasta verisi, arıza ve fidye yazılımı karşısında tek kopya demektir. Bu reçete kliniğin gerçek risklerini sayar, cihaz tabanını sertleştirir, geri yükleme provasını kurar ve buluta geçiş kararını doğru sorulara bağlar.
PratiVia’yı deneyin
PratiVia’yı hizmetleriniz, hekim kadronuz ve hasta akışınızla birlikte kullanmaya başlayın.
PratiVia ile hemen başlayın
Kayıt ol