title: "Hastane Veri Kurtarma ve KVKK Özel Nitelikli Veri: HBYS, PACS, Laboratuvar Sistemleri" description: "Hastane bilişim altyapısında HBYS, PACS, RIS ve LIS sistemleri için veri kurtarma süreçleri, KVKK özel nitelikli sağlık verisi çift koruma yükümlülüğü ve fidye yazılım sonrası kritik müdahale adımları." date: "2026-06-01" author: "DSET Veri Kurtarma Mühendislik Ekibi" category: "Sektörel Veri Kurtarma" tags: ["hastane veri kurtarma", "HBYS", "PACS", "KVKK sağlık verisi", "fidye yazılım", "DICOM"]

Hastane Veri Kurtarma ve KVKK Özel Nitelikli Veri: HBYS, PACS, Laboratuvar Sistemleri

Hastaneler, hem hizmet sürekliliği hem de hukuki sorumluluk bakımından bilişim olaylarına en duyarlı kurumlardır. Bir HBYS sunucusunun saatlerce ayakta kalmaması, planlı ameliyat ertelemelerinden acil servis triyajının manuele dönmesine, eczane ilaç barkod doğrulamasının durmasına kadar zincirleme etkiler yaratır. Aynı kesinti, KVKK madde 6 kapsamında özel nitelikli kişisel veri kategorisinde değerlendirilen sağlık verisinin gizliliği, bütünlüğü ve erişilebilirliği açısından da ciddi sonuçlar doğurabilir. Bu yazıda hastane bilişim ortamının üç temel yığını olan HBYS, PACS ve LIS sistemlerinde veri kaybı senaryolarını, kurtarma stratejilerini ve KVKK uyum çerçevesini ele alıyoruz.

Bu makale, ana rehberimiz olan Veri Kurtarma Rehberi 2026 içeriğinin sağlık sektörüne özgü destekleyici bölümüdür. Bilgi işlem yöneticileri, başhekim yardımcıları, KVKK irtibat kişileri ve teknik servis ekipleri için yazılmıştır.

Hastane Bilişim Mimarisinin Katmanları

Modern bir hastanenin bilişim altyapısı, görünenden çok daha katmanlıdır. Bir hastanın acil servise kabulünden taburcusuna kadar geçen süreçte onlarca alt sistem birbiriyle konuşur. Veri kurtarma planı yaparken bu katmanların her birinin iş etkisi ve veri tipi ayrı ayrı haritalanmalıdır.

HBYS (Hastane Bilgi Yönetim Sistemi)

HBYS, hastanenin operasyonel omurgasıdır. Hasta kayıt, randevu, yatış, taburcu, fatura, SGK MEDULA entegrasyonu, e-reçete, e-rapor süreçleri buradan yürür. Tipik bir HBYS veritabanı Oracle, MSSQL veya PostgreSQL üzerinde çalışır ve günlük yüzbinlerce işlem yazar. Yedekleme stratejisi genellikle gece tam yedek artı saatlik log yedeği şeklinde kurulur.

HBYS veri kaybı senaryoları:

  • Veritabanı sunucusunda RAID dizisi çökmesi (özellikle eski donanımda RAID 5 üzerinde ikinci disk fail durumu).
  • Yanlış DELETE veya TRUNCATE çalıştırılması; geliştirme ortamı ile üretim ortamının karıştırılması.
  • Yedek sunucu olarak konumlandırılan ikinci makineye replikasyonun aslında bozuk akmış olması; kontrol edildiğinde sadece şemanın geldiği, son üç aylık verinin gelmediği vakalar.
  • Fidye yazılım sonrası DBF, MDF, LDF, BAK, FRM, IBD dosyalarının şifrelenmesi.

PACS ve RIS (Görüntüleme Sistemleri)

PACS yani Picture Archiving and Communication System, MR, BT, ultrason, mamografi, röntgen cihazlarının ürettiği görüntülerin saklandığı, DICOM standardına uygun arşiv katmanıdır. RIS yani Radiology Information System ise radyoloji bölümünün iş akışını, randevu, tetkik, raporlama süreçlerini yönetir. PACS arşivleri TB seviyesinden başlar, üniversite hastanelerinde PB seviyesine ulaşabilir.

