SIMRS Tanpa Disaster Recovery: 3 Skenario Kritis yang Wajib Disimulasikan Wadir

SIMRS tanpa Disaster Recovery Plan (DRP) adalah risiko tersembunyi yang paling sering diabaikan — sampai sistem mati dan seluruh pelayanan berhenti. Ketika ransomware WannaCry menyerang RS Kanker Dharmais pada Mei 2017, sekitar 60 komputer SIMRS terenkripsi, memaksa seluruh operasional beralih ke prosedur manual selama berhari-hari (Liputan6.com, 2017). Sejak berlakunya Permenkes No. 6 Tahun 2026, setiap jam downtime SIMRS bukan sekadar gangguan operasional: ini adalah potensi ketidakpatuhan pelaporan ke Sistem Informasi Kesehatan Nasional (SIKN), terputusnya akses data BPJS melalui V-Claim, dan hilangnya sinkronisasi rekam medis ke SatuSehat. Tiga skenario berikut adalah yang paling sering terjadi — dan yang paling sering tidak disimulasikan.

Mengapa SIMRS Kini Tidak Boleh Berhenti

Permenkes No. 6 Tahun 2026 Pasal 74 mengharuskan setiap RS mengintegrasikan seluruh dokumentasi kegiatan operasional ke SIKN secara digital dan berkelanjutan — bukan hanya saat audit, bukan hanya data tertentu, melainkan seluruh aktivitas klinis dan administratif. RS yang belum memenuhi ketentuan ini diberi waktu transisi hingga 12 Juni 2028 (Pasal 83). Artinya, ketergantungan pada SIMRS yang selalu tersedia bukan lagi pilihan teknis, melainkan kewajiban regulasi dengan tenggat yang jelas.

Implikasinya bagi operasional sangat konkret. Jika SIMRS mati — karena alasan apa pun — aliran data ke SatuSehat terputus, entry klaim BPJS tidak dapat dilakukan, dan rekam medis pasien yang sedang dirawat tidak dapat diakses secara digital oleh DPJP. Permenkes No. 82 Tahun 2013 tentang SIMRS telah mewajibkan setiap RS menyelenggarakan sistem informasi yang mencakup aspek keamanan fisik, jaringan, dan aplikasi — namun keamanan tanpa rencana pemulihan adalah setengah pekerjaan.

Dalam konteks STARKES KMK HK.01.07/MENKES/1596/2024, kelengkapan dan kelangsungan sistem informasi rekam medis (bab MRMIK) adalah kriteria yang dievaluasi surveior akreditasi. DRP SIMRS yang terdokumentasi dan telah disimulasikan bukan hanya melindungi operasional — ia juga menjadi bukti kepatuhan saat penilaian KARS dilakukan.

Skenario 1: Server Mati Mendadak

Server SIMRS yang mati mendadak — akibat kerusakan hardware, pemadaman listrik, atau overheat di ruang server — menghentikan seluruh operasional digital RS dalam hitungan detik. Pendaftaran pasien, entry tindakan, billing, dan akses rekam medis berhenti bersamaan. Tanpa prosedur manual yang sudah dilatih, RS beroperasi dalam kegelapan informasi pada saat yang paling kritis. Insiden ransomware WannaCry di RS Kanker Dharmais (Mei 2017) membuktikan skenario ini secara konkret: sistem antrian dan informasi pasien lumpuh total, dan pemulihan baru bisa dilakukan setelah reinstall ulang sistem operasi di setiap komputer yang terinfeksi — proses yang membutuhkan waktu berhari-hari (Liputan6.com, 2017).

Dampak spesifik yang sering diabaikan:

• Billing dan kasir tidak dapat mencetak kwitansi atau menghitung biaya perawatan, menyebabkan antrean panjang saat shift ramai atau saat pergantian jaga.
• Entry klaim BPJS melalui V-Claim tidak dapat diakses karena aplikasi berjalan di atas infrastruktur yang sama dengan SIMRS utama.
• Ruang perawatan intensif kehilangan akses ke catatan tindakan terbaru jika rekam medis sepenuhnya elektronik tanpa salinan cadangan yang dapat diakses luring.
• SatuSehat bridging terputus, dan data kunjungan yang tidak terkirim saat downtime harus direkonsiliasi manual setelah sistem pulih — proses yang memakan waktu dan berisiko inkonsistensi.

Yang harus ada dalam DRP untuk skenario ini:

Sebuah DRP yang fungsional mencakup: target Recovery Time Objective (RTO) — berapa lama sistem boleh mati sebelum prosedur darurat diaktifkan; UPS dan generator backup untuk menjaga ruang server tetap bertenaga; serta prosedur pendaftaran dan tindakan manual yang sudah dilatih secara berkala oleh seluruh unit. Beberapa RS juga menyiapkan failover server atau lingkungan cloud sebagai cadangan aktif yang dapat diaktifkan dalam hitungan menit.

Bila RS sedang mengevaluasi apakah infrastruktur SIMRS yang ada masih layak atau sudah saatnya diganti, pertimbangkan 5 kondisi pemaksa penggantian SIMRS beserta checklist evaluasi vendor 2026 sebagai kerangka keputusan yang terstruktur.

