📚 Bagian dari panduan: Panduan Klaim BPJS

Saat Klaim JKN Sepenuhnya Elektronik, Downtime SIMRS Menghentikan Pendapatan

Vera MedMinutes, Content & Marketing MedMinutes · · 7 menit baca
Layar komputer menampilkan sistem rekam medis elektronik di ruang administrasi rumah sakit

Sejak klaim JKN bergeser dari berkas pindaian ke data Rekam Medis Elektronik (RME) yang terintegrasi SATUSEHAT, downtime SIMRS berhenti menjadi sekadar gangguan pelayanan. Begitu sistem mati, RS tidak hanya kehilangan akses ke riwayat pasien — ia juga kehilangan kemampuan menghasilkan dokumen elektronik sumber klaim untuk setiap episode yang terjadi selama gangguan. Prosedur kontinjensi yang dulu cukup berupa formulir kertas kini harus menjamin data itu bisa direkonstruksi kembali ke format klaim elektronik, bukan sekadar diarsipkan.

Sebagian besar RS sudah punya prosedur downtime untuk kebutuhan akreditasi: formulir manual, alur eskalasi ke IT, dan pelatihan staf. Yang sering belum disiapkan adalah langkah setelah sistem kembali normal — bagaimana data dari jam-jam sistem mati itu masuk kembali ke RME secara valid, lengkap, dan tepat waktu untuk diajukan sebagai klaim JKN.


Apa yang Berubah Sejak Klaim JKN Bersandar pada Data RME

Surat Edaran Bersama (SEB) yang ditandatangani Kementerian Kesehatan, BPJS Kesehatan, Kementerian Dalam Negeri, KPK, dan BSSN pada 30 Juli 2026 mempercepat implementasi RME terintegrasi SATUSEHAT sebagai dokumen elektronik pendukung pengelolaan klaim JKN. Agustus 2026 ditetapkan sebagai masa transisi dan uji coba, mendorong RS mitra berpindah dari klaim berbasis berkas pindaian ke klaim berbasis data RME — dengan target pemberlakuan penuh pada 2027 jika evaluasi nasional mendukung.

Per Mei 2026, Kementerian Kesehatan melaporkan 2.400 RS telah mengirimkan data untuk enam layanan RME ke SATUSEHAT (Kemenkes, 30 Juli 2026) — menunjukkan arah kebijakan ini sudah berjalan luas, bukan sekadar wacana. Bagi Direktur RS yang RS-nya sudah mengirim data tersebut, hal yang relevan untuk dipikirkan bukan lagi "apakah kami harus ikut", tapi "apa yang terjadi pada klaim kami kalau sistem ini mati di tengah jalan".


Kenapa Downtime SIMRS Sekarang Berarti Berhenti Mengajukan Klaim

Pada model lama, downtime SIMRS adalah masalah operasional: dokter menulis manual, perawat mencatat di kertas, dan proses administrasi klaim menyusul belakangan begitu berkas pindaian tersedia. Kerugian utamanya adalah waktu dan tenaga kerja ulang, tapi pintu pengajuan klaim tetap terbuka asal berkas fisik lengkap.

Pada model yang didorong SEB RME-SATUSEHAT, pintu pengajuan klaim itu sendiri bersandar pada keberadaan data elektronik. Episode pelayanan yang terjadi selama sistem mati tidak otomatis punya dokumen elektronik sumber klaim begitu sistem kembali — data itu harus dimasukkan ulang secara terstruktur ke RME sebelum bisa disertakan dalam pengajuan klaim. Semakin lama downtime berlangsung tanpa prosedur rekonstruksi yang jelas, semakin besar volume episode yang menumpuk di luar sistem, dan semakin besar risiko keterlambatan pengajuan klaim untuk periode tersebut.

Ini mengubah sifat risiko downtime di mata direksi: dari risiko pelayanan dan kepatuhan menjadi risiko langsung terhadap arus pendapatan RS dari peserta JKN — populasi pasien yang bagi banyak RS adalah porsi terbesar dari total kunjungan.


Demo Gratis 30 Menit
Satu rekam medis,
satu jalur data
RME dan SIMRS MedMinutes berbagi satu sumber data, sampai ke pelaporan mutu dan integrasi SatuSehat.
Jadwalkan Demo→
Tanpa biaya, tanpa kewajiban

