KVKK ve Özel Nitelikli Sağlık Verisi: Geliştirici Kontrol Listesi

Sağlık verisi işleyen bir yazılımda KVKK uyumu, sözleşmeye eklenen bir madde değil kodda ve altyapıda karşılığı olan bir gereksinim listesidir. Zorunlulukların kaynağı üç belge: 6698 sayılı Kanun'un 6. maddesi (özel nitelikli veriler), Kişisel Verileri Koruma Kurulu'nun 31/01/2018 tarih ve 2018/10 sayılı kararı (yeterli önlemler) ve Kişisel Sağlık Verileri Hakkında Yönetmelik (RG 21/06/2019, 30808). Bu üçü size somut şeyler söylüyor: veriyi kriptografik yöntemle saklayın, anahtarı ayrı ortamda tutun, tüm hareketleri loglayın, uzaktan erişimde en az iki kademeli kimlik doğrulama kullanın ve bir hekimin hangi hastanın kaydını ne kadar süreyle görebileceğini kodda sınırlayın. Aşağıdaki liste, bu maddelerin yazılım karşılıklarıdır.

Bu yazı hukuki görüş değil, mühendislik kontrol listesidir. Atıf yapılan madde numaraları ve tarihler 25 Eylül 2026'da resmî metinlerden doğrulanmıştır. Mevzuat değişir; projeye başlarken maddelerin güncel hâlini teyit edin.

Önce Hangi Hukuki Sebebe Dayandığınızı Koda Yazın

6698 sayılı Kanun'un 6. maddesi, 2/3/2024 tarihli 7499 sayılı Kanun'la değiştirildi ve 1 Haziran 2024'te yürürlüğe girdi. Değişiklikten önce sağlık ve cinsel hayata ilişkin veriler ayrı bir rejime tabiydi; şimdi tüm özel nitelikli veriler için tek bir liste var. Madde 6/3, işlemenin mümkün olduğu hâlleri yedi bent hâlinde sayıyor. Sağlık yazılımlarında iş gören bent (e):

"Sır saklama yükümlülüğü altında bulunan kişiler veya yetkili kurum ve kuruluşlarca, kamu sağlığının korunması, koruyucu hekimlik, tıbbi teşhis, tedavi ve bakım hizmetlerinin yürütülmesi ile sağlık hizmetlerinin planlanması, yönetimi ve finansmanı amacıyla gerekli olması"

Buradan çıkan mühendislik kararı şu: bir HBYS'de hasta kaydını açmak için açık rıza ekranı koymayın. Dayanak (a) bendi (açık rıza) değil, (e) bendidir. Açık rızayı her yere serpmek uyumu artırmaz; aksine, rıza geri alındığında işlemeyi durdurmanız gerektiği için sistemi imkânsız bir duruma sokar. Rıza gereken yerler ayrıdır ve nettir: ikincil kullanım (pazarlama, üçüncü tarafla paylaşım, ticari analitik) ve Kişisel Sağlık Verileri Hakkında Yönetmelik'in 10. maddesindeki gibi özel hâller.

O 10. madde, avukat erişimi için tek başına bir doğrulama kuralı üretir: "Avukatlar, müvekkilinin sağlık verilerini genel vekâletname ile talep edemezler." Vekâletnamede özel nitelikli verilerin işlenmesine ilişkin açık rızayı gösteren özel bir hüküm aranır. Yani hasta dosyası paylaşım akışınızda "vekâlet var mı?" sorusu yetmez; "vekâlette özel hüküm var mı?" alanı gerekir ve bu bir serbest metin değil, operatörün işaretlediği ve kim işaretlemişse kaydedildiği bir alan olmalıdır.

Madde 6/4 ayrıca şunu söylüyor: "Özel nitelikli kişisel verilerin işlenmesinde, ayrıca Kurul tarafından belirlenen yeterli önlemlerin alınması şarttır." Bu cümle, 2018/10 sayılı kararı tavsiye olmaktan çıkarıp zorunluluk hâline getiren bağlantıdır.