PACS tarafındaki kurtarma zorlukları:

  • DICOM dosyaları çok sayıda küçük dosya halindedir; bir hasta tetkikinde 500 ile 2000 arasında .dcm dosyası bulunabilir. Klasör başına dosya sayısı yüksek olduğu için dosya sistemi metadata bozulması büyük etki yaratır.
  • Görüntüler genellikle iki kademeli depolamada tutulur: yakın erişim için SAS veya NVMe disk, uzun arşiv için NAS veya tape. Soğuk arşiv erişiminde LTO bantlarının bozulması ciddi bir risktir.
  • Çoğu kurumda PACS sunucusu üreticiye özgü bir veri tabanı kullanır; ham DICOM dosyalarını geri kazansanız bile çalışma listesi ile eşleme bozulursa görüntü hastaya bağlanmaz hale gelir.

DICOM standardının tanımladığı meta veri yapısı için resmi referans dicomstandard.org adresinde yer alır. Veri kurtarma sırasında DICOM tag bütünlüğünün korunması, görüntünün klinik olarak kullanılabilir olması için zorunludur.

LIS (Laboratuvar Bilgi Sistemi)

LIS, biyokimya, mikrobiyoloji, patoloji, kan bankası gibi laboratuvarların tetkik isteklerini, cihaz sonuçlarını ve raporları yöneten katmandır. Cihazlardan gelen sonuçlar genellikle HL7 mesajlaşma standardı ile LIS'e iletilir, oradan HBYS'ye geçer. HL7 spesifikasyonu için hl7.org referans alınır.

LIS verisindeki kayıplar özellikle hassastır çünkü patoloji raporları ve kan bankası eşleştirme verileri gibi kayıtlar tek nüsha üretilir ve onkoloji takibi gibi uzun yıllar süren süreçlerde kritik öneme sahiptir. LIS yedeklerinde sıkça karşılaşılan sorunlar:

  • Cihaz ara yüzleri ile LIS arasındaki ara katmanın (interface engine) loglarının yedeklenmemiş olması.
  • Patoloji görüntülerinin ayrı bir dijital patoloji sunucusunda tutuluyor olması ve bu sunucunun ana yedekleme politikasının dışında bırakılması.
  • Mikroskobun ürettiği whole slide image dosyalarının onlarca GB boyutlarda olması sebebiyle yedekleme penceresine sığmaması.

e-Nabız ve Ulusal Entegrasyon

Hastane sistemleri Sağlık Bakanlığı e-Nabız platformuna düzenli veri akışı sağlar. e-Nabız resmi sayfası enabiz.gov.tr adresinde yer alır. Hastanedeki veri kaybı çoğu zaman e-Nabız tarafına çoktan yansımış kayıtların yerel kopyasının kaybedilmesi anlamına gelir; ancak hukuki sorumluluk yerel veri sorumlusunda kalmaya devam ettiği için merkez kopya tek başına yeterli savunma sayılmaz.

KVKK Özel Nitelikli Veri: Çift Koruma Yükümlülüğü

Sağlık verisi, 6698 sayılı Kişisel Verilerin Korunması Kanunu madde 6'da sayılan özel nitelikli kişisel veriler arasındadır. Kanunun resmi metnine mevzuat.gov.tr/MevzuatMetin/1.5.6698.pdf adresinden ulaşılabilir. KVKK'nın yayımladığı sağlık verisi rehberleri kvkk.gov.tr üzerinde duyurulmaktadır.

Özel nitelikli veri statüsü, sıradan kişisel veriye göre daha sıkı koruma yükümlülüğü doğurur. Veri kurtarma süreci bakımından bu yükümlülüğün üç pratik yansıması vardır:

  1. Erişim disiplini. Kurtarma sırasında ham veri parçalarına erişen her teknisyen, ayrı taahhüt altına alınmalı, işlem adımları kayıt altında olmalıdır.
  2. Saklama lokasyonu. Kurtarma laboratuvarı, sağlık verisinin yurt içinde işlenmesi tercihiyle uyumlu olmalıdır. Bulut tabanlı, sınır ötesine çıkan analiz yöntemleri özel nitelikli veri için sakıncalıdır.
  3. Şifreleme ve imha. Geri kazanılan veri hastaneye teslim edildikten sonra kurtarma ortamındaki ara kopyalar NIST 800-88 veya muadili standartlara uygun şekilde imha edilmelidir.

