title: "Hospital Data Recovery and KVKK Special Category Data: HBYS, PACS, and Laboratory Systems" description: "Data recovery processes for HBYS, PACS, RIS, and LIS systems in hospital IT infrastructure, the dual protection obligation for KVKK special category health data, and critical response steps after a ransomware attack." date: "2026-06-01" author: "DSET Data Recovery Engineering Team" category: "Sector Data Recovery" tags: ["hospital data recovery", "HBYS", "PACS", "KVKK health data", "ransomware", "DICOM"]

Hospital Data Recovery and KVKK Special Category Data: HBYS, PACS, and Laboratory Systems

Hospitals are among the institutions most sensitive to IT incidents, both in terms of service continuity and legal liability. When an HBYS server stays down for hours, the effects cascade: scheduled surgeries are postponed, emergency department triage reverts to manual processes, and pharmacy drug barcode verification grinds to a halt. The same outage can also have serious consequences for the confidentiality, integrity, and availability of health data, which is treated as special category personal data under KVKK Article 6. In this article, we examine data loss scenarios, recovery strategies, and the KVKK compliance framework for the three core stacks of a hospital IT environment: HBYS, PACS, and LIS.

This article is a sector specific supporting section to our main guide, Data Recovery Guide 2026. It is written for IT managers, deputy chief physicians, KVKK contact persons, and technical support teams.

The Layers of Hospital IT Architecture

A modern hospital's IT infrastructure is far more layered than it appears. From a patient's admission to the emergency department through to their discharge, dozens of subsystems communicate with one another. When building a data recovery plan, the business impact and data type of each of these layers must be mapped out separately.

HBYS (Hospital Information Management System)

HBYS is the operational backbone of the hospital. Patient registration, appointments, admissions, discharges, billing, SGK MEDULA integration, e-prescription, and e-report processes all run through it. A typical HBYS database runs on Oracle, MSSQL, or PostgreSQL and writes hundreds of thousands of transactions per day. The backup strategy is usually set up as a full nightly backup plus hourly log backups.

HBYS data loss scenarios:

  • A RAID array failure on the database server (especially a second disk failure on RAID 5 in older hardware).
  • An accidental DELETE or TRUNCATE; confusing the development environment with the production environment.
  • Replication to a second machine positioned as a backup server having actually streamed in a corrupted state; cases where, on inspection, only the schema arrived but the last three months of data did not.
  • Encryption of DBF, MDF, LDF, BAK, FRM, and IBD files following a ransomware attack.

PACS and RIS (Imaging Systems)

PACS, or Picture Archiving and Communication System, is the archive layer that stores the images produced by MRI, CT, ultrasound, mammography, and X-ray devices, in compliance with the DICOM standard. RIS, or Radiology Information System, manages the radiology department's workflow: its appointment, examination, and reporting processes. PACS archives start in the terabyte range and can reach the petabyte range in university hospitals.

The recovery challenges on the PACS side:

  • DICOM files come as large numbers of small files; a single patient examination may contain between 500 and 2,000 .dcm files. Because the number of files per folder is so high, file system metadata corruption has a major impact.
  • Images are usually kept in two tier storage: SAS or NVMe disks for fast access, and NAS or tape for long term archiving. LTO tape degradation is a serious risk when accessing the cold archive.
  • In most institutions the PACS server uses a vendor specific database; even if you recover the raw DICOM files, the image becomes impossible to link to the patient if the mapping to the worklist is broken.

The official reference for the metadata structure defined by the DICOM standard is available at dicomstandard.org. Preserving DICOM tag integrity during data recovery is essential for the image to remain clinically usable.

LIS (Laboratory Information System)

LIS is the layer that manages test requests, device results, and reports for laboratories such as biochemistry, microbiology, pathology, and the blood bank. Results from devices are usually transmitted to the LIS via the HL7 messaging standard, and from there to HBYS. The HL7 specification is referenced at hl7.org.

Losses in LIS data are particularly sensitive, because records such as pathology reports and blood bank cross match data are produced in a single copy and are critically important in long running processes such as oncology follow up. Common problems with LIS backups:

  • The logs of the interface engine between device interfaces and the LIS not being backed up.
  • Pathology images being kept on a separate digital pathology server, and that server being left out of the main backup policy.
  • The whole slide image files produced by the microscope being tens of gigabytes in size, and therefore not fitting within the backup window.

e-Nabiz and National Integration