2018/10 Kararı: Denetlenen Somut Liste

Kurul'un 31/01/2018 tarihli kararı, özel nitelikli veri işleyen veri sorumlularının alması gereken önlemleri sayıyor. Elektronik ortam başlığı altındaki maddeler doğrudan altyapı gereksinimidir:

Karar ayrıca idari tarafta üç şey istiyor: özel nitelikli veriler için ayrı bir politika ve prosedür, süreçte yer alan çalışanlara düzenli eğitim, yetkilerin periyodik olarak gözden geçirilmesi ve işten ayrılan personelin yetkisinin derhâl kaldırılması. Son madde teknik bir gereksinimdir: kimlik yönetiminiz İK sisteminizle bağlı değilse "derhâl" gerçekleşmez. Ayrılan kullanıcıyı haftalık bir raporla kapatan kurumlarda o pencere gerçekte yedi gündür.

Erişim Kaydı Yetmez, Erişim Penceresi Gerekir

Kişisel Sağlık Verileri Hakkında Yönetmelik'in 6. maddesi, çoğu HBYS'nin hiç uygulamadığı bir kuralı getiriyor: sağlık hizmeti sunumunda görevli kişiler ilgili kişinin sağlık verilerine "ancak, verilecek olan sağlık hizmetinin gereği ile sınırlı olmak kaydıyla" erişebilir. Maddenin üçüncü fıkrası, e-Nabız hesabı bulunmayan kişiler için bu sınırı süreyle somutlaştırıyor:

Bu bir raporlama kuralı değil, bir yetkilendirme kuralıdır. Rol tabanlı erişim (RBAC) tek başına yetmiyor; "hekim" rolü olan herkesin her hastayı görebildiği bir sistem bu maddeye uymuyor. Gereken şey, hasta ile kullanıcı arasında bağlam kuran bir kontrol:

<?php
// Hasta kaydina erisim yetkisi: rol degil, BAGLAM kontrolu.
// Kisisel Saglik Verileri Hakkinda Yonetmelik m.6/3 karsiligi.

final class HastaErisimPolitikasi
{
    public function gorebilirMi(Kullanici $k, Hasta $h, ?string &$sebep = null): bool
    {
        if ($k->aileHekimiOlduguHastalar()->contains($h->id)) {
            $sebep = 'aile_hekimi';                 // sure siniri yok
            return true;
        }

        if ($h->yatisi?->aktifMi() && $h->yatisi->kurumId === $k->kurumId) {
            $sebep = 'yatan_hasta';                 // taburcuya kadar
            return true;
        }

        if ($h->randevulari()->bugun()->where('hekim_id', $k->id)->exists()) {
            $sebep = 'randevu_gunu';                // yalnizca bugun
            return true;
        }

        if ($h->kurumGirisleri()->sonSaat(24)->where('kurum_id', $k->kurumId)->exists()) {
            $sebep = 'kurum_girisi_24s';            // 24 saatlik pencere
            return true;
        }

        return false;
    }
}

Acil durum için bir kaçış yolu gerekir, ama kaçış yolu sessiz olmamalıdır. Yaygın ve denetimde savunulabilir çözüm "kırmızı düğme" (break-glass): kullanıcı gerekçe girer, erişim açılır, kayıt ayrı bir tabloya yazılır ve sorumlu hekime/veri sorumlusuna bildirim gider. Denetimde sorulacak soru "kimse kural dışı erişti mi?" değil, "kural dışı erişimler görüldü mü ve incelendi mi?" olur.

