SOP Disaster Recovery & Backup DICOM Radiologi Faskes

Insiden kegagalan perangkat keras server, kerusakan partisi RAID, atau serangan ransomware pada instalasi radiologi dapat menghentikan seluruh layanan diagnostik rumah sakit. Kehilangan arsip citra medis DICOM bukan hanya menghambat tindakan medis pasien gawat darurat, tetapi juga melanggar ketentuan hukum retensi rekam medis.

Dokumen ini memaparkan Standar Operasional Prosedur (SOP) Disaster Recovery (DR) dan arsitektur backup teruji untuk sistem PACS fasilitas kesehatan.

---

Arsitektur Backup DICOM 3-2-1 untuk Fasilitas Kesehatan

Sistem PACS memproses dua jenis data yang memiliki karakteristik penyimpanan berbeda:

1. Layer Metadata Transaksional: Database relasional (PostgreSQL / MySQL) yang menyimpan data pasien, nomor rekam medis, Accession Number, serta teks ekspertise dokter.
2. Layer Objek Citra Diagnostik: File biner *.dcm berukuran 10 MB hingga 2 GB per pemeriksaan (CT-Scan / MRI).

+-------------------------------------------------------------------------------+
|                      ARSITEKTUR BACKUP 3-2-1 RADIOLOGI FASKES                 |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ Modalitas Rontgen / CT / MRI ]                                             |
|                |                                                              |
|                v                                                              |
|  +-----------------------------+                                              |
|  | 1. Primary NVMe PACS Server | ---- (Live Diagnostic Production)            |
|  +-----------------------------+                                              |
|                |                                                              |
|       (Rsync / WAL / 4 Jam)                                                   |
|                v                                                              |
|  +-----------------------------+                                              |
|  | 2. On-Prem NAS Local Backup | ---- (Secondary Copy - Local Network)        |
|  +-----------------------------+                                              |
|                |                                                              |
|     (TLS 1.3 / S3 Object Lock)                                                |
|                v                                                              |
|  +-----------------------------+                                              |
|  | 3. Cloud S3 Immutable Vault | ---- (Offsite Copy - Anti-Ransomware WORM)   |
|  +-----------------------------+                                              |
|                                                                               |
+-------------------------------------------------------------------------------+

3 Salinan Data Wajib:

• Salinan 1 (Primary): Tersimpan di penyimpanan lokal server produksi (NVMe SSD RAID 10) untuk akses instan workstation dokter.
• Salinan 2 (Secondary Local): Tersimpan di perangkat Network Attached Storage (NAS) terpisah pada segmen VLAN internal faskes.
• Salinan 3 (Offsite Cloud): Tersimpan di cloud storage pihak ketiga yang terenkripsi dan terpisah secara geografis dengan fitur Object Lock.

---

Target Metrik Pemulihan: RTO dan RPO

Fasilitas kesehatan wajib menetapkan batas kuantitatif pemulihan bencana:

Parameter	Target Standar Faskes	Definisi Operasional
Recovery Time Objective (RTO)	< 30 Menit	Waktu maksimal sistem PACS harus aktif kembali setelah server fisik mati total.
Recovery Point Objective (RPO)	< 15 Menit	Batas maksimal hilangnya data pemeriksaan baru sejak backup terakhir.

---

SOP Teknis Backup Database & Citra DICOM

1. Script Otomasi Backup Metadata PostgreSQL

Jalankan script backup database terjadwal via cron setiap malam, dikombinasikan dengan pengarsipan Write-Ahead Logging (WAL) berkala:

#!/usr/bin/env bash
# /opt/scripts/backup-pacs-db.sh
set -euo pipefail

BACKUP_DIR="/mnt/nas-backup/pacs-db"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="pacs_production"
TARGET_FILE="${BACKUP_DIR}/db_${DB_NAME}_${DATE}.sql.gz"

mkdir -p "${BACKUP_DIR}"

# Dump database PostgreSQL dengan kompresi gzip level 9
pg_dump -U postgres -h 127.0.0.1 "${DB_NAME}" | gzip -9 > "${TARGET_FILE}"

# Hapus backup lokal yang lebih tua dari 30 hari
find "${BACKUP_DIR}" -type f -name "*.sql.gz" -mtime +30 -delete

echo "[$(date)] Backup PostgreSQL PACS selesai: ${TARGET_FILE}"

2. Sinkronisasi File Citra DICOM ke Immutable Cloud Storage

Gunakan transfer biner inkremental dengan verifikasi checksum SHA-256:

#!/usr/bin/env bash
# /opt/scripts/sync-dicom-cloud.sh
set -euo pipefail

SOURCE_DIR="/var/lib/orthanc/db/pacs-storage"
S3_BUCKET="s3://faskes-pacs-archive-vault/dicom-data"

# Sinkronisasi ke S3 bucket dengan enkripsi server-side AES256
aws s3 sync "${SOURCE_DIR}" "${S3_BUCKET}" \
    --sse AES256 \
    --storage-class STANDARD_IA \
    --no-progress

echo "[$(date)] Sinkronisasi DICOM ke Cloud Vault S3 sukses."

---

Prosedur Uji Restorasi (Disaster Recovery Drill)

Backup tanpa verifikasi pemulihan berisiko menghasilkan file korup saat bencana terjadi. Faskes wajib menjalankan SOP uji coba setiap akhir bulan:

[ ] 1. Siapkan mesin virtual / sandbox DR terisolasi (tanpa koneksi ke modalitas live).
[ ] 2. Unduh file dump database PostgreSQL terbaru dari NAS backup.
[ ] 3. Eksekusi `gunzip -c db_backup.sql.gz | psql -U postgres -d pacs_sandbox`.
[ ] 4. Unduh 50-100 sampel folder file *.dcm dari storage S3 offsite.
[ ] 5. Buka web viewer PACS sandbox dan lakukan query pasien berdasarkan NIK / Accession Number.
[ ] 6. Pastikan windowing (WW/WL), multi-frame cine loop, dan ekspertise tampil utuh.
[ ] 7. Catat durasi pemulihan riil ke dalam formulir Berita Acara Disaster Recovery.

---

Kesimpulan

Keandalan layanan radiologi modern bergantung pada kesiapan rencana disaster recovery. Dengan menerapkan strategi 3-2-1, mengunci arsip offsite dengan teknologi immutable WORM, dan menguji proses pemulihan secara konsisten, rumah sakit memastikan integritas rekam medis pasien tetap terlindungi dalam segala skenario kegagalan sistem.