Prosedur Kontinjensi: dari Formulir Kertas ke Rekonstruksi Data Elektronik

Prosedur downtime yang hanya berhenti di "catat manual, lanjutkan pelayanan" tidak lagi cukup. Empat elemen berikut perlu ditambahkan pada prosedur kontinjensi yang sudah ada:

Titik rekonstruksi data yang jelas. Tentukan siapa yang bertanggung jawab memindahkan catatan manual ke RME begitu sistem kembali — bukan "nanti diselesaikan tim koding", tapi peran dan tenggat yang eksplisit per unit pelayanan.

Urutan prioritas entri ulang. Episode dengan nilai klaim besar atau mendekati batas waktu pengajuan BPJS Kesehatan dientri lebih dulu, bukan berdasarkan urutan kedatangan berkas fisik ke meja administrasi.

Jejak waktu yang konsisten dengan kejadian sebenarnya. Data yang direkonstruksi harus mencatat waktu pelayanan yang sebenarnya terjadi, bukan waktu entri ulang — inkonsistensi semacam ini yang paling sering memicu catatan verifikator saat klaim diajukan.

Evaluasi pasca-insiden yang mengukur backlog klaim, bukan hanya durasi downtime. Lama sistem mati adalah metrik teknis; jumlah episode yang butuh rekonstruksi dan berapa hari tambahan yang dibutuhkan untuk menuntaskannya adalah metrik yang relevan bagi Wadir Keuangan.

Standar Akreditasi Rumah Sakit (STARKES) sudah mewajibkan RS memiliki SPO tertulis untuk downtime terencana dan tidak terencana sebagai elemen penilaian Bab MRMIK — dasar ini bisa diperluas untuk mencakup langkah rekonstruksi data klaim, bukan membuat prosedur baru dari nol.

Kepemilikan proses ini juga perlu dipertegas. Selama ini, SPO downtime lazim "dimiliki" oleh unit IT karena sifatnya teknis, sementara dampaknya terhadap klaim ada di ranah casemix dan keuangan. Begitu rekonstruksi data menjadi penentu apakah klaim bisa diajukan tepat waktu, keterlibatan tim casemix sejak fase rekonstruksi — bukan baru masuk setelah data lengkap — mempersingkat jarak antara sistem pulih dan klaim siap diajukan.


Dampak Arus Kas: Downtime yang Tidak Terlihat di Laporan Pelayanan

Laporan pelayanan harian biasanya hanya mencatat apakah pasien terlayani atau tidak selama downtime — dan jawabannya hampir selalu "ya, dengan prosedur manual". Yang tidak muncul di laporan itu adalah berapa episode yang data elektroniknya belum lengkap, dan berapa lama klaim untuk episode tersebut akan tertunda dibanding siklus normal.

Bagi Wadir Keuangan, inilah titik buta yang perlu ditutup. Downtime dua hari yang "berhasil ditangani" dari sisi pelayanan bisa tetap menggeser puluhan hingga ratusan klaim ke periode pengajuan berikutnya kalau rekonstruksi data tidak diselesaikan cepat — menambah tumpukan pending yang sumbernya bukan kesalahan koding atau kelengkapan berkas biasa, melainkan gangguan sistem yang jejaknya mudah terlupakan begitu layanan kembali normal.

Masalah ini juga mudah lolos dari radar laporan bulanan karena sifatnya musiman — downtime tidak terjadi setiap bulan, sehingga dampaknya tidak otomatis muncul sebagai pola berulang di laporan pending klaim rutin. Tanpa catatan khusus yang menandai "pending akibat gangguan sistem tanggal sekian", episode-episode ini akan bercampur dengan penyebab pending lain yang sudah lebih dikenal, dan evaluasi akar masalahnya ikut kabur.


Peran Direksi: Menyiapkan Kontinjensi Sebelum Masa Transisi Berakhir

Dengan masa transisi SEB berjalan sejak Agustus 2026 dan target pemberlakuan penuh pada 2027, RS masih punya jendela waktu untuk menguji prosedur kontinjensi ini sebelum ia benar-benar menjadi satu-satunya jalur klaim. Beberapa langkah yang bisa diambil direksi sekarang:

