Migrasi SIMRS Lama: Tantangan, Risiko & Langkah Aman

Rumah sakit jarang mengganti SIMRS karena bosan. Pemicunya hampir selalu konkret: vendor lama berhenti merilis pembaruan, bridging V-Klaim sering putus di tanggal-tanggal sibuk klaim, atau kewajiban rekam medis elektronik dalam Permenkes 24 Tahun 2022 mustahil dipenuhi oleh aplikasi yang dibangun satu dekade lalu. Keputusan berpindah biasanya cepat diambil. Yang lambat, dan sering diremehkan, adalah proses migrasi SIMRS itu sendiri: memindahkan data pasien belasan tahun, menjaga pelayanan tetap berjalan, dan memastikan tagihan BPJS tidak tersendat satu hari pun.

Artikel ini membahas sisi yang jarang muncul di brosur vendor: apa yang bisa salah saat migrasi, seberapa besar dampaknya, dan urutan langkah yang terbukti mengurangi risiko. Jika Anda masih di tahap memilih sistem, panduan dasar ada di artikel panduan lengkap SIMRS rumah sakit; tulisan ini melanjutkannya ke fase eksekusi.

Kenapa migrasi SIMRS lebih sulit dari implementasi baru

Rumah sakit yang baru pertama kali memasang SIMRS memulai dari nol: master data disusun rapi sejak awal. Rumah sakit yang bermigrasi mewarisi seluruh sejarah sistem lamanya, termasuk kekacauannya.

Data legacy hampir pasti kotor

Beberapa pola yang muncul berulang di lapangan: satu pasien memiliki dua atau tiga nomor rekam medis karena pendaftaran ulang saat sistem lama lambat; kode obat lokal yang dibuat petugas farmasi bertahun-tahun tanpa acuan, sehingga tidak bisa langsung dipetakan ke Kamus Farmasi dan Alat Kesehatan (KFA) yang dibutuhkan SatuSehat; diagnosis tersimpan sebagai teks bebas, bukan kode ICD-10; tanggal lahir kosong atau diisi 01-01-1900. Ada juga kasus ekstrem yang nyata terjadi: database sistem lama ternyata tidak punya dokumentasi skema sama sekali, dan vendor aslinya sudah tutup.

Data kotor ini bukan sekadar masalah estetika. Duplikasi nomor rekam medis berarti riwayat alergi pasien bisa terpecah di dua berkas. Kalau yang terbawa ke sistem baru hanya salah satunya, konsekuensinya klinis, bukan administratif.

Jembatan ke BPJS dan SatuSehat tidak boleh putus

SIMRS modern hidup di tengah jejaring integrasi: V-Klaim untuk penjaminan, E-Klaim untuk pengajuan INA-CBG, antrean online Mobile JKN, dan pengiriman resource FHIR ke SatuSehat. Saat cutover, semua sambungan ini harus berpindah bersama aplikasi. Rumah sakit yang memotong bridging di tengah periode klaim akan merasakan akibatnya di arus kas bulan berikutnya. Detail teknis integrasi klaim dibahas terpisah di artikel bridging SIMRS dengan V-Klaim, E-Klaim, dan INA-CBG.

Risiko migrasi SIMRS yang perlu dihitung sejak awal

Sebelum menandatangani kontrak, petakan risiko berikut bersama vendor dan tim internal. Tabel ini bisa menjadi kerangka awal risk register proyek Anda.

Dua baris terakhir sering dilupakan. Data kesehatan dalam UU PDP masuk kategori data pribadi bersifat spesifik, dan rumah sakit sebagai penyelenggara sistem elektronik juga terikat kewajiban pengamanan dalam PP 71 Tahun 2019. Migrasi, yang pada dasarnya adalah memindahkan seluruh basis data pasien keluar dari sistem produksi, adalah momen paling rawan dalam siklus hidup data itu.

Langkah aman migrasi SIMRS, dari audit sampai rollback

1. Audit dan bersihkan data sebelum dipindahkan

Jangan memindahkan sampah ke rumah baru. Mulai dengan profil data: berapa pasien aktif, berapa duplikat tersangka, berapa persen diagnosis yang sudah berkode ICD-10, bagaimana kondisi master obat dan tarif. Hasil audit ini menentukan estimasi durasi yang realistis. Pembersihan duplikat nomor rekam medis sebaiknya dikerjakan tim rekam medis sendiri dengan dukungan alat bantu, karena keputusan menggabungkan dua berkas pasien butuh penilaian manusia.

2. Sepakati pemetaan kode di awal, hitam di atas putih

Kode obat lama ke KFA, tarif lama ke struktur tarif baru, unit layanan lama ke master baru. Dokumen pemetaan ini menjadi acuan saat hasil migrasi diperdebatkan kemudian hari. Sekaligus manfaatkan momen ini untuk menyiapkan interoperabilitas: pemetaan ke terminologi standar adalah sebagian besar pekerjaan dalam checklist kesiapan integrasi SatuSehat, jadi kerjakan sekali untuk dua tujuan.

3. Lakukan migrasi percobaan, bukan hanya sekali

