Migrasi SIMRS Tanpa Downtime: Playbook Ganti Sistem untuk RS yang Tak Boleh Berhenti

Mengganti SIMRS di rumah sakit yang beroperasi 24 jam adalah keputusan yang tidak boleh diambil secara impulsif — dan tidak boleh juga ditunda terlalu lama. Rumah sakit yang masih memakai SIMRS lama berisiko gagal survei STARKES (KMK HK.01.07/MENKES/1596/2024) karena tidak memenuhi standar MRMIK elektronik, sekaligus kehilangan sertifikasi integrasi SatuSehat. Namun mengganti sistem sembarangan bisa menghentikan IGD, mengganggu klaim BPJS, dan merusak data rekam medis ribuan pasien. Playbook ini memetakan cara melakukan migrasi SIMRS secara bertahap — dari pra-migrasi hingga go-live — sehingga pelayanan tidak berhenti sedetik pun.

Mengapa Migrasi SIMRS Tidak Bisa "Big Bang"

Pendekatan big bang — mematikan SIMRS lama pada Jumat malam dan menyalakan sistem baru pada Senin pagi — hanya aman di lingkungan dengan data minimal dan staf terlatih penuh pada sistem baru. Untuk RS tipe B, C, atau D yang melayani ratusan pasien per hari, pendekatan ini menyimpan tiga bom waktu sekaligus: (1) data historis yang belum termigrasi sempurna tidak dapat diakses saat klinisi membutuhkannya, (2) tim belum terbiasa dengan antarmuka baru sehingga input data melambat atau keliru, dan (3) tidak ada jalan kembali jika ditemukan bug kritis di hari pertama.

Permenkes 24/2022 tentang Rekam Medis menetapkan bahwa sistem RME yang digunakan wajib memenuhi tiga pilar keamanan informasi: kerahasiaan (confidentiality), keutuhan (integrity), dan ketersediaan (availability). Ketersediaan — artinya sistem harus dapat diakses saat dibutuhkan untuk pelayanan pasien — adalah prinsip yang paling langsung terdampak oleh migrasi yang buruk. Ketiadaan akses rekam medis, bahkan selama dua jam, dapat memicu kesalahan klinis dan pelanggaran regulasi sekaligus.

Untuk RS yang sudah mengenal risiko ini dari sudut 6 titik kritis MRMIK yang sering gagal saat survei STARKES, migrasi yang terencana adalah langkah pencegahan — bukan sekadar proyek IT.

Tiga Strategi Migrasi: Pilih Sesuai Profil Risiko RS

Rumah sakit dapat memilih salah satu dari tiga pendekatan utama, bergantung pada profil risiko operasional dan kematangan data existing:

1. Migrasi bertahap per modul. Sistem baru diaktifkan satu modul dalam satu waktu — dimulai dari pendaftaran dan data demografi pasien, lalu rekam medis klinis, kemudian farmasi dan billing. Pendekatan ini meminimalkan risiko per tahap, tetapi memerlukan integrasi data antara sistem lama dan baru selama masa transisi.

2. Migrasi bertahap per unit. Satu atau dua unit (misalnya rawat jalan dan IGD) beralih ke sistem baru lebih dahulu, sementara rawat inap masih menggunakan sistem lama. Cocok untuk RS dengan volume rawat inap tinggi yang tidak bisa toleran terhadap gangguan sama sekali.

3. Parallel run penuh. Kedua sistem berjalan bersamaan selama 1–3 bulan, dengan input data dilakukan di keduanya secara paralel. Mahal secara tenaga, tetapi memberikan jaminan validasi data paling ketat sebelum cut-over final.

Pilihan strategi tidak harus tunggal — RS tipe C dan D di Indonesia umumnya mengombinasikan pendekatan per modul dengan parallel run selektif pada modul keuangan dan farmasi, yang paling rentan terhadap kehilangan data.

Fase 1 — Pra-Migrasi: 4 Langkah Wajib Sebelum Sistem Baru Menyala

Empat langkah ini harus tuntas sebelum sistem baru diaktifkan di lingkungan produksi:

Langkah 1: Audit dan pembersihan data di sistem lama. Data pasien duplikat, nomor rekam medis ganda, dan kode diagnosa yang tidak standar harus diselesaikan di sistem lama sebelum dipindahkan. Membawa data kotor ke sistem baru hanya memindahkan masalah, bukan menyelesaikannya.

Langkah 2: Pemetaan skema data (data mapping). Setiap field di sistem lama dipetakan ke field yang sesuai di sistem baru. Ini termasuk format tanggal, kode INA-CBG, kode ICD-10, dan struktur nomor SEP. Perbedaan kecil dalam format data dapat menyebabkan kegagalan klaim BPJS pasca-migrasi.