Downtime akan selalu terjadi — jaringan putus, server bermasalah, migrasi sistem berjalan tidak sesuai rencana. Yang membedakan RS yang siap adalah apakah gangguan itu berhenti menjadi masalah teknis semata, atau ikut menyeret arus pendapatan dari klaim JKN yang seharusnya bisa diselamatkan dengan prosedur yang sudah dipikirkan lebih dulu.


Dasar Hukum


FAQ

Apakah downtime SIMRS membuat RS tidak bisa mengajukan klaim JKN?

Sejak klaim JKN bersandar pada data RME yang terintegrasi SATUSEHAT, downtime SIMRS yang berkepanjangan membuat RS tidak bisa menghasilkan dokumen elektronik sumber klaim untuk episode pelayanan yang terjadi selama gangguan — bukan hanya pelayanan pasien yang tertunda, tapi juga arus pendapatan dari klaim periode tersebut.

Berapa lama RS bisa menunda pengiriman klaim JKN tanpa dampak arus kas yang berarti?

Tidak ada angka baku yang berlaku untuk semua RS karena bergantung pada volume klaim harian dan siklus pembayaran BPJS Kesehatan yang sudah berjalan. Yang pasti, setiap hari downtime menambah tumpukan episode yang data elektroniknya belum lengkap, sehingga semakin lama gangguan berlangsung tanpa prosedur rekonstruksi, semakin besar backlog klaim yang harus dikejar setelah sistem kembali normal.

Apa beda prosedur kontinjensi downtime sebelum dan sesudah SEB RME-SATUSEHAT?

Sebelumnya, formulir kertas sebagai pengganti sementara cukup menjamin pelayanan pasien tetap jalan — berkas pindaian masih bisa dilampirkan belakangan untuk klaim. Setelah klaim bersumber dari data RME terintegrasi SATUSEHAT, formulir kertas itu harus direkonstruksi kembali menjadi data elektronik yang valid sebelum klaim bisa diajukan, sehingga prosedur kontinjensi wajib mencakup langkah entri ulang terstruktur, bukan sekadar penyimpanan arsip fisik.

Kapan kebijakan No RME, No Claim berlaku penuh untuk klaim JKN?

Surat Edaran Bersama lima lembaga yang ditandatangani 30 Juli 2026 menetapkan Agustus 2026 sebagai masa transisi dan uji coba, dengan target pemberlakuan penuh pada 2027 jika evaluasi nasional terhadap kesiapan RME-SATUSEHAT di seluruh RS mendukungnya.


Sumber

Share
Konsultasi Gratis
Frustrasi dengan vendor
SIMRS Anda?
Ceritakan situasi RS Anda. Dalam demo 30 menit, kami tunjukkan berapa yang bisa dihemat — langsung dari data klaim Anda.
Chat via WhatsApp→
Jawab < 1 jam di jam kerja

Dipercaya 60+ rumah sakit di 10+ provinsi

RSUP Dr. Hasan SadikinRSUP Dr. Hasan Sadikin
RS Univ. AndalasRS Univ. Andalas
RSD WongsonegoroRSD Wongsonegoro
RS Bethesda YogyakartaRS Bethesda Yogyakarta
RS SMC TelogorejoRS SMC Telogorejo
RST Bhakti Wira TamtamaRST Bhakti Wira Tamtama
LADOKGI RE MartadinataLADOKGI RE Martadinata
RS Islam Jemursari SurabayaRS Islam Jemursari Surabaya
RS Islam Arafah JambiRS Islam Arafah Jambi
RS Roemani MuhammadiyahRS Roemani Muhammadiyah
RS Panti Wilasa Dr. CiptoRS Panti Wilasa Dr. Cipto
RSD Idaman BanjarbaruRSD Idaman Banjarbaru
RSUP Dr. Hasan Sadikin
RS Univ. Andalas
RSD Wongsonegoro
RS Bethesda Yogyakarta
RS SMC Telogorejo
RST Bhakti Wira Tamtama
LADOKGI RE Martadinata
RS Islam Jemursari Surabaya
RS Islam Arafah Jambi
RS Roemani Muhammadiyah
RS Panti Wilasa Dr. Cipto
RSD Idaman Banjarbaru