Uji Coba Paralel SIMRS Sebelum Go-Live: 4 Skenario yang Wajib Disimulasikan

Uji coba paralel SIMRS adalah tahap menjalankan sistem lama dan sistem baru secara bersamaan sebelum cutover penuh, agar setiap transaksi bisa dibandingkan dan kesalahan terdeteksi sebelum pelayanan pasien bergantung sepenuhnya pada sistem baru. Empat skenario wajib disimulasikan: transaksi pendaftaran-billing ganda, gangguan jaringan saat transisi, kontinuitas data pasien rawat inap aktif, dan integrasi eksternal ke BPJS/SatuSehat.

Migrasi SIMRS yang gagal jarang disebabkan oleh sistem baru yang buruk. Penyebab paling umum adalah RS langsung "big bang" — mematikan sistem lama dan mengaktifkan sistem baru dalam satu waktu, tanpa fase pembuktian ketika kedua sistem masih bisa saling mengoreksi. Begitu sistem lama nonaktif, RS kehilangan jaring pengaman untuk membandingkan data, dan setiap kesalahan tersembunyi baru terlihat setelah pasien atau klaim BPJS terdampak.

Biayanya juga tidak simetris. Menambah satu-dua minggu masa uji coba paralel hanya berarti staf mencatat dua kali lebih lama; tapi go-live yang gagal berarti klaim BPJS tertunda, riwayat pengobatan pasien rawat inap terputus, dan tim IT harus melakukan pemulihan darurat sambil pelayanan tetap berjalan. Studi tentang faktor keberhasilan implementasi sistem informasi rumah sakit secara konsisten menemukan bahwa kesiapan pengguna dan dukungan manajemen — bukan semata kecanggihan teknis sistem baru — yang paling menentukan apakah migrasi berjalan mulus atau justru menambah beban kerja staf di lapangan.

Artikel ini membahas empat skenario uji coba paralel yang wajib disimulasikan sebelum SIMRS baru dinyatakan siap menggantikan sistem lama sepenuhnya, ditambah kriteria kapan RS boleh melanjutkan ke go-live dan kapan harus menunda.

Skenario 1: Transaksi Pendaftaran dan Billing Berjalan Ganda

Selama masa uji coba paralel, setiap transaksi pendaftaran, tindakan, dan billing pasien harus dimasukkan ke sistem lama dan sistem baru secara bersamaan, lalu direkonsiliasi setiap hari untuk memastikan angka pendapatan dan jumlah kunjungan cocok di kedua sistem sebelum salah satu dimatikan.

Praktik ini dikenal sebagai parallel running — strategi migrasi sistem di mana sistem baru mengambil alih fungsi sistem lama secara bertahap sambil keduanya tetap beroperasi, dan setiap transaksi direkonsiliasi harian untuk memastikan akurasi. Untuk RS, titik paling rawan biasanya bukan pendaftaran pasien baru, melainkan proses yang jarang terjadi tapi berdampak besar: koreksi tagihan, pembatalan tindakan, dan penyesuaian tarif kelas rawat. Transaksi jenis ini sering luput dari skenario uji coba yang hanya menguji alur "jalan normal".

Rekonsiliasi harian idealnya melibatkan staf billing/kasir yang membandingkan total transaksi, bukan hanya tim IT — karena staf front-office yang paling cepat mengenali selisih angka yang tidak wajar dibanding validasi teknis semata.

Skenario 2: Gangguan Jaringan atau Downtime Saat Masa Transisi

RS wajib menyimulasikan kondisi jaringan terputus atau server tidak responsif tepat di tengah masa paralel, lalu menguji apakah petugas front-office dan rawat inap tahu prosedur pencatatan manual sementara, dan apakah data manual tersebut bisa disinkronkan kembali ke sistem baru tanpa duplikasi atau kehilangan data begitu koneksi pulih.

Justru karena dua sistem berjalan bersamaan, risiko gangguan jaringan selama masa transisi lebih tinggi dibanding kondisi operasional normal — beban server bertambah karena mencatat dua kali, dan proses sinkronisasi antar sistem menambah titik kegagalan baru. RS yang tidak menyimulasikan skenario ini biasanya baru menyadari prosedur downtime belum jelas justru saat insiden nyata terjadi, ketika staf sudah kehilangan kebiasaan mencatat manual karena terlalu lama bergantung pada sistem digital.