Langkah 3: Backup penuh dan verifikasi restore. Backup lengkap sistem lama harus dilakukan — dan yang lebih penting, prosedur restore dari backup tersebut harus diuji. Backup yang tidak pernah diuji adalah false security. Simpan salinan backup di lokasi terpisah dari server produksi.

Langkah 4: User Acceptance Testing (UAT) oleh pemilik proses. Tim klinisi, tim koder, dan tim billing — bukan hanya tim IT — harus menguji sistem baru menggunakan skenario kerja nyata: pendaftaran pasien baru, input CPPT, koding diagnosa, penerbitan SEP, dan proses klaim. UAT yang hanya dilakukan oleh IT tidak cukup untuk menemukan masalah alur kerja klinis.

Fase 2 — Parallel Run: Menjalankan Dua Sistem Sekaligus

Parallel run adalah periode di mana sistem lama dan sistem baru berjalan bersamaan. Ini adalah investasi tenaga yang signifikan — staf harus menginput data di dua tempat — tetapi manfaatnya tidak tergantikan: setiap inkonsistensi data antara kedua sistem dapat ditemukan dan diperbaiki sebelum sistem lama dimatikan.

Selama parallel run, tentukan satu sistem sebagai "sistem otoritatif" untuk keperluan klaim BPJS dan akreditasi. Sistem baru sebaiknya menjadi sistem otoritatif sejak awal parallel run, dengan sistem lama sebagai referensi validasi. Ini mengkondisikan staf untuk mulai bergantung pada sistem baru secara nyata, bukan hanya sebagai latihan.

Koneksi ke SatuSehat Platform (yang menggunakan standar HL7 FHIR untuk pertukaran data) juga harus dikonfigurasi di sistem baru selama fase ini. Pengiriman data ke SatuSehat sebaiknya dilakukan hanya melalui satu sistem untuk menghindari duplikasi data kunjungan. RS yang sudah memahami 12 kriteria teknis SIMRS untuk integrasi SatuSehat perlu memastikan semua kriteria tersebut terpenuhi di sistem baru sebelum memutus koneksi dari sistem lama.

Fase 3 — Cut-Over: Dari Dua Sistem Menjadi Satu

Cut-over adalah momen di mana sistem lama resmi dihentikan dan sistem baru menjadi satu-satunya yang beroperasi. Ini bukan acara mendadak — ini adalah prosedur terencana dengan checklist, jam yang ditetapkan, dan kriteria rollback yang sudah disepakati.

Pilih waktu cut-over dengan cermat. Jadwalkan pada periode low-traffic: Sabtu dini hari antara pukul 01.00–04.00 WIB adalah jendela yang sering dipilih RS karena volume pasien rawat jalan minimal dan pasien rawat inap dalam kondisi stabil. Hindari hari sebelum deadline klaim BPJS.

Tetapkan kriteria rollback sebelum cut-over dimulai. Keputusan rollback harus berdasarkan kriteria objektif yang sudah disepakati — misalnya: jika dalam empat jam pertama ditemukan lebih dari lima inkonsistensi data kritis yang tidak dapat diperbaiki secara cepat, sistem lama diaktifkan kembali. Jangan membiarkan keputusan rollback menjadi debat mendadak di tengah malam.

Siapkan tim komando (command center). Selama 24–48 jam pertama pasca cut-over, operasikan command center yang terdiri dari perwakilan IT, klinisi senior, staf billing, dan pihak vendor SIMRS. Setiap masalah dieskalasi ke command center, bukan diselesaikan oleh masing-masing unit secara sendiri-sendiri.

Validasi Data Pasca-Migrasi: Wajib Sebelum SIMRS Lama Dimatikan Permanen

Setelah cut-over berhasil dan rollback tidak diperlukan, masih ada satu tahap kritis sebelum SIMRS lama dapat dinonaktifkan secara permanen: validasi data menyeluruh oleh pemilik data di setiap unit.

Validasi ini harus mencakup setidaknya: (1) jumlah total pasien terdaftar di sistem baru sesuai dengan sistem lama; (2) tidak ada nomor rekam medis yang hilang atau terduplikasi; (3) data transaksi keuangan periode terakhir sebelum migrasi sudah terposting dengan benar; dan (4) integrasi dengan V-Claim BPJS dan SatuSehat berfungsi normal.

Jangan tergesa-gesa menonaktifkan sistem lama. Data dari SIMRS lama mungkin masih dibutuhkan untuk rekonsiliasi klaim BPJS periode sebelumnya atau untuk keperluan audit. Pertahankan akses baca ke sistem lama setidaknya selama 3–6 bulan pasca-migrasi.