Çift koruma kavramı şu anlama gelir: hem hastane bir veri sorumlusu sıfatıyla yükümlüdür, hem de kurtarma hizmeti veren firma veri işleyen sıfatıyla aynı sıkılıkta tedbir almak zorundadır. Aralarındaki sözleşme, KVKK madde 12'nin gerektirdiği teknik ve idari tedbirleri açıkça yansıtmalıdır.

Fidye Yazılım Senaryosu: Hastanede İlk Saatler

Hastane fidye yazılım vakaları, kamuya açık örneklerle birlikte literatüre girmiştir. İrlanda Sağlık Servisi HSE'nin 2021 yılında yaşadığı geniş çaplı saldırı, ulusal sağlık sisteminin haftalarca etkilendiği bir vakadır ve hadise sonrasında HSE tarafından yayımlanan bağımsız değerlendirme raporu kamuya açıktır. ABD'de de çeşitli hastane ağlarının fidye yazılım sebebiyle hizmetlerini sınırlamak zorunda kaldığı dönemler yaşanmıştır. Bu vakalar bize şunu öğretir: hastane fidye yazılımı sadece bir BT olayı değildir, klinik bir olaydır.

Bir hastane fidye yazılımı tespit ettiğinde ilk 24 saatte yapılması gerekenler için ayrıntılı süreç Fidye yazılım ilk 24 saat rehberinde anlatılmıştır. Hastaneye özgü olarak öne çıkan ek adımlar:

  • Klinik düşürme planı. HBYS olmadan acil servisin nasıl çalışacağı, eczane ilaç çıkışlarının nasıl yapılacağı, laboratuvar sonuçlarının nasıl raporlanacağı önceden tatbikat edilmiş olmalıdır.
  • Görüntüleme yedeği. Acil cerrahi vakalarda BT cihazına yerel olarak kaydedilen görüntülerin PACS'a yazamadan önce CD veya USB üzerinden ameliyat ekibine ulaştırılması süreci tanımlanmalıdır.
  • Kan bankası izolasyonu. Kan bankası eşleştirme sistemleri, mümkün olduğunca diğer ağdan ayrık tutulmalı ve fidye yazılım olayında çevrim dışı manuel cross match prosedürüne geçilebilmelidir.

Şifreli sunucuların ham diskleri kapatılmadan önce bellek imajı alınmalıdır; ancak bu yapılırken bütünlük zinciri korunmalıdır. ISO/IEC 27037 standardı, dijital delil tanımlama, toplama ve koruma süreçleri için referanstır ve iso.org/standard/44381.html sayfasından erişilir. Hastane olaylarında bu standart hem adli süreçler hem KVKK tarafındaki olay raporlaması için belirleyicidir. Adli bilişim süreciyle veri kurtarma süreci aynı laboratuvarda paralel olarak ilerletilebilir.

Olay tespit edildikten sonraki en geç 72 saat içinde KVKK'ya bildirim yükümlülüğü doğar. Süreç ve form için KVKK veri ihlali bildirimi rehberi takip edilmelidir.

Hastane RAID ve Depolama Mimarisi Üzerine Notlar

Hastanelerde halen aktif çalışan birçok HBYS sunucusu, eski nesil RAID 5 dizileri üzerinde durmaktadır. RAID 5'in çift disk arıza toleransının olmaması, kapasitenin TB seviyesine çıktığı 2020 sonrası dönemde ciddi bir risk haline gelmiştir; yeniden inşa süresi uzadıkça ikinci diskin de düşme olasılığı artar. Yeni kurulan hastane sistemlerinde RAID 6 veya RAID 10, hatta dağıtık nesne depolama tercih edilir hale gelmiştir.