Uji coba ini juga jadi kesempatan memverifikasi apakah cetak formulir manual, nomor rekam medis sementara, dan alur serah-terima data kertas-ke-digital masih dipahami staf yang bertugas di shift malam dan akhir pekan — bukan hanya staf senior yang hadir saat pelatihan awal.

Sebagian RS menganggap skenario ini cukup diuji sekali di lingkungan sandbox oleh tim IT. Praktik yang lebih aman adalah menjalankan simulasi tak terjadwal — staf front-office dan rawat inap tidak diberi tahu kapan persisnya "gangguan" akan disimulasikan — supaya hasil uji coba mencerminkan reaksi nyata, bukan reaksi yang sudah dihafal karena tahu jadwal latihan sebelumnya.

Skenario 3: Kontinuitas Data Pasien Rawat Inap yang Sedang Berjalan

Pasien yang sedang dirawat inap saat migrasi berlangsung adalah kelompok berisiko paling tinggi, karena riwayat pengobatan, hasil lab, dan catatan asuhan keperawatannya harus tetap utuh dan bisa diakses tanpa jeda meski episode perawatannya "menyeberang" dari sistem lama ke sistem baru di tengah jalan.

RS perlu menyimulasikan minimal satu episode rawat inap penuh — dari admisi, pemberian obat, hasil penunjang, hingga rencana pemulangan — yang sengaja dibuat berjalan melintasi tanggal cutover, untuk memastikan dokter dan perawat tetap bisa melihat riwayat lengkap pasien tanpa harus membuka dua sistem secara manual. Kegagalan pada titik ini bukan sekadar masalah administratif: riwayat obat atau alergi yang terputus saat pergantian sistem berisiko langsung pada keselamatan pasien.

Uji coba paralel yang baik selalu melibatkan simulasi kasus rawat inap kompleks — pasien dengan banyak diagnosis, lebih dari satu DPJP, atau rencana pemulangan yang berubah — karena skenario sederhana cenderung lolos tanpa mengungkap celah nyata di alur kerja klinis.

Skenario 4: Integrasi Eksternal Tetap Berjalan Tanpa Klaim Tertunda

Selama masa paralel, bridging ke V-Claim BPJS Kesehatan dan pelaporan ke SATUSEHAT/SIKN harus tetap berjalan dari kedua sistem tanpa menghasilkan data ganda atau klaim yang tertunda verifikasinya, karena keterlambatan pengiriman SEP atau data kunjungan berdampak langsung pada arus kas RS.

Titik paling rawan pada skenario ini adalah nomor SEP dan nomor rekam medis: jika sistem baru menghasilkan nomor identitas berbeda dari sistem lama untuk pasien yang sama, proses verifikasi klaim BPJS bisa menolak berkas karena dianggap tidak sesuai riwayat kunjungan sebelumnya. RS perlu memastikan mapping data pasien antar sistem sudah diuji dengan sampel nyata sebelum migrasi penuh, bukan hanya diasumsikan berjalan otomatis oleh vendor.

Permenkes 6/2026 tentang Rumah Sakit — yang berlaku sejak 12 Juni 2026 — mewajibkan RS mengintegrasikan seluruh dokumentasi penyelenggaraan kegiatannya ke Sistem Informasi Kesehatan Nasional. Kewajiban ini tidak berhenti selama masa transisi SIMRS; justru periode migrasi adalah saat risiko putusnya pelaporan ke sistem nasional paling tinggi, sehingga skenario integrasi eksternal wajib termasuk dalam uji coba paralel, bukan diuji belakangan setelah go-live.

Kriteria Go/No-Go: Kapan Boleh Lanjut, Kapan Harus Ditunda

Keputusan melanjutkan ke go-live harus berdasarkan kriteria objektif yang disepakati sebelum uji coba dimulai — bukan diputuskan di tengah tekanan jadwal proyek — karena kriteria yang dilonggarkan saat mendekati tenggat adalah penyebab paling umum masalah pasca-migrasi yang sebetulnya sudah terdeteksi saat uji coba tapi diabaikan.