Skenario 2: Koneksi Internet Terputus

Terputusnya koneksi internet — akibat gangguan ISP, kabel putus, atau pemutusan layanan — tidak mematikan server lokal, tetapi melumpuhkan seluruh integrasi eksternal yang semakin wajib ada di RS modern. Ini adalah skenario yang lebih sering terjadi dibanding server mati, namun DRP-nya justru lebih sering absen karena dianggap bukan "downtime SIMRS" secara teknis.

Dampak yang muncul dalam hitungan menit:

• V-Claim BPJS tidak dapat diakses — verifikasi kepesertaan, pengajuan SEP, dan pengiriman klaim BPJS terhenti. Pasien BPJS yang masuk melalui IGD tidak dapat diverifikasi secara sistem, memaksa staf beralih ke prosedur manual yang tidak selalu tersedia.
• SatuSehat API tidak dapat menerima data kunjungan dan rekam medis. Data yang tidak terkirim saat downtime harus dikumpulkan dan dikirim ulang setelah koneksi pulih, dengan risiko duplikasi atau gap yang memerlukan rekonsiliasi.
• Antrean online dan pendaftaran berbasis aplikasi terputus, memaksa RS kembali ke sistem manual tanpa nomor antrian digital yang terstruktur.
• Integrasi laboratorium dan radiologi eksternal — apabila hasil pemeriksaan dikirim melalui API — tidak dapat diterima oleh SIMRS, menghambat keputusan klinis DPJP.

Yang harus ada dalam DRP untuk skenario ini:

DRP yang memadai mencakup: kontrak dengan ISP sekunder (jalur redundan) yang dapat diaktifkan otomatis atau dengan prosedur manual sederhana; prosedur luring untuk verifikasi kepesertaan BPJS secara manual (kartu fisik, koordinasi telepon dengan kantor BPJS terdekat) yang sudah dilatih oleh staf front-office; serta protokol rekonsiliasi data SatuSehat yang jelas — kapan mulai rekonsiliasi, siapa penanggungjawabnya, dan berapa batas toleransi gap yang diterima.

Skenario 3: Kegagalan Migrasi atau Pembaruan Sistem

Upgrade versi SIMRS, migrasi ke server baru, atau pembaruan database adalah momen paling berisiko dalam siklus hidup sebuah sistem informasi RS. Kegagalan di titik ini bisa berarti kehilangan data transaksi yang belum di-backup, rekam medis yang tidak lengkap, atau ketidakcocokan data antara sistem lama dan baru yang baru terdeteksi setelah operasional berjalan.

Skenario konkret yang paling sering terjadi:

• Rollback gagal: upgrade dilakukan di luar jam pelayanan, tetapi ketika muncul masalah, proses rollback ke versi sebelumnya membutuhkan waktu lebih lama dari perkiraan — sehingga SIMRS tidak tersedia saat shift pagi dimulai dan pasien sudah mulai berdatangan.
• Inkonsistensi data pasca-migrasi: struktur database berubah di versi baru, tetapi data lama tidak termapping dengan benar — menyebabkan kode diagnosis tidak terbaca, nomor rekam medis duplikat, atau riwayat billing tidak cocok dengan tindakan yang sudah diinput.
• Kegagalan migrasi sebagian: sebagian data berhasil dipindahkan, sebagian tidak — dan tim baru menyadarinya ketika RS sudah beroperasi di sistem baru dan tidak mudah lagi kembali ke sistem lama.

Yang harus ada dalam DRP untuk skenario ini:

Inti DRP untuk skenario ini adalah kebijakan backup wajib sebelum setiap upgrade — tidak ada pembaruan sistem tanpa backup penuh yang sudah diverifikasi terlebih dahulu; lingkungan staging (server atau environment duplikat) tempat upgrade diuji sebelum diterapkan ke sistem produksi; serta prosedur rollback yang sudah dilatih dengan target waktu yang realistis dan dapat dieksekusi oleh tim IT tanpa eskalasi. Waktu pembaruan dan SLA ketersediaan sistem sebaiknya juga ditetapkan secara eksplisit dalam kontrak dengan vendor SIMRS.

Dasar Hukum

Menyusun DRP SIMRS dalam 5 Langkah Praktis

DRP SIMRS yang efektif bukan dokumen tebal yang tersimpan di laci — melainkan prosedur yang sudah dilatih, diuji, dan diperbarui secara berkala. Berikut kerangka kerja yang dapat diadaptasi sesuai skala dan kapasitas RS Anda.

Langkah 1 — Business Impact Analysis (BIA) Identifikasi proses mana yang paling terdampak jika SIMRS mati: billing, V-Claim, SatuSehat, rekam medis IGD, atau seluruhnya. BIA menentukan urutan prioritas pemulihan sehingga tim tahu sistem mana yang harus pulih lebih dulu.