Hospital systems provide a regular flow of data to the Ministry of Health's e-Nabiz platform. The official e-Nabiz page is at enabiz.gov.tr. Data loss within a hospital often means losing the local copy of records that have already been reflected on the e-Nabiz side; however, since legal liability remains with the local data controller, the central copy alone is not considered a sufficient defense.

KVKK Special Category Data: The Dual Protection Obligation

Health data is among the special category personal data listed in Article 6 of Law No. 6698 on the Protection of Personal Data. The official text of the law can be accessed at mevzuat.gov.tr/MevzuatMetin/1.5.6698.pdf. The health data guidelines published by the KVKK Authority are announced at kvkk.gov.tr.

Special category status creates a stricter protection obligation than ordinary personal data. For the data recovery process, this obligation has three practical implications:

  1. Access discipline. Every technician who accesses raw data fragments during recovery must be placed under a separate undertaking, and the processing steps must be logged.
  2. Storage location. The recovery laboratory must be consistent with the preference for processing health data within the country. Cloud based analysis methods that cross borders are inadvisable for special category data.
  3. Encryption and disposal. After the recovered data is delivered to the hospital, the intermediate copies in the recovery environment must be disposed of in accordance with NIST 800-88 or equivalent standards.

The concept of dual protection means the following: the hospital is liable in its capacity as a data controller, and the firm providing the recovery service must take measures with the same rigor in its capacity as a data processor. The contract between them must clearly reflect the technical and administrative measures required by KVKK Article 12.

The Ransomware Scenario: The First Hours in a Hospital

Hospital ransomware cases have entered the literature alongside publicly documented examples. The large scale attack experienced by Ireland's Health Service Executive (HSE) in 2021 is a case in which the national health system was affected for weeks, and the independent assessment report published by the HSE afterward is publicly available. In the United States, too, there have been periods when various hospital networks had to limit their services because of ransomware. These cases teach us one thing: hospital ransomware is not just an IT incident, it is a clinical incident.

The detailed process for what should be done in the first 24 hours when a hospital detects ransomware is described in the Ransomware: The First 24 Hours guide. The additional steps that stand out as hospital specific:

  • Clinical downgrade plan. How the emergency department will operate without HBYS, how pharmacy drug dispensing will be carried out, and how laboratory results will be reported must have been rehearsed in advance.
  • Imaging backup. For emergency surgical cases, a process must be defined for delivering images saved locally on the CT device to the surgical team via CD or USB before they can be written to PACS.
  • Blood bank isolation. Blood bank cross matching systems should be kept as separate as possible from the rest of the network, and it should be possible to switch to an offline manual cross match procedure in a ransomware incident.

A memory image of encrypted servers must be taken before they are shut down; however, the chain of integrity must be preserved while doing so. The ISO/IEC 27037 standard is the reference for the processes of identifying, collecting, and preserving digital evidence, and it can be accessed at iso.org/standard/44381.html. In hospital incidents this standard is decisive for both legal proceedings and incident reporting on the KVKK side. The digital forensics process can be advanced in parallel with the data recovery process in the same laboratory.

A notification obligation to the KVKK Authority arises within 72 hours at the latest after the incident is detected. The KVKK data breach notification guide should be followed for the process and the form.

Notes on Hospital RAID and Storage Architecture

Many HBYS servers still running actively in hospitals stand on older generation RAID 5 arrays. RAID 5's lack of dual disk fault tolerance has become a serious risk in the post 2020 period as capacities have climbed into the terabyte range; the longer the rebuild takes, the higher the probability that a second disk will also fail. In newly built hospital systems, RAID 6 or RAID 10, and even distributed object storage, have become the preferred choices.

Three fundamental rules to observe with RAID arrays from a data recovery perspective:

  1. Resynchronization must not be started after disks have failed; issuing a rebuild command on top of a broken array dramatically reduces the chances of recovery.
  2. The order of the disks must be marked physically. When the controller's vendor metadata cannot be read, the correct order is reconstructed through trial and error.
  3. On high capacity arrays such as PACS, working on a clone basis is essential. The disk on which a recovery attempt is made must never be the original disk.

Because the storage on PACS servers is part of the clinical medical device ecosystem, it also falls within the scope of the ISO 13485 quality management standard; the standard can be referenced at iso.org/standard/59752.html. The boundary between the vendor maintenance contract and the data recovery intervention should be clarified in advance in a way that preserves the warranty.

The Hospital Specific Dimension of Backup Strategy