Yönetmelik ayrıca iki gizlilik senaryosu tanımlıyor ve ikisi de veri modelinizi etkiler. Madde 6/5: geçmiş verilerinin görülmesini istemeyen kişiye e-Nabız üzerinden gizlilik tercihi sunulur ve bu veriler ancak kişinin telefonuna gönderilen kodun hekime iletilip sisteme girilmesiyle açılır. Madde 6/6: mahremiyet düzeyi daha yüksek, bilinmesi kişinin sosyal hayatını ve ruh sağlığını olumsuz etkileme riski taşıyan veriler Bakanlıkça belirlenir ve sağlık personelinin erişimine ölçülü kısıt getirilebilir. Pratikte: tanı/işlem kayıtlarınızda bir mahremiyet_seviyesi alanı olmalı ve bu alan sonradan eklenmesi en pahalı alanlardan biridir.

Ekranda ve Kâğıtta Görünen de Veri Güvenliğidir

Aynı yönetmeliğin 5. maddesi, çoğu geliştiricinin kendi işi saymadığı iki şeyi doğrudan yükümlülük hâline getiriyor. Beşinci fıkra: sağlık hizmeti sunucuları tahlil ve tetkik sonuçları gibi basılı materyal üzerinde "gerekli kısmî kimliksizleştirme veya maskeleme tedbirlerini" uygular ve materyal yetkisiz kişilerin eline geçerse kime ait olduğunun tespitini zorlaştıracak tedbirleri alır.

Yani laboratuvar sonuç çıktınızda TC kimlik numarasını tam basıyorsanız uyumsuzsunuz. Maskeleme tanımı yönetmeliğin 4. maddesinde var: alanların silinmesi, üstlerinin çizilmesi, yıldızlanması gibi işlemler. Uygulaması basit, sonradan eklenmesi ise tüm rapor şablonlarını gözden geçirmeyi gerektiriyor.

Dördüncü fıkra ise banko, gişe ve masa düzeninde aynı anda hizmet alanların birbirinin verisini duymasını, görmesini veya öğrenmesini engelleyecek tedbirleri istiyor. Yazılım tarafındaki karşılığı: kısa ekran kilidi süresi, hasta adını listede kısaltma, çağrı ekranlarında tam ad yerine sıra numarası ve ad baş harfleri.

Saklama ve İmha: Üç Sayı Ezberlenir

Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik (RG 28/10/2017, 30224) üç somut süre veriyor:

• Periyodik imha aralığı azami 6 ay. Veri sorumlusu bu aralığı saklama ve imha politikasında belirler, ama altı ayı aşamaz.
• Politikası olmayan veri sorumlusu için 3 ay. İşleme şartları ortadan kalktıktan sonra üç ay içinde silme, yok etme veya anonim hâle getirme tamamlanır.
• İmha kayıtları en az 3 yıl saklanır. Silme, yok etme ve anonim hâle getirme işlemlerine ilişkin kayıtlar tutulur ve saklanır.

Buna Kişisel Sağlık Verileri Hakkında Yönetmelik'in 11/2. maddesi ekleniyor: "Ölmüş bir kimsenin sağlık verileri, en az 20 yıl süre ile saklanır." Bu iki kural birlikte, sağlık yazılımlarında imha mantığının neden basit bir "X yıl sonra sil" işi olmadığını gösteriyor: saklama süresi veri türüne, hastanın durumuna ve başka mevzuattan gelen yükümlülüklere göre değişir.

Mühendislik tarafında iki hata tekrarlanıyor. Birincisi, deleted_at ile yapılan yumuşak silmeyi imha saymak. Yönetmeliğin silme tanımı "ilgili kullanıcılar için hiçbir şekilde erişilemez ve tekrar kullanılamaz hâle getirilmesi"dir; sorgudan çıkan ama tabloda duran ve rapor ekranından görülebilen bir satır bu tanıma uymaz. İkincisi, yedekleri unutmak. Canlı veritabanından silinen kayıt altı aylık yedeklerde duruyorsa imha tamamlanmamıştır; yedek rotasyon süreniz saklama politikanızla uyumlu olmalıdır.