Kriteria go/no-go minimal mencakup: nol selisih rekonsiliasi transaksi pendaftaran-billing selama tiga hari berturut-turut, prosedur downtime terbukti berhasil disimulasikan minimal sekali oleh staf non-senior, seluruh episode rawat inap uji coba menunjukkan riwayat pasien utuh tanpa data hilang, dan tidak ada klaim BPJS yang tertunda akibat mapping data yang salah. Jika salah satu kriteria ini belum terpenuhi, jadwal go-live sebaiknya digeser — literatur implementasi sistem informasi kesehatan secara konsisten mencatat bahwa dukungan manajemen dan kesiapan pengguna, bukan semata kesiapan teknis sistem, yang paling menentukan keberhasilan implementasi jangka panjang.

Dasar Hukum

• Permenkes 6/2026 tentang Rumah Sakit — ditetapkan 4 Juni 2026 dan berlaku sejak 12 Juni 2026 — mencabut 21 peraturan lama termasuk Permenkes 82/2013 tentang Sistem Informasi Manajemen Rumah Sakit (SIMRS), dan mewajibkan RS mengintegrasikan seluruh dokumentasi operasionalnya ke Sistem Informasi Kesehatan Nasional. Masa penyesuaian diberikan maksimal 2 tahun (sampai Juni 2028), atau 4 tahun untuk RS Kelas D Pratama yang sudah berizin (sampai Juni 2030). Pelanggaran ketentuan ini dapat dikenai sanksi administratif.
• KMK HK.01.07/MENKES/1596/2024 tentang Standar Akreditasi Rumah Sakit (STARKES 2024) — melalui Bab MRMIK (Manajemen Rekam Medis dan Informasi Kesehatan) — mensyaratkan RS mampu menunjukkan bukti kesinambungan pengelolaan rekam medis dan sistem informasi klinis, termasuk kesiapan prosedur saat terjadi gangguan sistem atau pergantian aplikasi.

FAQ

Berapa lama idealnya uji coba paralel SIMRS dijalankan sebelum go-live?

Praktik umum industri sistem informasi menyarankan minimal satu siklus transaksi penuh — biasanya 1-2 minggu untuk RS dengan volume rawat jalan tinggi — agar pola beban puncak, akhir pekan, dan proses rekonsiliasi bulanan sempat teruji sebelum sistem lama dimatikan.

Apakah RS kecil dan menengah tetap wajib menjalankan keempat skenario ini?

Ya, meski skalanya bisa disederhanakan. RS dengan volume transaksi lebih kecil dapat memangkas durasi uji coba, tetapi keempat skenario — pendaftaran/billing, gangguan jaringan, kontinuitas pasien aktif, dan integrasi eksternal — tetap relevan karena risikonya bukan soal ukuran RS, melainkan soal proses yang sama-sama berjalan di semua kelas rumah sakit.

Siapa yang seharusnya memimpin uji coba paralel SIMRS, IT atau unit layanan?

Idealnya kepemimpinan bersama: tim IT/vendor menjalankan aspek teknis (sinkronisasi data, uptime, bridging), sementara Wadir Pelayanan atau kepala unit terkait memvalidasi bahwa alur kerja klinis dan administratif tetap sesuai standar pelayanan. Uji coba yang hanya divalidasi tim IT sering melewatkan masalah pada alur kerja nyata di lapangan.

Apa yang harus dilakukan jika ditemukan masalah kritis saat uji coba paralel?

Tunda tanggal go-live. Kriteria go/no-go yang ditetapkan di awal proyek harus bersifat objektif dan tidak dilonggarkan hanya karena tekanan jadwal — mengejar target waktu migrasi lebih berisiko daripada menunda beberapa minggu untuk memperbaiki masalah yang ditemukan saat sistem lama masih bisa jadi jaring pengaman.

Sumber

• Peraturan Menteri Kesehatan Nomor 6 Tahun 2026 tentang Rumah Sakit — jdih.kemkes.go.id
• Keputusan Menteri Kesehatan HK.01.07/MENKES/1596/2024 tentang Standar Akreditasi Rumah Sakit (STARKES 2024) — jdih.kemkes.go.id
• "Hospital information system user acceptance factors: User group perspectives" — studi tentang faktor keberhasilan implementasi sistem informasi rumah sakit, PubMed (pubmed.ncbi.nlm.nih.gov/28140717/)
• Konsep parallel running dalam migrasi sistem informasi — praktik standar manajemen perubahan sistem TI