HIMSS is one of the international umbrella reference organizations for health informatics, and its digital maturity models are defined at himss.org. Rising maturity levels are directly tied to a good backup and disaster recovery plan. The recommended backup framework for a hospital:

  • For HBYS, at least one full backup per day, a transaction log backup at 15 minute intervals, and at least one copy replicated to a site in a different building or a different city.
  • For PACS, a cold archive (LTO or object storage) alongside the near archive, plus an annual periodic integrity test (the openability of DICOM files should be checked through random sampling).
  • For LIS, device interface logs and pathology images should be placed under a separate backup policy.
  • The configuration backup must not be forgotten. If the HL7 messaging rules, MEDULA integration parameters, certificates, and e-signature configurations are not in the backup, the system may not stay up for three days even if the data is recovered.
  • An offline copy is mandatory. When ransomware also infects the backup area, the only way back is the offline copy.

Pharmacy, Blood Bank, and Medical Device Integrations

In a hospital IT environment there are also subsystems that often take a back seat but produce critical disruption in the event of data loss. Pharmacy automation, drug barcode verification, robotic drug preparation lines, the narcotics tracking register, blood bank traceability records, and dialysis device session logs all fall into this group. The common feature of these systems is that they mostly run on a single point and are not included in centralized backup coverage.

The practical questions that should be asked when preparing a data recovery plan are:

  • Do the electronic records of the narcotics register in the pharmacy go into the nightly backup, or are they kept only on the pharmacy server?
  • How frequently is the software managing blood bank temperature records and cold chain logs exported?
  • Over what period are the session logs of dialysis machines pulled to the center?
  • Does the data produced by anesthesia recording devices land in the patient file via HBYS, or from a separate module?

If the answer to these questions is "I don't know," then even if no data loss has occurred yet, the risk is effectively already present. The cheapest step toward preventing loss is for hospital IT managers to prepare a subsystem backup inventory table at least twice a year.

The Virtualization Layer and the Snapshot Fallacy

The bulk of hospital servers run on virtualization platforms such as VMware, Hyper-V, or Proxmox. IT teams sometimes act as if the snapshot mechanism were a backup. This is an extremely risky fallacy. A snapshot keeps the changes written over the main disk in a separate file; when the main disk is corrupted, the snapshot means nothing on its own. To make matters worse, snapshot chains that go undeleted for a long time degrade performance and, as they accumulate, can produce database inconsistency.

The practical rule for hospital virtual machines:

  • A snapshot should be taken only briefly before maintenance and version upgrades, and removed as soon as the operation is complete.
  • The VMDK or VHDX files of a virtual machine must be protected with application consistent backups; this means the database engine brings transactions to a consistent point at the moment of backup.
  • The LUN beneath the datastore must itself also be backed up; a virtual machine backup alone is not always sufficient when the datastore is corrupted.

Post Recovery Clinical Validation

Once data recovery is technically complete, the final step to take in the hospital is clinical validation. The IT team will say the data has been restored, but this is not enough. The following checks should be performed during validation:

  • Are the discharge summaries of 20 cases whose admissions closed in the previous week complete?
  • Does the text of pathology reports issued in the last three days match the old printouts exactly?
  • Do the images and reports of 50 randomly selected examinations on PACS open?
  • Has the signature chain in the e-prescription and e-report chain been broken?
  • Are the MEDULA invoice line items consistent?

This validation must be documented in a record and kept as an incident closure record in the internal KVKK register.

DSET Health Sector Emergency Response Service

The DSET team, in its laboratory located at Hacettepe Teknokent in Ankara, offers 24/7 emergency response coverage for hospital IT systems. Because health infrastructure is classified as critical infrastructure, the process is run at engineer level from the moment the incident report is received, without waiting for a formal response flow. The scope of the service:

  • Data recovery at the RAID, virtualization, and database levels on HBYS, PACS, RIS, and LIS servers.
  • Raw data extraction from database files encrypted after ransomware and, where possible, logical reconstruction.
  • DICOM integrity analysis and the reestablishment of the mapping between patient identity information and the image.
  • Preparation of a technical evidence package for KVKK incident reporting (timestamped image, hash list, intervention logbook).
  • ISO/IEC 27037 compliant chain of custody management.

If HBYS is down in your hospital, if data cannot be pulled from the PACS archive, if LIS results appear lost, or if you have encountered a ransomware alert, call our emergency line at +90 536 662 38 09 without making any further intervention to the systems. Before coming on site, our response team performs an initial remote assessment, determines the sequence that will minimize clinical disruption, and advances the data recovery process in parallel with your KVKK obligations.

Your institution's data environment is a trust; health data is a patient's most sensitive data. Protecting that trust and, when necessary, recovering it, is our shared responsibility.