Anonimleştirme ile kimliksizleştirme aynı şey değildir. Yönetmelik ikisini ayrı tanımlıyor: anonim hâle getirme, verinin başka verilerle eşleştirilerek dahi hiçbir surette kimliği belirli bir kişiyle ilişkilendirilememesidir. Kimliksizleştirme ise "farklı bir ortamda muhafaza edilen diğer verilerle bir araya getirilmeksizin" ilişkilendirilememesi, yani geri döndürülebilir bir işlemdir. TC kimlik numarasını bir tabloda tutup diğer tabloya hash koymak anonimleştirme değildir; hâlâ kişisel veridir ve tüm yükümlülükler devam eder. Bu ayrımı yanlış kuran ekipler "veriyi anonimleştirdik" diyerek analitik ortamına gerçek veri taşır.

Veri İşleyen Sözleşmesi: Madde 12/2 Sizi Müştereken Sorumlu Yapıyor

Kanun'un 12. maddesinin ikinci fıkrası açık: "Veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi tarafından işlenmesi hâlinde, birinci fıkrada belirtilen tedbirlerin alınması hususunda bu kişilerle birlikte müştereken sorumludur." Yazılım firması, bulut sağlayıcı, çağrı merkezi, PACS sağlayıcısı, e-posta gönderim servisi: hepsi veri işleyendir ve hepsi bu fıkranın kapsamındadır.

Bir veri işleyen sözleşmesinde teknik ekibin ısrar etmesi gereken maddeler:

• İhlal bildirimi süresi. Kurul'un 2019/10 sayılı kararına göre veri işleyen, verinin kanuni olmayan yollarla elde edildiğini öğrendiğinde durumu gecikmeksizin veri sorumlusuna bildirir. Sözleşmede bunu saatle tanımlayın; 72 saatlik sayacı veri sorumlusu için işletecek olan sizsiniz.
• Alt işleyen (alt yüklenici) onayı. Sağlayıcının kullandığı üçüncü servisleri (log toplama, hata izleme, yapay zekâ servisi) isim isim listeletin ve değişiklikte önceden bildirim şartı koyun.
• Verinin fiziksel konumu. Madde 9, yeterlilik kararı yoksa uygun güvencelerden birini şart koşuyor: Kurul tarafından ilan edilen standart sözleşme, bağlayıcı şirket kuralları veya taahhütname. Standart sözleşme imzalanmasından itibaren beş iş günü içinde Kuruma bildirilir. Yurt dışında barındırılan bir log servisi bile bu kapsama girer.
• Sözleşme sonunda iade ve imha. Hangi formatta, ne kadar sürede, imha tutanağıyla.
• Denetim hakkı. Madde 12/3, veri sorumlusuna gerekli denetimleri yapma veya yaptırma zorunluluğu getiriyor; bu hak sözleşmede yoksa yükümlülüğü yerine getiremezsiniz.

Hata izleme araçları burada özel bir risk taşıyor. Bir istisna yakalandığında istek gövdesini olduğu gibi üçüncü tarafa gönderen bir kurulum, hasta verisini yurt dışına aktarıyor demektir. Gönderilen alanların maskelenmesi kütüphane ayarı değil, mimari karardır.

72 Saat Sayacı Ne Zaman Başlar?

Kanun'un 12/5. maddesi ihlali "en kısa sürede" bildirmeyi emrediyor. Kurul'un 24/01/2019 tarih ve 2019/10 sayılı kararı bu ifadeyi 72 saat olarak somutlaştırdı: veri sorumlusu ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde Kurula bildirir. Haklı bir gerekçeyle bu süreye uyulamazsa gecikmenin nedenleri de bildirimle birlikte açıklanır. İlgili kişilere bildirim ise etkilenenlerin belirlenmesini takiben makul olan en kısa sürede, doğrudan ulaşılamıyorsa veri sorumlusunun internet sitesi üzerinden yapılır.