Bagi RS yang sedang mempertimbangkan perbandingan arsitektur antara RME, SIMRS, dan ekosistem terintegrasi, artikel RME vs SIMRS vs Ekosistem Terintegrasi memberikan kerangka pilihan yang relevan sebelum keputusan migrasi dibuat.

Dasar Hukum

• Permenkes 24/2022 tentang Rekam Medis — mewajibkan sistem RME memenuhi tiga pilar keamanan informasi (kerahasiaan, keutuhan, ketersediaan); mengatur kompatibilitas dan interoperabilitas sistem elektronik; mewajibkan pendaftaran sistem ke Kemenkes.
• KMK HK.01.07/MENKES/1596/2024 tentang Standar Akreditasi Rumah Sakit (STARKES) — Bab MRMIK mewajibkan penyelenggaraan rekam medis elektronik yang memenuhi standar keamanan, integritas, dan ketertelusuran sebagai syarat akreditasi.

Sumber

• Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis — peraturan.bpk.go.id
• Keputusan Menteri Kesehatan RI Nomor HK.01.07/MENKES/1596/2024 tentang Standar Akreditasi Rumah Sakit (STARKES) — jdih.kemkes.go.id
• Platform SatuSehat — Panduan Integrasi SIMRS via HL7 FHIR — satusehat.kemkes.go.id

FAQ

Berapa lama proses migrasi SIMRS untuk RS tipe C?

Proses migrasi SIMRS untuk RS tipe C rata-rata membutuhkan waktu 3–6 bulan, meliputi analisis dan pembersihan data existing (2–4 minggu), pemetaan dan transformasi data (4–8 minggu), serta parallel run (4–12 minggu). Durasi ini bergantung pada kompleksitas data historis, jumlah modul yang dimigrasikan, dan kesiapan tim internal. RS yang memiliki data historis lebih dari 5 tahun dan integrasi BPJS aktif cenderung membutuhkan waktu di ujung atas rentang ini.

Apa saja risiko data paling berbahaya saat ganti SIMRS?

Tiga risiko data tertinggi dalam migrasi SIMRS adalah: (1) duplikasi data pasien — satu pasien muncul dengan dua nomor rekam medis berbeda, yang langsung merusak kontinuitas rekam medis dan berpotensi menimbulkan kesalahan klinis; (2) kehilangan transaksi keuangan yang belum terposting atau terpotong saat cut-over, berdampak langsung pada rekonsiliasi klaim BPJS; dan (3) inkonsistensi kode ICD-10 antara sistem lama dan baru, terutama jika sistem baru menggunakan versi atau pemetaan yang berbeda. Ketiga risiko ini harus diantisipasi dalam fase data mapping dan validasi pasca-migrasi.

Apakah SIMRS lama harus tetap berjalan saat sistem baru mulai aktif?

Ya, selama fase parallel run. Menjalankan kedua sistem bersamaan bukan pemborosan — ini adalah jaring pengaman satu-satunya jika ditemukan inkonsistensi data kritis setelah go-live. SIMRS lama dimatikan hanya setelah validasi data dinyatakan tuntas oleh pemilik data di setiap unit. Bahkan pasca-cut-over, akses baca ke sistem lama sebaiknya dipertahankan selama 3–6 bulan untuk keperluan rekonsiliasi klaim dan audit.

Bagaimana koneksi SatuSehat dikelola saat SIMRS sedang dalam proses migrasi?

Koneksi SatuSehat menggunakan standar HL7 FHIR dan harus dikonfigurasi ulang di sistem baru sebelum cut-over. Selama parallel run, pengiriman data ke SatuSehat sebaiknya dilakukan melalui satu sistem saja untuk menghindari duplikasi data kunjungan. API key dan client ID sistem baru harus diverifikasi aktif dan terverifikasi di portal SatuSehat Platform (satusehat.kemkes.go.id) sebelum SIMRS lama dimatikan.

Apa yang harus dilakukan jika cut-over gagal dan perlu rollback?

Rollback adalah prosedur terencana, bukan keputusan darurat mendadak. Sebelum cut-over dimulai, tetapkan secara tertulis: (1) kriteria objektif yang memicu rollback (misalnya lebih dari lima inkonsistensi data kritis dalam empat jam pertama); (2) siapa yang berwenang memutuskan rollback; dan (3) prosedur teknis untuk mengaktifkan kembali sistem lama. SIMRS lama harus tetap dalam kondisi aktif dan semua transaksi sejak cut-over harus dapat diinput ulang. Tim command center yang siaga penuh adalah prasyarat cut-over yang aman.