Veri kurtarma açısından RAID dizilerinde dikkat edilmesi gereken üç temel kural:

  1. Diskler düştükten sonra yeniden senkron başlatılmamalıdır; bozuk dizinin üstüne rebuild komutu vermek, kurtarma şansını dramatik şekilde düşürür.
  2. Disklerin sıralaması fiziksel olarak işaretlenmelidir. Üreticinin kontrolcü meta verisi okunamadığında doğru sıralama deneme yanılma ile yeniden inşa edilir.
  3. PACS gibi yüksek kapasiteli dizilerde klon temelli çalışma esastır. Üzerinde kurtarma denemesi yapılan disk, asla orijinal disk olmamalıdır.

PACS sunucularındaki depolama, klinik tıbbi cihaz ekosisteminin bir parçası olduğu için ISO 13485 kalite yönetim standardı kapsamına da girer; standart için iso.org/standard/59752.html referans alınabilir. Üretici bakım sözleşmesi ile veri kurtarma müdahalesi arasındaki sınır, garantiyi koruyacak şekilde önceden netleştirilmelidir.

Yedekleme Stratejisinin Hastaneye Özgü Boyutu

HIMSS, sağlık bilişiminin uluslararası referans çatı kuruluşlarındandır ve dijital olgunluk modelleri himss.org üzerinde tanımlanır. Olgunluk seviyelerinin yükselmesi, doğrudan iyi bir yedekleme ve felaket kurtarma planına bağlıdır. Hastane için önerilen yedekleme çerçevesi:

  • HBYS için günde en az bir tam yedek, 15 dakikalık aralıklarla işlem log yedeği, en az bir kopya farklı bina veya farklı şehirdeki sahaya replike edilmiş olmalı.
  • PACS için yakın arşivin yanında soğuk arşiv (LTO veya nesne depolama), ek olarak yıllık periyodik bütünlük testi (DICOM dosyalarının rastgele örnekleme ile açılabilirliği kontrol edilmelidir).
  • LIS için cihaz ara yüzü logları ve patoloji görüntüleri ayrı bir yedek politikasına alınmalı.
  • Konfigürasyon yedeği unutulmamalıdır. HL7 mesajlaşma kuralları, MEDULA entegrasyon parametreleri, sertifikalar, e-imza yapılandırmaları yedekte yoksa veri geri gelse bile sistem üç gün ayakta kalkmayabilir.
  • Çevrim dışı kopya zorunludur. Fidye yazılım yedek alanına da bulaştığında geri dönüşün tek yolu çevrim dışı kopyadır.

Eczane, Kan Bankası ve Tıbbi Cihaz Entegrasyonları

Hastane bilişim ortamında çoğu zaman ikinci planda kalan, ancak veri kaybı durumunda kritik aksaklık üreten alt sistemler de vardır. Eczane otomasyonu, ilaç barkod doğrulama, robotik ilaç hazırlama hatları, narkotik takip defteri, kan bankası izlenebilirlik kayıtları ve dializ cihazlarının seans logları bu gruba girer. Bu sistemlerin ortak özelliği, çoğunlukla tek noktada çalışmaları ve merkezi yedekleme kapsamına alınmamış olmalarıdır.

Veri kurtarma planı hazırlanırken sorulması gereken pratik sorular şunlardır:

  • Eczanedeki narkotik defterinin elektronik kayıtları gece yedeğine giriyor mu, yoksa sadece eczane sunucusunda mı tutuluyor?
  • Kan bankası sıcaklık kayıtları, soğuk zincir loglarını yöneten yazılım hangi sıklıkta dışa aktarılıyor?
  • Diyaliz makinelerinin seans logları hangi sürede merkeze çekiliyor?
  • Anestezi kayıt cihazlarının ürettiği veriler hasta dosyasına HBYS üzerinden mi, yoksa ayrı bir modülden mi düşüyor?

Bu sorulara verilen cevap "bilmiyorum" ise, veri kaybı henüz yaşanmamış olsa bile risk fiilen yaşanıyor demektir. Hastane bilgi işlem yöneticilerinin yılda en az iki kez alt sistem yedek envanteri tablosu hazırlaması, kaybı önlemenin en ucuz adımıdır.

Sanallaştırma Katmanı ve Snapshot Yanılgısı