Sayaç "ihlali öğrendiğiniz an" başlar ve mühendislik açısından asıl soru budur: öğrenebiliyor musunuz? Erişim logu tutup hiç bakmayan bir sistemde ihlal öğrenilmez, fark edilmez. Somut gereksinimler:

• Anormal erişim tespiti: bir kullanıcının saatlik hasta kaydı açma sayısında eşik ve alarm.
• Toplu dışa aktarma (export) işlemlerinin ayrı loglanması ve ikinci onaya bağlanması.
• Logların uygulama veritabanından ayrı, silinemez (append-only) bir hedefe yazılması. Sistemi ele geçiren kişi logu da siliyorsa log yoktur.
• Nöbet/çağrı planı. 72 saat takvim saatidir; cuma akşamı fark edilen bir ihlalde pazartesi sabahı çoktan geç kalınmıştır.

2026 Ceza Bandı

Kanun'un 18. maddesindeki tutarlar her takvim yılı başında yeniden değerleme oranıyla güncelleniyor. 27 Kasım 2025 tarihli Resmî Gazete'de yayımlanan 585 Sıra No'lu Vergi Usul Kanunu Genel Tebliği ile ilan edilen %25,49 oran üzerinden 2026 tutarları:

Ayrıca 17. madde, kişisel verilere ilişkin suçlarda Türk Ceza Kanunu'nun 135 ila 140. maddelerini işaret ediyor ve silme yükümlülüğüne aykırılığı TCK 138 kapsamına sokuyor. İdari para cezası kurumun, ceza sorumluluğu ise kişinin üzerindedir.

Bu Şurada Kırılıyor

Test ortamına canlı veri kopyalamak. En yaygın ihlal budur ve genellikle hiç fark edilmez. Geliştirici bir hatayı üretmek için canlı yedeği yerel makinesine indirir. O an veri, korumasız bir dizüstü bilgisayardadır. Çözüm yasak koymak değil, maskeleyen bir kopyalama aracı sağlamaktır: yoksa yasak delinir.

Logun kendisinin özel nitelikli veri içermesi. SQL sorgusunu parametreleriyle loglayan bir uygulama, tanı kodlarını ve kimlik numaralarını düz metin olarak diske yazar. Log dosyaları genellikle şifrelenmez, uzun süre saklanır ve erişimi geniştir. Log maskeleme kuralınızı ilk gün yazın.

Yapay zekâ servislerine hasta metni göndermek. Epikriz özetleme, kodlama önerisi, sesli not çözümleme gibi kullanımlar yurt dışına veri aktarımıdır ve Madde 9'un kapsamındadır. Model sağlayıcının "veriyi eğitimde kullanmıyoruz" taahhüdü, aktarımın kendisini hukuka uygun hâle getirmez.

Yetkiyi rolle, kaydı kullanıcıyla eşleştirmek. Ortak kullanılan bir "poliklinik" hesabı varsa erişim logunuz kimin baktığını göstermez. Denetimde işe yaramayan bir log, hiç tutulmamış logdan yalnızca depolama maliyeti kadar farklıdır.

Teslim Öncesi Kontrol Listesi

Sıkça Sorulan Sorular

Hasta kaydı açarken açık rıza almalı mıyım?

Tıbbi teşhis, tedavi ve bakım hizmetlerinin yürütülmesi için hayır. Dayanak Madde 6/3'ün (e) bendidir. Açık rıza, tedavi dışındaki amaçlar (pazarlama, üçüncü tarafla ticari paylaşım, araştırma katılımı) ve mevzuatın ayrıca rıza aradığı hâller için gerekir.

Disk şifrelemem var, bu yeterli mi?

Değil. Kurul kararı verinin kriptografik yöntemlerle muhafazasını ve anahtarların farklı ortamda tutulmasını istiyor. Disk şifreleme yalnızca fiziksel hırsızlığa karşı korur; uygulama sunucusu ayaktayken veri açıktır. Sağlık verisi taşıyan alanları uygulama düzeyinde şifreleyin.