Langkah 2 — Tetapkan RTO dan RPO Recovery Time Objective (RTO): berapa jam maksimum SIMRS boleh tidak tersedia sebelum DRP diaktifkan. Recovery Point Objective (RPO): berapa jam data boleh hilang — ini menentukan frekuensi backup yang dibutuhkan. Penerapan ISO 22301 di rumah sakit Indonesia merekomendasikan RTO maksimal 4 jam untuk gangguan sistem rekam medis sebagai titik awal (Setiawan dkk., Jurnal RESTI, 2019). Sebuah studi implementasi Disaster Recovery Center di RS Indonesia berhasil mencapai RTO di bawah 15 menit dengan failover otomatis dan tingkat keberhasilan 100% (Jurnal Rekayasa Informasi ISTN).

Langkah 3 — Susun Prosedur Manual Operasional Setiap unit yang bergantung pada SIMRS harus memiliki prosedur kerja manual yang terdokumentasi dan telah dilatih. Tanpa ini, DRP hanya rencana di atas kertas yang tidak berguna saat insiden terjadi.

Langkah 4 — Lakukan Simulasi Berkala Uji DRP minimal satu kali per tahun — simulasikan skenario server mati, koneksi terputus, atau rollback gagal. Catat waktu aktual pemulihan dan bandingkan dengan RTO yang ditetapkan. Temuan dari simulasi menjadi dasar perbaikan prosedur.

Langkah 5 — Dokumentasikan untuk Survei Akreditasi Simpan hasil simulasi, log insiden, dan bukti backup sebagai dokumen yang dapat ditunjukkan kepada surveior KARS saat penilaian bab MRMIK. Bukti tertulis bahwa DRP ada dan sudah diuji jauh lebih kuat daripada pernyataan lisan saat survei.

FAQ

Apa itu Disaster Recovery Plan (DRP) untuk SIMRS?

Disaster Recovery Plan (DRP) SIMRS adalah dokumen prosedur tertulis yang menjelaskan langkah pemulihan sistem informasi manajemen rumah sakit ketika terjadi gangguan — baik server mati, koneksi internet putus, maupun kegagalan migrasi data. DRP mencakup target waktu pemulihan (RTO), target titik pemulihan data (RPO), prosedur aktivasi manual, dan simulasi berkala agar seluruh tim siap bertindak ketika insiden terjadi.

Berapa lama downtime SIMRS yang boleh terjadi sebelum berdampak ke regulasi?

Tidak ada ambang waktu spesifik dalam regulasi, namun Permenkes No. 6 Tahun 2026 Pasal 74 mewajibkan RS melaporkan seluruh aktivitas operasional secara digital dan berkelanjutan ke SIKN. Setiap jam downtime yang menyebabkan data tidak terkirim ke SatuSehat atau V-Claim tidak dapat diakses berpotensi menjadi temuan ketidakpatuhan — terutama saat audit akreditasi STARKES berdasarkan KMK 1596/2024.

Apa perbedaan backup data dan disaster recovery plan?

Backup data adalah salinan cadangan data yang dibuat secara berkala (harian, mingguan). Disaster Recovery Plan adalah rencana menyeluruh yang mencakup backup data sekaligus prosedur pemulihan operasional — siapa yang dihubungi, sistem mana yang diprioritaskan, dan bagaimana pelayanan tetap berjalan selama sistem utama pulih. Sebuah RS bisa punya backup data tetapi tidak punya DRP, sehingga tetap mengalami kekacauan saat insiden terjadi karena tidak ada prosedur yang pernah disimulasikan.

Apakah DRP SIMRS diwajibkan dalam standar akreditasi STARKES?

Standar MRMIK dalam STARKES KMK 1596/2024 mengatur ketersediaan dan kelangsungan sistem informasi rekam medis dan kesehatan. RS yang tidak memiliki DRP SIMRS berisiko mendapat temuan dalam bab MRMIK saat survei akreditasi, karena kelengkapan dan kesinambungan akses rekam medis elektronik merupakan salah satu kriteria penilaian surveior KARS.

Sumber

• Kementerian Kesehatan RI. Peraturan Menteri Kesehatan No. 82 Tahun 2013 tentang Sistem Informasi Manajemen Rumah Sakit. peraturan.go.id
• Kementerian Kesehatan RI. Peraturan Menteri Kesehatan No. 24 Tahun 2022 tentang Rekam Medis. jdih.kemkes.go.id
• Kementerian Kesehatan RI. Peraturan Menteri Kesehatan No. 6 Tahun 2026 tentang Rumah Sakit. Berita Negara RI 2026/382. jdih.kemkes.go.id
• Kementerian Kesehatan RI. Keputusan Menteri Kesehatan No. HK.01.07/MENKES/1596/2024 tentang Standar Akreditasi Rumah Sakit (STARKES). jdih.kemkes.go.id
• Setiawan, I., Waluyo, R., & Pambudi, W. A. (2019). Perancangan Business Continuity Plan dan Disaster Recovery Plan Teknologi dan Sistem Informasi Menggunakan ISO 22301. Jurnal RESTI. doi.org/10.29207/resti.v3i2.911
• International Organization for Standardization. ISO/IEC 22301:2019 Security and Resilience — Business Continuity Management Systems. iso.org
• Liputan6.com. Pasien RS Dharmais Rasakan Dampak Serangan Ransomware WannaCry (Mei 2017). liputan6.com