Hastane sunucularının büyük bölümü VMware, Hyper-V veya Proxmox gibi sanallaştırma platformları üzerinde çalışır. Bilgi işlem ekipleri zaman zaman snapshot mekanizmasını yedek sanarak hareket eder. Bu son derece riskli bir yanılgıdır. Snapshot, ana diskin üzerine yazılan değişiklikleri ayrı bir dosyada tutar; ana disk bozulduğunda snapshot tek başına bir anlam ifade etmez. Üstüne üstlük, uzun süre silinmemiş snapshot zincirleri performansı düşürür ve birikim halinde veritabanı tutarsızlığı üretebilir.

Hastane sanal makineleri için pratik kural:

  • Snapshot sadece bakım ve sürüm yükseltme öncesi kısa süreli olarak alınmalı, işlem biter bitmez kaldırılmalıdır.
  • Sanal makinenin VMDK veya VHDX dosyaları uygulama tutarlı olarak alınan yedeklerle korunmalıdır; bu, veritabanı motorunun yedek anında işlemleri tutarlı bir noktaya getirmesi anlamına gelir.
  • Sanallaştırma deposunun (datastore) altındaki LUN'un kendisi de yedeklenmiş olmalıdır; tek başına sanal makine yedeği, depo bozulmasında her zaman yeterli olmaz.

Kurtarma Sonrası Klinik Doğrulama

Veri kurtarma teknik anlamda bittikten sonra hastanede atılacak son adım, klinik doğrulamadır. Bilgi işlem ekibi veriyi geri getirdiğini söyler, ancak bu yeterli değildir. Doğrulamada şu kontroller yapılmalıdır:

  • Önceki hafta yatışı kapanmış 20 vakanın taburcu epikrizleri eksiksiz mi?
  • Son üç gün içinde verilen patoloji raporlarının metni, eski çıktılarla bire bir eşleşiyor mu?
  • PACS üzerinde rastgele seçilen 50 tetkikin görüntüleri ve raporları açılıyor mu?
  • e-reçete ve e-rapor zincirinde imza zinciri kırılmış mı?
  • MEDULA fatura kalemleri tutarlı mı?

Bu doğrulama tutanağa bağlanmalı ve KVKK iç sicilinde olay kapanış kaydı olarak tutulmalıdır.

DSET Sağlık Sektörü Acil Müdahale Hizmeti

DSET ekibi, Hacettepe Teknokent Ankara üzerinde konumlanan laboratuvarında hastane bilişim sistemlerine yönelik 7 gün 24 saat acil müdahale kapsamı sunar. Sağlık altyapısı kritik altyapı sınıfında değerlendirildiği için olay başvurusu alındığı andan itibaren süreç mühendis düzeyinde çalıştırılır, formal yanıt akışı beklenmez. Hizmet kapsamı:

  • HBYS, PACS, RIS, LIS sunucularında RAID, sanallaştırma ve veritabanı düzeyinde veri kurtarma.
  • Fidye yazılım sonrası şifrelenmiş veritabanı dosyalarında ham veri çıkarımı ve, mümkün olduğunda, mantıksal yeniden yapılandırma.
  • DICOM bütünlük analizi, hasta kimlik bilgisi ile görüntü eşlemesinin yeniden kurulması.
  • KVKK olay raporlaması için teknik delil paketi hazırlanması (zaman damgalı imaj, hash listesi, müdahale kayıt defteri).
  • ISO/IEC 27037 uyumlu zincirleme delil yönetimi.

Hastanenizde HBYS ayakta değilse, PACS arşivinden veri çekilemiyorsa, LIS sonuçları kayıp görünüyorsa veya fidye yazılım uyarısıyla karşılaştıysanız sistemlere ek müdahale yapmadan +90 536 662 38 09 numaralı acil hattımızdan bizi arayın. Müdahale ekibimiz, sahaya gelmeden önce uzaktan ilk değerlendirmeyi yapar, klinik aksamayı en aza indirecek sıralamayı belirler ve veri kurtarma sürecini KVKK yükümlülüklerinizle paralel ilerletir.

Kurumunuzun veri ortamı emanettir, sağlık verisi hastanın en hassas verisidir; bu emanetin korunması ve gerektiğinde geri kazanılması ortak sorumluluğumuzdur.