Hangi verileri "özel nitelikli" saymalıyım?

Madde 6/1 listeliyor: ırk, etnik köken, siyasi düşünce, felsefi inanç, din, mezhep veya diğer inançlar, kılık kıyafet, dernek/vakıf/sendika üyeliği, sağlık, cinsel hayat, ceza mahkûmiyeti ve güvenlik tedbirleri, biyometrik ve genetik veriler. Sağlık tarafında yalnızca tanı değil, randevu kaydının varlığı bile bir kliniğe ait olduğunda sağlık verisi hâline gelir.

Kimliksizleştirdiğim veriyi serbestçe kullanabilir miyim?

Hayır. Kimliksizleştirme geri döndürülebilir olduğu için veri hâlâ kişisel veridir. Serbest kullanım yalnızca anonim hâle getirilmiş veri için geçerlidir ve anonimleştirmenin ölçütü "başka verilerle eşleştirilerek dahi ilişkilendirilememe"dir. Küçük hasta gruplarında tek başına yaş ve ilçe bilgisi bile yeniden kimliklendirmeye yeter.

Veri işleyen olarak ihlali ben mi bildireceğim?

Kurula bildirimi veri sorumlusu yapar. Veri işleyen, durumu öğrendiğinde gecikmeksizin veri sorumlusuna bildirmekle yükümlüdür. Sözleşmede bu bildirimin kime, hangi kanaldan ve kaç saat içinde yapılacağını yazın; aksi hâlde veri sorumlusunun 72 saati sizin e-postanızı kimin okuduğuna bağlı olur.

Bulut sağlayıcım yurt dışında, ne yapmalıyım?

Önce yeterlilik kararı olup olmadığına bakılır. Yoksa Madde 9/4'teki uygun güvencelerden biri sağlanmalıdır; kurumsal yapılarda en pratik yol Kurul'un ilan ettiği standart sözleşmedir ve imzadan itibaren beş iş günü içinde Kuruma bildirilmesi gerekir. Bu, teknik değil idari bir iştir ama entegrasyon takviminizde yer kaplar.

Bir Sonraki Adım

Elinizdeki sistemde bugün yapabileceğiniz tek somut iş: veri akış envanteri çıkarmak. Hangi tabloda hangi özel nitelikli alan var, o alan hangi ekranda görünüyor, hangi rapora giriyor, hangi dış servise gidiyor, hangi log dosyasına düşüyor. Bu envanter olmadan şifreleme de maskeleme de eksik kalır, çünkü neyi koruyacağınızı bilmiyorsunuzdur. Envanter çıkınca yukarıdaki kontrol listesi bir haftalık somut iş planına dönüşür.

Sağlık tarafındaki entegrasyon mimarisi için HBYS ve USS entegrasyonu ile MEDULA entegrasyonu rehberlerimize bakabilirsiniz. Güvenlik tarafındaki yaklaşımımızı güvenlik merkezi sayfasında, sağlık projelerimizi sağlık & medikal sayfasında bulabilir, kendi sisteminiz için iletişim sayfasından yazabilirsiniz.

Kaynaklar: 6698 sayılı Kişisel Verilerin Korunması Kanunu (mevzuat.gov.tr resmî tam metin; madde 6, 7, 9, 12, 16, 17, 18); Kişisel Verileri Koruma Kurulu'nun 31/01/2018 tarih ve 2018/10 sayılı Kararı; Kişisel Verileri Koruma Kurulu'nun 24/01/2019 tarih ve 2019/10 sayılı Kararı; Kişisel Sağlık Verileri Hakkında Yönetmelik (RG 21/06/2019, 30808); Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik (RG 28/10/2017, 30224); 585 Sıra No'lu Vergi Usul Kanunu Genel Tebliği (RG 27/11/2025) ile ilan edilen yeniden değerleme oranı. Tamamı 25 Eylül 2026'da okunmuştur.