Praktik yang sehat: minimal dua kali trial migration ke lingkungan uji, dengan rekonsiliasi angka setiap kali. Jumlah pasien, jumlah kunjungan per tahun, total piutang, saldo stok farmasi pada tanggal potong. Selisih sekecil apa pun harus bisa dijelaskan. Trial kedua juga berfungsi mengukur durasi: kalau konversi penuh butuh 14 jam, jendela cutover akhir pekan harus dirancang dengan angka itu, bukan dengan asumsi.

4. Pilih strategi cutover yang sesuai kapasitas tim

• Big bang: seluruh modul pindah serentak dalam satu jendela, biasanya akhir pekan. Cepat selesai, tetapi menuntut kesiapan penuh semua unit dan rollback yang jelas.
• Bertahap per modul: misalnya rawat jalan dan farmasi dulu, rawat inap menyusul. Risiko per tahap lebih kecil, tetapi ada periode dua sistem hidup berdampingan yang menambah beban rekonsiliasi.
• Paralel run: sistem lama dan baru berjalan bersama beberapa pekan untuk fungsi kritis seperti kasir dan klaim. Paling aman untuk validasi, paling mahal di tenaga.

Tidak ada pilihan yang benar untuk semua rumah sakit. RS tipe C dengan tim TI dua orang sebaiknya tidak memaksakan paralel run penuh; sebaliknya, RS rujukan dengan volume klaim besar hampir selalu membutuhkannya untuk modul penagihan.

5. Siapkan rollback dan jangan buru-buru mematikan sistem lama

Tetapkan sebelum go-live: kondisi apa yang memicu keputusan kembali ke sistem lama, siapa yang berwenang memutuskan, dan sampai jam berapa keputusan itu masih mungkin. Setelah go-live berhasil pun, sistem lama sebaiknya dipertahankan dalam mode baca selama masa retensi berjalan atau sampai seluruh arsip terverifikasi pindah. Saat server lama akhirnya dipensiunkan, media penyimpanannya perlu disanitasi dengan benar; NIST SP 800-88 adalah acuan yang lazim dipakai untuk memastikan data pasien tidak bisa dipulihkan dari disk bekas. Menghapus file atau memformat ulang saja tidak cukup.

Momentum regulasi: migrasi sekalian penuhi kewajiban RME

Banyak rumah sakit menjadikan kewajiban rekam medis elektronik sebagai momentum penggantian sistem, dan itu masuk akal: daripada menambal sistem lama agar sekadar lolos, lebih efisien berpindah ke SIMRS yang sejak awal dirancang untuk RME, pelaporan, dan pengiriman data ke SatuSehat. Rincian kewajiban dan tenggatnya kami bahas di artikel persiapan RME sesuai Permenkes 24/2022. DHealth, SIMRS yang dikembangkan grup kami dan telah dipakai di berbagai rumah sakit, menyertakan metodologi migrasi ini sebagai bagian dari implementasi, bukan layanan tambahan; tim migrasi datanya bekerja bersama tim rekam medis rumah sakit sejak fase audit data, bukan hanya saat cutover.

Migrasi SIMRS pada akhirnya bukan proyek teknologi semata. Bagian tersulitnya justru disiplin proses: audit jujur atas kondisi data, keberanian menunda go-live saat rekonsiliasi belum bersih, dan komitmen manajemen menyediakan waktu tim internal. Vendor yang baik akan memaksa Anda melewati semua itu. Vendor yang menjanjikan migrasi selesai dua minggu tanpa melihat data Anda terlebih dahulu justru perlu dicurigai.

Pertanyaan yang sering diajukan

Berapa lama migrasi SIMRS biasanya berlangsung?

Untuk RS tipe C dengan data relatif bersih, 3 sampai 6 bulan dari kickoff sampai go-live adalah rentang yang wajar; RS besar dengan riwayat data panjang bisa 6 sampai 12 bulan. Faktor penentu terbesar bukan ukuran rumah sakit, melainkan kualitas data lama dan ketersediaan waktu tim internal untuk validasi.

Apakah semua data historis wajib dimigrasikan ke sistem baru?

Tidak harus seluruhnya masuk ke database produksi. Yang umum: data demografi dan ringkasan klinis pasien aktif dimigrasikan penuh, sedangkan berkas lama disimpan sebagai arsip yang tetap bisa diakses. Yang wajib dijaga adalah retensinya, karena Permenkes 24/2022 mensyaratkan penyimpanan rekam medis elektronik paling singkat 25 tahun sejak kunjungan terakhir.

Bagaimana nasib klaim BPJS yang sedang berjalan saat cutover?

Klaim periode berjalan sebaiknya diselesaikan di sistem lama sampai tuntas, sementara kunjungan baru langsung tercatat di sistem baru. Karena itu tanggal cutover idealnya jatuh di awal periode klaim, dan mapping akun serta tarif INA-CBG harus sudah teruji di lingkungan staging sebelumnya.

Apakah rumah sakit perlu tim TI besar untuk bermigrasi?

Tidak, tetapi perlu tim yang tepat: satu penanggung jawab proyek dengan mandat manajemen, perwakilan rekam medis, casemix, farmasi, dan keuangan. Pekerjaan teknis konversi menjadi tanggung jawab vendor; pengetahuan tentang arti data dan keputusan penggabungannya hanya dimiliki orang dalam rumah sakit.